Das klassische Anforderungsmanagement (Requirements Engineering) findet immer noch eine große Akzeptanz in plangetriebenen Projekten. Nach “Wasserfall” ist die lückenlose und eindeutige Analyse und Dokumentation in den unterschiedlichen Projektphasen essenziell, um das Vorhaben möglichst in Zeit und Budget umzusetzen.
Bei der agilen Produktentwicklung steht die Kommunikation im Vordergrund. Interdisziplinäre Teams ersetzen Phasen und Silos, Backlog Items ersetzen Systemanforderungen und dienen eher als temporäres Kommunikationsmedium zwischen allen Beteiligten.
Gibt es in diesem Kontext agiler Zusammenarbeit überhaupt noch Anforderungen?
Nach dem IREB-Standard (International Requirements Engineering Board) ist die Definition einer Anforderung wie folgt:
Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß 1. oder 2.
Auch wenn der Begriff “Anforderung” manch einem Agilisten negativ aufstößt, evt. zu “fordernd” klingt, mit wenig Raum für gemeinsame Gestaltung und Selbstorganisation, so kann nach o.g. Definition auch ein Backlog Item (z.B. in Form einer User Story) als Anforderung gesehen werden. Aber unabhängig von der Begrifflichkeit (Anforderung, Feature, User Story oder Backlog Item) sind wir uns alle einig, dass wir eine priorisierte Liste von dem benötigen, was im Produkt benötigt wird – und das auch nach o.g. Definition.
Richtige Anforderungen und ein gut priorisierter Anforderungskatalog (Backlog) sind unserer Ansicht nach sogar essenzielle Faktoren für den Erfolg der agilen Produktentwicklung.
Was Anforderungsvermittlung im agilen Kontext ausmacht
Die Methoden und Tätigkeiten im Anforderungsmanagement bleiben weitestgehend gleich. Anforderungen müssen ermittelt, dokumentiert, validiert und verwaltet werden. Genauso wie die agilen Prinzipien die Art und Weise der Zusammenarbeit in der agilen Produktentwicklung prägen (siehe agilesmanifesto.org), so müssen sich auch die Tätigkeiten im Anforderungsmanagement an diesen Prinzipien orientieren. Für das Anforderungsmanagement und die agile Herangehensweise der Anforderungsvermittlung (wir bevorzugen den Begriff der Anforderungsvermittlung als Weiterentwicklung des klassischen Requirements Engineering) bedeutet das u.a. das Folgende.
1. Fokussiere Dich auf das aktuell Relevante (“just in time”-Anforderungen)
Die einzelne Anforderung muss erst vollständig beschrieben sein, wenn die Entwicklung des entsprechenden Inkrements startet, in dem die Anforderung umgesetzt werden soll. In Scrum bedeutet das; die Verfeinerung zum “Definition of Ready” ist erst zum Sprint Planning notwendig. Es ist ratsam, Anforderungen für 2 bis 3 Sprints detailliert und priorisiert zu haben. Die restlichen Themen für die Umsetzung können auch nur grob beschrieben sein. Auch in der Anforderungsvermittlung ist “die Kunst, die Menge nicht getanen Arbeit zu maximieren” (Prinzip 10 aus dem agilen Manifest).
2. Habe das Große und Ganze im Auge
Wie kann ich richtige Entscheidungen bzgl. der Priorisierung und der (“just in time”) Detaillierung von Backlog Items treffen, wenn ich mich lediglich auf die kommenden Sprints fokussiere? Das funktioniert natürlich nur, wenn ich auch das große Ganze, das “Big Picture”, kenne und stets im Auge behalte. Der Gedanke, im agilen Kontext starten zu können ohne klarer und abgestimmter Ziele, ist ein typisches agiles Missverständnis (genau wie die Verwendung des Begriffs “MVP” als Rechtfertigungsversuch bei Misserfolg ;).
Insbesondere bei der agilen Produktentwicklung mit einem hohen Grad an Selbstorganisation sind klare inhaltliche Rahmen entscheidend für den Erfolg. Eine klare Bedarfsformulierung, eine Produktvision und eine Kontextabgrenzung sind die Basis dafür (siehe auch Bedarf formulieren).
Das Use Case Diagramm mit einer Übersicht der Akteure, dem Systemkontext und den Anwendungsfällen ist immer noch eine gute Hilfestellung auf der Ebene des “Big Pictures”, nicht nur im klassischen Lastenheft, um Anforderungen und Lösungsraum im nächsten Schritt mit Hilfe von Story Maps weiter zu erforschen.
3. Behalte stets die Sicht des Benutzers
Die agile Produktentwicklung hat dann einen hohen Nutzen, wenn Anforderungslage (bzw. Marktentwicklung) und Technologie noch nicht komplett klar sind und eine vollständige Definition der Lösung keinen Sinn macht. Jeder, der schon einmal mit einem (interdisziplinären) Team zur Lösungsfindung in ein Brainstorming eingestiegen ist, weiß zu schätzen, wie wertvoll diese Art der Zusammenarbeit ist.
Für die Anforderungsvermittlung bedeutet das, noch stärker als bei der klassischen und phasenorienterten Entwicklung, Problem und Lösungsraum zu trennen. Die Formulierung von Bedarfen der Nutzer ist die Basis für den Austausch mit dem Team und der weiteren Einschränkung des Lösungsraums im Rahmen der Produktentwicklung. Das ist auch einer der Gründe, warum sich im agilen Kontext die Verwendung von “User Stories” gegen die Formulierung von (System-)Anforderungen durchgesetzt hat.
4. Dokumentiere!, aber nur das Notwendige
Bei der agilen Produktentwicklung geht es um eine kontinuierliche Weiterentwicklung und das Nutzen von Veränderungen im System und Systemkontext. Die Notwendigkeit für das Erstellen von Entwicklungsartefakten und aufwändiger Dokumentation wird oft in Frage gestellt.
Aber auch in der agilen Produktentwicklung sollte es neben kurzlebigen Backlog Items und bunter Karten eine langlebige Dokumentation geben. Dazu gehört bspw. das Big Picture, Ziele und Teilziele, Systemkontext, aber auch die modellbasierte Dokumentation zum besseren Verständnis der Produktfunktionalität und des IST-Zustandes.
Das Erstellen von aufwändiger Dokumentation und Entwicklungsartefakten über Backlog Items hinaus ist allerdings nur dann sinnvoll, wenn die Informationen eine längere Gültigkeit haben als eine Iteration in der Entwicklung.
Das Trennen kurzlebige und langlebige Dokumentation dient als Richtlinie dafür, wie viel Aufwand in die Dokumentation investiert werden sollte. So kann auch Verschwendung vermieden werden!
5. Definiere Rituale für Deine Tätigkeiten
Dadurch, dass bei der agilen Entwicklung keine klar abgegrenzten (Analyse-)Phasen existieren, sondern Eigenschaften und Funktionen der einzelnen Inkremente kontinuierlich neu priorisiert und detailliert werden, ist eine Anforderungsanalyse niemals fertig.
Neu ernannte Product Owner, die vom Wasserfall in ein iteratives Vorgehen wechseln, kennen das Symptom, in Arbeit zu versinken; Tagsüber zu viele Termine und Abstimmungen und zu wenig Zeit, Konzepte und Backlog Items zu erstellen.
Iterative Produktentwicklung bedeutet auch iterative Anforderungsvermittlung, d.h. möglichst in Regelterminen zusammen zu finden (Backlog Refinement, Story Time, Epic Time und co.) und weniger ad hoc Meetings abzuhalten. So können alle Themen abhängig von der Flughöhe in den dafür geplanten Zeiteinheiten abgearbeitet werden. Rituale entstehen, der Fokus wird geschärft.
Fazit
Die Anforderungsvermittlung ist im agilen Kontext mindestens genauso wichtig wie im klassischen Phasen orientierten Projektgeschäft. Je selbstorganisierter und agiler (reaktionsfähiger) ein Team arbeitet, umso klarer müssen Problemverständnis und inhaltlicher Rahmen sein. Die Ausprägung der einzelnen Aktivitäten sowie Verantwortlichkeiten bei der Anforderungsvermittlung unterscheidet sich allerdings bei unterschiedlichen Vorgehen (klassisch und agil).
