Robert Bruckbauer |
Ein Projekt wird auf der „grünen Wiese” gestartet, um ein schlecht bzw. stellenweise gar nicht dokumentiertes Bestandsystem (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 Bestandsystem 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 Projektorganisation ist nur in Deutschland, dort aber auf mehrere Standorte verteilt.
- Das IT-System muss „vollständig” dokumentiert sein.
Der Produktverantwortliche 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 Produktverantwortliche 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 Produktverantwortlichen 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 Produktverantwortliche
Bei der Besprechung des agilen Entwicklungsprozesses entzündet sich eine Diskussion über die Vorteile von Scrum gegenüber einem phasenorientierten Modell.
Mit Scrum wird die Entwicklung billiger.
— —Der Auftraggeber
Der Produktverantwortliche 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 Produktdokumentation eine große Rolle.
— —Der Produktverantwortliche
Eine Produktdokumentation 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 Produktdokumentation 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 Produktverantwortliche muss sein Team überzeugen, dass eine Produktdokumentation bereits beim Projektstart notwendig ist.
Die Produktdokumentation 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 Produktverantwortliche
Er erklärt dem Team, dass die Produktdokumentation 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 Produktdokumentation 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 Produktverantwortlichen 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 Produktverantwortliche 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 Produktverantwortliche 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 Produktverantwortlichen kann er immer besser einschätzen, was machbar ist und wie schnell es wirksam für die Nutzer des IT-Systems wird.
Der Produktverantwortliche 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 Produktdokumentation zu pflegen. In Sprint 5 haben sie darum eine Maßnahme aus der Retrospektive umgesetzt, die Produktdokumentation in zwei Teile zu spalten. Der Produktverantwortliche 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öffentlich 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 Produktverantwortlichen angenommen und lesen regelmäßig die Produktdokumentation.
Durch den Einsatz von cards+ wird bereits beim Projektstart der Grundstein für eine Produktdokumentation gelegt. Gleichzeitig gab der Produktverantwortliche damit auch das Versprechen, eine vollständige Produktdokumentation 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 Produktverantwortliche 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 Produktdokumentation.