In den letzten Blog-Beiträgen haben wir gesehen wann, welche Art, von wem dokumentiert werden muss. Aber wie bekommen wir Qualität in die Dokumentation und ist das überhaupt zwingend notwendig?
Viele sehen Dokumentation als notwendiges Übel an, das man möglichst spät im Prozess angeht. Sonderlich detailliert und qualitativ hochwertig muss sie auch nicht sein, da funktionierende Software ohnehin wertvoller ist. Klar sollte der Fokus auf der Entwicklung von guter Software liegen, aber man kann auch qualitative Dokumentation ohne großen Aufwand verfassen. Alles, was man dafür braucht, bringt das agile Mindset bereits mit.
Im letzten Beitrag haben wir festgestellt, dass es sinnvoll ist, mit jedem Sprint zu dokumentieren, auch wenn sich der Inhalt mitunter über die Zeit grundlegend verändern mag. Zweck ist es, ein MVP der Dokumentation herauszubringen, das bereits Mehrwert stiftet und gereviewt werden kann. Neben der regelmäßigen Sprintreview und Codereviews sollte es nämlich auch Dokumentationsreviews geben.
Diese Art der Reviews gehen weit über Rechtschreibkorrekturen hinaus. Im Review sollte geprüft werden, ob die Dokumentation inhaltlich korrekt ist und den notwendigen Detaillierungsgrad hat. Die Dokumentation muss zur Zielgruppe passen. Am besten holt man sich hier Feedback ein. Der Reviewer kann aber auch aus dem Team kommen. Hier existiert durch die regelmäßigen Retrospektiven eine Kultur des Lernens und ein offener Umgang mit Kritik, was förderlich für effiziente Reviewarbeit ist.
Bestenfalls spiegelt sich das Review in der Definition of Done wider, so dass nicht nur Code, sondern auch die Dokumentation durch ein Vieraugen-Prinzip qualitätsgesichert werden kann. Durch Reviews wird Software bis zu 60% besser, also können sie der Dokumentation auch nur gut tun.
Referenzen:
- Dokumentation in agilen Projekten – Andreas Rüping
- Review (Softwaretest) Wikipedia
Agile Dokumentation 