Dokumentation in der agilen Softwareentwicklung – braucht man das?

In Projekten mit agiler Vorgehensweise kommt es häufiger vor, dass es sehr wenig Dokumentation gibt. Während man in den traditionellen Methoden vor der ersten Zeile Code zuerst exzessiv spezifiziert hat, läuft das bei agilen Projekten genau andersherum. Warum ist das so?

Im agilen Manifest steht der Wert „funktionierende Software mehr als umfassende Dokumentation“. Darüber hinaus wird direkte Kommunikation innerhalb des Teams als effektivste Methode angesehen, um Informationen zu übermitteln.

In Summe werden diese Aspekte ins Feld geführt, um auf Dokumentation weitestgehend zu verzichten. Schließlich gibt es noch die vielen User Stories, anhand derer schnell Software entwickelt wird.

Was in kleinen Teams für das erste Release auch noch gut funktioniert, wird spätestens bei weiteren Releases, zusätzlichen und wechselnden Mitarbeitern und wachsender Software nicht mehr ausreichen. Und wer kennt es nicht, wenn man sich wieder mit einem zurückliegenden Thema beschäftigt und nicht mehr genau weiß, was und warum damals etwas beschlossen und umgesetzt wurde – da freut sich jeder, wenn er auf etwas Dokumentation zurückgreifen kann.

Auch der übliche Hinweis auf den Code („da steht ja alles exakt drin“) hilft nur bedingt. Erkennbar ist, wie etwas umgesetzt wurde, aber meist nicht warum.

Wenn man auf die klassischen Elemente in Scrum schaut, entstehen ganz viele Epics und User Stories. Mit Hilfe der Akzeptanzkriterien der User Stories können Anforderungen gut nachvollziehbar sein. Schwierig ist es aber, einen Überblick über Prozesse / Abläufe zu erhalten. Hier ist man mit den eher kleinteiligen User Stories aufgeworfen und muss sich mühsam durch alle Details der Tickets durchhangeln, um den aktuell gültigen Stand zu verstehen.

Abhängig von der Zielgruppe werden verschiedene Arten von Dokumentationen benötigt. Während am Anfang des Projekts Fachbereich, Entwickler und Tester im Fokus stehen, werden mit dem ersten produktiven Release auch Unterlagen für Benutzer, für den Support / Betrieb oder auch das Wartungsteam benötigt.

Wir bei exensio orientieren uns an den folgenden Grundsätzen:

• Diagramme anstatt zu viel Prosatext
  Für die meisten Menschen sind grafische Darstellungen schneller zu erfassen als einen langen Text zu lesen. Für die Dokumentation fachlicher Zusammenhänge oder Prozesse sollte man auf Standards (UML, BPMN etc. ) zurückgreifen, da diese ein einheitliches Verständnis der Darstellung sicherstellen und weniger Raum für Interpretation zulassen. Für Benutzerdokumentationen kann eher eine freie Form der Darstellung gewählt werden.
• Struktur anstatt Textwüsten
  Um Texte und Beschreibungen kommt man nicht drumherum. Leichter verständlich werden Texte, wenn diese gut strukturiert werden, beispielsweise durch Aufzählungen und Tabellen.
• Generieren anstatt manueller Erstellung
  Der Einsatz von Entwicklungswerkzeugen ermöglicht es oftmals, Dokumentationen aus dem Tool heraus automatisiert zu erstellen. Klassisches Beispiel ist ein Datenbankmodell, das beispielsweise aus dem Datenbank Tool oder einer Entwicklungsumgebung generiert werden kann oder eine Beschreibung von Schnittstellen.

Bei der Entscheidung über die Art der Dokumentation sollte man im Hinterkopf behalten, dass die Dokumentation zukünftig gepflegt werden muss. Diagramme oder gut strukturierte Texte sind leichter zu pflegen als lange Prosatexte, generierte Dokumente sind auf Knopfdruck verfügbar.

Folgende Inhalte sind besonders wichtig für spätere Analysen und Anpassungen:

• Datenstrukturen
  Am Anfang eines Projekts sind zunächst die fachlichen Zusammenhänge der zu verarbeitenden Daten interessant, später wird das Model technisch umgesetzt. Ob man später noch beiden Sichten benötigt, hängt stark von der Komplexität ab. Generell ist hier eher die Generierung der Dokumentation dann basierend auf dem implementierten Stand erstrebenswert.
• Abläufe / Prozesse / Workflows
  Agiles Vorgehen fördert das Zerlegen in kleine, umsetzbare Aufgaben (Epic – User Story – Task). Für das Schätzen und Umsetzen der Anforderungen ist das sehr hilfreich – für das Verständnis von größeren Zusammenhängen aber eher hinderlich. Daher ist es empfehlenswert, Prozesse / Workflows nochmals separat zusammenhängend zu beschreiben (bspw. als Use Case).
• „Lebensläufe“
  In Geschäftsanwendungen gibt es immer Objekte, die durch verschiedene Rollen bearbeitet werden und dadurch ein „Leben“ in verschiedenen Stadien durchlaufen. Für die relevanten Geschäftsobjekte sollten daher diese Status und deren Übergänge dokumentiert werden (bspw. durch ein UML Zustandsdiagramm).
• Schnittstellen
  Das Thema Schnittstellen hat 2 Aspekte: zum einen sind die konkreten Schnittstellen zu anderen Systemen gemeint, zum anderen sind diese Schnittstellen auch im Kontext von System-übergreifenden Prozesse/Abläufen relevant. Dieses Verständnis hilft beispielsweise auch bei der ersten Fehleranalyse im Support. So können Anfragen gleich an den richtigen Ansprechpartner geleitet werden.
• Benutzer Interface
  Beim Benutzer Interface sollte man aufpassen, am Anfang nicht zu viel zu investieren, da Änderungen eher häufig stattfinden. Empfehlenswert ist mit Wireframes zu starten, da diese mit geeigneten Tools leichter zu erstellen sind. Nach der Implementierung können dann echte Screenshots von der Software verwendet werden.
• Software-Architektur
  Hier wird die Strukturierung der Software in Bausteine festgehalten, technische Schnittstellen beschrieben sowie Entwurfsentscheidungen dokumentiert. Diese Informationen sind insbesondere für die Weiterentwicklung des Systems relevant.

Ja nach Art und Gegenstand des Projekts gibt es sicher noch weitere wichtige Inhalte, die lohnend sind, zu dokumentieren.

Um auf die Ausgangsfrage zurückzukommen: Ja, Dokumentation ist unbedingt erforderlich. Allerdings sollte man sich gut überlegen, wie eine effiziente, gut pflegbare Dokumentation erstellt wird. Auch bei einem iterativen Vorgehen lassen sich jeweilige Dokumentationsaufgaben einplanen. Zur Definition, wann eine Aufgabe als abgeschlossen gilt („definition of done“), gehört dann auch eine entsprechende Aufgabe zur Aktualisierung der zugehörigen Dokumentation. Eine Dokumentation wird sich im Projektverlauf sehr schnell als lohnend herausstellen.