Die Dokumentation fällt in vielen IT-Projekten dadurch auf, dass sie nur unzureichend vorhanden ist. Insbesondere in agilen Projekten wird gern auf einen Absatz aus dem Agilen Manifest verwiesen:

Working software over comprehensive documentation.

agilemanifesto.org

Heißt das, wir brauchen gar nichts zu dokumentieren, solange unsere Anwendung funktioniert?

Nein, wenn man genau hinschaut, sieht man, dass dort nicht steht, man solle nichts dokumentieren. Gemeint ist viel mehr, dass man nicht unbedingt umfangreiche Doku verfassen muss, wenn man funktionierenden Code hat. Der Aufwand, den man in die Dokumentation steckt, muss dem Nutzen angemessen sein.

Außerdem drückt sich das Agile Manifest hier etwas vor dem Henne-Ei-Problem: Aufgrund welcher Vorgaben soll ich denn meinen funktionierenden Code erstellen? Als seriöser Entwickler kann ich mich ja nicht auf Basis von mündlichen Überlieferungen des Auftraggebers an die Arbeit machen. Ich brauche irgendwas Handfestes, Schriftliches, mit dem ich anfangen kann, meine Anwendung zu bauen.

Es gibt in jedem Projekt auch Wissen, das man nicht in Form von Programmcode konservieren kann. Zu dieser Erkenntnis sollte man schon deswegen gelangen, weil Dokumentation stets in einer Zielgruppen-kompatiblen Form vorliegen sollte und nicht jedes Projektmitglied zwangsläufig Programmcode lesen kann.

Dokumentation soll dazu beitragen, dass alle Beteiligten ein gemeinsames Verständnis vom Projektziel und vom Weg dorthin bekommen.

Auch in einem agilen Projekt wird man nicht darum herumkommen, dafür Informationen in menschlich lesbarer Form aufzuschreiben. Das Mittel dar Wahl ist dafür meist ein Wiki, auf das jeder Beteiligte Zugriff hat.

Was wird dokumentiert?

Zunächst natürlich die User-Stories. Muss hier bis in kleinste Detail ausformuliert werden? Nicht zwangsläufig. Die Mindestanforderung ist natürlich, dass das Team versteht, was der Product Owner haben möchte. Weitere, im Prozess des Story-Tellings gewonnene Erkenntnisse sollten ebenfalls schriftlich festgehalten werden.

Architekten und Entwickler werden im Verlauf der Implementierung einige kritische Entscheidungen treffen und diese im Wiki dokumentieren. Gab es mehrere Alternativen, von denen einige verworfen wurden, sollte auch dieser Entscheidungsprozess nachvollziehbar aufgeschrieben werden.

Überhaupt sollten wichtige Entscheidungen immer schriftlich dokumentiert werden. Schon allein, um langwierige Diskussionen zu Entscheidungsfindungen nicht mehrfach führen zu müssen.

Wird die erstellte Anwendung noch durch externe Tester geprüft, sind diese ebenfalls auf eine vorhandene Dokumentation angewiesen, um auf deren Basis Testfälle formulieren zu können.

Eine Kulturfrage

In agilen Projekten, die nach Scrum oder einem vergleichbaren Vorgehensmodell geführt werden, sind alle Team-Mitglieder gleichermaßen für den Projekterfolg und die Qualitätssicherung verantwortlich. Dazu gehört, wie gerade dargelegt, auch die Dokumentation.

Diese entsteht leider nicht von selbst und nicht jedes Team-Mitglied wird mit großer Freude drauflosschreiben. Insbesondere wenn Budget und Zeit gegen Ende einer Iteration knapp werden, wird die Schreibbereitschaft allgemein abnehmen.

Dennoch sollten Projektverantwortliche, Scrum-Master und/oder Architekten sicherstellen, dass die notwendige Dokumentation auch trotz widriger Umstände erstellt wird.

Dabei hilft es sehr, wenn sie diese Dokumentationskultur selbst vorleben und sie nicht ausschließlich vom Team einfordern.