200, 300 oder noch mehr User Stories – wie soll ich da mein Produkt im Griff behalten? Woher weiß ich als Product Owner, ob die User Stories alle meine Anforderungen abdecken und wie ich die User Stories günstig schneide? Wie verstehe ich als Entwickler, was die User Story im Produkt bewirkt? Wie kann ich als Tester regressionsfähige Testfälle schreiben, ohne dass mir der Testaufwand explodiert? Diesen spannenden Fragen ist Accso in der Hood-Schulung zur Methode „Use Case 2.0“ auf den Grund gegangen.

Ein hochaktuelles Thema, wie wir beide – Christine Schmetzer und Renato Vinga-Martins – finden. Und obwohl wir das Konzept bereits vor knapp 2 Jahren im Rahmen des Hood-Themen-Breakfast (Use Case 2.0) kennen gelernt hatten, wollten wir noch mehr über den konkreten Einsatz und die Verzahnung mit Dokumentation und Testen lernen. Im Kreise erfahrener Kollegen – vielen Dank an Felix Feldmeier, Nikolaus Fröhlich, Thore Kleinschmidt, Martin Kronenburg, Petra Weilmünster und Helena Unger für den regen Erfahrungsaustausch – konnten wir unsere Vorstellungen praxistauglich machen.

Das Fazit vorneweg

Ohne zu viel vorwegzunehmen, hier unsere Meinung in zwei Sätzen:

• Ja, Use Case 2.0 ist auch in agilen Projekten ein gutes Werkzeug für Stabilität und Überblick.
• Nein, wir haben immer noch kein einsatzbereites Konzept für regressionsfähige Testfälle.

Der Einsatz von Use Case 2.0 lohnt sich. Die Methodik gibt uns ein Mittel zur Abwägung zwischen Flexibilität und Aufwand für kontinuierliche Anpassungen an die Hand.

Für alle, die an Details interessiert sind, eine Zusammenfassung der Inhalte:

Agile Projekte bestimmen unseren Alltag

Seit einigen Jahren gibt es viele agile Projekte und alle kennen Scrum. Das Backlog ist dabei das zentrale Artefakt für Anforderungen. Dort treffen sich alle Beteiligten, und es ist gängige Praxis, Backlog-Einträge als User Story nach dem Muster „Als <Rolle> möchte ich <Ziel/Ergebnis>, um <Nutzen> zu erreichen.“ zu formulieren. So weit, so charmant: Produktdekomposition in fachliche Features, im Wesentlichen nach Nutzwert priorisiert; das leuchtet ein, wenn wir in komplexen Projektumgebungen die Change-Request-Schlachten durch gemeinsames konstruktives Umpriorisieren ersetzen wollen. Sei willkommen, Veränderung. Doch die Praxis macht es uns nicht leicht, denn plötzlich ist alles so kleinteilig. Ich verliere den Überblick darüber, wo ich stehe, und bin gefühlt dauernd mit Testen beschäftigt. Es bleibt dem genialen Product Owner überlassen, seine Inhalte gemeinsam mit dem Team in passende User-Story-Häppchen zu schneiden, die Produktvision konsequent zu verfolgen und die Anforderungen allen Beteiligten zu vermitteln. Denn agile Rahmenwerke wie Scrum erheben keinen Anspruch auf eine bestimmte Formulierungs-, Modellierungs- oder Dokumentationsform.

Der Use Case: da gab es schon einmal ein Konzept

Aber halt! Die Älteren unter uns haben ein Déjà-vu. Da war doch was so vor 25 Jahren. Ivar Jacobson hatte der Verzettelung in funktionalen Anforderungen den Use Case im objektorientierten Entwurf entgegengesetzt. Der revolutionäre Gedanke war, die Anforderungen durch Interaktionsabläufe miteinander zu verknüpfen und auf diese Weise ein Systemverständnis aus Sicht der beteiligten Akteure zu erzeugen. Gleichzeitig diente der Use Case zur Anforderungsvalidierung, er ist also eine zusätzliche Sicht aufs System. Und als die Amigos dann die UML einführten, da waren auch die Use Cases mit dabei. Wir haben sie in unsere Spezifikationen, Konzepte und sogar Schätzverfahren übernommen. Und jetzt? Seit wir mit Anforderungen flexibel umgehen und klassische Spezifikationen als Vorgehensballast gelten, schreiben wir kaum noch Use Cases. 

Use Case 2.0 verbindet den Use Case mit dem agilen Vorgehensmodell

Bereits 2011 ist Ivar Jacobson mit dem Use Case wieder aus der Versenkung aufgetaucht. Sein neuer Beitrag ist mit Use Case 2.0, die Verbindung zwischen dem Use-Case-Konzept und der agilen Vorgehensweise am Beispiel von Scrum herzustellen. Der Use Case bleibt unverändert, das agile Vorgehen ebenfalls, aber die geschickte Verknüpfung bringt den gewünschten Überblick. Das Ergebnis steht allen Interessierten frei als use-case-ebook zur Verfügung. Die Verbindung entsteht mit Hilfe der neuen Begriffe Story und Use-Case Slice, wobei Story in diesem Zusammenhang eine etwas unglückliche Wahl darstellt. 

Denn die Story ist wörtlich als Geschichte im Sinn einer logisch zusammenhängenden Aktionsfolge zu verstehen. Sie ist nur im Spezialfall mit der User Story identisch. Die Abbildung visualisiert den Use Case als sogenannten Basic Flow (der geradlinige Verlauf) mit einer Reihe von Alternativen (ALT N). Jeder mögliche Durchlauf erzählt eine eigene Geschichte (Vorsicht: Kombinatorik!). Auch eine Story kann als Arbeitseinheit zu groß sein, um sie in einem Sprint umzusetzen. Damit entsteht der Use-Case Slice als Pendant zur User Story (nicht in der Abbildung dargestellt).

Bei uns hat das am Beispiel des Use Case „Einkauf abkassieren“ so ausgesehen:

Unsere Erkenntnisse daraus sind:

• Wenn wir eine gewisse Stabilität wollen, dann müssen wir unsere Ziele im Voraus fixieren (z.B. die Inhalte fürs nächste Release). Klingt nur trivial.
• Der Use Case bietet einen passenden Stabilitätsanker. Er zeigt auf natürliche Weise den Umgang mit dem System. (Nicht für alle Arten von Systemen, sie müssen schon an Aktionsfolgen orientiert sein.)
• Der Use Case muss noch nicht fertig detailliert sein, wenn wir mit seiner Umsetzung beginnen. Wir können in Teilen arbeiten. Aber waswir umsetzen, das muss hinreichend detailliert sein.
• Die Dekomposition eines Use Case machen wir mit Hilfe von Geschichten (Story). Wir schneiden niemals horizontal(z.B. im ersten Sprint alle Schritte vollständig bis zur PIN-Eingabe, im zweiten Sprint alle restlichen bis zur Geldausgabe), sondern immer vertikal (z.B. im ersten Sprint die normale Geldausgabe, im zweiten die Berücksichtigung von Fehleingaben). Denn Geschichten haben immer einen Anfang und ein Ende.
• Die stabile Story ist unsere Grundlage für stabile Testfälle. Wenn wir unsere Testfälle so konzipieren, dann können wir sie frühzeitig schreiben und lange unverändert nutzen. 

Der Use-Case Slice als Auftragseinheit für die Umsetzung im Sprint

Die Story ist eine nahe liegende Auftragseinheit. Jede Story besitzt einen Anfang und ein Ende und ist hinreichend detailliert beschrieben. Da die Story nach Definition stabil bleiben soll (soweit das in Planungen eben möglich ist), ist sie auch der ideale Ansatzpunkt fürs regressive Testen. Die Abbildung zeigt, wie die Use Cases in ihrer Fertigstellung inkrementweise wachsen. Kenne ich die Stories meiner Use Cases und mit welchem Slice ich welche Story fertiggestellt habe, dann habe ich eine gute Übersicht über den fachlichen Fertigstellungs- und Abdeckungsgrad. Im einfachsten Fall besteht ein Slice aus der kompletten Story, und es gilt in der uns bekannten Terminologie: Use-Case Slice = Use-Case Story = User Story.

Schade allerdings, wenn eine (Use-Case-)Story nicht vollständig in einem Inkrement (= Sprint) umsetzbar ist. Use Case 2.0 sieht für diese Situation weiteres Slicing vor. Das Team führt im Backlog Grooming gemeinsam das Slicing durch. Ist die Story zu groß, dann müssen eben mehrere Slices her. Damit teilen wir die Story in Fragmente auf und passen bei jedem Fragment wieder auf, dass es wie die Story vertikal geschnitten ist, d.h. einen Anfang und ein Ende hat.

Ein Beispiel für solch ein Slice ist das Bezahlen an der Supermarktkasse, aber auf das Zahlungsmittel Bargeld eingeschränkt. Erst in weiteren Slices kommen weitere Zahlungsmittel wie Kreditkarte oder EC-Karte hinzu. Dieses Beispiel verdeutlicht auch den Kompromiss, den wir beim Slicing auf dieser Ebene eingehen müssen:

• Wir können die Bargeldzahlung ohne Auswahlmöglichkeit fest in unseren Ablauf nehmen, um so das Ergebnis mit minimalem Aufwand und ohne Vorgriff auf zukünftige Aufgaben fertigzustellen. In diesem Fall nehmen wir eine gewisse Instabilität unserer Story in Kauf, wohl wissend, dass wir die zugehörigen Testfälle später werden anpassen müssen. Das entspricht dem agilen Prinzip, immer gerade soviel umzusetzen, wie zur Ergebniserreichung notwendig ist. Dieses Prinzip bewahrt uns vor überkomplexen Lösungen, die anschließend niemand benötigt, die den Wartungsaufwand erhöhen und die wir evtl. sogar wieder zurückbauen müssen. Aber eng ausgelegt erzeugt das Prinzip mangels Voraussicht eben auch mehr Instabilität.
• Oder wir antizipieren den Schritt mit der Zahlungsmittelauswahl, der bei nur einer Option fachlich sinnlos ist, um bereits frühzeitig dem vorgesehenen Story-Ablauf zu entsprechen und stabile Regressionstests zu ermöglichen. In diesem Fall nehmen wir den Verstoß gegen das genannte agile Prinzip in Kauf.

Als Slicing-Techniken haben wir die Splitting Patterns zum Zerlegen von User Stories erfolgreich angewendet. Diese sind sehr zu empfehlen, nachzulesen und illustriert bei AgileForAll.

Bei uns hat das Slicing am Beispiel des Use Case „Einkauf abkassieren“ so ausgesehen:

Weiterführende Links

Das Use-Case-2.0-Whitepaper (2011): https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
Muster zum User-Story-Splitting / Use-Case-Slicing: http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf
Einführungsartikel über Use Case 2.0: http://www.heise.de/developer/artikel/Use-Case-2-0-Agile-Projektplanung-mit-Use-Case-Slices-2535642.html