Use Case 2.0: Agile Projektplanung mit Use Case Slices

Architektur/Methoden  –  3 Kommentare

Use Case 2.0 ist eine skalierbare, agile Technik zur Entwicklung von Anforderungen, mit denen sich die inkrementelle Systementwicklung steuern lässt. Ihre Besonderheit liegt in der Integration etablierter Techniken des Requirements Engineering in eine agile Vorgehensweise. Damit bieten Use Cases auch in agilen Projekten Vorteile, die diese so nicht erwartet haben.

Sind Use Cases (oder Anwendungsfälle) überhaupt noch ein zeitgemäßes methodisches Konzept? Ivar Jacobson definierte 1987 auf der OOPSLA [1] einen Use Case als "a special sequence of transactions, performed by a user and a system in a dialogue". Heute, mehr als 25 Jahre später, sind Use Cases noch immer quicklebendig, und zwar nachweislich: So zeigt eine Studie aus dem Jahr 2013 [2], dass derzeit 73 Prozent der befragten Unternehmen Use Cases einsetzen. Ein Viertel davon seit mehr als zehn Jahren. Deutsche Unternehmen stehen damit nicht allein: Nach einer ebenfalls 2013 durchgeführten Umfrage in der Schweiz [3] verwenden dort 51 Prozent der Befragten Use Cases für die Spezifikation von Anforderungen. Das ist naheliegend, denn sie beantworten aus Sicht des Anwenders die Frage, was das geplante System leisten soll.

Anders sieht es in Unternehmen aus, die sich für agiles Vorgehen entschieden haben. Hier werden zum Erfassen der Anwenderwünsche User Stories eingesetzt. 2001 grenzte Ron Jeffries [4] mit seiner 3C-Formel "soziale" User Stories von der "dokumentarischen" Anforderungserhebung mit Use Cases ab. Das erste C steht für Card, also Karte. User Stories sollen so kurz und prägnant sein, dass sie auf reale Karten (z. B. Haftnotizen oder Karteikarten) passen. Dieser Platz sollte ausreichen, um dem Team klarzumachen, was das Ziel bei der Umsetzung der Story ist.

User Stories sind keine Anforderungen, die so weit verfeinert sind, dass mit einem Satz alles gesagt ist. Es wird lediglich ein einzelner Satz festgehalten. Was der Kunde darüber hinaus zur Anforderung zu sagen hat, wird nicht aufgeschrieben, sondern in Gesprächen geklärt. Dafür steht das zweite C: Conversation. Stories werden in der Regel sogar mehrmals besprochen, zum Beispiel im Verlauf eines Anforderungsworkshops, in einer Schätzklausur und während der Sprint-Planung.

Um einen Nachweis zu haben, ob die Stories in der vom Anwender gewünschten Weise implementiert wurden, werden für jede Story Akzeptanzkriterien festgehalten. Und dafür steht das dritte C: Confirmation. Für die Formulierung von User Stories werden Textschablonen vorgeschlagen wie: "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erhalten." Und für die Rückseite: "Angenommen <Vorbedingungen>, wenn <Aktion>, dann <Ergebnis>." Das bedeutet: Auf der Rückseite stehen die Akzeptanztests, die die implementierte User Story bestehen muss.

User Stories werden für die Projektplanung priorisiert. Das wichtigste Kriterium dafür ist der Anwendernutzen. Je umfangreicher agile Projekte werden, desto stärker tritt das Manko von User Stories zu Tage: Teams beklagen, dass das Big Picture, also der Überblick über die Systemfunktionalität, verloren geht. Use Cases, dargestellt in Use-Case-Diagrammen der UML, zeigen gerade hier ihre Stärke. Sie geben einen Überblick über das Verhalten eines Systems und zeigen auf, wie es benutzt wird. Nach heutigem Verständnis fasst ein Use Case alle Folgen von Anwender-System-Interaktionen zusammen, die auftreten können, wenn ein Anwender ein fachliches Ziel mit einem geplanten System erreichen will.

Ein Use Case ist also ein spezifisches Verhalten eines Systems, das dazu beiträgt, ein Business-Ziel zu erreichen. Nicht nur die User Story ist darauf fokussiert, einen Wert für den Anwender zu schaffen. Auch Use Cases stellen den Anwendernutzen in den Vordergrund. Warum passen aber Use Cases scheinbar nicht zu modernen, agilen Entwicklungstechniken? Sie sind in der Regel zu umfangreich, um in einem typischen Sprint von zwei bis drei Wochen realisiert zu werden. Und: Ein Use Case bildet meist den Kontext für mehr als eine Anforderung.

Zahllose Quellen im Internet beschäftigen sich mit der Ableitung von User Stories aus Use Cases. Aber Zweifel sind angebracht: Ist es wirklich sinnvoll, ein Konzept in ein anderes zu transformieren, eine sprachliche Form in eine andere zu "übersetzen"? Wäre es nicht vernünftiger, in derselben methodischen Welt zu bleiben? Kann man nicht auch direkt mit Use Cases agil planen? Ja, man kann.