Blog

Unser Blog erscheint regelmäßig mit neuen Beiträgen aus den Themenbereichen der Anforderungsvermittlung und agilen Skalierung.

Notizbuch mit Anforderungsfabrik Logo Kugelschreiber daneben

Anforderungsvermittlung im agilen Kontext

Definierter iterativer Prozess

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:

  1. 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.

  2. 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.

  3. 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.

Von den Zielen über das Big Picture zur weiteren Detaillierung

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.

Problem und Loesung auf zwei verschiedenen Seiten

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!

Tabelle Langlebige und kurzlebige Dokumentationen die sich überschneiden

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.

Laptop mit Prozessen auf dem Bildschirm

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).

Geschäftsführer Jesko Schneider

Über den Autor

 

Jesko Schneider ist als Berater, Trainer und Coach in unterschiedlichen Branchen und Unternehmen rund um das Thema Requirements Engineering und der Umsetzung dieses bei der agilen Produktentwicklung tätig. 

Sein Einsatz in Kundenprojekten umfasst die Optimierung der Zusammenarbeit bei der komplexen Produktentwicklung im Rahmen von Digitalisierungsvorhaben (klassisch, agil oder hybrid).

Darüber hinaus ist er als Trainer und Coach bei der agilen Transformation von Unternehmen tätig, wobei sein Fokus auf der strukturierten und fokussierten Zusammenarbeit zwischen Business und IT liegt.

Gründer & Geschäftsführer

Über den Autor

Profilbild des Geschäftsführer Jesko Schneider

Jesko Schneider ist als Berater, Trainer und Coach in unterschiedlichen Branchen und Unternehmen rund um das Thema Requirements Engineering und der Umsetzung dieses bei der agilen Produktentwicklung tätig. 

Sein Einsatz in Kundenprojekten umfasst die Optimierung der Zusammenarbeit bei der komplexen Produktentwicklung im Rahmen von Digitalisierungsvorhaben (klassisch, agil oder hybrid).

Darüber hinaus ist er als Trainer und Coach bei der agilen Transformation von Unternehmen tätig, wobei sein Fokus auf der strukturierten und fokussierten Zusammenarbeit zwischen Business und IT liegt.

Gründer & Geschäftsführer

28. – 29. August 2024
05. – 07. August 2024

Sie wollen nichts mehr verpassen?

WordPress Cookie-Hinweis von Real Cookie Banner