Ein Projekt wird auf der „grünen Wiese” gestartet, um ein schlecht bzw. stellenweise gar nicht dokumentiertes Bestandssystem (engl. legacy system) komplett zu ersetzen. Das zu ersetzende Bestandssystem ist eine Individuallösung, die mehr schlecht als recht gewartet wird. Der letzte Programmierer, der sich im Code auskannte, ist nicht mehr verfügbar (Pension). Der Hersteller der eingesetzten Hardware bietet keine Wartung mehr an. Die Software kann aber nur unter erheblichem Aufwand auf andere Hardware portiert werden. Das Budget für die Wartung ist beschränkt. Die Kosten für die Wartung steigen kontinuierlich. Die Gründe sind fehlende Innovationen, immer mehr technische Schulden, Wissensverlust durch Fluktuation oder wachsende Lizenz- oder Betriebskosten. Der Auftraggeber sieht keine Zukunft für das Bestandssystem und möchte ein komplett neues IT-System.

Der Auftraggeber hat klare Projektziele, macht aber (noch) keine Vorgaben für die technische Umsetzung. Für das neue IT-System formuliert der Auftraggeber neben der grundlegenden Projektidee ein paar weitere Rahmenbedingungen:

• Das IT-System muss „zukunftssicher” sein.
• Das IT-System muss „agil” entwickelt werden.
• Die Projekt­organisation ist nur in Deutschland, dort aber auf mehrere Standorte verteilt.
• Das IT-System muss „vollständig” dokumentiert sein.

Der Produkt­verantwortliche entscheidet sich für die Methode cards+, um die Erwartungen des Auftraggebers an das neue Produkt zu formulieren. Er kennt die Methode und ist von seiner Wirksamkeit überzeugt. Mit dem Baustein Topic dokumentiert er den vom Auftraggeber gesteckten groben Rahmen, in dem er mit allem ihm zur Verfügung stehenden kreativen Kräften die notwendigen Fähigkeiten des IT-Systems identifizieren soll/darf. Der Produkt­verantwortliche nutzt die Bausteine Epic und Case, um diese Informationen nachhaltig zu dokumentieren. Er erhofft sich von der Methode die von ihm gewünschte Flexibilität im Backlog-Management.

Der Auftraggeber möchte vom Produkt­verantwortlichen wissen, wie er sicherstellt, dass das neue IT-Systems „zukunftssicher“ ist, wie er es nennt.

Wir können nur versuchen, die derzeit beste technische Lösung einzusetzen. Niemand kann in die Zukunft blicken. Wir müssen vorbereitet sein, mit so geringem Aufwand wie möglich einzelne Entscheidungen zu korrigieren. Das ist zukunftssicher.

— — 

Der Produkt­verantwortliche

Bei der Besprechung des agilen Entwicklungs­prozesses entzündet sich eine Diskussion über die Vorteile von Scrum gegenüber einem phasenorientierten Modell.

Mit Scrum wird die Entwicklung billiger.

— — 

Der Auftraggeber

Der Produkt­verantwortliche macht dem Auftraggeber klar, dass „agil“ nicht mit „billiger“ gleichzusetzen ist. Die Entscheidung, agil zu entwickeln, hat andere Beweggründe. Scrum stärkt das Team und fördert die Kommunikation.

Ob wir durch agile Entwicklung schneller Ergebnisse produzieren können, hängt maßgeblich von der Qualität der Anforderungen und von der Effizienz und Genauigkeit bei der Vermittlung des Produktwissens ab – und hier spielt die Produkt­dokumentation eine große Rolle.

— — 

Der Produkt­verantwortliche

Eine Produkt­dokumentation ersetzt keinesfalls direkte, persönliche Kommunikation im Team. Aber welches Wissen im Team ankommt, und wie die Kollegen das Wissen für ihren Bedarf sichern ist völlig unterschiedlich. Eine dokumentiertes Produktwissen hingegen ist immer verfügbar. Agil eine Produkt­dokumentation zu entwickeln bedeutet, alle Informationsquellen im Projektumfeld zu berücksichtigen. Damit wird Wissen für das Team verfügbar, auf das sie im Normalfall keinen direkten Zugriff haben.

Der Produkt­verantwortliche muss sein Team überzeugen, dass eine Produkt­dokumentation bereits beim Projektstart notwendig ist.

Die Produkt­dokumentation hilft uns, bereits am Beginn des Projektes eine gemeinsame Sprache zu etablieren. Durch die Erstellung und laufende Pflege des Glossars legen wir frühzeitig wichtige Begriffe im Projekt fest.

— — 

Der Produkt­verantwortliche

Er erklärt dem Team, dass die Produkt­dokumentation auch ein Ergebnis des ganzen Teams ist. Jeder im Team trägt seinen Teil zum Ganzen bei. Argumente für agile Entwicklung gelten auch für agiles Dokumentieren.

Die Pflege der Produkt­dokumentation wird vom Team als Akzeptanzkriterium festgelegt. In den vorläufigen Spielregeln des Teams wird implizit die Verwendung des Glossars festgeschrieben. Auch das Ziel sauberer und lesbarer Code wird geschärft. Prinzipien der Clean-Coder wie Einfachheit (Prinzip KISS), Redundanzfreiheit (Prinzip DRY), klare Verantwortlichkeit (Prinzip SRP) oder gleiches Abstraktionsniveau (Prinzip SLA) sollen angewendet werden. Die Karte mit der Forderung, Kommentare im Code zu vermeiden, wird zu Beginn kontrovers diskutiert und steht kurz davor, abgelehnt zu werden. Aber auch hier helfen die Argumente der Clean-Coder.

Es ist zielführend und für den Produkt­verantwortlichen auf jeden Fall machbar, bereits beim Start des Projektes alle Aufgabenbereiche des neuen IT-Systems zu erfassen und im Baustein Topic zu beschreiben, welche Geschäftsprozesse vom IT-System berührt werden. Wir kennen unsere interessierten Parteien - und zwar alle. Mit dem Titel bekommt jeder Aufgabenbereich einen aussagekräftigen Namen. Dadurch erhält das Team bereits sehr früh einen ersten Eindruck von der „Größe“ des Produktes.

Einen fachlichen Strukturrahmen zu definieren oder eine Architektur zu entwerfen ist kein Widerspruch mit einer agilen Methode. Agil bedeutet aber, dass der Produkt­verantwortliche nur das im Wiki dokumentiert, was er mit Auftraggeber oder dem Team bespricht.

Es ist jedoch illusorisch, bereits jetzt alle Fähigkeiten des IT-Systems zu kennen. Trotzdem macht es Sinn, alle Fähigkeiten, die der Auftraggeber explizit fordert, mit dem Baustein Case aufzuschreiben und mit dem Baustein Epic in Funktionalitäten zu gruppieren. Schon allein der Titel für Fähigkeiten oder Funktionalitäten schärft die gemeinsame Sprache. Verwendet das Team auch noch die Ideen des Domain-Driven-Design, dann sind die Bausteine Epic und Case wertvolle Hinweise zu den Kontextgrenzen.

Gleiches gilt für den Architekturentwurf. Gerade jetzt trifft das Team viele wichtige technische Entscheidungen. Sie mit dem Baustein zu dokumentieren ist besonders wichtig, weil jetzt alle betrachteten Lösungsalternativen und die Argumente für oder gegen eine Middleware, ein Framework oder ein technisches Konzept noch bekannt sind. Später können uns die begründeten Entscheidungen helfen, trotz Problemen an einer technischen Lösung festzuhalten oder sie aufgrund nicht behebbarer Mängel zu korrigieren.

Ein Fachklassenmodell, dass bis ins kleinste Detail Attribute und Operationen von Objekten beschreibt, ist zu diesem Zeitpunkt kein Vorteil. Sinnvoll ist jedoch, die Domänenobjekte zu identifizieren und ihnen abhängig vom Architekturstil mit den Bausteinen Entity bzw. Event einen eindeutigen Namen zu geben. Die Beschreibung im Wiki kann sich zu diesem Zeitpunkt darauf beschränken, das Verständnis zu schaffen und wichtige Zusammenhänge zu vermitteln.

Das Konzept der Microservices ist mit Sicherheit eine Herausforderung für jedes Team. Software wird dadurch nicht weniger komplex. Durch die Zerlegung eines großen Ganzen in klar abgegrenzte Teile wird die Komplexität aber besser beherrschbar. Das IT-System hat mehr Optionen für die Skalierung. Es ist daher nicht falsch, ganz früh auch über Dienste nachzudenken, die das IT-System haben soll. Für jede Schnittstelle ist ein Dienst erforderlich. Mit der Schneidung des IT-Systems ergeben sich abhängig vom Architekturstil noch viele weitere Dienste. Mit dem Baustein Service dokumentiert der Produkt­verantwortliche diese Analyseergebnisse. Mit dem Titel bekommt jeder Dienst einen eindeutigen Namen.

Der Auftraggeber bleibt seiner Linie treu. Er schätzt die Vorteile agiler Software-Entwicklung und akzeptiert den «Kontrollverlust» (O-Ton). Er bekommt ein Gefühl für die Geschwindigkeit (engl. velocity) des Teams. Zusammen mit dem Produkt­verantwortlichen kann er immer besser einschätzen, was machbar ist und wie schnell es wirksam für die Nutzer des IT-Systems wird.

Der Produkt­verantwortliche nutzt den Baustein Case, um daraus Storys für das Backlog in Jira zu entwickeln. Durch die Verknüpfung der Seite im Confluence mit der Story in Jira behält er den Überblick. Sowohl im Backlog als auch im Wiki. Den Baustein Epic nutzt er, um die Storys eine Funktionalität unter dem gleichen Titel zu gruppieren. So schlägt er eine elegante Brücke zwischen Confluence und Jira. Und er erkennt sehr schnell, ob eine Funktionalität fertig ist. Nämlich genau dann, wenn alle dem Epic untergeordneten Storys fertig sind.

Das Team hat neben der Entwicklung ihre Aufgabe akzeptiert, die Produkt­dokumentation zu pflegen. In Sprint 5 haben sie darum eine Maßnahme aus der Retrospektive umgesetzt, die Produkt­dokumentation in zwei Teile zu spalten. Der Produkt­verantwortliche kümmert sich um die Pflege der Bausteine der Systembeschreibung und Systemstruktur im Wiki. Das Team liefert mit jedem Produktinkrement Spezifikationen für die Bausteine der Systemstruktur, die durch einen halbautomatischen Mechanismus im Wiki veröffentlicht werden. Entscheidungen und Konzepte liegen weiterhin in der Verantwortung des Teams. Mittlerweile schätzen sie den Baustein Decision. Bei manchen Diskussionen im Team haben sich die Begründungen schon mehr als einmal bewährt.

Einige Nutzer, die regelmäßig als Domänenexperten zu Refinement- oder Review-Meetings eingeladen werden, haben das Angebot des Produkt­verantwortlichen angenommen und lesen regelmäßig die Produkt­dokumentation.

Durch den Einsatz von cards+ wird bereits beim Projektstart der Grundstein für eine Produkt­dokumentation gelegt. Gleichzeitig gab der Produkt­verantwortliche damit auch das Versprechen, eine vollständige Produkt­dokumentation mit hoher Qualität zu erstellen. Das Team trainiert von Anfang an die konsequente Arbeit mit einem Wiki, mit einer Kultur, die auf Kommunikation und Feedback großen Wert legt. Gemeinsam tragen alle interessierte Parteien Verantwortung für die Qualität des Produktes. Der Produkt­verantwortliche kann seinem Auftraggeber den Fortschritt neben dem lauffähigen Produktinkrement (engl. potentially shippable increment) auch in einer Form präsentieren, die er lesen kann: Als Baseline der Produkt­dokumentation.