Agiles Arbeiten erleichtert die IT-Dokumentation. Bikablo-Illustration zum Artikel.

Zusammenfassung

Wenn man meinen Blog nicht von Anfang an lesen möchte (das wäre sehr schade), schreibe ich hier noch einmal zusammengefasst auf, was ich unter agiler Dokumentation verstehe bzw. welches Verständnis ich voraussetze, wenn ich neue Blogartikel schreibe.

Dokumenation ist wichtig

Es ist richtig, dass nichts wichtiger ist als funktionierende Software. Aber es ist auch ziemlich kurz gedacht. Software, die keiner mehr richtig überblickt und kontrolliert, kann einem auf kurz oder lang auf die Füße fallen. Allerdings ist die Balance zwischen Feature-Entwicklung, Test und der notwendigen Dokumentation nicht trivial.

Dokumentation != Dokumentation

Wenn ich im Arbeitsalltag über Dokumentation rede, differenziere ich zwischen 3 Arten der Dokumentation:

  • Projektdokumentation: dient dazu, die Entwicklung zu unterstützen und den Status des jeweiligen Projekts wiederzugeben (Beispiele: User Stories, Burndown-Chart, Scrum Board, Konzeptideen…)
  • Produktdokumentation: beschreibt, wie das Produkt funktioniert, welche Daten es wie verarbeitet und wie es zu bedienen ist. Ich unterscheide hier zwischen übergreifender (z.B. Architketur) und featurebasierter Produktdokmentation.
  • Prozessdokumentation: bildet den Entwicklungsprozess ab (Beispiele: DoD, DoR, Teamkalender, Refinementprozess, …). Aufgrund der Verwechslungsgefahr mit Geschäftsprozessen rate ich dazu diese Art der Dokumentation „Organisatorisches“ zu nennen.

Dokumentation geht uns alle an

Scrum kennt eigentlich nur drei Rollen: den Product Owner, den Scrum Master und das Entwicklungsteam. Das Entwicklungsteam setzt sich interdisziplinär aus Mitgliedern wie Programmierern, Testern, Architekten, Business Analysten oder technischen Redakteuren zusammen. Niemand alleine kann Kenntnis von allen Dingen haben, die dokumentiert werden sollten oder könnten, deshalb ist Dokumentation auch nicht an einer bestimmten Rolle festzumachen, sondern Teamsache! Deshalb sollte Produktdokumentation z.B. auch in die Definition of Done aufgenommen und selbstverständlich IM Sprint erledigt werden.

Dokumenation muss Struktur haben

Dokumentation ist kein Selbstzweck, sondern soll verschiedenen Lesertypen/Personas die notwendigen Informationen für die Arbeit bereitstellen. Dafür benötigt man neben guten Inhalten auch eine gute Struktur. Durch die übersichtliche Darstellung in den verschiedenen Ebenen, stellt die Story Map eine mögliche Struktur für die Produktdokumentation dar. Es muss immer das Ziel sein abstrahiert zu dokumentieren. Je mehr ich nach bestimmten Ablaufmustern beschreiben kann, desto weniger muss ich zukünftig pro Feature beschreiben.