Projekte mit Use Cases agil planen

Wie beschreiben Sie Anforderungen? Als Use Cases? Dann sind Sie in guter Gesellschaft: Laut einer aktuellen Studie1 setzen 73% der deutschen Unternehmen Use Cases ein. Als zentraler Nutzen wird dabei genannt, dass Use Cases den funktionalen Zusammenhang eines Systems abbilden und so einen schnellen Überblick über die Systemfunktionalität schaffen. Aber das Konzept der Use Cases ist schon 27 Jahre alt – Ivar Jacobson stellte es erstmals auf der OOPSLA ’87 vor. Ist es in einer Welt, in der sich immer mehr Unternehmen für agile Entwicklung entscheiden, nicht längst überholt?

Haben Use Cases in agilen Projekten ausgedient?

Klare Antwort: keineswegs.

Gerade das Big Picture eines Systems, das Use Cases bieten, wird bei der Arbeit mit User Stories in agilen Projekten vermisst. Ohne das System als Ganzes zu verstehen, fehlt es an Orientierung und Entscheidungen über den Scope (was kann man später entwickeln oder sogar weglassen). Nutzen und Kosten lassen sich so nur schwer vorhersagen.

Fragt sich nur: Wie kann man die Vorteile von Use Cases nutzen und gleichzeitig Planungseinheiten gewinnen, mit denen man Projekte agil steuern und Systeme inkrementell entwickeln kann?

Zahllose Quellen im Internet beschäftigen sich mit der Ableitung von User Stories nach dem Schema “Als möchte ich , um ” aus Use Cases. Aber Zweifel sind angebracht: Ist es wirklich sinnvoll, ein methodisches Konzept in ein anderes zu transformieren, eine sprachliche Form in eine andere zu „übersetzen“? Wäre es nicht vernünftiger, in derselben Welt zu bleiben? Kann man nicht auch direkt mit Use Cases agil planen? Ivar Jacobson und seine Mitautoren Spencer und Bittner haben 2011 die Antwort darauf gegeben2: Ja man kann. Die Lösung heißt Use Case 2.0. Dahinter verbirgt sich eine Technik, die auf einem Slicing – also einem „Zerschneiden“ von Use Cases in planbare Einheiten – basiert.

Und Schnitt …

Ein Use Case ist eine Folge von Aktionen, die ein System durchführt und die als Resultat Nutzen für einen speziellen Anwender hervorbringt. Jeder Use Case enthält einen Basic Flow. Darunter verstehen wir eine Folge von Schritten, die auf „geradem“ Weg zum erfolgreichen Abschluss führt. Meisten gibt es zu einigen Schritten des Basic Flow Alternative Flows, das heißt bedingungsabhängige Abweichungen von „geraden“ Weg.

Jeder Weg vom Start eines Use Case bis zu seinem Ende – egal, ob er geradlinig ist oder über ein paar „Umwege“ – sprich Alternative Flows – führt , wird, sofern er denn sinnvoll ist und einen Nutzen für den Anwender schafft, als Use Case Story bezeichnet.

Wie hilft dieses Verständnis der Struktur von Use Cases bei der agilen Projektplanung? Ganz einfach: Eine oder mehrere Use Case Stories werden zu einer Planungseinheit – einem Use Case Slice – zusammengefasst. Ein Use Case Slice wird als Backlog-Item bei der agilen Entwicklung verwendet.

Zu einem Use Case Slice gehören aber nicht nur Use Case Stories in Form von Start-Ende-Flows durch den Use Case. Bestandteil eines Use Case Slice sind immer auch Testfälle. Zwei Use Case Slices können dieselben Use Case Stories enthalten, sich aber durch ihre Testfälle unterscheiden.

Fazit

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. Use Case 2.0 ist ein noch wenig bekanntes Konzept. Die Besonderheit von Use Case 2.0 liegt in der Integration etablierter Techniken des Requirements Engineerings in eine agile Vorgehensweise. Und damit bieten Use Cases auch zukünftig in agilen Projekten viele Vorteile.

Quellen

1 HK Business Solutions, Fraunhofer IESE: Ergebnisbericht „Use Cases in der Praxis“, 2013
2 Ivar Jacobson, Ian Spence, Kurt Bittner: Use-Case 2.0 ebook, Ivar Jacobson International, 2011

Weitere Informationen finden Sie unter www.microTOOL.de