Technical Debt und das geistige Taskboard

August 12, 2008 at 8:37 pm 2 comments


Entwickler wollen ihren eigenen Ansprüchen genauso gerecht werden wie den Ansprüchen anderer. Daher tun sich viele Scrum-Teams am Anfang schwer, sich einzugestehen, dass sie sich für den Sprint zuviel vorgenommen haben (Over Commitment). Für Product Owner ist es anfänglich ebenso schwer. Schließlich hat man auch als Product Owner seine Ziele und möglicherweise sogar bestimmte Features zu einem festen Zeitpunkt versprochen.
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?

Entry filed under: Uncategorized. Tags: , , .

Können Anwender/Fachexperten modellieren? Sind Aufwandsschätzungen Verschwendung?

2 Comments Add your own

  • 1. Alex  |  September 7, 2008 at 2:38 pm

    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.

  • 2. Stefan Roock  |  September 7, 2008 at 3:28 pm

    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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: