"Ich schreib da mal ein Ticket"

Zu den Sätzen, die vermutlich alle Entwicklerinnen und Entwickler, die in einem agilen Umfeld arbeiten, schon oft gehört (oder auch selbst gesprochen) haben, gehört: "Ich schreib da mal ein Ticket." Dieser Satz wird verwendet, sobald irgendein Bug auffällt, eine Unsauberkeit im Code, ein Problem in der Infrastruktur oder eine unzureichende Testabdeckung im aktuellen Feature. Statt den Fehler zu beheben oder den Code aufzuräumen, wird die Arbeit vertagt, sprich: "in's Backlog verschoben". Das wirkt agil, schließlich gibt die Vertagung zeitliche Ressourcen frei, um sich anderen Feature-Wünschen zu widmen und die Velocity zu erhöhen.

Ich kenne keine genauen Statistiken dazu, wie oft einmal geschriebener Code von anderen Entwicklern im Schnitt gelesen und verstanden werden muss. Die eigene Erfahrung sagt aber, dass wir viel mehr Code lesen als schreiben und auch mehr Zeit damit verbringen, vorhandene Software zu verstehen als neue Features zu implementieren. Es lohnt sich daher, den Code so verständlich wie möglich zu machen, denn beim Verstehen sind die größten zeitlichen Einsparungen möglich. Umso verwunderlicher ist die Haltung, das Aufräumen (Refactoring, Testen etc.) nicht sofort zu machen, sondern in die Zukunft zu verschieben. Bis es wirklich dazu kommt, dass das Aufräum-Ticket aus dem Backlog in den aktuellen Sprint gezogen wird, haben sich mitunter schon mehrere Entwickler um ein Verständnis des halbfertigen Ergebnisses bemühen müssen.

Jede kurzfristig gesparte Minute kann sich rächen, insbesondere durch den Verlust von Flexibilität. Wer auf neue Feature-Wünsche reagieren und die Velocity dauerhaft hochhalten möchte, braucht nichts mehr als sauberen, aufgeräumten und getesteten Code und eine stringente Architektur. Das geht aber nur, wenn Clean Code und Refactoring zum Abschluss eines Features selbstverständlich dazugehören.

Plausibel wirkt das beschrieben Vorgehen vielleicht auch nur auf diejenigen, die selbst keinen Code schreiben, also auf Produktmanager, Product Owner, Scrum Master etc. Sie sehen in diesem Fall nur die streng funktionalen Anforderungen und verlieren nicht-funktionale Qualitätsmerkmale wie Wartbarkeit, Robustheit, Verständlichkeit und Analysierbarkeit aus den Augen.

Für viele Entwickler ist aus den genannten Gründen klar, dass immer jetzt der beste Zeitpunkt zum Aufräumen ist. Für alle anderen möchte ich einen Vergleich anbieten: Man stelle sich vor, ein Handwerker verzichte nach getaner Arbeit darauf, seine Werkzeuge und die Werkstatt aufzuräumen, und schriebe stattdessen ein Ticket, um das Aufräumen bei Gelegenheit nachzuholen; oder in der Buchhaltung würden die Belege nicht zeitnah in entsprechende Ordner einsortiert, sondern erstmal auf anwachsenden Stapeln gelagert, bis im nächsten Frühjahr wirklich die Unterlagen für die Steuer fertig gemacht werden. Das mag mancher privat so machen, in einem professionellen Umfeld ist das aber undenkbar. Und genauso verhält es sich mit der Entwicklung von Software: Ein privates Hobbyprojekt mag unaufgeräumt bleiben (was ich dennoch nicht emfehle, ebensowenig wie der ungeordnete Stapel für die Steuerunterlagen). Soll Software professionell entwickelt werden, verbietet sich das.