Beides zusammen kann ausreichend Druck erzeugen, dass die Entwickler in den Zug einsteigen, der direkt in die Hölle fährt: Sie opfern Qualität, um den geplanten Sprintinhalt zum Sprintende zu schaffen. Sie gehen eine technische Schuld ein (Technical Debt), die ihnen später sehr schmerzhaft auf die eigenen Füße fällt - in Form einer steilen Aufwandskurve.
Dabei ist das erste Problem aus meiner Sicht gar nicht, dass man die technische Schuld eingegangen ist. Das erste Problem ist, dass das implizit passiert. Die Entwickler machen sich beim Programmieren geistige Tasks in der Art "Hier müsste man noch mal das Refactoring XYZ durchführen.", "Hier müssten noch die Tests nachgeschrieben werden." etc.
Diese Tasks gehören nicht in den "Hinterkopf". Diese Aufräum-Tasks gehören explizit und für alle sichtbar ins Sprint-Backlog (und damit auf das Taskboard). Damit hat man nicht nur die Merker, was man noch erledigen muss. Es wird auch sofort klar, dass man das Sprint-Commitment trotzdem NICHT erreicht hat. Man hat nur die übrig gebliebenen Tasks getauscht. Es sind keine fachlichen Features mehr offen, sondern technische Aufräumarbeiten.
Dieser Fakt ist erstmal zu akzeptieren und in der Sprint-Retrospektive zu beleuchten. Warum konnten wir unser Commitment nicht halten und wie machen wir es nächstes Mal besser? Und dann sollte man sich auch gleich noch die Frage stellen: Warum haben wir Qualität geopfert anstatt Funktionalität zu reduzieren und ist das Opfern der Qualität wirklich der bessere Weg?
Post bewerten
Atom.xml
2 Kommentare:
Stefan, ich finde deine Position problematisch, wenn man an Legacy-Code arbeitet. Schriebe ich alle Aufräum-Tasks auf, die ich bei uns täglich sehe, würde ich jeden Tag einen neuen Sprint erzeugen. Schlimmer noch: da wir es nicht schaffen, die leicht sichtbaren Probleme zu lösen, finden wir auch nie radikal einfachere Designs. Daher meine Hypothese: Enthält die Code-Basis erst einmal in großem Umfang Legacy-Code, kann man nur noch Nachlassverwaltung betreiben, solange das primäre Entwicklungsziel funktional ist.
Hallo Alex,
ja, der liebe Legacy-Code. Ich meinte zunächst gar nicht die Defizite im Code, die vorgefunden wurden, sondern dien die noch dazu geschrieben wurden.
Wenn man viel Legacy-Code hat, kriegt man den aus meiner Erfahrung während des Projektgeschäftes kaum repariert. Die Refactorings, die man nebenbei erledigen kann, beschränken sich auf Kleinigkeiten und bringen dann zuwenig. Ich würde bei Legacy-Code einen eigenen Plan ausarbeiten und ein eigenes Projekt draus machen wollen.
Ich glaube aber gleichzeitig, dass der Aufwand für die erste Grobreinigung gar nicht so groß sein muss. Ich würde mich nämlich im ersten Schritt darauf beschränken, klar abgegrenzte Module/Komponenten mit expliziten APIs zu definieren und den Code entsprechend zu ordnen. Innerhalb der einzelnen Modulen/Komponenten kann man dann das Chaos besser handhaben und schrittweise beseitigen.
Kommentar veröffentlichen