Wie ich schon berichtet hatte, fand im August die diesjährige Software Craftsmanship and Testing Conference als großer OpenSpace statt. Auf dieser habe ich auch eine Session zur Idee des techn. Schuldenberaters angeboten.
In dieser Session ging es um Aufgaben und Werkzeuge des Schuldenberaters aber auch ein wenig allgemein um technische Schulden. Die Ergebnisse möchte ich hier gern noch aus meinen Aufzeichnungen rekonstruieren.
Zunächst einmal sollte der Schuldenberater die größten Probleme ausfindig machen. Dies wird häufig das “Time to Feature” also die Zeit, welche es benötigt ein Feature wirklich fertig zu stellen, sein.
Im nächsten Schritt wird es häufig nötig sein, erst einmal ein Bewusstsein für die bestehenden Probleme sowohl im Team als auch im Management zu schaffen. Dazu kann er Metriken nutzen wie zum Beispiel die auf sqale.org vorgestellte für Wiedergutmachungskosten von technischen Schulden.
Ist dies geschafft, so ist es an der Zeit zu sehen wie dem Projekt zunächst kurzfristig und dann aber auch langfristig geholfen werden kann. Je nachdem wie es um die Software gestellt ist muss auch die Frage beantwortet werden, ob die angehäuften Schulden noch in Raten, also parallel zur "normalen" Weiterentwicklung zurückgezahlt werden können oder ob die größten Probleme im erst auf einen Schlag behoben werden müssen, bevor es weiter gehen kann.
Zur Behebung der Probleme kann die Pfadfinderregel (Boy Scout Rule) eingesetzt werden. Auch ist ein Collective Code Ownership oft eine gute Idee. Dies kann z.B. durch "Pair Refactoring" gefördert werden. Für größere Baustellen bieten sich immer mal wieder eingeplante Timeboxen an oder diese über individuelle Zielvereinbarungen (welche trotz "agilem" Vorgehen noch all zu oft verbreitet sind) zu beheben.
Ein weiteres Thema im Zusammenhang mit den technischen Schulden war die Dokumentation von Softwareprojekten. Wer kennt es nicht? Auch wenn die Benutzerhandbücher etc. vorhanden sind und oft auch in einem akzeptablen Zustand, ist die Dokumentation für die Entwickler ein graus. Es fängt bei den Quellcodekommentaren an geht weiter zu der nicht vorhandenen oder völlig lückenhaft gepflegten Dokumentation der Entscheidungen im Bereich Architektur, Design etc.
Ja auch dies sind technische Schulden. Eine Idee, welche ist aus dieser Session mitgenommen habe, ist zumindest eine art Logbuch zu führen. Also z.B. in einer Blogsoftware einfach alle aktuellen Entscheidungen "mal eben" in einem Beitrag fest zu halten und am besten noch kurz zu Taggen um sie einfacher wieder zu finden. Eine Teamdiskussion am Whiteboard? Einfach das Foto vom Whiteboard hoch laden und fertig. Dieses vorgehen ist recht schmerzfrei, da ohne viel Aufwand und Gedanken zu Format etc. hilft aber im nachhinein bestimmte Entscheidungen nachzuvollziehen. Und das ist doch das wichtigste an der Dokumentation für die Entwickler. Was hilft da ein toll formatierter, ausformulierter aber lückenhafter Text?
An dieser Stelle noch mal vielen Dank an alle, die sich an der Diskussion beteiligt haben!
Über Ergänzungen und weitere Ideen würde ich mich freuen.
In dieser Session ging es um Aufgaben und Werkzeuge des Schuldenberaters aber auch ein wenig allgemein um technische Schulden. Die Ergebnisse möchte ich hier gern noch aus meinen Aufzeichnungen rekonstruieren.
Zunächst einmal sollte der Schuldenberater die größten Probleme ausfindig machen. Dies wird häufig das “Time to Feature” also die Zeit, welche es benötigt ein Feature wirklich fertig zu stellen, sein.
Im nächsten Schritt wird es häufig nötig sein, erst einmal ein Bewusstsein für die bestehenden Probleme sowohl im Team als auch im Management zu schaffen. Dazu kann er Metriken nutzen wie zum Beispiel die auf sqale.org vorgestellte für Wiedergutmachungskosten von technischen Schulden.
Ist dies geschafft, so ist es an der Zeit zu sehen wie dem Projekt zunächst kurzfristig und dann aber auch langfristig geholfen werden kann. Je nachdem wie es um die Software gestellt ist muss auch die Frage beantwortet werden, ob die angehäuften Schulden noch in Raten, also parallel zur "normalen" Weiterentwicklung zurückgezahlt werden können oder ob die größten Probleme im erst auf einen Schlag behoben werden müssen, bevor es weiter gehen kann.
Zur Behebung der Probleme kann die Pfadfinderregel (Boy Scout Rule) eingesetzt werden. Auch ist ein Collective Code Ownership oft eine gute Idee. Dies kann z.B. durch "Pair Refactoring" gefördert werden. Für größere Baustellen bieten sich immer mal wieder eingeplante Timeboxen an oder diese über individuelle Zielvereinbarungen (welche trotz "agilem" Vorgehen noch all zu oft verbreitet sind) zu beheben.
Ein weiteres Thema im Zusammenhang mit den technischen Schulden war die Dokumentation von Softwareprojekten. Wer kennt es nicht? Auch wenn die Benutzerhandbücher etc. vorhanden sind und oft auch in einem akzeptablen Zustand, ist die Dokumentation für die Entwickler ein graus. Es fängt bei den Quellcodekommentaren an geht weiter zu der nicht vorhandenen oder völlig lückenhaft gepflegten Dokumentation der Entscheidungen im Bereich Architektur, Design etc.
Ja auch dies sind technische Schulden. Eine Idee, welche ist aus dieser Session mitgenommen habe, ist zumindest eine art Logbuch zu führen. Also z.B. in einer Blogsoftware einfach alle aktuellen Entscheidungen "mal eben" in einem Beitrag fest zu halten und am besten noch kurz zu Taggen um sie einfacher wieder zu finden. Eine Teamdiskussion am Whiteboard? Einfach das Foto vom Whiteboard hoch laden und fertig. Dieses vorgehen ist recht schmerzfrei, da ohne viel Aufwand und Gedanken zu Format etc. hilft aber im nachhinein bestimmte Entscheidungen nachzuvollziehen. Und das ist doch das wichtigste an der Dokumentation für die Entwickler. Was hilft da ein toll formatierter, ausformulierter aber lückenhafter Text?
An dieser Stelle noch mal vielen Dank an alle, die sich an der Diskussion beteiligt haben!
Über Ergänzungen und weitere Ideen würde ich mich freuen.
Kommentare
Kommentar veröffentlichen