Sinn und Unsinn von Dokumentation

Sinn und Unsinn von Dokumentation

Dokumentation in agilen Projekten

Bei jedem neuen Projekt stellt sich die Frage nach der Dokumentation. So kam auch in einem meiner Projekte das Thema mal wieder auf und daher möchte ich es hier kurz aufgreifen. Da jedes Umfeld anders ist, gibt es keine Musterlösung. Ich wähle daher den pragmatischen Weg.

 

Worauf kommt es an?

Die einfache Antwort auf die Frage „Wieviel Dokumentation erstelle ich für mein Projekt?“ lautet „So viel wie notwendig“. Was bedeutet das? Für jede Information gibt es einen Empfänger, der diese Information benötigt, einen Grund warum er sie benötigt, eine Form, in der er sie am besten verstehen kann und einen Zeitpunkt zu dem er sie benötigt.

Was impliziert dieses Vorgehen? Dass die Beteiligten sich unterhalten (“Individuals and Interactions over Processes and Tools“) und nicht nur vermuten, aus den eigenen Erfahrungen heraus annehmen, oder einem definierten Prozess entnehmen, welche Dokumentation benötigt wird (“Ich weiß, dass Entwickler immer alles ganz genau definiert haben wollen, deshalb beschreibe ich die Anforderungen so präzise wie möglich.”, “Wir brauchen das zwar nicht, aber unser Prozess schreibt das so vor.” “Zu jedem Produkt muss es auch ein Handbuch geben.” etc.).

Am Beispiel von Anforderungen: Der Empfänger (hier das Entwicklungsteam) legt fest, welche Informationen es zur Umsetzung benötigt – und zwar einzeln für jede Anforderung, unabhängig davon, ob dies formal in einer Definition of Ready definiert ist oder nicht. Der Grad der Ausführlichkeit der Dokumentation spielt sich im Laufe der Produktentwicklung ein; dann wenn sich eine Vertrauensbasis zwischen den Anforderern und dem Umsetzungsteam gebildet hat und nicht mehr jede Kleinigkeit dokumentiert werden muss, weil man Angst hat, sich gegenseitig etwas unterschieben zu wollen. Ich habe die Erfahrung gemacht dass je besser sich die Mitarbeiter untereinander vertrauen, je besser das Team die Vision vor Augen und damit eine gemeinsame Vorstellung von dem Produkt entwickelt hat, desto weniger muss dokumentiert werden.

 

 

Dokmentation dann erzeugen, wenn sie benötigt wird

Dokumenation wird dann erstellt, wenn sie benötigt wird. In unserem Projekten definieren wir z.B. nur die Anforderungen in einer ausführlicheren Form, die im nächsten Grooming oder Estimation besprochen werden sollen. Bei einer Planung zu Beginn eines Projekts erstellen wir die Anforderungen daher nur sehr grob, z.B. in Form einer Story Map, um daraus einen Gameplan (oder Roadmap) ableiten zu können.

Gleiches gilt für andere Dokumentationsformen. So soll in einem aktuellen Projekt das Produkt demnächst in den regulären Betrieb überführt werden (bis dato haben die Entwickler den Betrieb mit übernommen). Das Betriebskonzept schreiben wir erst jetzt. Hätten wir früher damit begonnen, so hätten wir es häufig ändern müssen, da wir viele Schnittstellen im Laufe der Entwicklung angepasst haben. Dies hättet nur unnötig Zeit gekostet. Ein Benutzerhandbuch, dass die nicht selbst-sprechenden Teile des Produkts erklärt, habe ich erstellt, als ich in das Projekt gekommen bin um das Produkt zu verstehen. Vorher wurde es nicht benötigt, da sich die Anwender schrittweise an die Anwendung gewöhnt haben (mit jedem Sprint wurde die Anwendung um neue Features erweitert). Ich habe die Erfahrung gemacht, dass gerade fachfremde Personen, die neu in das Team kommen, sehr gut geeignet sind, Dokumentation zu verfassen, da sie noch einen relativ unvoreingenommen Blick auf die für sie neue Anwendung haben.

 

 

Aufräumen

Viele kennen das sicherlich: Ein Glossar, dass nicht mehr aktuell ist, eine historische gewachsene chaotische wiki-Struktur, redundaten Information in überschiedlichen Versionen und ähnliches. Nicht nur für Neueinsteiger sorgt eine chaotisch strukturierte und veraltete Dokumentation für Desorientierung. Auch hier gilt es von Zeit zu Zeit einmal aufzuräumen und neu zu strukturieren. Aus den oben beschriebenen Gründen, habe ich auch hier die Erfahrung gemacht, dass dies am besten funktioniert, wenn dies von Personen durchgeführt wird, die neu mit dem Projekt oder Produkt oder dem Thema in Berührung kommen.

 

filed by Michael Cory

filed by Michael Cory

 

 

Resumé

In unterschiedlichen Produkten, Projekten, Abteilungen, Bereichen oder Unternehmen ist der Kontext, in dem Dokumentation erstellt wird, ein anderer. Es gibt Teams, die kommen, zumindest wenn sie noch klein sind, mit minimaler Dokumentation aus. Große komplexe Projekte mit vielen Teilnehmern in einem (politisch) komplexen Umfeld kommen ohne ausführliche Dokumentation nicht mehr aus. Wir empfehlen immer, Dokumentation dann erstellen, wenn sie notwendig wird, in einer Form wie sie der Empfänger benötigt … der plausibel darlegen sollte, warum er sie benötigt; um der willkürlichen Erstellung von Dokumenten zu entkommen.

 

Image:
Diesen Artikel teilen:

Einen Kommentar hinterlassen

*

Projektpfad – Der Blog für agile Produktentwicklung - Background

Suche eingeben

Alle Ergebnisse anzeigen