© Iconic Bestiary/Shutterstock.com
Lösungsansätze für einen Erfolg versprechenden Entwicklungsprozess

Scrum und die technische Schuldfrage


Agile Softwareentwicklung hat sich durchgesetzt. Die tief gehende Erkenntnis, dass iterative Softwareentwicklung sowohl Firmen- und Endkunden als auch Systemherstellern und Internetagenturen einen entscheidenden Wettbewerbsvorteil bietet, ist in der Branche angekommen. In Deutschland hat sich dabei Scrum als eines der führenden Prozessmodelle etabliert. In diesem Artikel möchten wir verschiedene Facetten von Scrum und technischer Schuld betrachten, jeweils im Kontext eines Softwareherstellers und einer E-Commerce-Agentur. Dabei wollen wir auch die Frage auflösen, wie mit technischer Schuld umzugehen ist.

Scrum ist ein einfacher und guter Prozess, um Softwareentwicklung zu verwalten. Kurzfristige Ziele werden der langfristigen Planung vorgezogen. Der Hauptvorteil besteht darin, dass agile Teams schneller auf Kundenwünsche reagieren können und gleichzeitig die Sicherheit eines soliden Plans und eines konkreten kurzfristigen Ziels haben. In einem Buch über Scrum beschrieb einer der Erfinder, Jeff Sutherland, die vielfältigen Vorteile dieses Prozesses. Er hob dabei hervor, dass man diese Methode nicht nur für Softwareentwicklung einsetzen könne, sondern zum Beispiel auch bei einer Kirchengruppe, beim Hausbau oder für die Selbstverwaltung. Das ist zunächst einmal verwirrend, da es doch bedeutet, dass Scrum nicht nur speziell für die Softwareentwicklung geeignet ist, obwohl es doch eigentlich genau für diesen Zweck eingeführt wurde. Tatsächlich bietet sich jedoch für viele unterschiedliche Branchen ein iterativer Entwicklungsprozess an. Scrum beschreibt im Kern vor allem einen Produktentwicklungs- und Pflegeprozess. Dieser eignet sich für die IT, aber eben auch für andere Gebiete.

Scrum implementiert Qualitätsziele nur über die sogenannte Definition of Done (DoD). Dabei handelt es sich nicht um konkrete Vorgaben, sondern einen Vertrag, der durch die Mitwirkenden für den Entwicklungsprozess definiert wird. Die DoD legt fest, unter welchen Kriterien ein einzelner Vorgang als erledigt gilt. An dieser Stelle entsteht das Hauptproblem mit Scrum in der Softwareentwicklung. Möchte man ein Medikament entwickeln, muss man durch eine Zulassungsstelle, möchte man ein Haus bauen, muss man die Pläne von der Behörde abnehmen lassen, doch möchte man eine Software veröffentlichen, scheint es keine Kontrollstelle zu geben.

Industrieweit vereinbarte und gehaltene Standards existieren in diesem Bereich nicht. In der Praxis gibt es daher Teams, die sich hohe Qualitätsstandards setzen und daran halten, und andere Teams, die ihr Hauptaugenmerk auf andere Punkte legen. Es ist bestimmt für jeden leicht vorstellbar, dass ein Team eine teilweise sehr strenge DoD für die UX-Elemente hat, aber dafür jede festgelegte technische Konvention schnell über Bord wirft, einfach nur, weil es dadurch auf kurze Sicht schnell vorankommt. Die DoD als Gefäß für unumstößliche Qualitätsstandards muss eben auch von Entwicklern gefüllt werden.

Technische Schuld

Auf Ward Cunningham geht der Begriff der „technischen Schulden“ (Technical Debt) zurück: „Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation, object-oriented or otherwise.“

Cunningham vergleicht schlechten Quellcode mit einer Art von Hypothek, für die natürlich auch Zinsen fällig werden. Es kann durchaus sinnvoll oder gar notwendig sein, eine Hypothek aufzunehmen, wenn dadurch das Produkt schneller vermarktungsfähig ist. Findet aber keine Tilgung der Hypothek statt, z. B. durch die Refaktorierung der Codebasis, dann entstehen langfristig erhebliche Kosten für die anfallenden Zinszahlungen. Es gibt darüber hinaus verschiedene Ausprägungen von technischer Schuld. Sehen wir uns im Folgenden zwei der extremeren Ausprägungen an.

Technische Schulden als Abkürzung

Man mag diese Art, Schulden zu produzieren, sogar mit Innovation verwechseln. Ein wie auch immer geartetes Softwaresystem setzt sich aus Konventionen zusammen. Mal gibt es Controller-Klassen, die einzelne Aktionen des Benutzers abarbeiten und kapseln. Mal gibt es Repositories für den Datenbankzugriff. Für gewöhnlich vereinbaren Teams, gleichartige Probleme auch auf gleichartige Weise zu lösen. Technische Schuld ist nun gegeben, wenn Elemente des Systems teilweise dieser Vereinbarung widersprechen. Wenn man zu lange alles e...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang