Anforderungsdokumentation (3/5): Typische Herausforderungen bei der Dokumentation agiler Anforderungen

Die Dokumentation von Anforderungen (auch agiler Anforderungen) gehört zu den Kernaktivitäten des Requirements Engineerings. Obwohl die Dokumentation in Projekten mit klassischen Vorgehensweisen selbstverständlich praktiziert wird, meiden viele die Umsetzung bei agilen Entwicklungsprojekten. Die Dokumentation wird als zu großer Aufwand bei wenig Ertrag empfunden. Warum dies so ist und wie die Anforderungsdokumentation dennoch agil bleiben kann, untersuchen wir in dieser Reihe von Blog-Artikeln.

Im ersten Teil haben wir untersucht, warum Anforderungen überhaupt dokumentiert werden. Im zweiten Teil dieser Serie haben wir den Mythos widerlegt, dass in agilen Entwicklungsumgebungen keine Dokumentation stattfinden sollte. In dem Wissen, dass die geistigen Väter der agilen Entwicklung wollten, dass Anforderungen dokumentiert werden, untersuchen wir nun in Teil 3, wie Dokumentation eine konstruktive Rolle in einer agilen Umgebung spielen kann. Zuerst einmal müssen wir allerdings verstehen, welchen Herausforderungen das Requirements Engineering in diesem Kontext gegenübersteht.

Obwohl agile Ansätze zu Verbesserungen in vielen Entwicklungssituationen geführt haben, sind auch neue Herausforderungen entstanden. In einem ausführlichen Überblick wurden etwa 50 Probleme, die in agilen Umgebungen auftreten, in vier Kategorien eingeteilt [18]. Wir beschreiben im Folgenden exemplarisch einige dieser Herausforderungen, die mithilfe guter Anforderungsdokumentationspraktiken abgeschwächt oder bewältigt werden könnten:

Kommunikation und sich ändernde Kultur & Denkweise: Dokumentierte Anforderungen sind ein wichtiger Aspekt in der Kommunikation. Sie dienen oft als Diskussions- und Entscheidungsgrundlage und können somit bei der Lösung von Problemen wie z.B. einer zu engen Bandbreite der Kommunikation helfen.

Gewinnen von Management, Kunden und Teammitgliedern für die Sache: Dokumentierte Anforderungen können als sichtbarer und überzeugender Nachweis der Arbeitsqualität und der geplanten Schritte verwendet werden. Die Dokumentation kann auch hilfreich sein, um die Projektmitglieder besser zu involvieren, was wiederum die Moral heben kann.

Management von alltäglichen operativen Problemen: Die Anforderungsdokumentation bildet die Basis, um eine gute Entwicklung der Anforderungen sicherzustellen, und liefert die Informationen, die für die Durchführung von Anforderungsmanagementoperationen erforderlich sind. Dazu gehört u.a., den Projektfortschritt zu verfolgen und zu visualisieren, Aufwandsschätzungen vorzunehmen und sicherzustellen, dass Testergebnisse vor der Freigabe in die Umsetzung einfließen können.

Sammeln von Erfahrungen und Realisierung: Erfahrung und dokumentiertes Material zum Vergleich sind hilfreich für eine zuverlässigere Budgetierung, für die Wiederverwendung und für die Skalierung auf Großprojekte.

Unsere Industrieerfahrung zeigt, dass Praktiker im Hinblick auf agile Ansätze oft mit Herausforderungen im Zusammenhang mit der Dokumentation von Anforderungen zu kämpfen haben, wie z.B.:

• Warum müssen manche Dinge dokumentiert werden, und welche Teile der bestehenden Dokumentation können als anforderungsrelevant betrachtet werden?
• Wie kann man den Umfang der Anforderungsdokumentation begrenzen, Chaos vermeiden und klare Kommunikation fördern?
• Wie kann man die Verantwortlichkeiten für die Erstellung / Überprüfung von Inhalten am besten zuweisen, und wie können Werkzeuge bei der Strukturierung dieser Informationen behilflich sein?
• Wie wird Anforderungsmanagement (Änderungen, Priorisierung, Releases / Versionierung) in agilen Umgebungen durchgeführt; zum Beispiel, wie kann man effizient mit Änderungsanfragen umgehen und wie lässt sich Tool-Unterstützung einsetzen?

In agilen Umgebungen wird das Requirements Engineering anders angegangen. Die Rolle, die der des Requirements Engineers am stärksten ähnelt, ist der Product Owner (PO). In Umgebungen ohne richtige Anforderungsdokumentation wird diese Rolle auch als eine Art „wandelndes Anforderungsdokument“ angesehen, aber wenn der PO nicht da ist und im Product Backlog keine oder nur mangelhafte Anforderungen verfügbar sind, kennt niemand im Team wirklich die Anforderungen. In solchen Umgebungen ist dies eine der Hauptursachen für Chaos bei agilen Prozessen.

Agile Umgebungen schreiben häufig nicht vor, wer dokumentierte Anforderungen, etwa in Form von User Stories, hinzufügen und bearbeiten darf, damit die Qualität gewährleistet bleibt. Wenn überhaupt vorgegebene Vorlagen vorhanden sind, werden diese oft nicht befolgt, und der PO verbringt keine Zeit damit, sie zu prüfen und abzugleichen. Das bedeutet, dass Qualitätsprobleme bei Anforderungen, insbesondere Mehrdeutigkeit und Inkonsistenzen, nicht gelöst werden.

Ein weiteres Problem ist, dass die Dokumentation zu knapp ist. Obwohl dies das agile Prinzip, dass Teammitglieder die Details kommunizieren müssen, zu bestärken scheint, wird in der Praxis unnötig viel Aufwand betrieben, um Dinge klarzustellen oder mehreren Personen die gleiche Anforderung zu erklären, wenn sie diese nicht verstehen, was dem Ziel der agilen Entwicklung – nämlich die Effizienz zu erhöhen – widerspricht. Hier ist die beste Lösung tatsächlich, mehr Informationen zu dokumentieren. Allerdings wirft dies ein weiteres dringendes Problem auf, dem wir uns im dritten und letzten Teil dieser fünfteiligen Beitragsserie widmen werden: Wie kann man den Umfang der Dokumentation so festlegen, dass die Anforderungsdokumentation in der jeweiligen agilen Umgebung bestmöglich gehandhabt wird und gleichzeitig ein Auswuchern der Dokumentation verhindert wird?

 

Referenzen:

[18] Miller, G. J. (2013). Agile problems, challenges, & failures. Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.