Lean Documentation Teil 1

Schaffe Werte, vermeide Verschwendung

Schlanke Dokumentation in agilem Umfeld

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 1: Die Anforderungsdokumentation wird hauptsächlich während der Entwicklungsphase gebraucht und ist danach weniger von Interesse. Sie ist somit eher kurzlebig. Außerdem zeigt die Erfahrung, dass die Anforderungsdokumentation häufigen Änderungen unterworfen ist. Das Anwenderhandbuch hingegen ist während des gesamten Lebenszyklus eines Produkts wertvoll (auch schon während der Entwicklung). Sie ist somit langlebig und dokumentiert in der Regel einen stabilen Zustand (siehe hierzu auch Teil 2).

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.

 

Kurzlebige Dokumente (auch bekannt als Projekt- und Prozessdokumentation) Langlebige Dokumente (auch bekannt als Produkt- und Systemdokumentation)
Diese Dokumente werden überwiegend während der Projektphase gebraucht und interessieren nach Ende eines Projektes in der Regel weniger. Diese Dokumente beschreiben Ergebnisse und werden Bestandteil des zu entwickelnden Produkts.
Sie sind für die Benutzung, den Betrieb und die Weiterentwicklung nach Ende eines Projekts notwendig und können aber auch bereits während der Projektphase hilfreich sein.
• Anforderungsdokumentation (z. B. User Stories)
• Projektplan (z. B. Product-Backlog)
• Verträge
• Statusberichte
• Vorgehensmodell
• Richtlinien
• usw.
• Produktbroschüre
• Anwenderhandbuch
• Betriebshandbuch
• Architekturdokumentation
• Designdokumentation
• Testkatalog
• Source-Dokumentation
• usw.

Die Produktbroschüre

– das initiale Ergebnisdokument

Auch wenn jede Produkt- und Systemdokumentation für den langfristigen Erfolg eines Produktes wichtig sein dürfte, möchte ich die Produktbroschüre als ein initiales Ergebnisdokument hervorheben.

Zu Beginn eines agilen Projekts steht die Idee zur Lösung eines Problems. Daraus entwickelt sich eine Produktvision. Außerdem werden die Rahmenbedingungen analysiert und beschrieben. Die Vision und die Rahmenbedingungen sind für jeden Projektbeteiligten notwendig und hilfreich, um einen Eindruck und Überblick vom Produkt und dem Umfeld zu bekommen und dienen der ständigen Fokussierung.

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.


Jetzt teilen: