Nicht nur weil Kommunikation wichtiger als Dokumentation ist, gerät Letztere oft in Vergessenheit oder wird kurz vor knapp noch irgendwie umgesetzt. Obwohl allen Beteiligten klar ist, dass Dokumentation notwendig ist, werden sie am Ende des Sprints davon überrascht. Wie schafft man es also, den Akt des Dokumentierens einzuplanen?
Die Antwort ist in der Frage schon enthalten, denn es muss im Planning aufgenommen und diskutiert werden. Das Team muss einplanen, dass Zeit und auch die notwendige Expertise im Team vorhanden ist. Dazu kann sich das Team folgenden Fragen stellen:
- Was sollte dokumentiert werden? Was ist kurzfristig notwendig und langfristig noch relevant?
- Welcher Aufwand ist gerechtfertigt?
- Gibt es jemanden im Team, der das notwendige Hintergrundwissen hat?
- Wie ist die Priorität?
All diese Fragen müssen vom Team (und nicht dem Productowner) beantwortet werden, denn das Team ist für die Umsetzung von Software verantwortlich. Hierzu zählt auch deren Dokumentation. Die Antworten sind wie immer von Team zu Team unterschiedlich.
Wie und ob die Fragen ausreichend beantwortet werden, unterscheidet sich auch von der gewählten Dokumentations-Methode. Hierzu gibt es verschiedene Varianten.
- Die Definition of Done kann dazu genutzt werden, dass zu jedem Programmier-Task „ausreichend dokumentiert“ wird. Was ausreichend heißt, entscheidet in dieser Variante oftmals der Entwickler alleine, der Dokumentation als notwendiges Übel betrachtet und eher technisch als fachlich dokumentiert.
- Dokumentation kann auch als gleichwertiger Task zu jeder Story aufgenommen werden. Der Task ist somit fester Bestandteil des Sprintboards, auf das in jedem Daily geschaut wird. Die Dokumentation kann so nicht vergessen werden. Zwar macht Dokumentation nicht bei jeder User Story Sinn, doch so kann das Team entscheiden, was relevant ist.
- Eine noch sichtbarere Variante ist es, eine eigene Dokumentations-Story zu schreiben. So kann sichergestellt werden, dass mehrere zusammenhängende Stories oder ganze Epics gemeinsam dokumentiert werden können. Man kann das große Ganze betrachten und mit etwas Abstand vielleicht besser bewerten, was langfristig erwähnenswert bleibt. Außerdem fördert eine solche Story mit mehrere Taks das gemeinsame Arbeiten an der Dokumentation. Die Gefahr in dieser Methode besteht darin, dass nicht fachlich motivierte Stories im Backlog unterpriorisiert werden und man dann zu gegebener Zeit nicht mehr gedanklich im Thema ist, so dass wichtige Aspekte vergessen werden könnten.
Ich persönlich fahre gut mit der zweiten Variante. Oft ist es so, dass im Team dann auch entschieden wird, dass zu einer bestimmten Story keine gesonderte Dokumentation notwendig ist und der Task wird unbearbeitet auf „done“ geschoben. Wie man damit umgeht, dass man mit der zweiten Variante im Vergleich zur dritten die Dokumentation immer wieder anpassen und neu schreiben muss, schaue ich mir in einem der nächsten Beiträge an.
Referenzen:
- Dokumentation in agilen Projekten – Andreas Rüping
Agile Dokumentation 