In bestehenden Projekten ist der Code oft schlecht strukturiert. Symptomatisch ist, dass kleine Änderungen ganze Kaskaden von Bugs nach sich ziehen können, oder es gibt No-Go-Areas, an die sich kaum noch jemand herantraut, weil sie so komplex geworden sind. Der einst so dynamische Projektfortschritt wird immer langsamer, und das Team kann kaum noch vorhersagen, wie lange die nächste “kleine Änderung” brauchen wird.
Diese Entwicklung hat natürlich niemand beabsichtigt, es ist einfach nach und nach immer mühsamer geworden, mit dem vorhandenen Code zu arbeiten. Manchmal fallen in diesem Zusammenhang auch die Stichworte “technische Schulden” (langfristige Nachteile aus kurzfristiger Zeitersparnis) und “Refactoring” (das Umstrukturieren und Vereinfachen des Codes). Dann kommt von Entwicklerseite gern der Stoßseufzer: “Wenn wir nur mal 6 Wochen am Stück Zeit hätten, um hier ein richtiges Refactoring zu machen” (wahlweise: um die technischen Schulden abzubauen). Falls der Vorschlag zur “Aktion 6 Wochen aufräumen” tatsächlich vorgebracht wird, ist die Reaktion vom Management (bzw. vom Business) vorhersehbar: “Was wollt Ihr? 6 Wochen Zeit verbrauchen, in denen kein einziges neues Feature geliefert wird? Wir sind doch jetzt schon weit hinter dem Plan. Und bei Euch dauert es doch sowieso immer länger als Ihr denkt, wer sagt mir denn, dass aus 6 Wochen nicht 10 Wochen werden? Verstehe ich das richtig, Ihr wollt jetzt das aufräumen, was Ihr in den letzten 2 Jahren gebaut habt? Warum habt Ihr es denn nicht gleich richtig gemacht?”. Fazit: Keine Chance.
Ich spare mir an dieser Stelle mal die Ursachenforschung und die Diskussion, inwiefern die Einwände des Managements berechtigt sind.
Klar ist: Schlechter wird’s von ganz allein, besser werden braucht Investitionen. Aber wieviel Investition, woher die Kapazität nehmen, und worauf soll man sich konzentrieren?
Hier ist eine Methode, wie Sie in kleinen Zeitscheiben in die Code-Qualität und damit in schnellere Entwicklung investieren können. Wir stellen dazu eine einfache Regel auf:
Die Ein-Stunden-Regel: Pro Ticket kannst Du eine Stunde in Code-Qualität investieren, entscheide selbst, wie Du sie verwenden willst. Der Code könnte einfacher sein? Automatisierte Tests fehlen? Das README ist nicht mehr aktuell? Egal was es ist, Du hast pro Ticket eine Stunde zur freien Verfügung für Verbesserungen.
Wenn Sie wollen, ist das eine Anwendung der Pfadfinder-Maxime “Leave it a little better than you found it”, und natürlich handelt es sich um Kaizen, die kontinuierliche Verbesserung in kleinen Schritten aus dem Lean Thinking. Neu ist nur die Konkretisierung auf eine Stunde pro Ticket.
Diese einfache Regel behandelt einige häufig von Entwicklern vorgebrachte Einwände gegen Verbesserungen:
Ich habe nie die Zeit dafür. Eine Stunde ist lang genug, um sich eine substanzielle Verbesserung vorzunehmen, fällt aber nicht allzu sehr in’s Gewicht. Mit der Ein-Stunden-Regel geben wir explizit die Erlaubnis, an Verbesserungen zu arbeiten, auch wenn das nächste Ticket schon wartet.
Es gäbe soviel zu verbessern, ich weiß nicht, wo ich anfangen soll. Die Verbesserung wird meist das Thema des aktuellen Tickets betreffen. So werden Bereiche bevorzugt, an denen wir sowieso gerade arbeiten, wo uns Verbesserungen also schon kurzfristig nützen können. Und falls die Verbesserung einen neuen Fehler produziert, bemerken wir den hoffentlich beim Testen des Tickets.
Wer weiß, ob sich das lohnt. Unterm Strich werden all diese kleinen Verbesserungen uns viel mehr Zeit einsparen als sie kosten. Statt jedesmal den ROI abzuschätzen, gehen wir lieber viele kleine Wetten ein, mit dem Einsatz von jeweils einer Stunde Arbeitszeit und potenziell großem Gewinn.
Wer weiß, wie lange das dauert. Wenn es doch länger als eine Stunde dauern sollte, kann man es ganz abbrechen. Meist wird aber ein nutzbarer Teilerfolg nach weniger als einer Stunde erzielt. Darauf kann man später im Rahmen eines anderen Tickets aufbauen. Mit der Zeit bekommen auch alle ein besseres Gefühl dafür, was in einer Stunde zu schaffen ist.
Wenn man die Ein-Stunden-Regel eine Weile praktiziert, verbessert das nicht nur die Qualität, sondern auch die Stimmung im Team. Außerdem werden die wirklich wichtigen Probleme nach und nach sichtbar: Wenn die Kleinigkeiten laufend weggeräumt werden, werden schließlich die wirklich großen Hindernisse erkennbar. Die sind dann wichtig genug, um konzentriert und mit mehr Ressourcen angegangen zu werden.
Matthias Berth