Mit Domain Storytelling ein Minimum Viable Product entwickeln
Domain Storytelling (DST) ist mittlerweile eine der interessantesten der etablierten Interview- und Modellierungstechniken in der agilen Anforderungsermittlung [1]. Es fördert Interaktion und direktes Feedback im Modellierungsprozess, einem der Kerngedanken des Collaborative Modeling.
Die für alle Stakeholder leicht verständlichen Szenario-Diagramme sind in den verschiedensten Anwendungsfeldern der Software-, Projekt- oder Produktentwicklung im Einsatz, um z. B. die Kommunikation zwischen dem Softwareentwicklungsteam, Business-Analyst:innen und den Fachexpert:innen zu unterstützen.
Eines dieser Anwendungsfelder ist die zentrale Fragestellung "Wie starten wir mit der Softwareentwicklung bzw. wie können weiterführende Ausbaustufen vorhandener Produkte aussehen?".
Ein wesentlicher Teil der Antwort kann mit Hilfe des Ansatzes Minimum Viable Product (MVP) gegeben werden [2]. Dabei werden wichtige Erkenntnisse für konkrete Sprintplanungen, für übergreifende Release-Planungen mit Ausbaustufen und auch die gezielte Deployment-Planung gewonnen.
Wie konkret Domain Storytelling dazu Transparenz schaffen kann und notwendige Diskussionen und Entscheidungen vereinfacht, wird nun anhand einer vielfach erprobten Vorgehensweise mit passendem Praxisbeispiel erläutert.
Domain Storytelling
Die Methode nutzt eine einfache Bildsprache, um Geschichten über den Anwendungsbereich zu erzählen und zu dokumentieren. Die Bildsprache besteht im Wesentlichen aus drei Arten von Symbolen, die als Icons und Pfeile dargestellt werden:
- Akteure sind die handelnden Personen und IT-Systeme einer Geschichte. Typischerweise benannt mit einer Rollenbezeichnung (z. B. Bus-Disponent:in).
- Arbeitsgegenstände nutzen die Akteure im Zuge ihrer Tätigkeiten. Hierbei handelt es sich oft um physische Gegenstände, wie z. B. ein Bus oder auch vergegenständlichte Konzepte, wie der "Auftrag".
- Aktivitäten beschreiben, wie die Akteure handeln und interagieren und werden durch Pfeile dargestellt. Die Nummerierung der Pfeile zeigt die Reihenfolge der Aktivitäten. Die Aktivitäten werden durch Verben in unserer Geschichte dargestellt.
Icons und Pfeile werden durch kurze Texte so erläutert, dass ein "visueller" Satz entsteht. Für die Beschriftung verwenden wir Begriffe aus der Domänensprache. Das Ergebnis wird als Bild mit einfachen Piktogrammen dokumentiert.
Die Ausgangssituation
Wenn an einem Flughafen keine sogenannte Gate-Position für den direkten Einstieg von Passagieren in das Flugzeug verfügbar ist, werden diese mit einem Tenderbus zur Abflugposition auf dem Vorfeld gefahren, um dort per mobiler Treppe einzusteigen.
Die Dienstleistung wird normalerweise durch einen Bodenverkehrsdienst am Flughafen, beispielsweise dem Ground Handling, erbracht. Ein Bus-Disponent kümmert sich um das Zusammenspiel von Flugplan und Busbestellungen und setzt dabei eigene Ressourcen wie Tenderbusfahrer:innen und Tenderbusse zur Durchführung von Aufträgen ein.
Zusammen mit allen Stakeholdern wurde dieser potentielle Problemraum analysiert, um Ideen und Verbesserungsvorschläge für eine Neugestaltung des Ablaufs zu ermitteln. Eine Vision mit Schwerpunkt in Richtung Digitalisierung und konkrete Ziele zur Umsetzung bildeten dann die Basis für fachliche Entscheidungen im Lösungsraum.
Eine wichtige Erkenntnis war, dass der Einsatz einer Business-App für Tenderbusfahrer:innen den Ablauf des Passagiertransports erheblich vereinfachen würde. In der Vergangenheit haben insbesondere eine permanente Funkkommunikation und die Rückerfassung der Auftragsdokumentation in Papierform zu vielfältigen Problemen in der Abwicklung von Busbestellungen geführt.
Mit Hilfe eines Szenario-Diagramms wurde ein neuer Soll-Ablauf für die Subdomäne (DDD [3]) Tenderbus-Auftragsdisposition beim Ground Handling im Lösungsraum konzipiert.
Das Erstellen dieser Art von Szenario-Diagrammen wird durch das Open-Source-Tool Egon.io unterstützt [4]. Mit diesem Modeler ist es möglich, die im Ursprung schon überschaubaren Visualisierungen zusätzlich Step-by-Step durchzugehen. Durch gezielte Rückfragen an alle beteiligten Stakeholder zu konkreten, einzelnen Aktivitäten an alle beteiligten Stakeholder kann ein detailliertes gemeinsames Verständnis ("Soll es genauso passieren?") aufgebaut werden. Weiterhin kann auch für den Gesamtablauf ("Welche Akteure, Aktivitäten oder Ereignisse fehlen?") durch die Reduzierung auf das Wesentliche weitere Transparenz und Klarheit geschaffen werden.
Mögliche Sonderfälle werden anfangs nicht und später nur im Fokus der konkreten Geschichte berücksichtigt, um die Einfachheit und Übersichtlichkeit nicht zu gefährden. Dies ermöglicht es auch Fachbereichen und anderen Stakeholdern, aktiv auf Basis der Diagrammstruktur an Diskussionen teilzunehmen. Aufbauend auf der Vision, den konkreten Zielen und dem neu konzipierten Soll-Ablauf ist es nun möglich, strukturiert in die Planung der nächsten Schritte einzusteigen.
Strategische und taktische Planung
Durch die verwendete Bildsprache lassen sich wichtige Vorüberlegungen bzw. Fragen zum weiteren Vorgehen über das Szenariodiagramm sehr einfach identifizieren und übersichtlich markieren.
- Welche Akteure (grau markiert) profitieren wie vom Einsatz der neuen Business-App bei der Ausübung ihrer täglichen Tätigkeiten? Dies schafft ein gutes Gefühl dafür, wie diese Akteure eng ins Projekt eingebunden werden müssen bzw. abgeholt werden müssen, um Akzeptanz für kommende Veränderungen zu schaffen.
- Welche Teile der Altanwendung sollen/dürfen nicht verändert werden bzw. welche Aktivitäten sollen auch in Zukunft nicht mit IT unterstützt werden (rot markiert)?
- Welche Aktivitäten sollen zukünftig digitalisiert bzw. mit IT unterstützt werden (grün markiert)?
Durch die Klarheit in der Visualisierung kann diese Diskussion auch mit dem Management, dem Betriebsrat oder anderen indirekt involvierten Stakeholdergruppen geführt werden. Damit können Entscheidungen in der Produktentwicklung in alle Richtungen durch ein zielgerichtetes, nutzenorientiertes MVP mit nachfolgenden Ausbaustufen so fokussiert wie möglich auf die Bedürfnisse der Stakeholder angepasst werden. Wenn beispielsweise eine Business-App nur fokussiert für die Tenderbusfahrer:innen entwickelt werden würde, dann würden die Busdisponent:innen sehr wahrscheinlich nur noch passiv und widerwillig zum Projekterfolg beitragen, weil ihre tägliche Arbeit nicht wirklich beeinflusst und erleichtert werden würde.
Nun wird die Frage "Wie starten wir konkret mit der Implementierung der neuen Produktsoftware?" immer wichtiger.
Der MVP-Workshop
Nachdem diese Fragen geklärt bzw. visualisiert wurden, steht einem erfolgreichen Workshop zur Festlegung eines MVP und ggf. weiterer Ausbaustufen nichts mehr im Wege. Neben dem Product Owner führen wir diese Workshops in der Regel mit dem kompletten Entwicklungsteam durch.
Es bietet sich ein Whiteboard für Präsenz- oder Online-Termine an, welches eine vorbereitete Spielwiese mit Fokus MVP und mehrere Stapel Sticky Notes für das MVP und potenzielle Ausbaustufen enthält. Für die neue Tenderbus-Business-App sieht das Board vor Start des Workshops beispielsweise so aus (s. Abb. 4).
Die farblich unterschiedlichen Sticky Notes enthalten Label wie MVP, Ausbaustufe 1, Ausbaustufe 2 usw. aber auch die Möglichkeit, bestimmte Aktivitäten als Abgrenzung (aktuell nicht im Scope) zu markieren, falls in der Diskussion Erkenntnisse in diese Richtung neu erarbeitet werden. Ein typisches Ergebnis eines MVP-Workshops ist in Abb. 5 zu sehen.
In der Regel liegen als Ergebnis mindestens ein MVP-Szenario-Diagramm und eine weitere mögliche Ausbaustufe vor. Um wieder Klarheit und ein einfaches Verständnis zum jeweiligen Scope zu schaffen, wird das zugrunde liegende Szenario-Diagramm mit dem Modeler in die Variante MVP und die möglichen Ausbaustufen zugeschnitten.
Im konkreten Praxisprojekt wurden dann die beiden Ergebnisse als Grundlage für den Start der Produktentwicklung genutzt und als Basis für die Sprintplanung verwendet (s. Abb. 6 & 7):
Die Motivation, das MVP im Praxisbeispiel so minimalistisch auszulegen, war durch folgende Schwerpunkte begründet:
- Das vorrangige Ziel war es, möglichst schnell mit den Busfahrern in einen Feedback-Dialog einsteigen. Dies sollte durch Fokussieren der Darstellung des Busauftrags auf dem Tablet erreicht werden.
- Zusätzlich sollte unmittelbar getestet werden, wie das Tablet sich in der konkreten Nutzung macht und wie es im Bus idealerweise montiert werden könnte.
- Da die Authentifizierung an einer mobilen App "Standard" ist, wird auch ein rudimentäres Login berücksichtigt.
Je nach Reifegrad der App-Entwicklung und der Entwicklungsgeschwindigkeit kann die Ausbaustufe 1 dann schon deutlich komplexer ausgelegt werden, um eine direkte Interaktion zwischen den wichtigsten Stakeholdern zu ermöglichen.
Um durch die ureigensten Ziele eines MVP, wie das frühzeitige Nutzerfeedback, zu lernen oder Fehlentwicklungen zu erkennen, unterliegen die Szenario-Diagramme durch das adaptive Vorgehen einer permanenten Weiterentwicklung. Dies führt insbesondere in den Ausbaustufen zu regelmäßigen Anpassungen an die konkrete Funktionalität, welche auf dem Whiteboard zusammen mit dem Szenario-Diagramm und Sticky Notes sehr leicht umsetzbar sind.
Manchmal entstehen je nach Gewichtung der Ziele aus der strategischen und taktischen Planung auch mehrere MVP-Varianten und Ausbaustufen für das mögliche weitere Vorgehen. Diese Varianten können problemlos auf dem Whiteboard durch Duplizieren und Verändern nebeneinandergestellt, im Detail verglichen und diskutiert werden, bis eine Einigung nach aktuellem Kenntnisstand erzielt wird.
Fazit
Das beschriebene Vorgehen eignet sich für alle denkbaren Projekt- und Produktentwicklungen, um strukturiert wichtige Erkenntnisse für eine mögliche Entwicklungsplanung mit Releases zu gewinnen.
Die kollaborative Erstellung und Weiterentwicklung der Szenario-Diagramme mit Fokus auf das Thema Minimum Viable Product fördert das gemeinsame Verständnis der unterschiedlichsten Stakeholdergruppen und überbrückt spielerisch mögliche Gräben zwischen Fachbereich und dem Softwareentwicklungsteam.
Die einfache und transparente MVP-Visualisierung unterstützt einerseits Product Owner und Projektleiter:innen im Erwartungsmanagement von Anwender:innen und involviertem Management. Andererseits kann jede:r im Team Mitarbeitende ad hoc erklären, woran gerade gearbeitet wird. Dies kommt besonders zum Tragen, wenn aufgrund eines empirischen Vorgehens beispielsweise Szenarien von Ausbaustufen mit neuen Erkenntnissen angepasst werden müssen.
Dabei entsteht als Nebenprodukt in der Produktentwicklung mit den Szenario-Diagrammen der Ausbaustufen eine Dokumentation der Release-Planung mit denen sich die einzelnen Entwicklungsschritte, insbesondere zur Funktionalität, sehr gut nachvollziehen lassen.
- Domain Storytelling (DST)
Stefan Hofer, Henning Schwentner (2023): Domain Storytelling - E. Ries,2014: Lean Startup
- Wikipedia: Domain-driven Design
- Open-Source-Tool zum Erstellen von Szenario Diagrammen Egon.io
