Agile Vorgehen, allen voran Scrum, gelten als Gegenentwurf zur klassischen Projektabwicklung nach dem Wasserfallmodell. Durch kürzere Auslieferungszyklen und häufigeres Feedback sollen bessere Produkte und Systeme entstehen. Vernachlässigt wird dabei allerdings oft das Thema "Dokumentation". Immer häufiger hört man Aussagen wie "Wir schreiben keine Dokumentation mehr, wir machen jetzt Scrum!" oder "Warum Anforderungen erheben? Wir brauchen doch nur noch User Stories". Begründet wird das damit, dass funktionierende Software laut agilem Manifest (www.agilemanifesto.org) schließlich höher zu bewerten sei als umfassende Dokumentation.

Die Einführung eines agilen Vorgehens bedeutet jedoch keineswegs die Abschaffung jeglicher Dokumentation. Im Gegenteil: Wird in Scrum-Projekten auf die Dokumentation der zu Beginn einer System-Entwicklung erhobenen Anforderungen verzichtet, fehlt später jegliche Basis für die Wartung und Weiterentwicklung des Produkts. Denn in Scrum (scrum.org) werden Anforderungen in Form von User Stories dokumentiert, die in der Theorie auf Kärtchen geschrieben und entsorgt werden, sobald die Funktionalität implementiert ist. Wenn Sie entsprechend mit puristisch auf Karten geschriebenen User Stories arbeiten und diese nach erfolgter Abnahme wegwerfen, stehen Sie am Ende des Projekts ohne Dokumentation da (mehr zum Thema "Scrum" siehe: "Agile Softwareentwicklung mit Scrum und User Stories", Projektmagazin Ausgabe 2/2010).

Es mag akzeptabel sein, auf eine Dokumentation zu verzichten, wenn Sie für interne Kunden ein kleines Projekt durchführen, dessen Komplexität niedrig und dessen Laufzeit kurz ist. In den meisten Fällen jedoch wird eine fehlende Dokumentation Sie vor verschiedene Probleme stellen, auch wenn Sie ein lauffähiges System entwickelt haben, das bereit zur Auslieferung ist.

Die häufigsten Probleme sind:

• Fehlt eine Dokumentation von Funktionalitäten und Schnittstellen des Systems, wird früher oder später ein Reverse-Engineering erforderlich werden, falls das System weiterentwickelt werden soll. Da der Produktlebenszyklus im Allgemeinen nicht mit dem Abschluss des Entwicklungsprojekts endet, können je nach Lebensdauer des Systems noch Jahre oder sogar Jahrzehnte lang Bugfixing sowie Wartung und Pflege notwendig sein.
• Es ist schwierig, neue Mitarbeiter einzuarbeiten, da diese ohne Dokumentation keinen fachlich fundierten Überblick erhalten, was das System eigentlich tut.

Dieser Beitrag zeigt, warum es wichtig ist, auch bei agil durchgeführten Projekten Anforderungen zu dokumentieren, wie umfangreich diese sein sollten, wann der richtige Zeitpunkt für die Dokumentation ist und wie Sie die Aufgabe der Dokumentation in den Scrum-Prozess integrieren.

Was bringt eine Anforderungsdokumentation?

Auch wenn eine Anforderungsdokumentation mit zusätzlichem (mehr oder weniger großem) Aufwand verbunden ist, bringt sie wesentliche Vorteile, die diesen Aufwand rechtfertigen (Bild 1).

Bild 1: Vorteile einer Anforderungsdokumentation.

Effizientere Realisierung

Während der Entwicklung hilft eine Anforderungsdokumentation beim Aufbau von domänenspezifischem Wissen, das im Rahmen der Realisierung für viele Designentscheidungen benötigt wird. Denn um Abhängigkeiten und Zusammenhänge berücksichtigen zu können, müssen die Funktionalitäten des Systems als Gesamtheit betrachtet werden. Eine Betrachtung des Systems alleine aus dem Blickwinkel von User Stories reicht dazu nicht aus, denn der Fokus liegt hier vor allem auf der Erstellung von Deliverables, mit dem Ziel, dass am Ende jedes Sprints ein potentiell auslieferungsfähiges, lauffähiges System vorliegt. Eine vollständige Systembeschreibung mit den Mitteln der Use-Case-Analyse erfolgt dagegen üblicherweise auf gröberer Ebene – ein Use Case umfasst meist mehrere oder sogar viele User Stories. Dadurch ergibt sich ein Blick aufs große Ganze, der nicht durch die Konzentration auf die nächsten ein oder zwei Sprints eingeengt ist.

Erleichtertes Ableiten von Testfällen

Zum Testen gibt es in Scrum wenig Aussagen. In der Praxis wird sehr häufig ein Scrum-orientiertes Vorgehen mit einem Test-driven Development (TDD) integriert. Die Verantwortung für das Testen liegt damit beim Entwicklungsteam, das das entwickelte Inkrement allerdings immer nur aus seiner eigenen Sicht betrachten (und testen) kann und nicht aus der des späteren Anwenders. Entwicklertests können daher die Abnahmetests durch den Product Owner nicht ersetzen. Dieser benötigt allerdings für eine Abnahme – sofern sie nicht nur rein informell erfolgen soll – Testfälle auf einer Ebene, die mehr Details als die Ebene der User Stories enthält. Sind jedoch nur die User Stories als dokumentierte Grundlage vorhanden, muss er diese Testfälle selbst erstellen. Damit ist nur eine Traceability auf abstrakter Ebene möglich, was aber im Allgemeinen nicht ausreicht, um eine sinnvolle Auswirkungs-Analyse durchzuführen.

Einfacheres Testen nach einer Weiterentwicklung

Die fehlende Verbindung zwischen Testfällen und detaillierteren Anforderungen erschwert auch das Testen nach einer Weiterentwicklung. Denn dabei verändert sich meist nur ein Teil einer User-Story, nicht aber die Story an sich. Nur wenn bekannt ist, welche Testfälle von einer Änderung betroffen sind, kann der geänderte Schritt gezielt getestet werden; die restlichen Testfälle können dann in automatisierten Regressionstests durchlaufen werden. Sofern nur ein Link zwischen der User-Story und den zugehörigen Testfällen besteht, müssen bei Änderung der User-Story alle Schritte noch einmal getestet und ausführlich bewertet werden.