Wie funktioniert Use Case 2.0?

Was beinhaltet Use Case 2.0, welche Vorteile bietet das Konzept und wie kann es in der Praxis genutzt werden?

1
2
3
4
5
6
Use Cases für die agile Entwicklung
1

In einem Use Case – auch Anwendungsfall genannt – wird das nach außen sichtbare Verhalten eines Systems aus Sicht der Nutzer beschrieben.

2

Jeder Use Case enthält einen Basic Flow. Darunter versteht Use Case 2.0 eine Folge von Schritten, die auf „geradem“ Weg zum erfolgreichen Abschluss führt.

3

Natürlich gibt es auch Alternativen, mit denen ein Verhalten dargestellt wird, wenn nicht der “gerade” Durchlauf möglich ist. Use Case 2.0 spricht hier von Alternative Flows.

4

Eine Begrenzung der Anzahl von Alternative Flows gibt es nicht. Jeder mögliche Weg vom Start eines Use Case bis zu seinem Ende wird als Use Case Story bezeichnet.

5

Beim Slicen werden eine oder mehrere Use Case Stories zu einer Planungseinheit – einem Use Case Slice – zusammengefasst.

6

Das Slicen selbst erfolgt “vertikal”, also vom ersten zum letzten Schritt und nicht horizontal über verschiedene Use Case Stories hinweg.

Follow a manual added link

So wenden Sie das Use Case 2.0-Konzept in der Praxis an. Machen Sie den Test.

objectiF RPM – Unternehmenssoftware für mehr Business Agilität testen.

Die Idee von Use Case 2.0

Ivar Jacobson stellte 1987 erstmals sein Konzept der Use Cases vor. Er definierte damals einen Use Case als “a special sequence of transactions, performed by a user and a system in a dialogue”. Frei übersetzt beschreibt ein Use Case also das nach außen sichtbare Verhalten eines Systems aus Sicht der Nutzer. Ein Nutzer kann hierbei eine Person, eine Rolle oder ein anderes System sein. Die Stärke von Use Cases – auch Anwendungsfälle genannt – ist es, dass sie einen Überblick über das Verhalten eines Systems geben. Sie bieten das Big Picture eines zu entwickelnden Systems. Ohne das System als Ganzes zu verstehen, fehlt es an Orientierung. Die Folge: Entscheidungen über den Scope (was kann man später entwickeln oder sogar weglassen) und damit auch über Nutzen und Kosten sind schwer zu treffen.

In der Praxis sind Use Cases häufig zu umfangreich, um im Rahmen der agilen Entwicklung in typischen Sprints von zwei bis drei Wochen realisiert zu werden. Wie können Sie dennoch direkt mit Use Cases agil planen? Jacobsen und seine Mitautoren Spencer und Bittner haben 2011 darauf die Antwort gegeben: Mit Use Case 2.0.

Die Idee von Use Case 2.0 ist einfach: Ein Use Case wird scheibchenweise realisiert und geliefert. Dazu wird der Use Case in kleinere Einheiten, die sogenannten Use Case Slices, “zerschnitten”, die jeweils innerhalb eines Sprints realisiert werden können. “Geschnitten” wird jeweils entlang einer Interaktionsfolge von Akteur und System. Das „scheibchenweise“ Realisieren und Liefern hilft dabei, ein frühzeitiges Feedback von den Stakeholdern zu bekommen. Das besondere Augenmerk, das auf dem Nutzen liegt, sorgt dafür, dass die Stakeholder zuerst die Systemteile bekommen, die den größten Wert für sie darstellen.

Die Grundprinzipien von Use Case 2.0

  • Beschreibe Dinge einfach – mit Geschichten (“stories”)

  • Verstehe das “Big Picture”

  • Stelle den Nutzen in den Mittelpunkt

  • Baue das System in Slices auf

  • Liefere das System in Inkrementen

  • Passe dich den Bedürfnissen des Teams an

Use Case Slices definieren

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

  • Die „Scheibe“ eines Use Case, die immer als erste realisiert werden sollte, ist der Basic Flow.
  • Weitere Slices werden durch eine oder die Zusammenfassung mehrerer Use Case Stories gebildet.
  • 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 zu einer User Story immer Akzeptanzkriterien definiert werden sollten, ist auch ein Use Case Slice ohne Testfall nicht vollständig. Das heißt, zu einem Use Case Slice gehört immer mindestens ein Testfall.
  • Zwei Use Case Slices können dieselben Use Case Stories enthalten, sich aber durch ihre Testfälle unterscheiden.

Slice the Slice

Wie gehen Sie mit Use Case Slices um, die zu groß für einen Sprint sind? Verkleinern Sie den Slice oder in anderen Worten: Slice the Slice. Wenn es unumgänglich ist, einen Use Case Slice bzw. die darin enthaltene Use Case Story weiter zu “zerschneiden”, sollten folgende Regeln zum Slicen von Use Case Slices beachtet werden:

  • Jedes Teil, wenn es implementiert ist, liefert ein Stück funktionierende Software.
  • Jedes Teil – auch allein – schafft einen Wert für den Anwender.
  • Jedes Teil ermöglicht potenziell ein Feedback des Anwenders.
Follow a manual added link

Wissen zum Mitnehmen

Alles über Use Cases
in unserem PDF
kompakt zum Download

Follow a manual added link

Downloads

  • Whitepaper
  • Tipps & Tricks
  • Software

Use Cases für die agile Entwicklung nutzen

Zuerst müssen die Stakeholder des Projekts, d.h. die Anwender und Akteure, die direkt mit dem System arbeiten, identifiziert werden. Ihre Ziele müssen verstanden werden, denn Use Cases dienen immer dazu, Ziele der Anwender zu erreichen. Auf dieser Grundlage können Sie 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 können Sie ein „Top Down“-Vorgehen (vom Use Case ausgehend einzelne Schritte, Abläufe und Alternativen finden) oder ein „Bottom Up“-Vorgehen (zum Beispiel per Brainstorming alle möglichen Abläufe sammeln und zu einem Use Case zusammenfassen) wählen oder beide Vorgehensweisen kombinieren.

Sobald Sie einige stabile Use Cases identifiziert haben, können Sie parallel zur weiteren Use Case-Analyse beginnen, die gefundenen Use Cases durch Story­telling der Anwender genauer zu verstehen, ihre Flows detailliert zu beschreiben und Use Case Stories zu bilden. Es ist hilfreich, bei der Beschreibung der Abläufe bereits die Testfälle “mitzudenken”, also die Testfälle zur gleichen Zeit wie die Use Case Flows zu entwickeln. Sobald Use Case Stories definiert sind, können Sie Use Case Slices bilden. Der erste Slice sollte immer auf dem Basic Flow aufbauen. Use Case Slices müssen dabei so klein geschnitten werden, dass sie in einem Sprint umgesetzt werden können.

Use Case 2.0 setzt nicht voraus, dass alle Use Cases vollständig definiert werden, bevor Ihre Realisierung beginnt. Um erste Backlog Items zu gewinnen, genügt es, einige zentrale Use Cases zu identifizieren. Ein Use Case muss auch nicht komplett in Slices zerlegt werden – es reicht aus, die Slices zu bilden, die für die Planung des/der nächsten Sprints notwendig sind, und die restlichen Use Case Stories erst bei Bedarf weiter zu Slices zu gruppieren.

1
2
3
4
5
Use Cases und Backlogs
1

Wer sind die Stakeholder des Projekts und welche Ziele verbinden Sie mit dem Vorhaben?

2

Im Zuge der agilen Entwicklung bietet sich die Verwaltung von Features und Epics, sowie Use Cases oder Use Case Slices in einem zentralen Backlog für Ihre Domäne an.

3

Die Entwicklung und das Slicing von Use Cases sind typische Aufgaben des Requirements Engineerings. Sie können parallel zur agilen Entwicklung ablaufen, um das Release Backlog kontinuierlich aufzufüllen.

4

Mit den Use Case Slices wird im agilen Planungsprozess genauso gearbeitet wie mit User Stories. Use Cases eignen sich gut, um den Funktionsumfang von Releases abzustecken. Use Case Slices helfen bei der Planung kleinerer Inkremente innerhalb eines kompletten Releases.

5

Hier können Sie mit dem Pull Prinzip arbeiten, d.h. das Team kann sich aus dem Release Backlog Slices in das Team Backlog ziehen.

Übersicht
Wissen Online
Wissen mit Tool anwenden:
objectiF RPM
Mehr Wissen als PDF:
Downloadcenter

Pin It on Pinterest

Share This