Was ist eigentlich der methodische Unterschied zwischen Use Cases und User Stories? Ich habe mich selbst nicht sonderlich intensiv mit Use Cases beschäftigt, kann hier also nur wiedergeben, was ich von Alistair Cockburns Erklärung verstanden habe: Eine User Story ist letztlich die Überschrift eines Szenarios, möglicherweise zusammen mit einem Beispiel. Mehrere Szenarien ergeben gemeinsam einen Use Case.
Darf man als Agilist nun Use Cases verwenden, oder nicht? Die Frage ist in dieser Form natürlich Unsinn, weil es bei agiler Entwicklung nicht darum geht, was man „darf“ und was nicht, sondern wie man ein Ziel erreicht. Das Ziel ist in diesem Fall ein adäquates Verständnis der Art und Weise, wie das System eingesetzt wird.
Ich selbst sehe Use Cases gerne als fachliches Design. Wie auch beim technischen Design gibt es hier zwei Möglichkeiten: Man kann das Design vor der Umsetzung zumindest in groben Zügen festlegen, oder es während der Umsetzung „emergent“ entstehen lassen. Sie können also vor der Umsetzung eine „echte“ Use Case Analyse machen, oder sie inkrementell durchführen.
Letzlich wird das Ergebnis der Analyse aber (in ausführbarer Form) vorliegen müssen. Wenn Sie XP betreiben, ist das in der Regel in Form von Akzeptanztests, meistens mit Hilfe des FIT Frameworks. Diese sollten alle relevanten User Stories abdecken, mithin alle releventen Szenarien eines Use Cases. Zur Notation der einzelnen Tests hat Brain Marick einige lesenswerte Gedanken in seinem Blog beschrieben, die sich mit ein wenig gutem Willen und Geschick auch mit FIT bzw. FitNesse umsetzen lassen.
Wie viel Analyse im Vorfeld notwendig ist – mithin wieviel Use Case Analyse – hängt unter anderem davon ab, wie gut die Akzeptanztest-Schreiber die Fachlichkeit überblicken und mit welchen Techniken sie sich wohl fühlen. Auch sollten man bedenken, dass es oft sehr viel schwieriger ist, Akzeptanztests zu refaktorisieren, als „richtigen“ Code emergent zu entwickeln.
In keinem Fall bedeutet Analyse im Vorfeld aber die Rückkehr der tausendseitigen Fachkonzepte. Auch hier gilt, so viel wie nötig, so wenig, wie möglich. Viele meiner Kunden waren aber durchaus glücklich mit fünf- bis zehnseitigen Analysedokumenten, deren Kern oft von Use Cases getrieben war. Auf dieser Basis wurden dann die einzelnen User Stories definiert und priorisiert, die Akzeptanztests geschrieben und der Code umgesetzt. Der Zusatzaufwand war selten mehr, als eine Woche. Andere Teams haben lieber von unten nach oben gearbeitet, hatten aber am Ende auch die User Stories nach Use Cases gruppiert (die Struktur aber oft anfangs auf dem Whiteboard entworfen). Ich selbst habe noch keinen Grund gefunden, mich vehement für die eine oder die andere Seite einzusetzen, solange das Ergebnis stimmt.
PS: Thank you Alistair for the review!
Nice summary, Jens – I like your description of user story as the „title/heading“ of a scenario. I have always said, „A reminder for a conversation“, except that begs the question „about what?“ … which is answered by, „about the scenario for which this is the title!“
The two points to draw from your well-phrased sentence are:
– the user story covers ONE scenario; the use case covers MULTIPLE scenarios
– the user story describes the title only, rarely not the scenario itself; the use case describes each scenario (abstractly).
More importantly, the reason I keep introducing use cases to people is that I keep running across project suffering from three things:
1. No notion of „what is the size of this thing we’re building“ (missing any concept of „completeness“)
2. No context for each story
3. No look-ahead as to what needs early research to get answers in good time.
Use cases answer these 3 problems in a way that nothing around user stories or features or product backlog items do. So I find myself re-introducing use cases to agile teams to save them from these problems. This is written up in more detail at http://alistair.cockburn.us/index.php/Why_I_still_use_use_cases
Nice posting, thanks,
Alistair
Jens,
Thanks for posting this. I took the liberty of doing an English translation and reposting. See here.
Let me know if you want me to take it down.
Pingback: Use Cases und User Stories | setzweinblog