Das Prinzip Use Case 2.0
Was beinhaltet Use Case 2.0, welche Vorteile bietet das Konzept und wie kann es in der Praxis genutzt werden?
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.
So wenden Sie das USe Case 2.0-Konzept in der Praxis an.
Erfahren Sie hier mehr zu Requirements Modelling
mit objectiF RPM oder objectiF RM »
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.
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 Storytelling 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.
