Anforderungsmanagement mit Microsoft Azure DevOps

In unserem Beispielszenario wird es um die Entwicklung einer Mobilitätslösung gehen, die wir als Softwarehersteller entwickeln. Das Ziel des Projektes ist es, eine Mobilitätsplattform zu entwickeln, die unseren Kunden erlaubt die Reiseerfahrung auf der Kurzstrecke zu verbessern und mit anderen Transportmitteln entlang der gesamten Reisekette zu kombinieren. Im ersten Jahr des Rollouts sollen in den Pilotstädten mindestens 200 Roller verfügbar sein, kein Verlust gemacht und mindestens zwei weitere Transportmittel integriert werden. Im Vordergrund steht hierbei die nahtlose Integration über mehrere Transportmittelanbieter sowie eine einfache Handhabung der Applikation, zur Maximierung des Kundenerlebnisses.

Bevor wir in das Anforderungsmanagement mit Azure DevOps einsteigen, erstellen wir eine passende Projektumgebung in Azure DevOps auf - beginnend mit der Projektstartseite. Diese dient allen Projektstakeholdern als Einstiegspunkt, um sich einen Überblick zu den Projektinhalten und der Organisation zu verschaffen. Azure DevOps bietet hierzu u.a. die Möglichkeit, Wiki-Seiten zu erstellen und als Übersichtsseiten für Projekte zu nutzen, welche bspw. für die Projektbeschreibung, die Ziele, Ansprechpartner und technischen Details zu den Umgebungen genutzt werden können. Für das Projekt „Seamless Mobility“ haben wir folgende Projektseite erstellt:

Als Nächstes steht die Konkretisierung der Projektziele in Form von Epics, Features und erster (grober) User Stories an. Insbesondere Epics stellen einen direkten Bezug zu den Zielen des Projekts her. Daher empfiehlt es sich, vom Groben (den in Form von Epics formulierten Projektzielen) zum Feinen (den zugeordneten Features und User Stories) vorzugehen. Dieser Ansatz bietet den Vorteil, dass stets auch kleinteilige Anforderungen der Projektvision zuordenbar bleiben.

In unserem Projektbeispiel haben wir folgenden Epics definiert:

• E-Scooter Provisioning (alles rund um die vertragliche Zusammenarbeit mit einem E-Scooter Hersteller, also die generelle Infrastruktur)
• E-Scooter Booking App (die App, mit der die E-Scooter gebucht werden können und über die später auch kombinierte Buchungen vorgenommen werden können bspw. im Verbund mit einem Bahnticket)
• Integration of other transport providers (die technische Integration mit anderen Buchungsplattformen wie bspw. der DB oder Car2Go App)

Nachfolgend sehen Sie eine mögliche Aufbaustruktur ausgehend von den definierten Epics, die schrittweise in Features und daraufhin in User Stories verfeinert werden.
 

Bei der Beschreibung von Anforderung empfehlen wir dem Projektteam eine gleichbleibende Struktur zur Erfassung. So wird sichergestellt, dass Anforderungen auf allen Detailebenen (Epic, Feature und User Story) vollständig und umfassend beschrieben werden. Dazu eignen sich Vorlagen, wie z.B. das Epic Template in SAFe. Azure DevOps bietet sehr einfach die Möglichkeit, einmal erstellte Vorlagen für die Ausformulierung ihrer Work Items als Templates zu speichern.

Wenn Sie fortan ein neues Epic, Feature oder ein anderes Work Item erstellen, können Sie jederzeit auf Ihre zuvor hinterlegten Vorlagen für den jeweiligen Work Item Typ zurückgreifen:

Grundlegend lässt sich festhalten, dass es sich bewährt hat nicht nur High-Level Anforderungen mit den Projektergebnissen zu verknüpfen, sondern auf allen Detailebenen den Nutzen für den Kunden und das Produkt in den Vordergrund zu rücken. Unsere Empfehlung lautet, dies noch nicht für alle Work Items und Item Levels im Detail durchzuführen – Gründe hierfür sind die Sicherstellung der Reaktionsfähigkeit auf Änderungen des Projekt- und Produktumfangs sowie das Vermeiden von aufwändigen Detaildiskussionen oder auch Schätzungen für User Stories und Features, die im Laufe des Projekts ggf. gar nicht umgesetzt werden.

Nachdem Anforderungen in Form von Epics und Features beschrieben und analysiert wurden, müssen sie geschätzt werden. Als Schätzmethode bietet sich hier eine Expertenschätzung sowie relative, abstrakte Schätzungen (z.B. T-Shirt Sizes) an, die die Epics und Feature ins Verhältnis zu bereits implementierten Lösungen setzt. Relative Schätzungen bieten den Vorteil, dass sie häufig sehr viel schneller als klassische Schätzungen durchgeführt werden können. Durch die Nutzung von abstrakten Größen, wie T-Shirtgrößen wird den fehlenden Details und der damit verbundenen Unsicherheit der Schätzung auf Epic oder Featureebene Rechnung getragen. Die Schätzung genügt jedoch einer ersten Einschätzung und Priorisierung. Bei der Verwendung abstrakter Schätzungen ist wichtig, dass sich das Projektteam auf ein gemeinsames Verständnis, z.B. S <= 4 Wochen, M <= 8 Wochen, L <= 16 Wochen.

Neben einer Aufwandsschätzung empfehlen wir außerdem, den Geschäftswert abzuschätzen, um so Aufwand und Nutzen ins Verhältnis setzen zu können. Zur Erfassung der Planungsdetails bietet Azure DevOps bereits viele hilfreiche Felder. Ein benutzerdefiniertes Feld zur Erfassung einer groben Schätzung in Form von T-Shirtgrößen lässt sich einfach ergänzen.

Nachdem die Epics und die wichtigsten Features formuliert, grob geschätzt und priorisiert wurden, können sie zeitlich grob geplant werden. Azure Marketplace bietet für Azure DevOps eine Vielzahl  von Erweiterungen (häufig auch kostenlos). Darunter auch die Erweiterung "Feature Timeline and Epic Roadmap" an, mit deren Hilfe eine Roadmap-Planung schnell und einfach gelingt. 

Azure DevOps bietet eine intuitive und trotzdem vielseitige Benutzeroberfläche zur Unterstützung der agilen Anforderungsdefinition und -analyse. Durch den gezielten Einsatz von Extensions lassen sich auch ohne großes Budget eine Vielzahl von Anwendungsfällen schnell und einfach realisieren.