Fast Beats Right
Ok, ok, manchmal muss es wirklich schnell gehen. Ein unverschiebbarer Release-Termin, der kleine Marktvorsprung vor der Konkurrenz, Gesetzesänderungen mit einem harten Termin, all dies sind Gründe, die dafür sprechen, mal fünfe gerade sein zu lassen und schnell etwas eigentlich Halbfertiges auf den Markt zu werfen.
Time-to-Market ist heutzutage entscheidend, sagt man. Aber wie weit darf man dabei gehen?
Allgemein bekannt sollte inzwischen sein, dass 80% der Kosten für ein Stück Software in der Maintenance anfallen und nicht in der Ersterstellung (siehe u.a. http://www.oracle.com/technetwork/java/codeconventions-139411.html). Jede Ausrede in die Richtung „Es reicht, wenn ich meinen Code verstehe“ (siehe Anti-Pattern Superheld) ist damit absolut hinfällig, da die Maintenance in aller Regel nicht von den gleichen Personen übernommen wird wie die initiale Programmierung. Eine saubere Entwicklung mit ständigem Refactoring ist dabei Pflicht.
Mir gefällt an der Stelle der Gedankengang von Ward Cunningham, der den Begriff „technische Schulden“ (technical debt) geprägt hat. Bei seinem damaligen Engagement im Projekt WyCash (einer Finanzsoftware und übrigens dem ersten vollständigen XP-Projekt überhaupt) musste er seinem Chef erklären, wofür man Refactoring überhaupt braucht. Um im Finanzbild zu bleiben, hat er erklärt (frei übersetzt) :
- Das Auslassen der Entwurfsphase ist wie das Leihen von Geld
- Refactoring ist wie die Rückzahlung des Kredits
- Langsamere Entwicklungsgeschwindigkeit aufgrund hoher Komplexität ist wie das Zahlen von Zinsen
- Wenn das ganze Projekt unter dem Schlamassel zusammenbricht, ist das, als würden die bösen Jungs vorbeikommen und deine Hände mit der Autotür zerquetschen, weil du deine Raten nicht bezahlt hast
In der Tat kann man in schlechten agilen Projekten häufig sehen, dass die Velocity Sprint für Sprint abnimmt. Die übliche Begründung dafür ist dann in der Regel, dass die Software insgesamt inzwischen so komplex geworden ist, dass neue Features eben mehr Zeit kosten als am Anfang des Projekts. Nach einer Weile wird dieser Effekt dann so groß, dass ein „Refactoring-Sprint“ eingebaut werden muss, um überhaupt noch Fortschritt zu erzielen. Dies ist natürlich nur ein Symptom, die eigentliche Krankheit liegt woanders.
Missing Definition of Done
Im Kalendereintrag „Zugabe“ sind wir bereits ausführlich auf die Definition of Done eingegangen. Hier wollen wir nur noch einmal verdeutlichen, welchen Effekt es haben kann, wenn sie nicht eingehalten wird:
Wird die Definition of Done dauerhaft korrekt eingehalten, ist die Velocity (Anzahl Features je Zeiteinheit) konstant, die Summe der Features steigt also linear (grüne Linie). Wenn das Team Teile der Definition of Done nicht einhält, steigt die Geschwindigkeit zunächst, da ja weniger Tätigkeiten ausgeführt werden müssen. Mit der Zeit allerdings wird die Geschwindigkeit immer langsamer, da der Code immer unsauberer wird und Änderungen dadurch erschwert werden (rote Linie). Dies kann soweit führen, dass die Geschwindigkeit gegen Null geht, bis dann tatsächlich nur eine groß angelegte Refactoring-Offensive wieder Leben in das Projekt hauchen kann. Die Differenz zwischen den Linien (gelber Bereich) ist dann die technische Schuld, die wir uns aufgeladen haben und leider irgendwann zurückzahlen müssen.
Anmerkung für Pfennigfuchser: streng genommen ist schon der erste Bereich, in dem die rote Linie die größere Steigung hat, ein Vorsprung, der nur auf Pump zustande gekommen ist und zu den technischen Schulden beiträgt.
Fazit
Ein Projekt, in dem eigentlich einfache Änderungen überproportional lange dauern und deren Velocity ständig abnimmt, ist schon tief in den roten Zahlen, um im Finanzbild zu bleiben. Dabei kann es so einfach sein: die saubere Erfüllung einer guten, sinnvollen und ständig hinterfragten Definition of Done ist der Schlüssel zu erfolgreicher Softwareentwicklung. Wer auch nach Monaten im Projekt kleine Features schnell umsetzen will, muss von Anfang an in Qualität investieren. Klingt einfach? Ist einfach! Und die Nachwelt (aka Maintenance-Team) wird es einem danken!
