Agile Produktplanung (APP) – Missverständnisse

Im ersten Teil dieser Blogreihe haben wir gesehen, dass bereits die Frage nach plan- und dokumentenbasiertem Requirements Engineering oder agilem RE falsch gestellt sein kann. In diesem Teil widme ich mich nun den Missverständnissen rund um den RE-Prozess, Produkt-Backlog und User Stories.

Es gibt nicht den einen RE-Prozess

Requirements Engineering ist grundsätzlich eine prozessunabhängige Disziplin. Diese Disziplin sollten Sie jeweils an die Erfordernisse und den Kontext Ihres Vorhabens anpassen. Das betrifft in erster Linie die Art der Zusammenarbeit und die zeitliche Abfolge der Aktivitäten.
Bewährte Konzepte und Artefakte des Requirements Engineerings sind allerdings nach wie vor notwendig und sinnvoll, egal, nach welchem Vorgehensmodell gearbeitet wird. So existieren Anforderungen immer auf verschiedenen Abstraktionsbenen (siehe Informationsmodell). Um werte-orientiert arbeiten zu können,  ist dabei insbesondere die Trennung zwischen Problem und Lösung notwendig.

Können Sie sich denken, warum die Lösungsebene immer in fachliche (was) und technische (wie) Lösung getrennt werden sollte?

Richtig! Die fachliche Ebene ist tendenziell stabiler als die technische. Die Trennung schafft daneben auch die Möglichkeit, bewußt alternative technische Lösungen für eine gewünschte Fachlichkeit zu bedenken.

Jede dieser Ebenen kann in sich mehrere Verfeinerungsebenen beinhalten, die es erlauben, vom Groben zum Feinen zu kommen. Die Verbindung der Anforderungen über diese Ebenen, sowie auch nach „außen“, etwa zu den Testfällen, erlaubt uns die Prüfung wichtiger Fragen nach Verfolgbarkeit und Testabdeckung.

All diese Informationselemente auf den verschiedenen Ebenen  müssen, unabhängig vom Vorgehensmodell, erfasst und verwaltet werden, um sie allen Beteiligten jederzeit verfügbar zu machen. Was können Informationselemente sein? Dazu gehören Visionen und Ziele, die Definition des Kontextes, des Systemumfangs und der Schnittstellen zu anderen Systemen, detaillierte funktionale Anforderungen, Qualitätsanforderungen und Randbedingungen, sowie die Definition relevanter Fachbegriffe als Glossar und/oder Domänenmodell.

Um diese Informationen zu verwalten, benötigen wir ein geeignetes Werkzeug. Geeignet kann in einem Fall ein leichtgewichtiges Wiki bedeuten, in einem anderen Fall ein schwergewichtiges Requirements Management Tool, das die effiziente Verwaltung und Verlinkung von tausenden von Anforderungen unterstützt. Im agilen Umfeld wird dazu auch oft das Product Backlog benutzt.

Anforderungen und Product Backlog

Die Verwaltung von Anforderungen ist allerdings eine Aufgabe des Requirements Engineerings. NICHT die Aufgabe des Product Backlog Managements. Das Product Backlog ist ein Planungsinstrument.  Es ist laut SCRUM Guide „eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert.“

Eines der Missverständnisse ist, dass das Product Backlog zur Verwaltung der Anforderungen gedacht ist. Das Erfassen und Verwalten der Anforderungen (der Inhalte) und das Steuern der Umsetzung dieser Inhalte sind unterschiedliche Aufgaben. Darum benötigen sie unterschiedliche Sichten und Techniken.

Warum ist diese Trennung zwischen der Sicht auf den Inhalt und der Steuerungssicht so wichtig? Damit die unterschiedlichen Aspekte, die auch teilweise mit unterschiedlichen Zuständigkeiten verbunden sind, effizient behandelt werden können.

Das Product Backlog ist eine geordnete Liste von Elementen mit den Eigenschaften Beschreibung, Reihenfolge, Schätzung und Wert. Für die Verwaltung des Inhalts benötigt man andere Eigenschaften, etwa die strukturierte Darstellung durch Anforderungshierarchien. Zudem müssen die Zusammenhänge zwischen den Anforderungen (und auch zu anderen Artefakten) übersichtlich verwaltet werden können.

Unsere Erfahrung bei HOOD zeigt immer wieder, dass die Vermischung dieser beiden Aspekte (Inhalt und Umsetzung) im gleichen Tool dazu führt, dass ein Product Backlog leider nach kurzer Zeit zu einer Müllhalde wird. Die kann der Product Owner nicht mehr sinnvoll und effizient nutzen.

Anforderungen und User Stories

Ein weiteres Problem und somit ein weiteres Missverständnis für den Umgang mit Anforderungen im agilen Umfeld stellt die Fokussierung auf User Stories dar.

User Stories sind Platzhalter für Anforderungen. Sie sind das Versprechen, über Anforderungen zu reden, wenn die User Story wichtig genug ist, um für den nächsten oder übernächsten Sprint eingeplant und umgesetzt zu werden (Mike Cohn, User Stories Applied). User Stories sind also in erster Linie ein Kommunikationsmittel. Sie sollen helfen, die Prinzipien des Manifests für agile Softwareentwicklung umzusetzen. Diesbezüglich besonders wichtig sind das Prinzip 4 (Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.) und 6 (Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.). Wenn wir sie auf Karten schreiben und über Wände bewegen, sind sie hervorragende Planungsartefakte, um unseren Kunden Sprint für Sprint Wert zu liefern. Sie sind aber keine sinnvollen Dokumentationsartefakte für Anforderungen. Eine größere Anzahl von User Stories führt schnell zu dem, was James Shore die „Story Card Hell“ nennt. Wir sehen vor lauter Bäumen den Wald, vor lauter User Stories die Zusammenhänge nicht mehr, die Anfang-bis-Ende-Benutzungsszenarien der Anwender.

Ein gemeinsames Verständnis schaffen

Wie können wir Missverständnisse vermeiden und ein gemeinsames Verständnis der Anforderungen schaffen? Wie können wir in den Köpfen der Beteiligten ein gemeinsames Bild der Anforderungen erzeugen? Und zwar auf allen Abstraktionsebenen, von der Vision über das Big Picture, bis zu den Detailanforderungen auf fachlicher und technischer Ebene? Um gemeinsame Bilder zu erzeugen, ist direkte Kommunikation das beste Mittel.

Um danach diese Bilder in ein auslieferbares Produktinkrement umzusetzen, brauchen wir auch Dokumentation. Wir müssen die Probleme (Warum-Anforderungen), die fachlichen (Was-Anforderungen) und technischen (Wie-Anforderungen) Lösungen beschreiben, natürlichsprachlich, mit Diagrammen, mit Beispielen etc., um gemeinsam daran arbeiten zu können. In der vor-agilen Zeit haben wir oft zu viel dokumentiert und viel zu wenig miteinander geredet. Der manchmal missverstandene zweite Leitsatz des Manifests (Funktionierende Software ist wichtiger als umfassende Dokumentation.) führt unserer Erfahrung nach oft dazu, dass wir immer noch zu wenig miteinander reden und jetzt auch noch zu wenig dokumentieren. Das ist kein Fortschritt.

Wie können wir die üblichen Fallen und Missverständnisse beim RE im agilen Umfeld umschiffen? Gibt es ein Vorgehen, das sich nahtlos in das SCRUM-Framework integriert? Im dritten und vorletzten Teil unserer Blogreihe stelle ich Ihnen das APP-Framework detailliert vor.

Möchten Sie bereits jetzt mehr zur Agilen Produktplanung erfahren? Dann empfehle ich das Training zum Certified Agile Requirements Specialist, für Sie, oder auch zusammen im Team.

Dieser Blogbeitrag wurde von Uwe Valentini für HOOD geschrieben.

Series Navigation

<< Agile Produktplanung (APP) – RE wird agilAgile Produktplanung – ein Framework >>