Von User stories und Use cases
Im ersten Moment könnte man meinen, das sei jeweils dasselbe - oder zumindest so ähnlich. In der agilen Softwareentwicklung ist das natürlich nicht der Fall. Auf der einen Seite unterscheiden sich Use cases von User stories deutlich, andererseits haben sie auch Gemeinsamkeiten.
User Stories (oder Anwenderszenarien bzw. einfach Benutzergeschichte) sind in knapp zwei Sätzen zusammengefasste Handlungsanweisung an die Software. Anders gesagt, es ist eine in Alltagssprache fomulierte Anforderungen an die Software aus Sicht des Anwenders. Sie helfen bei der Analyse von Nutzeranforderungen. In der Regel sollte der Auftraggeber einer Softwareanwendung diese User stories verfassen. User stories sind eine der wichtigen Methoden, um ein agil entwickeltes Projekt zu steuern bzw. seinen Erfolg zu messen. Benutzer sollen zum Beispiel in einem System Adressänderungen vornehmen können. Dann sieht eine User story schlicht und ergreifend so aus: Adressänderung: Eine Adressänderung gilt als vorgenommen, wenn an den Parametern X, Y, Z ein Änderung durchgeführt wurde.
Im Gegensatz dazu sind Use cases die konkreten Anwendungsfälle (widerum nicht zu verwechseln mit Geschäftsprozessen. - Einen guten Artikel zu Geschäftsprozessen bei Wikipedia.)
Auch bei Wikipedia fand ich diese kompetente Definition eines Use case:
“Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert”.
Um bei dem Beispiel der Adressänderung zu bleiben, gibt es in diesem Vorgang mehrere Möglichkeiten, wie das System mit dem Anwender, der die Änderungen vornimmt, interagiert. Unter Umständen ergeben sich verschiedene Wege (Fälle eben), die an Bedingungen gekoppelt sind - die widerum durch das System vorgegeben sind (das können Geschäftsprozesse sein oder Regeln). Jeder Use Case ist eine in sich abgeschlossene Anwenderaktion. Eine Use story kann sich durchaus in mehrer Use cases aufsplitten - je nachdem, wie komplex die “Geschichte” ist. Andererseits können User stories so simpel sein, dass sie gleichzeitig als Use cases verwendet werden können. Zum Beispiel die Anforderungen, die für den Start einer Anwendung definiert sind. Das ist so simpel, da braucht es neben der User story dann keinen Use case mehr.
Aus meiner Sicht werden User stories in der agilen Softwareentwicklung noch stark vernachlässigt. Use cases haben sich als Bestandteil der Entwicklungsprozesse innerhalb des Software-Developments schon lange ihren Platz erobert. User stories dagegen, die die Kundensicht und deren Anforderungen in die Entwicklung mit einbringen, müssen sich aus meiner Sicht ihren Platz noch erkämpfen. Dabei erleichtern sie den implementierenden Teams die Arbeit enorm. Mit User stories können Auftraggeber von Software ihre Anforderungen selbständig und in ihrer eigenen Sprache formulieren.
Buchtipp: User Stories Applied: For Agile Software Development von Mike Cohn
bei Amazon (und nein, wir haben keine Amazon-Partnerschaft). Mike Cohn beschreibt sehr anschaulich wie man Use stories schreibt und über die Fülle der einzelnen User stories die Übersicht behält. Es richtet sich also vorrangig an Businessverantwortliche, die während der Implementierung die Sicht des Anwenders vertreten. Sie haben die tiefe Kenntnis der Interaktionsprozesse bzw. deren Anforderungen aus Business-Sicht. Und die muss zwingend in den Entwicklungsprozess integriert werden bzw. ihre erfolgreiche Umsetzung ist schliesslich der Schlüssel für den Erfolg der Softwareentwicklung.
Ein weiterer Link zu User stories bei Extreme Programming
