Dokumentation in agilen Projekten – so geht's

Agiles Vorgehen in der Softwareentwicklung boomt, durch häufiges Feedback und kurze Auslieferungszyklen sollen schließlich bessere Produkte entstehen. Ein wichtiges Thema wird dabei allerdings oft vernachlässigt: die Dokumentation der zu Beginn erhobenen Anforderungen. So reicht z.B. in Scrum die Dokumentation der User Stories für die spätere Wartung und Weiterentwicklung der Software alleine nicht aus. Marta Bednarczyk und Dr. Stefan Queins zeigen, warum eine Dokumentation der Anforderungen wichtig ist, wie Sie den richtigen Zeitpunkt für diese Tätigkeit finden und auf welche Weise Sie diese in den Scrum-Prozess integrieren können.

 

Dokumentation in agilen Projekten – so geht's

Agiles Vorgehen in der Softwareentwicklung boomt, durch häufiges Feedback und kurze Auslieferungszyklen sollen schließlich bessere Produkte entstehen. Ein wichtiges Thema wird dabei allerdings oft vernachlässigt: die Dokumentation der zu Beginn erhobenen Anforderungen. So reicht z.B. in Scrum die Dokumentation der User Stories für die spätere Wartung und Weiterentwicklung der Software alleine nicht aus. Marta Bednarczyk und Dr. Stefan Queins zeigen, warum eine Dokumentation der Anforderungen wichtig ist, wie Sie den richtigen Zeitpunkt für diese Tätigkeit finden und auf welche Weise Sie diese in den Scrum-Prozess integrieren können.

 

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.

Nachvollziehbarkeit der Realisierung

Wird ein bestehendes System weiterentwickelt, verändern sich…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
3 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 6
Kommentare 3

Alle Kommentare (3)

Verena
Wagenpfeil

Sehr unkonkrete Angaben. Praxis-Beispiele würden der Thematik gut tun.

 

Guest

Letztendlich ist nur die Spezifiaktion und Dokumentation während der Realisierung mit den Regeln von Scrum verträglich. Wer sollte die Anforderungsspezifikation denn erstellen, wenn nicht der Product Owner, der ja (alleine) für das Produkt verantwortlich ist?

Eine vollständige Spezifikation vorab beraubt mich außerdem wesentlicher Werte von Scrum, da ja nur noch die Reihenfolge relevant ist, nicht mehr das Was und Ob und das Lernen aus dem Feedback. Scrum ist eben dann hilfreich, wenn die Anforderungen nicht alle vorab bekannt oder verstanden sind und man trotzdem schon starten kann (was nicht für alle Projekte gilt - solche sind dann nicht für Scrum geeignet).

Der Artikel beschreibt korrekt, wie der PO jede einzelne User Story vor dem Sprint mit den Stakeholdern klären und abstimmen kann, damit das Team im Planning Meeting weiß, was zu tun ist. Details können weiterhin während der Implementierung abgesprochen werden.

Sofern eine Dokumentation (für die Wartung, Revisionszweck o.ä.) benötigt wird, sollte dies in den Akzeptanzkriterien oder in der Definition of Done beschrieben werden. Somit wäre kein Backlog Item 'done', ohne dass die Dokumenation vorhanden ist.

 

Oguzhan
Karaduman

Es scheint mir dass Scrum nicht richtig verstanden worden ist.