Missverständnisse wie die Annahme, dass Dokumentation wertlos ist, weil nur Code bleibenden Wert hat, oder dass nur funktionierende Software der Weg zur Validierung von Anforderungen ist, findet man leider immer wieder in agilen Projekten. Häufig werden User-Storys als ausreichend erachtet, um die Anforderungen an Dokumentation sicherzustellen. Diese werden in einer User-Story-Map in einen Gesamtzusammenhang gestellt und den Epics und den einzelnen Releases zugeordnet. Bei umfangreicheren Projekten entstehen aber schnell 300, 600 oder mehr User-Storys, die dann in der User-Story-Map nicht mehr übersichtlich und einfach nachvollziehbar dargestellt werden können. Eine weitere Herausforderung ist, dass User-Storys häufig aufeinander aufbauen. Will man den Programmablauf nachvollziehen, muss man alle betreffenden User-Storys in der richtigen Reihenfolge betrachten.

Wozu dokumentieren wir überhaupt, wenn am Ende die Software funktioniert? Dokumentation wird für verschiedene Zwecke erstellt: gesetzliche Zwecke, als Basis für Überlegungen über Umsetzungsalternativen, Kommunikationszwecke und zur Bewahrung.

Gleichzeitig gibt es unterschiedliche Stakeholder bei einer Dokumentation: Entwickler, Tester, Operations, Fachabteilung, fachliche Betriebsführung und eventuell ein Wartungsteam, das nicht an der ursprünglichen Umsetzung beteiligt war. Die verschiedenen Stakeholder haben unterschiedliche Anforderungen an eine Dokumentation: Eine Fachabteilung zum Beispiel wird keine Expertise in Programmiersprache haben. Werden Änderungen an der Software durchgeführt, ist es ihr nicht zuzumuten, die aktuell implementierte Logik aus dem Code herauszulesen. Soll eine Kommunikation an Endanwender erfolgen, ist nur eine verständliche textliche Dokumentation sinnvoll, Programmcode ist völlig ungeeignet.

Aber auch für das Entwicklungsteam ist eine Dokumentation wertvoll. Ist kein Entwickler aus dem Umsetzungsprojekt mehr verfügbar, muss das Wissen um die Projektlogik auf andere Weise bewahrt werden als in den Köpfen der Projektmitarbeiter.

Werden nach einem Rollout Fehler gemeldet, muss nachvollziehbar sein, ob es sich um einen Fehler oder eine gewollte Eigenschaft der Software handelt. Das gilt auch, wenn eine Fehlermeldung erst deutlich nach dem Rollout eingeht. Darüber hinaus existieren gegebenenfalls rechtliche Anforderungen an eine Dokumentation, die einzuhalten sind.

Lerne jetzt in unserem Videokurs die Grundlagen der Agilität kennen!

Im klassischen Vorgehensmodell (V-Modell) wurde zuerst ein Fachkonzept geschrieben, darauf aufbauend entwickelt, die Entwicklung getestet und final das Ergebnis vom Auftraggeber abgenommen. Wenn es endlich soweit war, hatte sich die Welt bereits weitergedreht und Anforderungen, die am Anfang in den Prozess gegeben wurden, waren mittlerweile obsolet oder zumindest nicht mehr aktuell. Das kann etwa bei Business-Intelligence (BI)-Projekten ein Problem sein, wenn sich nach Fertigstellung des Projekts und Sichtung der ersten Reports mit den Kennzahlen plötzlich herausstellt, dass andere Kennzahlen oder sogar andere Datenquellen benötigt werden. Abhilfe schaffen für dieses Dilemma kann folgendes agiles Business-Intelligence-Vorgehensmodell.

Es besteht im Wesentlichen aus den Komponenten Systemstrategie und Building-Block. Für Kleinstanforderungen, die kurzfristig ausgerollt werden müssen (etwa Hotfixes), ist ein entsprechender Bypass vorgesehen.

Im Rahmen der Systemstrategie werden die grundlegenden, langfristigen funktionalen, nichtfunktionalen und betrieblichen Anforderungen erhoben, soweit sie zu diesem Zeitpunkt bereits bekannt sind und eine Produktvision entwickelt. Auf Basis dieser Anforderungen kann eine passende Architektur entworfen und eine Realisierungs-Roadmap mit priorisierten Anforderungen erstellt werden. Auf Basis dieser Realisierungs-Roadmap erfolgt dann die Umsetzung in einzelnen Building-Blocks. Im Scrum-Wortschatz würde man dies als Backlog mit priorisierten User-Storys bezeichnen.

Ein Building-Block umfasst neben der fachlichen Konzeption der einzelnen Anforderungen auch alle Aufgaben der Entwicklung, des Tests und der Abnahme durch den Kunden. Trotzdem entspricht ein Building-Block nicht einem klassischen Scrum-Sprint.

Ein Building-Block dauert genau doppelt so lange wie ein Sprint. Durch die Parallelisierung der Building-Blocks gelingt es aber trotzdem, dass der Kunde nach jedem Umsetzungssprint eine neue Softwarelieferung einschließlich der notwendigen Dokumentation erhält. Denn während das Umsetzungsteam an der Entwicklung der Inhalte des Building-Block 1 arbeitet, kann sich das Konzeptionsteam bereits mit der fachlichen Konzeption für Building-Block 2 beschäftigen und inkrementell die Dokumentation aufbauen. Nach der Hälfte des Umsetzungsprints werden die Anforderungen beziehungsweise User-Storys für den nächsten Sprint vorgestellt und eventuelle Fragen und Anmerkungen des Umsetzungsteams berücksichtigt. Beginnt das Umsetzungsteam mit der Umsetzung von Building-Block 2, startet zeitgleich das Konzeptionsteam mit den Arbeiten für Building-Block 3. Das Konzeptionsteam läuft also inhaltlich immer einen Building-Block vor dem Umsetzungsteam.

Durch die Trennung der Systemstrategie von der Umsetzung einzelner Anforderungen beziehungsweise Paketen von Anforderungen im Rahmen von Building-Blocks wird von Beginn an ein klarer strategischer Rahmen gesetzt. Die Aufteilung von umfangreichen Gesamtvorhaben in Building-Blocks ermöglicht schnelle Erfolge und Erkenntnisse, die mit den Kunden diskutiert und in Folgeblocks genutzt werden können.

Neben dem Erstellen von Textdokumenten – etwa für die Dokumentation der nichtfunktionalen Anforderungen – ergibt es Sinn, eine strukturierte Dokumentation mit UML anzufertigen. Als Ergebnisse bieten sich hier Kontextdiagramme, Anwendungsfälle, Aktivitätsdiagramme und Fachklassen an, abhängig von der Granularität der User-Storys. Um aus der Dokumentation eine Referenz auf die User-Storys zu gewährleisten, sollten in den UML-Diagrammen Requirements verwendet werden, die ID und Titel der User-Story tragen. Ein Modellierungswerkzeug ermöglicht das schnelle Auffinden dieser Requirements in allen Diagrammen, in denen sie verwendet werden, und bietet so die Grundlage für eine Traceability. So entsteht eine Gesamtdokumentation, die projektbegleitend erstellt wird und immer den aktuellen Stand der Software widerspiegelt. Änderungen bestehender Funktionalitäten durch neuere User-Storys sind so einfach und transparent nachvollziehbar.

So wie Trinken wichtiger ist als Essen, so ist eine funktionierende Software wichtiger als eine umfassende Dokumentation. Aber so wenig, wie man dauerhaft auf Essen verzichten kann, kann man auch dauerhaft auf eine Dokumentation verzichten. Agile Arbeitsweise und fachliche Dokumentation schließen sich nicht aus, sondern sind wichtige Bestandteile eines erfolgreichen Projektvorgehens.