Auf der OOPSLA '87 stellte Ivar Jacobsen erstmals das Konzept der Use Cases vor. Heute, 27 Jahre später, sind Use Cases noch immer „quicklebendig“ – und zwar nachweislich: So zeigt eine Studie aus dem Jahr 2013 [1], dass 73 % der beteiligten deutschen Unternehmen aktuell Use Cases einsetzen. Ein Viertel davon sogar seit mehr als 10 Jahren. Deutsche Unternehmen stehen damit nicht allein: Nach einer ebenfalls im letzten Jahr durchgeführten Umfrage in der Schweiz [2] verwenden 51 % der befragten Unternehmen Use Cases für die Spezifikation von Anforderungen. Use Cases sind nicht ohne Grund so beliebt: Für viele Unternehmen bilden sie das Mittel der Wahl für die Stakeholderkommunikation. Use Cases helfen dabei, zu verstehen, wie ein System dazu beiträgt, die vom User angestrebten Ziele zu erreichen und die gewünschten Ergebnisse zu erzeugen. Als weiterer wichtiger Nutzen wird wahrgenommen, dass Use Cases den funktionalen Zusammenhang eines Systems abbilden und einen schnellen Überblick über die Systemfunktionalität schaffen. Gerade dieser Überblick wird bei der Arbeit mit User Stories in agilen Projekten häufig vermisst. Wie kann man zum einen die Vorteile von Use Cases nutzen und zum anderen Planungseinheiten finden, die für die agile Projektplanung geeignete sind? Zahllose Quellen im Internet beschäftigen sich mit der Ableitung von User Stories aus Use Cases. Aber ist es wirklich erstrebenswert, ein methodisches Konzept in ein anderes zu übersetzen? Wäre es nicht sinnvoller, in einer methodischen Welt zu bleiben? Kann man nicht auch agil mit Use Cases planen, ohne den Schritt zur User Story zu machen? Jacobsen hat mit zwei Mitautoren 2011 in [3] selbst die Antwort darauf gegeben: Ja man kann. Der Schlüssel dazu ist eine erweiterte Technik: Use-Case 2.0. Sie basiert auf einem Slicing – also einem „Zerschneiden“ der Use Cases. Die Use Case Slices bilden die Planungseinheiten für Sprints in agilen Projekten. Kriterium für das „Zerschneiden“ von Use Cases ist der mit einem realisierten Slice geschaffene Wert für den Anwender. Und so wie zu User Stories immer Testkriterien definiert werden sollten, gehören auch zu einem Slice unbedingt Test Cases. Quellen: [1] HK Business Solutions, Fraunhofer IESE: Ergebnisbericht „Use Cases in der Praxis“, 2013, http://www.hk-bs.de/Presse/wp-content/uploads/2014/03/Ergebnisbericht-Use-Cases-in-der-Praxis.pdf [2] SwissQ Consulting in Kooperation mit der Universität St. Gallen: Requirements Trends & Benchmarks Schweiz, 2013, http://www.swissq.it/wp-content/uploads/2012/11/Requirements-Trends-und-Benchmarks-2013_Web.pdf [3] Ivar Jacobson, Ian Spence, Kurt Bittner: Use-Case 2.0 ebook, Ivar Jacobsen International, 2011, http://www.ivarjacobson.com/Use_Case2.0_ebook/

2. 1987

3. OOPSLA ‘87

5. Use Cases
ein
zeitgemäßes
methodisches Konzept

6. 73%
7%
HKBS, Fraunhofer IESE: Ergebnisbericht Use Cases in der Praxis, 2014

7. Und was
machen sie
damit

8. Use Cases
=
Anforderungen

9. Anforderungen
Use Cases 51%
Prosa 45%
Requirements Trends & Benchmarks, swissQ mit der Universität St. Gallen, Schweiz 2013

10. Anforderungen
User Stories 34 %

11. Prinzip der 3 Cs
Card
Conversation
Confirmation

12. Angenommen
Als <Rolle>
möchte ich
<Vorbedingungen>,
wenn <Ziel/<Wunsch>,
Aktion>,
dann um <<Nutzen>
Ergebnis>

13. User Stories punkten mit
Nutzenals Basis für die
Priorisierung
Akzeptanzkriterien

14. User Stories
Planungseinheiten des agilen
Projektmanagements

15. Wo
bleibt die
Systemübersicht

16. Use Cases & Use Case
Diagramme punkten mit
Überblick über das Verhalten
eines Systems

17. moPATIS
mobiles
Patienteninformationssystem

18. Use Cases –
Eigenschaften

19. Use Case ist
… ein spezifisches Verhalten
eines Systems, das dazu beiträgt, ein
Business-Ziel zu erreichen

20. Use Cases sind
… in der Regel zu umfangreich,
um in einem typischen Sprint
von 2-3 Wochen realisiert zu werden

21. Use Case bildet
… den Kontextfür eine Menge von
Anforderungen

22. Aus
für
agile Entwicklung
mit Use Cases

23. Nein
Skalierbare agile Technik zur Entwicklung
von Anforderungen, mit denen die
inkrementelle Systementwicklung gesteuert
werden kann
http://www.ivarjacobson.com/Use_Case2.0_ebook/

24. Use Case 2.0 – Prinzipen
Einfach bleiben mit Storytelling
Big Picture verstehen
Wert in den Mittelpunkt stellen
System scheibchenweise bauen
System in Inkrementen liefern
Bedürfnissen des Teams gerecht werden

25. Was heißt scheibchenweise bauen?

26. 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 erzeugen

27. Use Case Basic Flow
Alt1
Alt3
Alt2
Start
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Ende
Alternative
Flows

28. Use Case Viele Use Case Stories

29. Flows & Use Case Stories
definieren

30. Slice 1 Slice 2

31. Use Case Slice
ein oder mehrere Use Case Stories
mit zugehörigen Testfällen

32. Use Case Slicing

33. Slices erzeugen
System modellieren
Slices einplanen
und realisieren
Iterativer Prozess
Akteure identifizieren
Use Cases ermitteln
Flows beschreiben
Ziele
Scope
Testfälle

34. Use Case Slicing – Regeln
Nicht alle Use Cases upfront entwickeln
Bei Use Case Entwicklung & Slicing Stakeholder
einbeziehen
Mit Basic Flows der wichtigsten Use Cases beginnen
Nach Pull-Prinzip Slices anfordern
Kein Slice ohne Testfall

35. Agil & Use Case 2.0 – passt!
Backlog-orientiert – Scrum
Workflow-orientiert – Kanban
Skalierbar – SAFe

36. Slices
entwickeln
Akteure identifizieren
Ziele verstehen
Vorbereitung
Use Cases
ermitteln
Use Case
Slicing
Product
Backlog
Sprint
planen
Sprint
Backlog

37. Agil planen

38. A Use Case
is still
a use case

39. Den Unterschied machen…
Flows
Use Case Stories
Use Case Slices

40. Lesbarkeit für Stakeholder
Akzeptanz bei Stakeholdern
Erstellungsaufwand
Passende Granularität

41. Use Case 2.0
mit in-STEP RED®
www.microTOOL.de