Agile Entwicklung und Anforderungsdokumentation ein Widerspruch? Die Dokumentation von Anforderungen ist eine Schlüsselaktivität im Requirements Engineering. Sie dient als wichtige Informationsquelle des Anforderungsmanagements. Doch trotz der allgegenwärtigen Rolle von Anforderungsdokumenten ist der Begriff „Dokumentation“ in agilen Umgebungen eher unbeliebt. Eine schlechte Dokumentationspraxis ist oft das Ergebnis einer Abneigung gegen das Dokumentieren. Während die sich daraus ergebenden Probleme einer schlechten Dokumentation wiederum die Überzeugung stärken, dass die Dokumentation von Anforderungen der agilen Entwicklung abträglich ist. In dieser fünfteiligen Serie von Blog-Artikeln untersuchen wir, wie die Anforderungsdokumentation agil bleiben kann, ohne Chaos zu verursachen.
Dieser Blog-Post ist der zweite Teil einer fünfteiligen Serie von Artikeln zum Thema Anforderungsdokumentation.
① Warum eine Anforderungsdokumentation erstellen?
Teil 1 untersucht, warum Anforderungen überhaupt dokumentiert werden.
② Der Mythos „Keine Dokumentation“ für agile Anforderungen
Teil 2 untersucht, wie die Anforderungsdokumentation agil bleiben kann, ohne Chaos zu verursachen.
③ Typische Herausforderungen bei der Dokumentation agiler Anforderungen
Teil 3 untersucht wie Dokumentation eine konstruktive Rolle in einer agilen Umgebung spielen kann.
④ Dokumentationsumfang eingrenzen bei der Dokumentation agiler Anforderungen
Teil 4 untersucht, wie das Chaos verhindert wird, dass durch ein Auswuchern der Dokumentation entstehen kann.
⑤ Welche Art von Werkzeugen benötige ich für die Anforderungsdokumentation?
Teil 5 untersucht, welche Werkzeuge für die Anforderungsdokumenationen verwendet werden, um in agilen Kontexten eine Bereicherung darzustellen.
Im ersten Teil haben wir untersucht, warum Anforderungen überhaupt dokumentiert werden. In Teil 2 analysieren wir nun, warum teilweise gegen Dokumentation in agilen Umgebungen argumentiert wird. Wir wollen damit versuchen, gewisse Missverständnisse auszuräumen. Die Basis agiler Entwicklung ist eine Beschreibung von vier Werten, in der ein bestimmter Aspekt der Softwareentwicklung stärker betont wird als ein anderer:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Besonders der zweite Wert wird oft fehlinterpretiert, indem er als „Funktionierende Software statt umfassender Dokumentation“ gelesen wird und argumentiert wird, dass es bei der agilen Entwicklung keine oder kaum Dokumentation gibt. Dies ist ein Trugschluss, denn das ist nicht das, was mit „mehr als“ gemeint ist.
Man stelle sich vor, es wäre korrekt, dass „mehr als“ bei diesen vier Werten tatsächlich „statt“ bedeuten würde. Ein agiles Team wäre dann eine Gruppe interagierender Individuen, die keinerlei Prozesse befolgen oder keinerlei Werkzeuge verwenden; sie hätten nicht einmal regelmäßig geplante Meetings, sondern würden nur spontan kommunizieren. Auch würden sie mit Kunden ohne jegliche rechtliche Basis zusammenarbeiten. Da sie keinerlei Plan hätten, hätten sie keine Ahnung, um was es geht und würden blind auf jede auftretende Veränderung reagieren. Es wäre eine wahrlich wundersame Leistung, wenn aus einer solchen Anarchie überhaupt eine funktionierende Software hervorgehen würde.
Es ist also offensichtlich, dass bei diesen vier Werten der agilen Entwicklung nicht „statt“ gemeint ist. Vielmehr weisen sie darauf hin, dass es, wenn eine Entscheidung zwischen dem einen und dem anderen Aspekt getroffen werden muss, es eine klare Präferenz gibt. Und obwohl diese Aspekte den anderen untergeordnet sind, heißt das nicht, dass sie unwichtig sind.
In der Praxis zeigt sich, dass der Einsatz von Prozessen und Werkzeugen bei der agilen Entwicklung gang und gäbe ist, dass Vertragsverhandlungen in vielen Fällen wichtig sind, und dass typischerweise ein klarer Plan verfolgt wird. Was die Werte jedoch vorgeben, ist, dass jeder dieser Aspekte fallen gelassen werden sollte, wenn Bedarf an seinem höherwertigen Gegenstück entsteht. Das bedeutet, dass Prozesse und Werkzeuge niemals vorschreiben dürfen, wie Individuen arbeiten und interagieren; dass Vertragsverhandlungen nicht die Zusammenarbeit mit dem Kunden bestimmen oder dominieren; und dass der Plan, der normalerweise befolgt wird, sofort fallen gelassen wird, wenn eine schnelle Reaktion auf Veränderungen erforderlich ist.
In ähnlicher Weise sollte es in agilen Umgebungen auch Dokumentation geben, und diese sollte so umfassend sein, wie es ‚ideal‘ ist; nicht mehr und nicht weniger. Diese ideale Situation ist dadurch gekennzeichnet, dass die Software letztendlich gut funktionieren sollte. Das heißt, bei dieser (umfassenden) Dokumentation geht es in erster Linie darum, sicherzustellen, dass alle Eigenschaften eines Systems vorgegeben sind und implementiert werden können, wobei all seine funktionalen Aspekte und Qualitätseigenschaften erfüllt sind.
Es ist kein Zufall, dass „funktionierende Software“ und „umfassende Dokumentation“ sich im gleichen agilen Wert befinden. Sie sind eng miteinander verbunden. Letztlich trägt die Dokumentation zum langfristigen Erfolg eines Systems bei und sichert diesen. Bei der Konzeption von agilen Ansätzen war nie die Rede davon, dass sie keine Dokumentation haben sollen. Dieses Missverständnis ist eines der hartnäckigsten im Bereich agile Entwicklung. Uns ist allerdings auch bewusst, dass es in agilen Entwicklungsumgebungen besondere Herausforderungen gibt, wenn es um die Dokumentation von Anforderungen geht. Im nächsten Teil dieser Serie berichten wir über typische Herausforderungen und konstruktive Lösungen in dieser Hinsicht.