Use Case 2.0

Prinzipien von Use Case 2.0

Use Case 2.0 hilft bei der agilen Entwicklung von Anforderungen, die im Zuge einer inkrementen Entwicklung umgesetzt werden. Die Technik bietet die Möglichkeit, Use Cases direkt auch in der agilen Entwicklung zu nutzen, ohne sie vorher in User Storys übersetzen zu müssen. Grundsätzlich basiert Use Case 2.0 auf sechs einfachen Prinzipien:

• beschreibe Dinge einfach mit Storys (nicht identisch mit den User Storys aus Scrum),
• verstehe das Big Picture,
• stelle den Nutzen des Akteurs in den Mittelpunkt,
• erstelle das System in Slices,
• liefere das System in Inkrementen,
• und passe das Vorgehen an die Bedürfnisse des Teams an.

Vorteile von Use Case 2.0

Das Use Case 2.0 Konzept bietet eine Reihe von Vorteilen:

• Das Konzept lässt sich in klassischen Wasserfall-Projekten als auch in der agilen Entwicklung sehr gut verwenden. Und es ist so leicht zu verstehen, dass sich zwei unterschiedliche Techniken wie die Arbeit mit Use Cases und das Arbeiten mit Backlogs kombinieren lassen.
• Wie bei der Arbeit mit User Storys wird die Konversation zwischen den Beteiligten gefördert und das gemeinsame Verständnis steigt.
• Häufig sind Use Cases zu umfangreich für eine Realisierung innerhalb eines Sprints. Durch das Slicing eines Use Cases entstehen kleinere Einheiten, die sich innerhalb eines Sprints realisieren lassen.

Use Case 2.0 Begriffe

Use Case 2.0 verwendet einige Begriffe wie Akteure, Stakeholder, System- und Systemelemente oder Anwendungsfalldiagramm, die im Kontext von Use Cases üblich sind. Darüber hinaus verwenden Ivar  Jacobsen und seine Mitautoren Spence und Bittner einige weitere Begriffe:

• Flow: Eine Beschreibung eines vollständigen oder teilweisen Pfades durch einen narrativen Anwendungsfall. Es gibt immer mindestens einen Basic Flow, und es kann Alternative Flows geben.
• Basic Flow: Die Beschreibung des normalen, geradlinigen Durchlaufs durch den Anwendungsfall. Er ist damit der wichtigste Teile des narrativen Anwendungsfalls und wird von den Akteuren am häufigsten genutzt.
• Alternative Flow: Beschreibung der Variante oder des optionalen Verhaltens als Teil eines narrativen Anwendungsfalls. Alternative Flows sind relativ zum Basic Flow des Anwendungsfalls definiert.
• Story: Eine Story beschreibt eine Möglichkeit, ein System zu verwenden, das für einen Benutzer oder einen anderen Stakeholder von Wert ist. In Use Case 2.0 wird eine Story beschrieben durch einen Teil des narrativen Anwendungsfalls, einen oder mehrere Flows, Anforderungen und einen oder mehrere Testfälle. Eine Story ist damit nicht identisch mit einer User Story aus Scrum.
• Use Case Modell: Ein Use Case Modell besteht hauptsächlich aus einer Reihe von Akteuren und einer Reihe von Anwendungsfällen sowie aus Diagrammen, die ihre Beziehungen veranschaulichen. Es beschreibt die sinnvolle Nutzung eines Systems und den Wert, den das System bietet.
• Use Case Slice: Ein Use-Case-Slice umfasst eine oder mehrere Storys, die aus einem Anwendungsfall ausgewählt werden und für Anwender einen eindeutigen Wert darstellen.

Die Anwendung von Use Case 2.0 in der Entwicklung

Wie lassen sich die Use Case 2.0 Prinzipien in der Produktentwicklung nutzen? Zuerst gilt es die Akteure zu identifizieren, die mit dem System arbeiten. Welche Ziele verfolgen diese Akteure? Es ist wichtig, diese Ziele zu verstehen, denn Anwendungsfälle dienen immer dazu, Ziele der Anwender zu erreichen. Auf dieser Grundlage können Sie damit beginnen, Use Cases zu ermitteln. Dazu gibt es zwei Optionen:

• Top Down – also vom Use Case ausgehend einzelne Schritte, Abläufe und Alternativen ermitteln.
• Bottom Up – also beispielsweise per Brainstorming, Brainwriting oder Braindumping verschiedene Abläufe sammeln und zu Anwendungsfällen zusammenfassen.

Beide Optionen lassen sich auch miteinander kombinieren. Es ist hilfreich, gleichzeitig zur Beschreibung der Abläufe – jeder sinnvolle Weg durch einen Anwendungsfall wird als Use Case Story bezeichnet – Testfälle zu entwickeln. Sobald Use Case Storys definiert sind, können Use Case Slices gebildet werden.

Use Case 2.0 setzt nicht voraus, dass alle Anwendungsfälle vollständig definiert werden, bevor Ihre Realisierung beginnt. Ein solches Vorgehen wäre alles andere als agil. Die Identifikation einiger zentraler Use Cases ist die Basis für die Definition der ersten Slices, die als solche direkt in das Backlog aufgenommen werden können. Ein Use Case muss auch nicht komplett in Slices zerlegt werden – es reicht aus, die Slices, die für die Planung des nächsten Sprints notwendig sind, nach Bedarf zu definieren.

Den drei Autoren von Use Case 2.0 war natürlich bekannt, dass es keine einheitliche Lösung für alle Herausforderungen bei der Entwicklung von Software und Systemen gibt. Kleine, kollaborative Teams können mit einfachen Karteikarten, große, verteilte Teams mit umfassenden Anwendungsfalldokumenten und spezialisierten Tools arbeiten. Für eine Organisation ist es wichtig, ein Vorgehen zu wählen, dass zur Organisation passt und den größten Nutzen bietet.

Use Case Slices definieren

Es gelten die folgenden Regeln zur Bildung von Use Case Slices:

• Use Case Slices müssen so klein geschnitten werden, dass sie in einem Sprint umgesetzt werden können.
• Die erste Use Case Story wird als Basic Flow bezeichnet. Sie wird als erstes realisiert.
• Ein Slice wird immer vertikal, also entlang einer oder mehrerer Use Case Storys, geschnitten. Er kann auch mehrere Use Case Storys umfassen.
• Jeder Slice benötigt mindestens einen Testfall
• Wenn zwei Use Case Slices dieselben Use Case Storys enthalten, müssen sie sich durch ihre Testfälle unterscheiden.
• Unklare Use Case Storys können nicht in die agile Planung aufgenommen werden. Hier ergibt die Verwendung von Technical Story oder Spike Story Sinn.

Slice the Slice in Use Case 2.0

Was passiert, wenn ein Use Case Slice für einen Sprint zu groß ist? Die Antwort lautet: Slice the Slice. Oder auf Deutsch: Verkleinern Sie den Slice so weit wie möglich. Lässt er sich aber nicht weiter verkleinern, sollten Organisation bei der Einplanung und Realisierung folgende agile Regeln beachten:

• Durch die Implementierung des Slices entsteht ein Stück funktionierende Software.
• Durch die Implementierung des Slices entsteht ein Wert für den Anwender.
• Die Implementierung des Slices ermöglicht ein Feedback des Anwenders.

Sind diese Regeln erfüllt, kann ein zu großer Use Case Slice durch mehrere kleine Use Case Slices ersetzt werden, die jeweils Teil-Storys mit zugehörigen Testfällen enthalten. Diese Use Case Slices für die Teil-Stories werden im Backlog Refinement aufbereitet und priorisiert, Sprint Planning eingeplant, im Sprint implementiert und im Sprint Review geprüft. Sind alle Teil-Storys implementiert, müssen die Testfälle des ursprünglichen Use Case Slices durchlaufen werden. Sind alle Use Case Storys implementiert, müssen die Testfälle des ursprünglichen Use Cases geprüft werden.

Herausforderungen beim Arbeiten mit Use Case 2.0

Beim Formulieren von Anwendungsfällen sollten Organisationen darauf achten, detaillierte Beschreibungen zu erstellen, die nicht zu kompliziert formuliert werden. Bei der Umsetzung selbst ist das Zerschneiden von Anwendungsfällen in Slices, die innerhalb eines Sprints realisiert werden, sehr wichtig. Die Umsetzung der Slices ist abhängig von der Größe eines Slices; gegebenenfalls müssen auch sie nochmals verkleinert werden. Hier ist technisches und wirtschaftliches Verständnis gefragt. Organisationen müssen abwägen, ob sie diejenigen Use Cases bzw. Use Case Slices zuerst realisieren, die technisch oder fachlich einen großen Anwenderkreis adressieren, oder solche, die einen kleineren Kreis ansprechen, der gegebenenfalls eine größere finanzielle Auswirkung hat.

Grundsätzlich bietet das Arbeiten mit Use Cases, Anwendungsfalldiagrammen, Use Case 2.0 und Misuse Cases ein umfassendes Konzept, um Systeme nicht nur im Detail sondern als Ganzes gut zu verstehen. Unternehmen müssen „lediglich“ die Konzepte konsequent und passend zur Organisation anwenden.

User Storys vs. Use Case Storys

Alistair Cockburn, einer der Urheber des agilen Manifests, hat drei Probleme beschrieben, die durch die ausschließliche Verwendung von User Storys in agilen Projekten entstehen:

• Die reine Verwendung von User Storys bietet Entwicklern keine Kontextinformationen.
• User Storys liefern dem Projektteam keine Hinweise auf den Grad der Fertigstellung.
• User Storys stellen keinen hinreichenden Mechanismus zur Verfügung, um in der Vorausschau mögliche Schwierigkeiten von noch nicht erledigter Arbeit zu ermitteln.

Ein großer Vorteil der Verwendung von Use Case 2.0 liegt in der Skalierbarkeit des Konzepts. Kleine Teams können ihre Beschreibungen so kurz wie möglich halten, so dass sie ähnlich einfach zu verstehen sind wie User Storys. Größere, möglicherweise verteilte Teams können hingegen umfassendere Beschreibungen erstellen und so alle wichtigen Aspekte dokumentieren. Dieses Vorgehen ist flexibel und liefert bei Bedarf sinnvolle Kontextinformationen. Wie detailliert die Use Case Storys dokumentiert werden, hängt also von der konkreten Situation und von den beteiligten Mitarbeitern ab.

Im Gegensatz zu User Storys, die meist in einem Backlog verwaltet werden, bieten Use Case Storys durch die Verbindung zu Use Cases und Use Case Diagrammen einen besseren Überblick über das System. Auch Abhängigkeiten zwischen Anforderungen lassen sich so besser nachvollziehen. Darüber hinaus helfen Use Case Storys während der Realisierung, einen Überblick über bereits fertig gestellte Systemteile zu erhalten.

User Storys sind mit Ihrem einfachen Aufbau „Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen“ leicht zu verstehen. Bei Use Cases wird hingegen häufig die Lesbarkeit als schwierig empfunden. Es empfiehlt sich daher, Stakeholder nicht mit der Dokumentation von Use Cases, Use Case Diagrammen oder Use Case Storys zu überfordern. Als Ausdrucks- und Arbeitsmittel sollten sie für die Kommunikation über Inhalte genutzt werden. Es ist sicherlich sinnvoll, wenn Stakeholder, Systemanalytiker und Entwickler auch im Zuge von Use Case 2.0 regelmäßig miteinander kommunizieren, zumal so auch mögliche Schwierigkeiten frühstmöglich erkannt werden können.

Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.