Methodik: Use Cases, User Stories und Akzeptanztests

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!

Dieser Eintrag wurde am 15.1.2008 um 08:52 verfasst und befindet sich in Agilität. Sie können alle Antworten zu diesem Eintrag über den Feed RSS 2.0 mitverfolgen. Hinterlassen Sie eine Antwort oder einen Trackback-Link zu Ihrer eigenen Homepage.

| Drucken