Wer mit Use Cases agil arbeiten will, hat ein Problem: Use Cases sind auf Systemniveau meistens zu umfangreich, um in einem Sprint realisiert zu werden. Wie zerteilt man Use Cases also in geeignete Planungseinheiten für die agile Entwicklung? Und das möglichst ohne aus dem Blick zu verlieren, dass ein Akteur mit einem Use Case immer ein fachliches Ziel erreichen will, also Nutzen für ihn entstehen muss? Die Technik Use Case 2.0 [1] gibt eine Antwort darauf. Hier das Konzept von Use Case 2.0 in 50 Sekunden:
Es gilt also Use Cases mit Flows zu beschreiben und zu „slicen“, also so zu zerschneiden, dass sie iterativ entwickelt und in Inkrementen geliefert werden können. Die Darstellung der Use Case Stories erleichtert es zu erkennen, welcher Wert für den Anwender jeweils darin steckt.
Aber was tun, wenn sich während der Schätzklausur oder bei der Sprintplanung herausstellt, dass eine Use Case Story zu einem Slice gemacht wurde, die eine so umfangreiche Interaktion zwischen Akteur und dem zu entwickelnden System abbildet, dass an eine Realisierung in einem Sprint nicht zu denken ist? Wie geht man mit Use Case Slices um, die immer noch zu groß für einen Sprint sind? Die Lösung heißt:
Slice the Slice
Wenn es unumgänglich ist, einen Use Case Slice bzw. die darin enthaltene Use Case Story weiter zu „zerschneiden“, sollten dabei folgende Regeln beachtet werden (in Anlehnung an das Aufteilen von Epics User Stories [2]):
Eine Use Case Story eines Use Case Slice sollte so aufgeteilt werden, dass
- jedes Teil, wenn es implementiert ist, ein Stück funktionierende Software liefert,
- jedes Teil – auch allein – einen Wert für den Anwender schafft,
- jedes Teil potenziell ein Feedback des Anwenders ermöglicht.
Sind diese Regeln erfüllt, kann ein zu großer Use Case Slice durch mehrere Use Case Slices ersetzt werden, die jeweils Teil-Stories mit zugehörigen Testfällen enthalten. Diese Use Case Slices für die Teil-Stories werden dann priorisiert, eingeplant, implementiert und im Sprint-Review geprüft. Also (agiles) Business as Usual – d.h., fast: Sind alle Teile fertig, einzeln getestet und abgenommen, müssen sie noch im Zusammenhang anhand der Testfälle des ursprünglichen Use Case Slice getestet werden – bei der Sprintplanung nicht vergessen!
Wie funktioniert das Aufteilen einer Use Case Story eines Use Case Slice konkret? Um diese Frage zu beantworten, schauen wir auf die Lösungen, die sich beim Zerlegen von User Stories bewährt haben, die in der agilen Entwicklung üblicherweise eingesetzten werden (Sie erinnern sich: “Als möchte ich , um “). Use Case Slices und User Stories dienen zwar beide als Anforderungen und Planungseinheiten, haben deshalb vieles gemeinsam. Sie unterscheiden sich aber auch in wesentlichen Punkten [3]. In jedem Fall lohnt es sich, zu fragen: Was macht man, wenn User Stories zu groß sind? Gibt es vielleicht Konzepte, die sich auf Use Case Slices übertragen lassen? Die gibt es in der Tat.
Slicing-Patterns
So schlägt Richard Lawrence zum Beispiel eine ganze Reihe von Mustern zum Zerlegen von User Stories vor.[4] Einige davon kann man leicht auf das Zerlegen von Use Case Slices übertragen. Hier sind zwei dieser Muster:
Muster 1: Man kann eine Use Case Story eines Use Case Slice zerlegen, indem man die Schnittstellen variiert.
Das Variieren der Schnittstelle wendet man an, wenn ein Use Case und damit auch seine Stories eine sehr komplexe Schnittstelle zu einem Fremdsystem besitzen. Man teilt dann eine Use Case Story eines Slice in Teil-Stories auf, in dem man die komplexe Schnittstelle vorläufig durch eine sehr einfache ersetzt. Und die echte Schnittstelle in einer zweiten Teil-Story realisiert. Wie in unserem Beispiel:
Hier kommuniziert ein Use Case einer Software für Ärzte mit einem Magnetresonaztomographen (MRT).
Use Case
Statt im Rahmen eines Slices gleich die Schnittstelle und die gesamte Funktionalität des Slices zu implementieren, werden Daten zunächst aus einfacherer Quelle besorgt – aus einer Datei. Damit wird die Funktionalität entwickelt. Die echte Schnittstelle entsteht mit einem zweiten Slice. Also, keine neue Idee, aber auch hier funktioniert sie:
Aufsplitten der Schnittstellen
Muster 2: Man kann eine Use Case Story eines Use Case Slice zerlegen, indem man ihre Interaktionsschritte (Steps des Flows) aufteilt.
Das Aufteilen der Schritte wendet man an, wenn die Use Case Story eines Use Case Slice sehr umfangreich ist. Man teilt dann einfach die Use Case Story so in Teil-Stories auf, dass Anfang und Ende des Flows in einer Teil-Story liegen und der verarbeitungsintensive Mittelteil in einer zweiten.
Nachfolgendes Beispiel zeigt, dass eine solche Zerlegung funktional zwar nur einen begrenzten Nutzen schafft, aber dennoch die Chance für ein erstes Feedback des Anwenders bietet.
Aufsplitten der Interaktionsschritte
Weitere Muster sind beispielsweise:
- das Aufteilen von Operationen,
- das Aufteilen von Daten.
Das Warum und Woher – Nachvollziehbarkeit schaffen
Wenn bei der Spezifikation eines Use Case klar wird, dass eine Use Case Story zu umfangreich ist, kann man sie sofort – noch bevor daraus Slices definiert werden – weiter zerlegen. Was aber, wenn erst in der Schätzklausur oder bei der Sprintplanung klar wird, dass ein Slice viel umfangreicher ist als gedacht? Wie alle Entwurfsentscheidungen sollte auch das Zerlegen von Use Case Slices dokumentiert werden, um nachvollziehbar zu bleiben.
Mit objectiF RPM gibt es dafür zwei Möglichkeiten:
- Eine Revision des Use Case anlegen. Dann den Use Case bearbeiten: Die zu großen Use Case Stories zerlegen und den Use Case erneut slicen.
- Den Use Case lassen wie er ist. Aber die bereits abgeleiteten zu großen Slices verfeinern. Slices sind in objectiF RPM eine spezielle Form von Requirements. Requirements können verfeinert werden. Hier empfiehlt sich, die Zerlegung in einem Requirements-Diagramm (nach der SysML) abzubilden.
Ein Team sollte sich für eine der beiden Möglichkeiten entscheiden und diese dann im Projekt konsequent und ausschließlich praktizieren – ganz nach dem Prinzip von Use Case 2.0: Adapt to meet the team’s needs.
Quellen:
[1] Ivar Jacobsen, Ian Spence, Kurt Bittner: Use-Case 2.0 – The Guide to Succeeding with Use Cases, Ivar Jacobson International, 2011, E-Book
[2] Rachel Davis, Slicing and Dicing Epic User Stories, 2010
[3] Ivar Jacobson, Ian Spence, Brian Kerr: Use-Case 2.0: The Hub of Software Development, Ivar Jacobson International, 2015
[4] Richard Lawrence: Patterns for Splitting User Stories, 2012