Die Frage, ob und wann ein Produkt “fertig” ist, beschäftigt uns schon seit es Projekte und Projektmanagement für Software-Produkte gibt. Auch im klassischen Wasserfallmodell ist es das wesentliche Ziel, am Ende der Abnahmephase ein für produktive Nutzung geeignetes Produkt zu haben. Agile Methoden unterscheiden sich in diesem Punkt nur durch den Versuch, Probleme am Weg zu diesem Ziel schneller und sicherer erkennen zu wollen und auf wechselnde Randbedingungen und Anforderungen besser und zielgerichteter reagieren zu können. Ob klassisch oder agil, auf dem Weg zum “fertigen” Produkt werden viele wichtige Entscheidungen getroffen. Für die Beurteilung der Vollständigkeit des Produktes definieren und prüfen wir vielfältige Kriterien und Qualitätsmerkmale.

14 Wir sind fertig

Entscheidungen

In einem Projekt ist es ein riesiger Vorteil, wenn Entscheidungen für alle Projektmitarbeiter transparent und nachvollziehbar sind. Gerade bei erfolgreichen Projekten, die lange genug laufen, sodass es spürbare Änderungen in der Organisation gibt (z.B. durch Fluktuation oder budget-getriebenen Auf- und Abbau von Teams), ist es äußerst hilfreich, das Wissen von “Entscheidern” im Projekt zu sichern. Ein Product-Owner als Vertreter des Auftraggebers ist so ein wichtiger Entscheider. Unterstützt von Business-Analysten entscheidet der Product-Owner in der Anforderungsanalyse über den Umfang des Produktes. Aber auch die cross-funktionalen Teams mit ihrer Rolle “Software-Experte” treffen wichtige Entscheidungen im Architekturentwurf und beeinflussen damit maßgeblich die Funktionalität des Produktes. In der Zusammenarbeit mit den Systemadministratoren bestimmen Entscheidungen im Team während der Entwicklung (Stichwort DevOps) über aktuelle und zukünftige Betriebskosten.

Mit dem Baustein Decision dokumentieren wir solche Entscheidungen mit mehr als einer Lösung. Das “Finden” dieser Lösungen ist ein Prozess. Für das Team bedeutet es Arbeit, neben der favorisierten Lösung weitere alternative Lösung zu evaluieren und letztendlich eine gut begründete Wahl zu treffen. Im Wiki dokumentieren wir alle Ergebnisse und den Prozess mindestens mit Zeitpunkt und Begründung.

ktip Eine Entscheidung mit Begründung ist immer “fertig”. Das bedeutet keineswegs, dass sie nicht geändert wird. Diese Veränderung bedeutet aber, dass wir uns ihre Auswirkungen sehr genau anschauen müssen.

Es gibt noch eine ganze Reihe weitere Bausteine, die ebenfalls eine Entscheidung dokumentieren. Der Baustein Topic definiert die “Leitplanken” für ein Projekt. Durch ein Topic legt der Auftraggeber fest, dass das Software-Produkt Lösungen für den beschriebenen Aufgabenbereich haben soll. Mit dem Baustein Epic hat der Product-Owner entschieden, dass eine Anforderung analysiert und eine Umsetzung im Product-Backlog eingeplant und priorisiert werden soll. Im Baustein Case einigen sich Product-Owner unterstützt von Business-Analysten und das Team auf eine ganz bestimmte Lösung für das beschriebene Problem. Mit der Lösung im Case legt sich das Team automatisch auf einen Architekturstil fest, verbunden mit der Auswahl bestimmter Middleware oder Frameworks.

Qualitätsmerkmale

Die Architecture Tradeoff Analysis Method (ATAM) ist eine Methode zur Bewertung von Software-Architekturen. Sie wurde vom Software Engineering Institute (SEI) der Carnegie Mellon University entwickelt und zeichnet sich durch einen strukturierten Prozessablauf aus. ATAM analysiert den Architekturentwurf in Bezug auf Qualitätsmerkmale und liefert eine Einschätzung zu Risiken. Dabei werden Konflikte zwischen qualitativen Zielen aufgezeigt und Zusammenhänge zwischen verschiedenen Qualitätsmerkmalen hergestellt. Einen Überblick über allgemein akzeptierte Qualitätsmerkmale gibt die internationale Norm ISO 25010:2011.

14 Wir sind fertig - Bild1

Qualitätsmerkmale werden in die Kategorien Zuverlässigkeit (englisch: reliability), Effizient (englisch: effciency), Übertragbarkeit (englisch: portability), Funktionalität (englisch: functionality), Benutzbarkeit (englisch: usability) und Wartbarkeit/Änderbarkeit (englisch: maintainability) eingeteilt. Das Qualitätsmerkmal “Konformität” ist zusätzlich in jeder Kategorie vorhanden.

Die Methode CARDS+ bietet zur Erfassung von Qualitätsmerkmalen den Baustein Decision. Jedes Qualitätsmerkmal wird damit erfasst. Neben konkreten Lösungen gibt es immer auch die besondere Lösung, dass das Qualitätsmerkmal für das vorliegende Produkt nicht anwendbar ist. Eine besondere Herausforderung ist jedoch, die mit fachlichen Anforderungen implizit formulierten Qualitätsmerkmale zu erkennen. In der Methode ATAM gibt es einen Arbeitsschritt mit dem Ziel, Anforderungen im sogenannten “UtilityTree” aufzuzeichnen. CARDS+ unterstützt diesen Vorgang, weil der Baustein Epic im Wiki von der Informationsdichte sehr gut zu dieser Analyse passt. In der abschließenden Diskussion der Ergebnisse kann wertvolles Wissen zurück in das Wiki fließen. Die Zuordnung von Epic und Qualitätsmerkmal kann durch ein Stichwort im Wiki festgehalten werden. Mit einem stichwort-basierten Bericht kann jederzeit eine Übersicht über die Verteilung der Qualitätsmerkmale im System erstellt werden.

Eine vollständige und korrekte Produktdokumentation ist ebenfalls ein nicht zu unterschätzendes Qualitätsmerkmal in Bezug auf die Wartbarkeit des Produktes. Mit anderen Worten bedeutet ein Wiki mit Bausteinen der Methode  CARDS+ die Erfüllung der Qualitätsmerkmale Analysierbarkeit, Modifizierbarkeit und Prüfbarkeit der Kategorie Änderbarkeit.

Akzeptanzkriterien

Jede User-Story im Product-Backlog benötigt weitestgehend objektive, vor allem aber prüfbare Akzeptanzkriterien, die den Zustand “fertig” beschreiben. Damit kann der Product-Owner beurteilen, ob die Realisierung der User-Story am Ende eines Sprints erfolgreich war. Zusätzlich beeinflussen aber auch nicht-funktionale Aspekte und Qualitätsmerkmale den Erfolg der Realisierung. Es ist nicht zielführend, diese für das komplette Produktinkrement geltenden Akzeptanzkriterien in jeder User-Story immer wieder gleichlautend einzutragen. Stattdessen einigen sich der Product-Owner und das Team auf einen Katalog von Akzeptanzkriterien, die wir “Definition of Done” (kurz DoD) nennen. Sie definiert den Zustand “fertig” für alle User-Stories im Sprint-Backlog.

Weitere Definitionen für die DoD:

The definition of done is a shared understanding of expectations that software must live up to in order to be releasable into production, managed by the development team.

https://www.scrum.org/Resources/Scrum-Glossary

The definition of done is orthogonal to user acceptance criteria (functional acceptance) for a feature. It is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature. Definition of done is informed by reality where it captures activities that can be realistically committed by the team to be completed at each level (feature, sprint, release).

https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod)

The definition of done is an agreed list of criteria that the software will meet for each product backlog item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse the definition of done with acceptance criteria, which are specific conditions an individual item has to fulfill to be accepted. The definition of done applies uniformly to all product backlog items.

https://less.works/less/framework/definition-of-done.html

Ein Team setzt sich Ziele. Sie wollen generell lesbaren Code erstellen. Die Testabdeckung soll gut sein. Die DoD ist das Versprechen, diese Ziele erreichen zu wollen. Mit dem Einsatz der Methode CARDS+ ist es möglich, neben dem eigentlichen Produkt – also Code, Test und Konfiguration – auch eine Produktdokumentation zu liefern. Dann ist es sinnvoll, die DoD um die wichtigsten Ziele der Methode zu erweitern: Gemeinsame Sprache im Wiki und im Code (u.a. keine Übersetzung von Fachbegriffen im Glossar), alle wichtigen Entscheidungen dokumentieren, Feedback zur Dokumentation geben (evtl. mit dem Hinweis, auf Code-Kommentare zu verzichten und stattdessen die Hinweise ins Wiki schreiben). Besonders hilfreich ist es, wenn die gesamte Projektorganisation, also alle, die am Produkt mitwirken, die Produktdokumentation als integralen Teil des Produktes betrachtet.

Vollständige Dokumentation

Eine Produktdokumentation ist nur dann fertig, wenn sie vollständig ist. Bei der Frage nach der Vollständigkeit dürfen wir aber nicht vergessen, dass wir in einem agilen Projekt nur jene Teile vollständig beschreiben können, die wir in einem Sprint bearbeiten. Ganz allgemein kann eine Produktdokumentation nur am Ende eines Sprints fertig und vollständig sein. Betrachten wir jedoch die einzelnen Bausteine der Methode CARDS+, dann müssen wir die Frage der Vollständigkeit im Zusammenhang mit dem Prozess betrachten, in dem wir den Baustein nutzen, um einen Teil des Produktwissens zu erfassen.

Beginnen wir mit dem Prozess “PM”. Das Kürzel “PM” steht für Projektmanagement, weil Software-Produkte in der Regel im Kontext eines Projektes entstehen. Für den Fall, dass ein Software-Produkt kontinuierlich entwickelt wird, kann “PM” auch für Produktmanagement stehen.

CARDS+ Projektmanagement

Im Prozess “PM” definieren Auftraggeber und Product-Owner gemeinsam, in welchen Aufgabenbereichen der Nutzer das Produkt unterstützen soll. Zur Sicherung dieser Entscheidung und der Motivation des Auftraggebers nutzt der Product-Owner den Baustein Topic. Randbedingungen für das Produkt erfasst der Product-Owner mit dem Baustein Decision, weil es hier neben einer konkreten Lösung immer die zweite Option gibt, dass diese Randbedingung für das vorliegende Produkt nicht zutrifft. Das gleiche gilt für die Definition von Qualitätsmerkmalen oder nicht-funktionale Aspekte. Beide Ergebnistypen des Prozesses “PM” sind nach Abschluss der Bearbeitung fertig. Da dieser Prozess auch in einem agilen Projekt nicht zwingend in einem Sprint stattfindet, wird der Zeitpunkt für den Zustand “fertig” durch den Product-Owner bestimmt.

Der Prozess “RE” steht für alle Tätigkeiten der Analyse von funktionalen Anforderungen und nicht-funktionalen Aspekten. Bei Produkten mit einer Benutzeroberfläche umfasst dieser Prozess auch die Tätigkeiten der Designer und Grafiker, die sich um das Nutzererlebnis (englisch: user experience) kümmern.

CARDS+ Anforderungsanalyse

In diesem Prozess verwenden der Product-Owner und Business-Analysten die Bausteine Epic und Case für die Sicherung der Ergebnisse der Anforderungsanalyse. Die Bausteine Domain, Service, Event und Entity legen die Business-Analysten in Abstimmung mit dem cross-funktionalen Team bereits jetzt an, um eine einheitlich Namensgebung im Produkt zu erhalten. Jetzt ist der richtige Zeitpunkt, weil während der Analyse ein größerer fachlicher Kontext betrachtet wird.

Auffällig ist, dass es im Prozess “RE” keinen Ergebnistyp gibt, der den Zustand “fertig” tatsächlich erreicht (erkennbar am Füllstand der “harvey balls”). Das ist nicht verwunderlich. Ein Epic kann in diesem Prozess nicht abgeschlossen werden, weil wir noch kein Feedback von Entwicklern und Testern haben, dass sie die Beschreibung verstanden haben. Außerdem ist es durchaus üblich, dass erst während der Realisierung noch Sonderfälle entdeckt werden, die eine alternative Lösung erfordern – was wir dann als zusätzlichen Case erfassen. Im Case fehlt die konkrete Lösung, die erst am Ende der Realisierung zu 100% fest steht. In diesem Prozess können wir hier bestenfalls eine Lösungsidee anbieten. Bei den technisch orientierten Bausteinen Service, Event und Entity geht es in diesem Prozess hauptsächlich darum, einen software-tauglichen und fachlich korrekten Namen zu finden. Nur bei einer projektspezifischen Lösung, die wiederholt verwendet wird, können wir konkreter werden. Aber fertig können diese Lösungsbeschreibungen erst nach der Realisierung sein. Ein Baustein Domain kann den Zustand “fertig” erreichen, wenn die Domain nur als Namensraum im Code oder Bezeichner für Konfigurationen (z.B. Git-Repository, Jenkins-Jobs oder Docker-Container) verwendet wird. Beim Baustein Layout hängt der Fertigstellungsgrad davon ab, wie die Ergebnisse der UX-Designer dokumentiert werden. Wenn im Projekt Wire-Frames, fotografierte Paper-Prototypes oder andere Entwurfsergebnisse als Produktdokumentation reichen (was ich persönlich sehr sinnvoll finde und empfehle) und die Details der Realisierung nur über den Code (z.B. XML bei JavaFX oder Android) dokumentiert werden, dann können Layouts in diesem Prozess tatsächlich abgeschlossen werden.

Der Prozess “SCRUM” steht ganz allgemein für ein agiles Vorgehen bei Entwicklung und Test. Scrum habe ich gewählt, weil ich diese Variante aus persönlicher Erfahrung am besten kenne. Es sind aber auch alle anderen Varianten wie Kanban, XP oder die Erweiterungen von Scrum wie Nexus, Less oder Safe möglich.

CARDS+ Realisierung

Der Product-Owner nutzt ein Refinement-Meeting, um Ergebnisse der Anforderungsanalyse aus dem Prozess “RE” einem Teil des Teams zu präsentieren. Er verwendet die Bausteine Layout, Epic und Case. Das Team gibt direktes Feedback, ob die Beschreibung und Darstellung im Wiki verständlich und ausreichend ist. Häufig ergibt sich ein besserer Inhalt aus den Rückfragen des Teams. Ein weiteres wichtiges Arbeitsergebnis ist die Formulierung einer konkreten Lösungsidee im Case. Es ist ganz wichtig, dass das Team bereits jetzt eine grobe Vorstellung der Lösung hat, die im Case festgehalten wird. Wichtige damit verbundene Entscheidungen zu Middleware, Frameworks oder Software-Patterns sind entweder bereits mit dem Baustein Decision dokumentiert oder werden im Meeting rudimentär erfasst. Die erste grobe Schätzung für die Komplexität kann als Kommentar eingetragen werden.

ktip Das Wiki ist hier eine große Erleichterung, weil gemeinsam dokumentiert wird. An einem Beamer kann jeder Entwickler mitlesen, was der Product-Owner schreibt. Die Anwesenden haben direkt die Möglichkeit, unklare Formulierungen zu erkennen und sofort korrigieren zu lassen. Mit dem Wiki bekommen außerdem alle nicht anwesenden Mitglieder des Teams die Chance, die Ergebnisse des Refinement-Meetings jederzeit nachzulesen.

Der Product-Owner nutzt die Ergebnisse, um nach dem Refinement-Meeting die notwendigen User-Stories im Product-Backlog zu erstellen – immer mit dem Verweis auf den zugrundeliegenden Baustein Case oder Layout.

Gleich zu Beginn eines Sprints bespricht das Team im Planning-Meeting die Lösungsidee aus jedem Case oder den Vorschlag für eine Benutzeroberfläche im Layout. Sie besprechen auch die damit verbundenen wichtigen Entscheidungen. Hier wird erneut der Baustein Decision benutzt, um die favorisierte Lösung hervorzuheben und zu begründen. Aber gerade zu diesem Zeitpunkt ist es wichtig, auch die oft nur kurz andiskutierten Alternativen zu erfassen, weil jetzt das Team vollständig vertreten ist und jeder Entwickler die Entscheidung mitträgt – durch sein Commitment beim Start des Sprints. Jetzt gilt: Wer nicht widerspricht, stimmt zu!

Unterstützt durch das agile Vorgehen ist es möglich, im Sprint neben Code und Test für das Produkt auch alle weiteren betroffenen Wiki-Seiten der Produktdokumentation laufend zu aktualisieren. Dieses Vorhaben wird besonders dann gelingen, wenn das Wiki für das Team einen wichtigen Wert darstellt. Einerseits erreichen wir dieses Ziel, wenn die Seiten im Wiki die Arbeit der Entwickler und Tester gut unterstützen. Wichtig ist auch, dass das Team schnell und leicht Feedback zu Inhalten im Wiki geben kann. Dieses wichtige Feedback entsteht beispielsweise beim Pair- oder Mob-Programming, wenn neben dem Code auch der Baustein Case und die dort beschriebene Lösung von den Entwicklern betrachtet wird. Bei der Realisierung einer Benutzeroberfläche ist der Baustein Layout die Vorlage für die Entwickler. Bei einer wesentlichen Abweichung durch die Programmierung wird das Layout noch während des Sprints angepasst. Feedback entsteht auch bei der Umsetzung von Akzeptanz- und Integrationstests für den neuen Code. Tester entdecken in tabellarisch aufgebauten Tests (z.B. mit Fitnesse) besondere Situationen, die ein Business-Analyst in der Anforderungsanalyse nicht erkannt hat.

Jedes Sprint-Ende markiert einen Zeitpunkt, an dem die Produktdokumentation vollständig ist für das Produktinkrement. Sie beschreibt das vorliegende Produkt, nicht mehr, aber auch nicht weniger. Sie ist so lange fertig, bis im nächsten Sprint das nächste Produktinkrement erstellt wird mit der nächsten Version einer vollständigen Produktdokumentation. Wir nutzen diesen Zeitpunkt, um eine baseline für das Produkt und die Produktdokumentation zu erstellen, am besten automatisiert.

Fertige Dokumentation

Im Projekt definieren wir unabhängig von der Methode CARDS+ die Akzeptanzkriterien für das Produktinkrement einmal in Form einer DoD und für jede einzelne User-Story im Zuge des Backlog-Managements. Eine einzelne User-Story im Sprint-Backlog muss am Ende eines Sprints alle spezifischen Akzeptanzkriterien und die DoD erfüllen. Darum zeigt das Team selbst im Review-Meeting dem Product-Owner und anderen interessierten Personen live am funktionierenden System, was es im Sprint erreicht hat. Auf Basis des Gezeigten entscheidet der Product Owner, ob das Ziel des Sprints erreicht wurde. Potentiell kann nun das Produktinkrement produktiv genutzt werden, wenn alle Kriterien erfüllt wurden. Feedback, Lob und Kritik durch den Product-Owner, Stakeholder und andere Anwesenden ist erwünscht und fließt in die weitere Arbeit ein.

Es ist meiner Ansicht nach ausgeschlossen, dass eine geplante Veränderung des Produktes im Rahmen einer User-Story keine Änderungen an der Produktdokumentation nach sich zieht. Selbst bei der Bearbeitung eines Defektes im Code ist im Normalfall eine kleine Anpassung oder Hinweis in der Beschreibung des betroffenen Cases zumindest sehr sinnvoll. Um den Zustand “die Produktdokumentation ist fertig” zu erreichen, ist es wichtig, dass im Review-Meeting ein Mitglied des Teams neben dem Produkt auch die entsprechenden Seiten im Wiki vorführt. Ideal ist es, wenn sie ganz bewusst für die Präsentation des Produktes genutzt und vom Product-Owner abgenommen werden. Dann können wir mit einem guten Gefühl von einer vollständigen Produktdokumentation sprechen, passend zum Umfang des aktuell produzierten Produktinkrementes.

Fazit

Die Bausteine der Methode CARDS+ sind so gestaltet, dass sie das komplette Wissen über das Produkt vollständig aufnehmen können. Reviews, Feedback und die Möglichkeit, im Wiki jederzeit Kommentare zu hinterlassen, sorgen für die notwendige Qualität der Inhalte. Agile Prozesse schaffen den notwendigen Rahmen, das Wissen effizient und zielgerichtet zu erarbeiten. Der Einsatz eines Wiki erlaubt uns, Wissen sofort zu erfassen, wenn es entsteht – auch und vor allem in den Meetings der agilen Methoden: Bei Scrum sind das Refinement-, Planning- und Review-Meeting. Die Struktur des Wiki folgt einem einzigen Ziel: Die Seiten können in einem agilen Prozess fertig gestellt werden. Das bedeutet, dass jede Seite passend zum Prozess genau die Informationen aufnehmen kann, die es gibt. Es müssen keine nicht prüfbaren Annahmen getroffen werden. Die Autoren der Seiten sind immer auch Experten zu diesem Zeitpunkt.

Stimmt die Disziplin und nutzen wir Methode und Wiki zu unserem Vorteil, werden wir am Ende eines Sprints sagen können: Wir sind fertig. Fertig mit dem Produktinkrement, potentiell nutzbar für den Auftraggeber, und der vollständig richtigen Produktdokumentation.