Continuous Documentation

Bild: Flickr / Denise Chan - CC BY-SA 2.0

Die üblichen Fehlwahrnehmungen agiler Softwareentwicklung sind vermutlich nie wieder so prägnant zusammengefasst worden wie vor zehn Jahren in einem einzigen Dilbert-Comic: "We're going to try something called agile programming. It means no more planning and no more documentation. Just start writing code and complaining." Legendär. Warum das Klischee der fehlenden Planung ein falsches ist steht bereits an anderer Stelle aufgeschrieben, jetzt zum zweiten, der angeblich fehlenden Dokumentation.

Eines vorweg: nicht jede Dokumentation ist sinnvoll. Viel zu häufig wird nur aus Prinzip dokumentiert, "weil es so vorgeschrieben ist". Es gibt Datengräber in denen in absurder Detailtiefe sinnloseste Informationen angehäuft wurden, wie etwa sämtliche Business Use Cases und Backend-Workflows von Komponenten die bereits vor Jahren ausgebaut wurden. Es gibt aber auch Dokumentationen die Sinn machen, etwa um gesetzliche Regulierungen zu erfüllen oder um komplexe Funktionen zu erklären. Wie geht man damit um?

Zunächst: anders als in den meisten klassischen Vorgehen. Einen Schockmoment erleben zum Beispiel viele Business Analysten wenn sie erfahren müssen, dass die Anforderungen nicht auch als Dokumentation benutzbar sind. Da jede spätere Anforderung die Ergebnisse jeder früheren überschreiben kann sind sie schon nach kurzem veraltet und unbrauchbar. Auch das Verfassen ganz am Ende ist nicht zu empfehlen, wenn man nicht gerade ein Faible für die Quälerei eines Reverse Engineering hat. Es muss früher und entwicklungsnäher stattfinden wenn es beherrschbar sein soll.

Best practice ist das Erstellen von Dokumentationen als Teil der Anforderungs-Umsetzung. Genau wie zu jeder neuen Funktion das Schreiben eines (automatisierten) Tests gehört kann auch das Schreiben von Anleitungen, Erläuterungen oder sonstigen Informationen dazugehören. Je nach Arbeitsweise lässt sich das sogar in den Akzeptanzkriterien, der Definition of Done o.ä. verankern. Ja, das bedeutet, dass all das permant angepasst werden muss. Continuous Documentation könnte man dazu sagen. Und ja, das ist viel Arbeit. Noch viel mehr Arbeit wäre es allerdings, erst gegen Ende damit zu beginnen. Wie gesagt, Reverse Engineering ist nichts Angenehmes.

Bleibt nur noch eine Frage: wer soll diese Arbeit machen? Die Antwort ist einfach - das Entwicklungsteam. Und bevor jetzt nach Luft geschnappt wird ("Waaaas? Die Entwickler sollen auch Anleitungen schreiben?") gibt es einen kurzen Verweis auf den Scrum Guide, dessen Inhalt sich an dieser Stelle auch auf andere agile Methoden übertragen lässt: "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment." Wenn zum Produkt eine Dokumentation gehört, dann gehört in das Team jemand der sie schreiben kann.