Vordenker der agilen Entwicklung schätzen „funktionierende Software mehr als umfassende Dokumentation“. So steht es im berühmten agilen Manifest. Und da Dokumentieren meist sowieso nicht zu den beliebtesten Tätigkeiten gehört, wird dies gelegentlich so interpretiert, dass man fast vollständig auf Dokumentation verzichtet. Damit hat man das Prinzip der agilen Entwicklung jedoch missverstanden. Denn wenn auch funktionierende Software höher als umfassende Dokumentation geschätzt wird, wird Dokumentation durchaus als wichtig bezeichnet. Was aber an klassischen Vorgehensweisen zurecht kritisiert wird: Dort sind oftmals umfangreiche Dokumente zwingend vorgeschrieben, auch wenn diese im Einzelfall gar keinen nützlichen Zweck erfüllen. Auf Dokumentation, die zum Selbstzweck geworden ist, sollte man wirklich verzichten.
Richtig angewandt kann Dokumentation in agilen Projekten aber sehr wertvoll sein. Denn auch wenn direkte Kommunikation meist besser zum Wissensaustausch geeignet ist als schriftliche Dokumente, so gibt es dennoch Situationen, wo keine direkte Kommunikation möglich ist. Beispielsweise wenn eine größere Zahl von Projektbeteiligten oder Stakeholdern informiert werden soll. Insbesondere gibt es aber Informationen, die über das Projektende hinaus zur Verfügung stehen sollten, z. B. für Betrieb und Wartung des Systems.
Letztlich muss jedes Team selbst entscheiden, wie viel und welche Dokumentation erforderlich ist. Andreas Rüping gibt daher in seinem Buch „Dokumentation in agilen Projekten“ (Anzeige) keine fertige Dokumentationsstruktur vor, die man mehr oder weniger unverändert übernehmen könnte. Insofern sind die vorgestellten Lösungsmuster auch eher Empfehlungen oder Prinzipien zum Aufbau eigener Dokumentationsrichtlinien.
Agile Dokumentation heißt bedarfsgerechte Dokumentation. Wichtigstes Prinzip ist die Orientierung am Leserkreis. Hierzu muss man sich im Klaren sein, wer die Leser sein werden und welche Informationen sie benötigen. Um die Dokumentation möglichst unkompliziert erstellen zu können sollten möglichst wenige, allgemein verstandene Tools eingesetzt werden, beispielsweise ein Projekt-Wiki.
Planung und Erstellung der Dokumentation werden wie andere Aufgaben im agilen Projekt behandelt. So wird beispielsweise mit dem Kunden besprochen, welche Art von Produktdokumentation benötigt wird. User Stories können als Akzeptanzkriterien beinhalten, dass sie geeignet dokumentiert sind. Übergreifende Dokumentationsaufgaben, wie z. B. ein Architekturdokument, können ggf. als eigene Stories geplant werden. Eine inkrementelle Dokumenterstellung stellt einerseits sicher, dass rechtzeitig dokumentiert wird, andererseits aber keine Inhalte erstellt werden, die nach kurzer Zeit schon wieder überholt sind. Dabei können die Zeiträume, nach denen ein weiteres Dokumentations-Inkrement erstellt wird, mehrere Sprints umfassen.
Weitere Empfehlungen betreffen u. a. die Auswahl der geeigneten Inhalte, die Verständlichkeit und Gestaltung von Dokumenten sowie die Verteilung und Ablage der Dokumentation. Nicht zuletzt sollte sie im Sinne eines aktiven Wissensmanagements zur Weitergabe von Erfahrungen genutzt werden. Eine übersichtliche Kurzfassung der vorgestellten Muster, ein Portfolio möglicher Dokumente und ein Glossar schließen das Buch ab.
Wer sich fertige Rezepte erhofft hat, wie man in einem agilen Projekt dokumentieren sollte, wird möglicherweise enttäuscht sein. Wer aber nützliche Empfehlungen und Hilfestellungen sucht, um selbst einen individuell passenden Dokumentationsansatz zu entwickeln, wird hier fündig.
Andreas Rüping:
Dokumentation in agilen Projekten.
Lösungsmuster für ein bedarfsgerechtes Vorgehen.
dpunkt 2013
Das Buch bei amazon (Anzeige)