Lean Documentation Teil 1

Das Agile Manifest wird häufig scherzhaft als Argument herangezogen, warum die Dokumentation in Softwareprojekten stiefmütterlich behandelt werden kann. Es geht dabei konkret um die Aussage aus dem Agilen Manifest, dass funktionierende Software mehr geschätzt wird als umfassende Dokumentation. Es wird aber auch gleich in einem Absatz darunter klargestellt, dass die Dokumentation weiter als wichtig erachtet wird.

Zum Glück, denn Dokumentation ist notwendig, damit eine Software effizient erstellt, betrieben, benutzt und weiterentwickelt werden kann.

In den kommenden Artikeln möchte ich das Thema Dokumentation aus der Sicht des Lean Management Grundsatzes „Schaffe Werte ohne Verschwendung“ in einem agilen Umfeld betrachten (auch wenn sich vieles auf klassische Projekte übertragen ließe). Was dieser Grundsatz bezogen auf die Dokumentation bedeutet, könnte generell wie folgt zusammengefasst werden:  Die Dokumentation

• wird tatsächlich von jemandem gebraucht,
• ist zur rechten Zeit verfügbar,
• ist leicht auffindbar, richtig und verständlich und
• ist so kurz wie möglich aber auch nicht kürzer (inkl. Vermeidung von Redundanzen).

Dabei könnte man es auch schon belassen. Die Mehrzahl der Leser sollte diesen Punkten grundsätzlich zustimmen können. Trotzdem möchte ich diese Gedanken weiter vertiefen.

Vergänglichkeit von Dokumentation

Was ist der Unterschied zwischen der Anforderungsdokumentation und dem Anwenderhandbuch?
Es gibt keinen – beide werden nicht gelesen!

Zugegeben, nicht wirklich witzig. Im Sinne des Lean Gedanken (Vermeide Verschwendung) gibt es aber tatsächlich mindestens zwei Unterschiede: die Vergänglichkeit und die Verständlichkeit des Dokumentierten.

Unterschied 2: Während der Entwicklungsphase ist das Projektteam zusammen und kann direkt bei Unklarheiten bezüglich der Anforderungen miteinander kommunizieren. Sprechen hilft! Wenn das Produkt übergeben und in Produktion ist, dann ist das Projektteam in der Regel nicht mehr verfügbar oder längst mit anderen Aufgaben betraut. Deswegen sollte das Anwenderhandbuch so verfasst sein, dass ein Anwender auch Jahre nach der Einführung ohne weitere Hilfe damit klar kommt.

Konkretisieren lässt sich das mit einem Vergleich:

In einem agilen Projekt sind die Anforderungen in der Regel bis zu einem gewissen Zeitpunkt recht vage beschrieben. Mit der Zeit und kurz vor der Umsetzung werden die Anforderungen konkreter. Anforderungen werden vielfach bewusst so verfasst, dass ein gewisser Spielraum für die endgültige Lösung und für Kommunikation mit dem Product Owner vorhanden ist. Der Aufwand für eine zu detaillierte, widerspruchsfreie  Anforderungsbeschreibung wird so reduziert.

Während des Sprints werden die spezifizierten Anforderungen durch direkte Kommunikation zwischen Entwickler und Product Owner weiter geschärft (oder auch mal geändert) und umgesetzt (oder gestrichen). Und daraus resultiert dann ein stabiler Zustand (z. B. eine Funktionalität). Dieser stabile Zustand wird  im Anwenderhandbuch mit so viel Sorgfalt beschrieben, dass der Anwender auch Jahre später ohne Nachfragen die Anwendung bedienen kann (siehe Teil 2).

Bitte nicht falsch verstehen: Auch die Anforderungsdokumentation ist wichtig und sollte gemäß ihrer Bestimmung ausreichend sorgfältig gepflegt werden. Trotzdem macht es Sinn, dass das Anwenderhandbuch mit noch mehr Sorgfalt gepflegt wird.

Bei der Produktentwicklung gibt es natürlich auch noch weitere Dokumentenarten, auf die der oben genannte Ansatz übertragen werden kann. In der Tabelle habe ich diese bezüglich ihrer Vergänglichkeit gegenübergestellt.

Die Beschreibung der Produktvision und der Rahmenbedingungen im Sinne von „Schaffe Werte ohne Verschwendung“ sind bereits erste Projektergebnisse und sollten somit Bestandteil der Produktdokumentation (z. B. in Form einer Produktbroschüre) werden.  Die initiale Investition in diese Broschüre dürfte sich im Laufe des Produktlebens mehrfach amortisieren.

Lean Documentation Teil 2 - Dokumentation zur rechten Zeit