Seite 2: Use Case 2.0

Inhaltsverzeichnis

Agilität mit Use Case 2.0

Im Dezember 2011 veröffentlichten Ivar Jacobson, Ian Spence und Kurt Bittner das Konzept Use Case 2.0 [5]. Es beschreibt eine skalierbare, agile Technik zur Entwicklung von Anforderungen, mit denen sich die inkrementelle Systementwicklung steuern lässt. Die Prinzipien des Konzeptes sind:

• Beschreibe Dinge einfach – mit Geschichten (durch "Storytelling").
• Verstehe das "Big Picture".
• Stelle den Nutzen in den Mittelpunkt.
• Baue das System scheibchenweise ("in Slices").
• Liefere das System in Inkrementen.
• Beachte die Bedürfnisse des Teams.

Die Problemlösung für agile Projektplanung mit Use Cases liefert die Technik des "Slicings" – das Aufschneiden eines Use Case in kleinere Einheiten, die sich dann innerhalb eines Sprints realisieren lassen. Wie funktioniert also scheibchenweises Bauen?

Erinnert sei noch mal an die Definition: "Ein Use Case ist eine Folge von Aktionen eines Systems, die ausgeführt wird, um ein sichtbares Ergebnis von Wert für Anwender oder andere Stakeholder zu generieren." Die Aktionsfolgen eines Use Case werden herkömmlich mit einem Textverarbeitungsprogramm dokumentiert. Häufig setzt man dazu spezielle Dokumentvorlagen ein. Darin wird zunächst das Hauptszenario beschrieben – das heißt der erfolgreiche Durchlauf eines Use Case. Dann beschreibt man die alternativen Szenarien. Sie definieren, was passiert, wenn Ereignisse eintreten, die den geraden Weg zum Erfolg verhindern. Use Case 2.0 verwendet eine andere Terminologie, die eine eher grafisch orientierte Beschreibungstechnik nahelegt.

Und Schnitt ...

In Use Case 2.0 wird für jeden Use Case zunächst jeweils der "Basic Flow" festgehalten. Er entspricht dem herkömmlichen Hauptszenario, ist also eine Folge von Schritten, die auf "geradem" Weg zum erfolgreichen Abschluss des Use Case führt. Zu einigen Schritten und Schrittfolgen des Basic Flow gibt es im Regelfall Alternativen, das heißt bedingungsabhängige Abweichungen vom "geraden" Weg. Diese Umwege werden als "Alternative Flows" bezeichnet.

Jeder Weg vom Start eines Use Case bis zu seinem Ende – egal, ob er geradlinig ist oder über ein paar Umwege führt, wird, sofern er denn sinnvoll ist und einen Nutzen für den Anwender schafft, als "Story" bezeichnet. Jede Story sollte eine Geschichte eines Anwenders bei der Benutzung des Systems erzählen. Um eine Story im Sinne von Use Case 2.0 von der User Story agiler Methoden im Folgenden unterscheiden zu können, sei sie hier "Use Case Story" genannt.

Wie hilft dieses Verständnis der Struktur von Use Cases bei der agilen Projektplanung? Je nach Umfang werden eine oder mehrere Use Case Stories zu einer Planungseinheit – einem Use Case Slice – zusammengefasst.

Zu einem Use Case Slice gehören aber nicht nur Use Case Stories in Form von Start-Ende-Flows durch den Use Case. So wie bei agilen Methoden zu einer User Story immer Akzeptanzkriteren definiert werden, ist auch ein Use Case Slice ohne Testfall nicht vollständig. Das heißt, zu ihm gehört immer mindestens ein Testfall. Dabei können zwei Use Case Slices die gleichen Use Case Stories enthalten, sich aber durch ihre Testfälle unterscheiden.

Die so gebildeten Use Case Slices eigenen sich als Planungseinheiten sowohl für einen Backlog-orientierten agilen Ablauf, wie ihn Scrum definiert, als auch für Workflow-orientiertes Vorgehen etwa nach Kanban. Er ist unter anderem auch im Rahmen des Scaled Agile Framework (SAFe) einsetzbar. Der Einsatz mit Scrum soll hier exemplarisch vertieft werden.

Use Case 2.0 und Scrum

Wie greifen das Use Case Slicing und Scrum ineinander? Ein aus Use Case Stories und Testfällen gebildetes Use Case Slice wird als Backlog-Item in das Product Backlog der agilen Entwicklung eingestellt. Bevor der Scrum-Ablauf beginnen kann, muss das Product Backlog zu einem gewissen Grad gefüllt sein. Es sind also Use Cases identifiziert und daraus Use Case Slices abgeleitet. Use Case 2.0 setzt nicht voraus, dass zu Beginn eines Projekts alle Use Cases vollständig definiert werden. Um erste Backlog-Items zu gewinnen, genügt es, einige zentrale Use Cases zu identifizieren. Das erfordert den folgenden Vorlauf:

Zuerst sind die Stakeholder des Projekts – also alle, die an dem Projekt ein Interesse haben – zu identifizieren. Dazu zählen auch die Anwender beziehungsweise die Akteure, die direkt mit dem System arbeiten. Ihre Ziele müssen verstanden werden. Denn Use Cases dienen immer dazu, Ziele der Anwender zu erreichen. Auf dieser Grundlage kann man damit beginnen, Use Cases zu ermitteln. Dafür eignet sich ein Workshop mit den Stakeholdern. Ausgangspunkt bei der Entwicklung von Use Cases sind natursprachliche Use-Case-Beschreibungen ("Narratives"). Bei der Entwicklung von Use Cases kann man ein Top-down-Vorgehen (vom Use Case ausgehend einzelne Schritte und alternative Abläufe finden) oder ein Bottom-up-Vorgehen (per Brainstorming alle möglichen Abläufe sammeln und zum Use Case zusammenfassen) wählen oder beide Vorgehensweisen kombinieren.

Sobald eine Reihe stabiler Use Cases identifiziert ist, lässt sich parallel zur weiteren Use-Case-Analyse damit beginnen, die gefundenen Use Cases durch Storytelling der Anwender genauer zu verstehen, ihre Flows detailliert zu beschreiben und Use Case Stories zu bilden. Hilfreich ist es, bei der Beschreibung der Abläufe bereits die Testfälle "mitzudenken", sie also zur gleichen Zeit wie die Use Case Flows zu entwickeln. Sobald Use Case Stories definiert sind, können Stakeholder, Entwickler und Tester in Zusammenarbeit Slices bilden. Das erste sollte immer auf dem Basic Flow aufbauen. Slices sind so klein zu wählen, dass sie sich in einem Sprint umsetzen lassen. Ein Use Case muss allerdings nicht komplett "aufgeschnitten" werden. Es reicht aus, die Slices zu bilden, die für den Arbeitsfortschritt notwendig sind und die restlichen Use Case Stories erst bei Bedarf weiter aufzuspalten.

Die Slices werden in das Product Backlog – also in den Bestand aller zu realisierenden Backlog Items – übernommen. Dort muss sie der Product Owner nach den Kriterien Priorität, Wert, Risiko und Notwendigkeit gewichten. Liegen gewichtete Backlog Items vor, kann der Entwicklungsprozess nach Scrum beginnen, während gleichzeitig dazu an der Entwicklung und dem Slicing weiterer Use Cases gearbeitet wird. Wenn Use Cases noch nicht in Slices unterteilt sind, lassen sie sich bereits als Platzhalter-Slice ins Backlog aufnehmen und später "klein schneiden". Sobald das Product Backlog vorbereitet ist, kommt das Entwicklerteam zum Zug: Es schätzt die hoch priorisierten Slices im Product Backlog, wählt Slices für den nächsten Sprint aus und übernimmt sie ins Sprint Backlog – genau so, wie es auch mit User Stories umgehen würde. Das Sprint Backlog wird abgearbeitet, bis das erste potenziell lieferfähige Produktinkrement fertig ist (das wird vermutlich gerade einmal den Basic Flow eines ersten Use Case umfassen) – und dann geht es mit der Planung für den nächsten Sprint weiter.

In kleineren Projekten kann das Entwicklerteam Ermittlung, Beschreibung und das Slicing von Use Cases und damit die Fortschreibung des Product Backlog selbst übernehmen. Jacobson empfiehlt Scrum-Teams, 5 bis 10 Prozent ihrer Zeit in die Pflege des Backlogs zu investieren. Für große Vorhaben bietet sich ein arbeitsteiliges, parallelisiertes Vorgehen an: Die Entwicklung und das Slicing von Use Cases sind typische Aufgaben des Requirements Engineering. Sie können parallel zur Entwicklung nach Scrum ablaufen, um das Product Backlog kontinuierlich "aufzufüllen".

Use Cases eignen sich gut zur Release-Planung, Use Case Slices gut zur Planung kleinerer Inkremente innerhalb eines kompletten Releases. Das Konzept Use Case 2.0 hilft somit, die Granularität der Entwicklung zu verfeinern. Jedes Inkrement baut auf dem vorhergehenden auf und bringt entweder mehr Funktionen oder verbessert die Qualität vorheriger Versionen.