Konzept

Refit Agile stellt einen Ansatz für agile Produktentwicklung vor, bei dem die übliche Adaption des agilen Vorgehensmodells um wertvolle Anteile der klassischen Verfahren ergänzt, also "nachgerüstet" wird. Dabei wird ein Leitsatz des agilen Manifestes, nämlich "Funktionierende Software ist wichtiger als umfassende Dokumentation" insofern relativiert, als eine gleichwertige Bedeutung der beiden Aspekte propagiert wird. Die erhöhte Bedeutung einer "effektiven" Dokumentation in der agilen Softwareentwicklung wird dann klar, wenn man Dokumentation nicht mehr als finalen Endpunkt von linearen Planungsschritten ansieht, sondern als wirksames Mittel, um bei einer kontinuierlichen agilen Planung von Lösungsoptionen eine wertvolle Unterstützung zu garantieren.

Üblicherweise wird Dokumentation als eine Tätigkeit zur Konservierung von Wissen und Erkenntnissen verstanden, die sich im Lauf der der Entwicklung ergeben. Aber es gibt auch Arten von Dokumenten, die zur Steuerung der Tätigkeiten in der Entwicklung dienen, welche im agilen Kontext nur für den kurzen Zeitraum einer Iteration eine Bedeutung haben, und zwar vor allem zur Planung und zur Unterstützung der Kommunikation des Entwicklungsteams. Ist die Iteration abgeschlossen, werden diese Dokumente im Rahmen der weiteren Entwicklung nicht weiter beachtet und veralten schnell. Für die nächste Iteration werden zur technischen Planung der Lösungsoptionen wieder spontan neue kurzfristige Dokumente erstellt, ohne auf eine aktuelle und vollständige Referenzdokumentation zurückzugreifen.

Somit ergibt sich im agilen Kontext meistens die Situation, daß zur Steuerung der Entwicklung nur provisorische Texte und Skizzen zur Unterstützung der Kommunikation erstellt werden, die zur Bewertung von Lösungsoptionen im Rahmen des bis dahin realisierten Gesamtsystems weder den Überblick noch die Präzision bieten, wie es eine direkte Verwendung der Referenzdokumentation des gesamten aktuellen Systemzustandes erlauben würde. Erst nach der erfolgreichen Umsetzung einer Lösung erfolgt dann die nachträgliche Aktualisierung der Dokumentation - wenn überhaupt - im Rahmen der Definition-Of-Done.

Aus Sicht des Autors ergibt sich hieraus ein Nachteil bei der Qualität der Entscheidungsfindung zur Bewertung von unterschiedlichen Lösungsoptionen. Es ist ein höherer mentaler Aufwand zu erwarten, wenn die technische Planung auf der Basis von provisorischen Artefakten mit ihren zwangsläufigen Abstraktionen und Ungenauigkeiten erfolgen muss, anstatt anhand der direkten Verwendung einer aktuellen Referenzdokumentation mit einer hohen Güte.

Refit Agile propagiert deshalb ein Konzept von Dokumentation im agilen Kontext, das zur Steuerung der Entwicklung auf einem Reifezyklus von Artefakten aufbaut, die als effektive Planungsgrundlage in jeder Iteration auf Basis einer stets aktuellen Referenzdokumentation identifiziert werden. Der Reifegrad bildet hierbei den Status der Artefakte in Bezug auf die Tauglichkeit eines Lösungsansatzes ab, der sich während der Implementierung mehrfach ändern kann. Die zur Planung erforderlichen Artefakte werden zu Beginn einer Iteration als Entwurf identifiziert oder neu erstellt. Der Zyklus der beteiligten Artefakte endet für diese Iteration, wenn die Lösungsoption erfolgreich umgesetzt und somit der Stand der Codebase mit dem Stand der Artefakte übereinstimmt.

Eine bewusste Trennung von Aktivitäten im Problemraum und im Lösungsraum hilft dabei, sich über den eigentlichen Bedarf oder die wesentlichen Anforderungen der Kunden bewusst zu werden und für die konkreten Nutzungskontexte eines Produktes die passende Lösung zu finden.

Die agile Produktentwicklung kann man so in die miteinander verschränkten Aktivitäten "Problem Discovery" als Erkundung des Problemraums und "Solution Delivery" als kontinuierliche Erstellung im Lösungsraum unterteilen, wofür sich mittlerweile die Bezeichnungen  Dual Track Agile  oder auch  Discovery & Delivery  etabliert haben:

• Bei der Problemerkundung geht es darum, Entscheidungen darüber zu treffen, was gebaut werden soll. Dazu werden in der Discovery Loop bekannte Probleme aus Sicht der Kunden formuliert und Hypothesen dazu aufgestellt, mit welchen Ideen man einen wirksamen Nutzen erzielen könnte. Durch lösungsneutrale Formulierungen der Ideen vermeidet man eine unnötige Einengung des Lösungsraums.
• Bei der Lösungserstellung geht es darum, wie ein Produkt mit hoher Qualität zu bauen und auszuliefern ist. Dazu werden in der Delivery Loop geeignete Methoden angewendet, um möglichst effiziente Lösungen zu den gefundenen Ideen umzusetzen und mit den Ergebnissen die Hypothesen aus der Problemerkundung zu bestätigen oder zu verwerfen.
• Diese beiden Tätigkeiten werden dabei über den sogenannten Options Pivot koordiniert, bei dem darüber entschieden wird, ob abhängig von den Ergebnissen entlang von bestätigten Hypothesen die Lösungserstellung mit weiteren Iterationen fortgesetzt wird oder in einer neuen Problemerkundung weitere Hypothesen ausprobiert werden sollen. Auf diese Art kann durch kontinuierliches Lernen aus den Erfahrungen mit den Ergebnissen bei den Nutzern eine ständige Produktverbesserung erzielt werden.

Die beiden Bereiche stehen also in einem Abhängigkeitsverhältnis, welches sich daraus ergibt, dass als Ergebnis der Problemerkundung die Produktziele für mehrere Planungsebenen an die Lösungserstellung übergeben werden. Dieser Übergabepunkt zwischen Problemerkundung und Lösungserstellung wird organisatorisch meistens als Backlog in Form einer priorisierten Liste von Anforderungen realisiert, die je nach konkreter Ausprägung schon mit favorisierten Lösungsoptionen dekoriert werden können.

In einem Artikel über Architektur und Design im Softwareengineering beschreibt Uwe Friedrichsen die Unterscheidung zwischen Problemerkundung und Lösungserstellung als zwei Teile einer Transformation [1]. Zusammengefasst geht es aus seiner Sicht insgesamt darum, alle existierenden Anforderungen in eine Lösung zu transformieren. Im ersten Teil dieser Transformation - der Problemerkundung - geht es darum, die ganzen Anforderungen zu verstehen, auszubalancieren und eine geeignete Lösungsidee für all diese ausbalancierten Anforderungen zu finden. Der zweite Teil der Transformation - die Lösungserstellung - besteht darin, die Lösungsidee in eine geeignete Struktur zu bringen, welche die Wartbarkeit und Änderbarkeit für den gesamten Lebenszyklus eines kontinuierlich verbesserten Produktes unterstützt.

Eine in dieser Hinsicht geeignete Struktur wird im Softwareengineering idealerweise durch eine Systemarchitektur mehr oder weniger formal beschrieben. Während eine Architektur nach dem klassischen Ansatz plangetrieben in einem Big-Design-Up-Front (BDUF) Ansatz so erstellt wird, dass sie die einmal ermittelten Anforderungen erfüllt, entsteht im agilen Kontext eine "emergente Architektur", die durch eine inkrementelle Lösungserstellung kontinuierlich bestätigt oder verworfen wird. Einen wesentlichen Anteil bei der Lösungserstellung muss dabei ein kontinuierliches Redesign bzw. Refactoring einnehmen, bei der sich die Architektur auf unterschiedlichen Granularitätsebenen an die immer besser verstandenen Anforderungen anpassen kann, um die oft unumgänglichen technischen Schulden zu begrenzen

Laut einem Artikel über Dokumentation im agilen Systems Engineering [2] ist es wichtig zu klären, welche Dokumentation in einem bestimmten Kontext notwendig und hilfreich zur Lösung eines Problems ist, also welchem Zweck die Dokumentation letztendlich dienen soll, um kein Selbstzweck zu sein. Nach den Ausführungen im Artikel ergeben sich primär folgende Zwecke, wenn man den Kontext speziell auf die Entwicklung eingrenzt und von regulatorisch relevanter Dokumentation absieht:

1. Dokumentation zur Steuerung der Tätigkeiten in der Entwicklung. Es handelt sich dabei um Dokumentation, die für die Kommunikation des Teams erforderlich ist und die einzelne Teammitglieder möglicherweise zum Durchdenken benötigen.
2. Dokumentation zur Konservierung von Wissen und Entwicklungserkenntnissen. Es handelt sich dabei um Dokumentation, die möglicherweise zu einem späteren Zeitpunkt für Folgeprojekte oder die Neuerstellung des Produktes benötigt wird.

Weil sich die oben beschriebenen Aktivitäten Problemerkundung und Lösungserstellung mit zwei verschiedenen Aspekten des gleichen Produktes befassen, spiegelt sich diese Unterscheidung auch in der jeweiligen Art ihrer Dokumentation wider. Eine Analyse der Zwecke von Dokumentation für die beiden Bereiche ergibt Folgendes:

• Bei der Problemerkundung werden die Anforderungen an die Funktionalität des Produktes beschrieben, was im Artikel der Dokumentation zur Steuerung der Entwicklungsaktivitäten zugeordnet wird. Es gibt jedoch keinen zwingenden Grund, diese Dokumentation nicht auch als Entwicklungserkenntnisse zu konservieren.
• Bei der Lösungserstellung werden die hierzu erforderlichen technischen Strukturen mit standardisierten Modellierungen beschrieben, was im Artikel der nachträglichen Dokumentation von Entwicklungserkenntnissen zugeordnet wird. Auch hier macht es Sinn, die geplanten Modelle als Entwurf zur Steuerung der Entwicklungsaktivitäten zu benutzen, da sie für die Kommunikation und das Durchdenken von Lösungsoptionen inenrhalb des Teams sehr hilfreich sind.

Es gibt also insgesamt betrachtet keine zwingende Notwendigkeit, eine Trennung zwischen der Dokumentation zur Steuerung und der Dokumentation zur Konservierung auf die unterschiedlichen Arten der Dokumentation im Problemraum und im Lösungsraum abzubilden.

Als besonderes Beispiel seien die detaillierten User Stories als formale Anforderungsartefakte genannt, die bei entsprechender Verwendung in beiden Bereichen ihren Zweck erfüllen. Die Beschreibung der gewünschten Interaktionen des Nutzers mit dem Produkt gehört dabei noch zum Problemraum, während die technische Beschreibung der Anwendungskomponenten auf der Benutzeroberfläche schon zum Lösungsraum gehört. Wenn man diese Artefakte so verwendet, dass sie in einem ersten Teil die lösungsneutralen Interaktionen des Nutzers und in einem zweiten Teil die Akzeptanzkriterien in Form von Bedienungssequenzen enthalten, dann wandern diese Dokumente aus der Problemerkundung in den Bereich der Lösungserstellung und dienen sowohl zur Steuerung der Entwicklung als auch zur Konservierung einer Beschreibung der Benutzeroberfläche. 

Refit Agile fokussiert sich nun auf den Bereich der Produkterstellung mit dem Zweck der Steuerung der Entwicklungstätigkeiten, wobei die Konservierung von Entwicklungserkenntnissen teilweise automatisch mit einbezogen wird, wie noch gezeigt werden wird. Die Kriterien für eine "effektive" Verwendung von Dokumentation in diesem Sinne lauten:

• Sie soll ein wirksames Mittel sein zur Beschreibung des Lösungsraumes bei der Iterationsplanung
• Sie soll ein wirksames Mittel sein zur Bewertung einer favorisierten Lösungsoption in Bezug auf die Minimierung von technischen Schulden
• Sie soll sich inkrementell ergänzen zu einer Referenz, welche mit zunehmendem Reifegrad die obigen Ziele im Sinne hochwertiger Entscheidungen unterstützt

Bei Refit Agile wird also nicht zwischen Dokumentation zur Steuerung und zur Konservierung unterschieden, sondern es wird nur von einer effektiven Dokumentation ausgegangen, mit der alle Artefakte gemeint sind, die zur Planung eines neuen Ausbauzustandes des Systems während der aktuellen Iteration modifiziert werden. Das Ziel ist dabei identisch mit dem Ziel aus dem Artikel beim Verzahnen von kurzlebiger mit langlebiger Dokumentation, um  "zu jedem Zeitpunkt der Systementwicklung über die zu diesem Zeitpunkt relevanten Teile der Dokumentation zu verfügen." Bei der technischen Realisierung dieser effektiven Referenzdokumentation können Ansätze wie Docs-as-code die Einbindung der Dokumentation in die Toolchain der Entwicklung unterstützen, indem die Arbeit an den Artefakten genauso wie die Arbeit an der Codebase behandelt wird.

Waren bei der klassischen Projektmethode überwiegend Spezialisten mit der Bearbeitung der jeweiligen Projektphasen befasst, die ihre Arbeitsergebnisse in Form von spezialisierter Dokumentation an die Kollegen der nachfolgenden Phasen weitergegeben haben, ist bei den agilen Methoden eine Unterstützung der Kommunikation innerhalb der Entwicklungsteams sinnvoll, deren Mitglieder sich bei einem Iterationswechsel ebenso der Herausforderung einer iterativen Planung stellen müssen.

Speziell bei der Entwicklung komplizierter technischer Systeme, in der unterschiedliche Gewerke aufeinander treffen und mehrere Teams gemeinsam ein funktionierendes System abliefern sollen, ist ein auch gemeinsames und präzises Verständnis für das Gesamtsystem von essenzieller Bedeutung. Wie oben dargelegt wurde, soll anhand einer effektiven Dokumentation, deren Artefakte sich inkrementell ändern, die Entwicklung hin zu einem neuen Ausbauzustand des Systems möglichst flexibel geplant werden.

Der folgende Ablauf skizziert das Prinzip einer Steuerung der Lösungserstellung mit Artefakten, wenn eine priorisierte Anforderungsliste in Form eines Backlogs als Schnittstelle zwischen Problemerkundung und Lösungserstellung vorausgesetzt wird und die wichtigsten Backlog Einträge in Form von User Stories vorhanden sind: 

1. Die für ein Inkrement notwendigen User Stories werden nacheinander aus dem Backlog zur Bearbeitung ausgewählt
2. Wenn die ausgewählten User Stories noch nicht als Artefakt im Repository existieren, werden diese dort initial angelegt
3. Es werden weitere Artefakte identifiziert, die zur Umsetzung der jeweiligen User Stories modifiziert oder neu angelegt werden müssen
4. Es werden digitale Tracker auf die schon existierenden oder neu angelegten Artefakte mit aussagekräftigen Namen erstellt
5. Die zur Umsetzung der User Stories notwendigen Erweiterungen werden durch Modifikationen der betroffenen Artefakte geplant
6. Die geplanten Erweiterungen werden gemäß der modifizierten Artefakte implementiert oder es wird bei Problemen der vorherige Schritt wiederholt

Bei den meisten Entwicklungsschritten diskutieren oft Beteiligte mit unterschiedlichem Wissen über die erforderlichen Erweiterungen in Bezug auf dasselbe Ausgangssystem auf Basis der vorliegenden Artefakte einer aktuellen Referenzdokumentation. Die so geplanten Modifikationen an der Codebasis müssen sich während der Implementierung erst bewähren, wobei es jederzeit bei negativen Erfahrungen zu einem Revisionsbedarf der Artefakte kommen kann. Diese Revision kann nur durch erneute Beratung der betroffenen Entwickler bzw. Spezialisten durchgeführt werden. Damit dieses Wechselspiel zwischen der Beratung erforderlicher Teammitglieder über die Revision einer geplanten Lösungsoption und der sich entwickelnden Implementierung durch das gesamte Team effektiv gesteuert werden kann, koordinieren sich alle Beteiligten über den Status der betroffenen Artefakte, die jeweils einen Reifegradzyklus durchlaufen.

Da über den Status der Realisierung der Artefakte im Dokumentenrepository ohne Weiteres keine Annahmen getroffen werden können, übernehmen die digitalen Tracker auf die identifizierten Artefakte sowohl die Rolle der präzisen Referenzierung im Repository als auch der Indikation des aktuellen Status im Verlauf eines flexiblen Reifegradmodells. Allerdings ist von entscheidender Bedeutung für die agile Arbeitsweise, den dynamischen Charakter im Umgang mit derart interpretierten Artefakten zu verstehen. Ein Kennzeichen agilen Arbeitens ist ein exploratives Vorgehen, bei dem ein zunächst geplanter Ansatz durch die gewonnenen Erkenntnisse während der Entwicklung überarbeitet wird, wobei die zur Planung dienende Artefakte unterschiedliche Reifegrade durchlaufen. Die Reifegrade der Artefakte spiegeln den Fortschritt des Entwicklungsteams bei der Findung einer Lösung wider, die sich möglichst nahtlos in den bestehenden Ausbauzustand des Gesamtsystems einfügen lässt.

Ein derart zur iterativen Planung der inkrementellen Entwicklungstätigkeiten genutztes Dokumentenrepository fügt sich ganz automatisch zu einer aktuellen Referenzdokumentation zusammen, für die man  -  wie in der vorangegangenen Betrachtung angedeutet - von einer kontinuierlichen Dokumentation sprechen kann. Der vielleicht wichtigste Aspekt dieses Ansatzes liegt aber darin, dass sich aufgrund der ständig aktualisierten Artefakte ebenso zwanglos eine hervorragende Basis zur Beurteilung und bewussten Entscheidung zur Aufnahme oder Reduktion von technischen Schulden ergibt.

Die folgende Grafik soll das Vorgehensmodell von Refit Agile anhand eines Reifezyklus von Artefakten visualisieren:

Der Artefakt Reifezyklus beginnt in jeder Iteration neu auf Basis der in allen vorherigen Iterationen aktualisierten Artefakte. Die Aktualität ist so lange sichergestellt, wie darauf geachtet wird, dass die Iterationen erst dann beendet werden, wenn alle in Bearbeitung gewesenen Artefakte im Zustand "Bereit" sind. Beginnend mit dem Reifegrad "Neu" für die zu einer User Story identifizierten Artefakte entwickelt sich der Reifegrad über "Entwurf", "Abgestimmt" und eventuell "Revision" wieder zu "Bereit".

Wie in allen agilen Verfahren üblich beginnt der Zyklus mit einem zur Bearbeitung ausgewählten Produkt Backlog Eintrag, bei dem es sich überwiegend um eine User Story handelt. Je nachdem, ob die Beschreibung der ausgewählten User Story schon als Artefakt existiert oder nicht, wird dieses im Repository angelegt und ein Tracker auf dieses Artefakt erstellt. Diese Initialisierung und der folgende Zyklus geschieht bei allen ausgewählten Backlog Einträgen.

Im Folgenden wird der Zyklus exemplarisch für eine User Story besprochen. Die Schritte beziehen sich auf genau die Aktivitäten, die sich mit den jeweiligen Artefakten im entsprechenden Reifegrad befassen.  Je nach Verlauf der Umsetzung kann der Schritt "Beratung" entweder ausfallen oder mehrmals notwendig werden, wenn sich die gewählten Lösungsoptionen nicht bewähren.

1. Planung (Beginn einer Iteration): Es wird im Rahmen einer Lösungsoption zur Umsetzung einer User Story identifiziert, welche weiteren Artefakte betroffen sind, also wo bestehende Inhalte von existierenden Artefakten geändert oder neue Inhalte ergänzt werden müssen. Für alle Tracker der identifizierten Artefakte wird der Reifegrad auf "Entwurf" gesetzt und darauf geachtet, dass die Tracker ausreichend präzise Benennungen zur geplanten Änderung des entsprechenden Artefaktes bekommen. Bevor eine User Story in die Umsetzung gehen kann, werden die identifizierten Artefakte von Teammitgliedern mit genügend Erfahrung als Entwurf erstellt oder Änderungen an den entsprechenden Artefakten so durchgeführt, dass sie die gewählte Lösungsoption spezifizieren.
2. Beratung (zum Reifegrad "Entwurf"): Das Team führt gemeinsam ein Review über die Entwürfe der geplanten Änderungen durch. Dabei soll sichergestellt werden, dass alle beteiligten Entwickler über die umzusetzenden Änderungen anhand der Artefakte ein gleiches Verständnis der gewählten Lösung erlangen. Wenn alle Entwickler der gewählten Lösungsoption zustimmen, werden die Tracker der entsprechenden Artefakte den zur Umsetzung geneigten Entwicklern zugewiesen und auf den Reifegrad "Abgestimmt" gesetzt.
3. Beratung (zum Reifegrad "Revision"): Der Fall eines Artefaktes mit diesem reduzierten Reifegrad tritt auf, wenn ein Entwickler im Verlauf der Umsetzung die Erfahrung macht, dass der gewählte Lösungsweg suboptimal ist oder gar nicht funktioniert. Die Beratung soll zu einer alternativen Lösungsoption führen. Wenn die beteiligten Entwickler einer Abstimmung zur neuen Lösungsoption zustimmen, werden die Tracker der betroffenen Artefakte erneut auf den Reifegrad "Abgestimmt" gesetzt.
4. Programmierung (zum Reifegrad "Abgestimmt"): Die Entwickler beginnen mit der Umsetzung der ihnen über die Tracker zugewiesenen Artefakte. Abhängig von Ihren Erfahrungen mit dem spezifizierten Lösungsansatz können sie jederzeit eine Revision der Artefakte anstreben, um eine tragfähige Lösung zu finden. In komplizierten Fällen kann es hierbei mehrfach zu einem Wechsel des Reifegrades von "Abgestimmt" und "Revision" kommen, was die entsprechenden Beratungen mit den hierzu notwendigen Entwicklern triggert.

Bei der Umsetzung der identifizierten Artefakte einer User Story sollte der Reifegrad vom jeweiligen Entwickler erst dann auf "Bereit" gesetzt werden, sobald davon auszugehen ist, daß sich die entsprechenden Artefakte bis zum Ende der Iteration nicht mehr ändern. Dies gibt allen beteiligten Entwicklern die Sicherheit, daß sie sich zB auf Interfaces, die sich im Zuge der Umsetzung geändert haben, nun so verlassen können, daß sie ihre Arbeit abschließen können. Der Reifegrad "Bereit" zeigt aber auch an, daß die Artefakte zum Ende der laufenden Iteration wieder den aktuellen Zustand der Codebase wiederspiegeln und so zur Planung der nächsten Iteration tauglich sind.

Wichtig bei diesem Reifegradmodell ist, daß sich in den meisten Schritten der Reifegrad der identifizierten Artefakte schrittweise erhöht, um zunächst die Zusammenarbeit für einen erfolgsversprechenden Lösungsweg zu planen und schließlich am Ende der Iteration mit dem höchsten Reifegrad den Zustand der Systemdokumentation als aktuelle Referenz anzuzeigen.

Quellen:

[1] Uwe Friedrichsen: Was ist der Unterschied zwischen Architektur und Design? (codecentric.de)

[2] C. Rupp, A. Rauh, C. Bock: Continuous Documentation im agilen Systems Engineering (informatik-aktuell.de)