Können User Stories die nachhaltige Dokumentation ersetzen?

Das Problem mit der fehlenden Anforderungsspezifikation

In der agilen Entwicklung gibt es keine Anforderungsspezifikation, wie üblicherweise in Wasserfall-Projekten. Stattdessen schreibt man User Stories und Epics, um den Entwicklern so zu vermitteln, was das Produkt können soll. Diese enthalten jedoch nicht denselben Detaillierungsgrad wie eine Anforderungsspezifikation, weil gemäss den agilen Prinzipien die Kommunikation vor allem direkt mündlich statt schriftlich erfolgen soll. User Stories und Epics bestehen nur aus einem Titel, einer Beschreibung und den Akzeptanzkriterien. Häufig sind zusätzliche Infos in Links und Kommentaren angefügt.

Die fehlende Anforderungsspezifikation in agilen Vorhaben ist ein Problem, wenn beispielsweise eine komplexe Funktion geändert werden soll. Denn dafür werden häufig Informationen zu den Business Rules benötigt. Diese sind jedoch, wenn überhaupt dokumentiert, meist in mehreren User Stories beschrieben. Oder sie sind in den Kommentaren versteckt respektive in einem Epic erfasst, dort aber nicht detailliert genug beschrieben. Die einzige Möglichkeit, nachträglich an die Information im Code zu gelangen, ist ein Reverse Engineering. Das ist jedoch sehr zeitaufwendig und daher kostenintensiv. In komplexen Systemen fällt derselbe riesige Aufwand jedes Mal an, wenn ein Bug gefixt, ein Change oder eine neue Funktion implementiert werden müssen.

Warum fehlt im agilen Vorgehen die Anforderungspezifikation?

Was genau erklärt das Fehlen einer Anforderungsspezifikation im agilen Vorgehen?

• Im Gegensatz zum Wasserfall-Vorgehen ist die Anforderungsspezifikation nicht automatisch ein Ergebnis des Prozesses. Es ist unklar, wer die Anforderungsspezifikation schreiben soll, weil es beispielsweise in Scrum, dem meistverbreiteten agilen Framework, die Rolle des Requirements Engineers nicht gibt.
• Zudem berufen sich Agile Teams oft auf das Agile Manifest. Eine Aussage daraus ist «Funktionierende Software wird höher geschätzt als umfassende Dokumentation». Dies wird häufig interpretiert als «Es braucht gar keine Dokumentation».
• Im Vorhaben herrschen Zeit- und Budgetdruck. Die Entwicklung neuer Funktionalität wird priorisiert, weil der Dokumentation nicht viel Wert beigemessen wird.

Die Lösung ist eine nachhaltige Dokumentation

Um dem, in der Einleitung angesprochenen zusätzlichen Reverse Engineering Aufwand in agilen Vorhaben entgegenzuwirken, braucht es eine nachhaltige Dokumentation. Gemäss Duden bedeutet nachhaltig «sich auf längere Zeit auswirkend». Es handelt sich also um Dokumente, deren Nutzen erhalten bleibt, wenn die Entwicklung beendet ist. Das sind typischerweise die Anforderungsspezifikation sowie die System- und Produktdokumentation. Diese Dokumente haben die oben beschriebene Problematik, dass sie oft erst im Nachgang verfasst werden und dadurch einen hohen Aufwand verursachen.

• Die Anforderungsspezifikation beschreibt die Aussensicht des Produkts, also was die Software leisten und was umgesetzt werden soll. Sie unterstützt die Wartung und Pflege des Produkts.
• Die Systemdokumentation (Architektur, Design, Test) beschreibt die Innensicht des Produkts, also wie die Software funktioniert und warum gewisse Entscheidungen getroffen worden sind. Sie hilft bei der Entwicklung, der Weiterentwicklung und bei der Überprüfung der Software.
• Die Produktdokumentation (wie z. B. Benutzerhandbuch, Installationshandbuch oder Betriebshandbuch) betrachtet das Endprodukt, das es zu erstellen gilt. Sie umfasst all die Dokumente, die den Betrieb und die Nutzung der Software beschreiben.

Abbildung 1: Innen- und Aussensicht

Im Folgenden liegt der Fokus auf der Anforderungsspezifikation. Wie kann diese konkret umgesetzt werden?

1. Das Entwicklungsteam erkennt den Mehrwert einer Anforderungsspezifikation, die die wesentlichen Business Rules (Geschäftsregeln) und getroffenen Entscheidungen enthält.
   Die Form und der Granularitätsgrad sollen das Zielpublikum berücksichtigen. Nicht alle können formalisierte Modelle lesen. Es lohnt sich, iterativ vorzugehen und früh vom Stakeholder Feedback einzuholen, um die optimale Granularität zu finden.
   Die Sprache muss adressatengerecht sein. Konkret heisst dies z. B., technische Ausdrücke auf Produktebene zu vermeiden und das offizielle Glossar zu verwenden.
2. Die Dokumentation wird im agilen Vorgehen integriert, indem die Aktualisierung der Anforderungsspezifikation Teil der «Definition of Done» (DoD) oder der «Definition of Ready» (DoR) wird. Damit wird sichergestellt, dass bei der Umsetzung jeder User Story die dazugehörige Dokumentation geschrieben wird. Darüber hinaus ist die Frage nach der Verantwortlichkeit auch geklärt; das Entwicklungsteam ist verantwortlich, dass die DoD erfüllt ist.
3. Das Dokumentationstool bietet mehreren Usern die Möglichkeit, gleichzeitig Änderungen zu machen, sprich ist multiuserfähig und verwaltet automatisch den Versionsverlauf. Ein Wikisystem wie Confluence, das sehr gut in Jira integriert ist, erfüllt diese Anforderungen beispielsweise.

Effiziente Weiterentwicklung des Produkts

Um eine komplexe Funktion zu ändern, ist kein teures Reverse Engineering mehr notwendig. Die klassische Anforderungsspezifikation mag im agilen Umfeld untergegangen sein, weil sie nicht mehr direkt entwicklungsrelevant ist. Aber es ist falsch zu meinen, User Stories könnten diese komplett ersetzen. Vielmehr ist die Lösung eine nachhaltige Dokumentation – konkret, eine am neuen Softwareentwicklungsprozess ausgerichtete Anforderungsspezifikation. Wichtig dabei ist, dass deren Aktualität sichergestellt ist. Ist dies der Fall, bietet eine solche Anforderungsspezifikation eine grosse Unterstützung bei der effizienten und kostengünstigen Weiterentwicklung des Produkts.

• Kennst du dieses Problem aus deinem Umfeld? Unsere erfahrenen Consultants helfen dir gerne weiter. Wir freuen uns auf deine Kontaktaufnahme.

Quellen:
https://rainergrau.com/
https://www.sophist.de
https://blog.hood-group.com