What’s in a story?
Der folgende Text ist eine Übersetzung des englischen Artikels “What’s in a story” von Dan North & Associates. Der Original-Autor schreibt in Ich-Form aus eigener Sicht. Der Text wurde nach bestem Wissen und Gewissen übersetzt. Anmerkung: Den Fachbegriff Storytelling fürs Marketing haben wir hier beschrieben.
Was macht eine Story aus?
Verhaltensgetriebene Entwicklung (Behavior-driven development - BDD) ist eine Methode, die von außen nach innen geht: Sie beginnt außen mit der Identifikation von Geschäftszielen oder -ergebnissen und bewegt sich dann hinab in ein Featur-Set (Funktionen-Sammlung), welches diese Ergebnisse erzielen soll. Jedes Feature (Funktion) ist als "Story" festgehalten, welche den Umfang des Features anhand seiner Akzeptanz-Kriterien definiert. Dieser Artikel stellt den BDD-Ansatz vor, Stories und deren Akzeptanz-Kriterien zu definieren und identifizieren.
Einleitung
Bei der Software-Entwicklung geht es darum, Software zu schreiben, um Geschäftsziele zu erreichen. Das klingt offensichtlich, aber häufig halten uns politische oder andere Umweltfaktoren davon ab, uns an diese Tatsache zu erinnern. Manchmal scheint Software-Entwicklung dazu da zu sein, “optimistische Reporte” oder etwas anderes zu produzieren, die das Senior Management bei Laune halten sollen. Oder einfach nur, um "Beschäftigung" zu zeigen, damit die Angestellten in Brot und Lohn bleiben - aber das ist ein anderes Thema.
Normalerweise sind Geschäftsziele zu grob formuliert und undurchsichtig, um direkt für die Software-Entwicklung verwendet werden zu können - wo soll man starten, wenn das Ziel lautet "5% der Betriebskosten einsparen"? Also benötigt man besser definierte Anforderungen, um mit der Arbeit anzufangen.
Verhaltensgetriebene Entwicklung (BDD) bedeutet, dass man die Idee zu einer Anforderung einfach und effektiv in einen implementierten, getesteten und produktionsfertigen Code umwandeln kann. Das setzt voraus, dass die Anforderung spezifisch genug ist, um allen klarzumachen, worum es genau geht. Um das zu erreichen, benötigt man einen Weg, eine Anforderung zu beschreiben, so dass alle Beteiligten - Geschäftsleute, Analysten, Entwickler und Tester - ein gemeinsames, gleiches Verständnis des Umfangs der Aufgabe haben. Von dieser Basis aus können sie gemeinsam definieren, wann eine Aufgabe “erledigt” ist und vermeiden Missverständnisse.
Hier kommt die Story ins Spiel. Sie muss eine Beschreibung der Anforderung und des Geschäfts-Benefits sein und ein Kriterien-Set enthalten, anhand dessen alle Beteiligten übereinstimmen, dass die Arbeit "erledigt" ist. Das ist eine rigorosere Definition als in anderen agilen Methoden. Hier wird sie auf verschiedene Art und Weise als "Versprechen nach einer Unterhaltung" oder einer "Beschreibung eines Features" beschrieben.
Die Struktur einer Story
BDD verfügt über eine Story-Struktur. Diese ist nicht zwingend notwendig - man kann ein anderes Story-Format verwenden und entwickelt immernoch verhaltensgetrieben - aber diese Struktur wird hier vorgestellt, da sie sich in vielen Projekten aller Formen und Größen als nützlich erwiesen hat. Ihre Story sollte zumindest alle im Template beschriebenen Elemente enthalten. Die Story-Vorlage sieht so aus:
Titel (eine Zeile Kurzbeschreibung der Story) Erklärend: As a [role] (als ... [Rolle]) I want [feature] (möchte ich ...[Feature]) So that [benefit] (damit, um zu, weil ... [Benefit]) Akzeptanz-Kriterien: (als Szenarios umschrieben) Scenario: Title (Szenario: Titel) Given [context] (Gegeben, vorangestellte Tatsache [Kontext]) And [more context] (Und [mehr Kontext]) When [event] (Wenn [Ereignis]) Then [outcome] (Dann [Ergebnis, Ziel]) And [another outcome] (Und [ein weiteres Ergebnis, Ziel]) Scenario: ...
Bedenken Sie, dass Stories in der Regel in englisch verfasst werden.
Story-telling
Eine Story sollte das Ergebnis einer Besprechung verschiedener Beteiligter sein. Ein Geschäftsanalyst spricht mit einem Stakeholder über ein Feature oder eine Anforderung und hilft dabei, diese in einer Story einzurahmen. Danach hilft ein Tester, den Umfang der Story zu definieren (in Form von Akzeptanz-Kriterien), indem er entscheidet, welche Szenarien sinnvoll oder weniger hilfreich sind. Ein Techniker wird eine Abschätzung des Arbeitsaufwandes für diese Story abgeben und alternative Ansätze vorstellen. Viele großartige Systeme stammen, neben den Menschen, die sie entwickelt haben, auch von denjenigen, die zuerst danach gefragt haben.
Das alles ist ein iterativer Prozess. Ein Stakeholder hat vielleicht eine Idee oder Vision eines Features, aber normalerweise keine Ahnung davon, wie viel Arbeit das kostet oder wer für diese Arbeit zuständig sein wird. Durch die Unterstützung der Technik- und Test-Experten werden die Stakeholder das Kosten-Nutzen-Verhältnis jedes Szenarios verstehen und eine Entscheidung treffen können, ob sie ein Feature wirklich wollen oder nicht. Selbstverständlich wird das gegen die anderen Anforderungen aufgewogen: Ist es sinnvoll, noch mehr Grenzfälle in dieser Story abzudecken, oder sollte man zur nächsten Story übergehen?
Manchmal wird das Entwicklerteam einfach nicht genügend wissen, um eine Aufwandsabschätzung durchzuführen. In diesem Fall werden sie sich entscheiden, mehr Recherchearbeit zu machen. Diese Aufgabe, die nicht als Ziel hat, ein Produkt abzuliefern, sondern Antworten auf Detailfragen zur Anforderung zu geben, nennt sich "Spike". [Anm.: Erst danach wird die Aufwandsabschätzung und damit das Kosten-Nutzen-Verhältnis möglich bzw. überschaubar sein.]
Charakteristika einer guten Story
Im Folgenden wird als Beispiel die Anforderungen an die Barentnahme an einem Geldautomaten zu definieren (Anm.: Stories werden auf englisch verfasst):
Story: Account Holder withdraws cash As an Account Holder [role] I want to withdraw cash from an ATM [feature] So that I can get money when the bank is closed [benefit] Scenario 1: Account has sufficient funds Given the account balance is \$100 And the card is valid And the machine contains enough money When the Account Holder requests \$20 Then the ATM should dispense \$20 And the account balance should be \$80 And the card should be returned Scenario 2: Account has insufficient funds Given the account balance is \$10 And the card is valid And the machine contains enough money When the Account Holder requests \$20 Then the ATM should not dispense any money And the ATM should say there are insufficient funds And the account balance should be \$20 And the card should be returned Scenario 3: Card has been disabled Given the card is disabled When the Account Holder requests \$20 Then the ATM should retain the card And the ATM should say the card has been retained Scenario 4: The ATM has insufficient funds ...
Wie Sie sehen, gibt es eine Vielzahl an Szenarios zu berücksichtigen. Manche haben mit dem Kontostand zu tun, andere mit der Karte selbst, und wieder andere mit dem Automaten an sich. Lassen Sie uns die Story "aufdröseln" um zu entscheiden, ob sie passt.
Der Story-Titel sollte eine Aktivität beschreiben.
Der Titel der Story, "Account Holder withdraws cash" (Kontoinhaber hebt Geld ab), beschreibt die Aktivität der Bargeldentahme durch den Kontoinhaber. Bevor man dieses Feature implementieren kann, wird der Kontoinhaber nicht dazu in der Lage sein, Geld vom Automaten abzuheben. Sobald das Feature steht, wird das möglich sein. Das gibt einen offensichtlichen Startpunkt für die Entscheidung, was "erledigt" bedeutet.
Würde der Titel lauten "Konto-Management" oder "Geldautmaten-Verhalten", müsste man tiefer blicken um zu verstehen, wann die Arbeit beendet ist und die Rahmenbedingungen wären nicht klar. "Konto-Management" z. B. könnte mit Lohn-Beantragung in Verbindung gebracht werden und "Geldautomaten-Verhalten" könnte die PIN-Änderung beinhalten. Der Story-Titel sollte immer das aktuelle Verhalten des Nutzers oder Systems beschreiben.
Die Erklärung sollte eine Rolle, ein Feature und einen Benefit enthalten
Die Vorlage "As a [role] I want [feature] so that [benefit]" hat eine Reihe an Vorteilen. Durch die Spezifikation der Rolle innerhalb der Erklärung weiß man, mit wem man über das Feature sprechen soll. Ein klarer Benefit führt dazu, dass der Story-Schreiber versteht, warum man dieses Feature haben will.
Interessant wird es, wenn man herausfindet, dass das Feature nicht wirklich den Benefit bringt, den man ihm zuschreibt. Das bedeutet meistens, dass Ihnen eine Story fehlt: Zwar gibt es eine Story mit dem aktuellen Feature, dieses bringt aber einen anderen Benefit. Aber die eigentliche Story, für die Sie ein anderes Feature benötigen, das den beschriebenen Benefit bringt, ist noch “verborgen”.
Die Beispiel-Story oben sagt uns, dass es einen Kontoinhaber gibt, der ein Feature möchte. Dadurch wissen wir, wo wir starten müssen zu untersuchen, was dieses können muss.
Der Szenarien-Titel sollte klarmachen, was das Szenario von den anderen unterscheidet
Sie sollten dazu in der Lage sein, die Szenarien nebeneinander aufzustellen und deren Unterschiede nur anhand der Titel festmachen können. Im obigen Beispiel sehen Sie, dass die Szenarien-Beschreibungen nur Aufschluss darüber geben, was in den Szenarien jeweils anders ist. Sie müssen nicht beschreiben "ein Kontoinhaber möchte Geld abheben von einem nicht gedeckten Konto und erhält die Antwort, dass die Transaktion nicht durchgeführt werden kann". Der Titel macht offensichtlich, ob dieses das gewünschte Szenario ist, verglichen mit den anderen.
Das Szenario sollte durch Givens, Whens und Thens beschrieben werden
Das ist die größte Änderung, die Teams erleben, wenn sie das erste Mal BDD verwenden. Durch die einfache Tatsache, dass Nutzer, Analysten, Tester und Entwickler das Vokabular von "Given, When und Then" annehmen, erfahren sie, dass eine Welt aus Mehrdeutigkeit verschwindet.
Nicht alle Szenarien sind so einfach: Manche sind eher eine Folge von Ereignissen: Gegeben ist [ein Kontext], wenn ich [etwas tu], dann [passiert das], wenn ich [etwas anderes tu]. dann [passiert etwas neues] etc. Ein Beispiel ist ein Programm-Assistent, bei dem man durch eine Folge von Bildschirmen geführt wird, um ein komplexes Datenmodell zu erstellen. Das ist perfekt geeignet, um Ereignis- und Ergebnis-Folgen zu kombinieren, solange Sie sich angewöhnen, in diesen Termen zu denken.
Eine dadurch auftauchende, interessante Veränderung ist, dass die Gesprächsqualität steigt. Sie werden schnell merken, sollten Sie ein (voraussetzendes) Given vergessen haben ("natürlich ist das Konto überzogen") oder auch ein Ergebnis / Ziel nicht verifiziert haben ("selbstverständlich bekommt der Karteninhaber seine Karte zurück"). In einem [dem Autor] bekannten Projekt hat der leitende Entwickler berichtet, dass Analysten und Entwickler aneinander vorbeiredeten, er aber nicht wusste, wie er ihnen das demonstrieren sollte. Ein paar Tage, nachdem Given/When/Then eingeführt wurde, konnte er sehen, dass die Qualität ihrer Interaktionen dramatisch gestiegen ist.
Givens sollten alle benötigten Kontexte enthalten und nicht mehr als das.
Alle überflüssigen Givens bzw. vorangestellte Tatsachen sind störend, da sie es schwieriger für jemanden, das erste Mal diese Story ansieht, machen zu erkennen, was für sie wichtig ist. Unabhängig davon, ob von der technischen oder der Geschäftsseite aus. Gleichzeitig führen alle fehlenden Givens zu Vermutungen. Wenn man ein anderes Ergebnis erreichen kann als in den vorhandenen Givens angegeben, muss etwas fehlen.
In diesem Beispiel sagt das erste Szenario etwas über den Kontostand, die Karte und den Geldautomaten selbst. All diese Elemente sind notwendig, um das Szenario zu definieren. Im dritten Szenario wird nichts über den Kontostand ausgesagt oder darüber, ob der Automat Geld enthält. Dies impliziert, dass die Karte einbehalten wird, unabhängig von Kontostand oder Status des Automaten.
Das Ereignis sollte das Feature beschreiben
Das Ereignis selbst sollte sehr einfach sein, typischerweise ein einzelner Aufruf im Code. Wie schon oben besprochen sind manche Szenarien komplizierter als das Beispiel, aber meistens werden sich die Szenarien einer Story um ein Einzelereignis drehen. Sie werden sich nur im Kontext (Givens) und den dazugehörigen erwarteten Ergebnissen unterscheiden.
Die Story sollte kurz genug sein, um in eine Iteration zu passen
Es gibt keine festen Regeln, nach denen Sie dies einhalten sollen, solange Sie alles in verständliche "Happen" herunterbrechen können. Generell gilt: Sollte es mehr als fünf oder sechs Szenarien geben, kann eine Story vermutlich in mehrere heruntergebrochen werden. Dann können ähnliche Szenarien gruppiert werden.
Man kann an dieser Stelle für das Geldautomaten-Beispiel nicht sagen, wie viele Szenarien mehr es für diese Story gibt, aber vermutlich sind es einige mehr. Grundsätzlich gibt es drei Dreh- und Angelpunkte in dieser Geschichte, nämlich der Kontostand, der Status der Karte und der Status des Automaten. Man könnte mit der Karte mehr ins Detail gehen: Was, wenn sie abgelaufen ist, sodass man sie nicht zum Geld abheben verwenden kann, der Automat sie aber dennoch zurückgibt? Was, wenn der Automat mittendrin die Transaktion abbricht? Was, wenn das Konto einen Dispokredit hat?
Es wäre dann besser, die Story in verschiedene, kleinere Stories herunterzubrechen:
- Der Kontoinhaber hebt Geld ab (Vermutung: Automat funktioniert und Karte ist valide)
- Der Kontoinhaber hebt Geld ab mit einer invaliden Karte (Vermutung: Automat funktioniert)
- Der Kontoinhaber hebt Geld von einem kaputten Automaten ab (Vermutung: Die Karte ist valide)
Auch wenn das gekünstelt wirkt, erlaubt dieses Vorgehen, den Fortschritt in geschäftlichen Begriffen zu demonstrieren und gibt mehr Datenpunkte her, die verfolgt werden können. Wichtig ist, die Story immer entlang von Geschäftslinien durch Szenarien herunterzubrechen (und dabei die Vermutungen explizit darzustellen), statt sie an technischen Strukturen auszurichten (z. B. Datenbanken in dieser Iteration entwickeln und Benutzeroberfläche in der nächsten...). Nur so können die nicht-technischen Stakeholder einen sichtbaren Fortschritt in deren eigenen Begriffen erkennen, statt sich nur auf Ihr Wort zu verlassen.
Wie unterscheidet sich die Story von Use Cases (Anwendungsfällen)?
Es gibt Anwendungsfälle und es gibt Anwendungsfälle. Der Original-Autor des englischen Artikels beschreibt, dass er ein großer Fan der Beschreibung von Alistair Cockburns Use Cases ist, im Gegensatz zu den überentwickelten Versionen, denen er in verschiedenen anderen Projekten begegnet ist. Da er aber wenig Erfahrung mit Use Case-getriebenen Projekten hat, wird er anderen überlassen, hier Vergleiche zu ziehen.
Er stimmt Cockburns Vorgang zu, mit geringer Präzision eines Ergebnisses oder Ziels zu starten, um sich zu einer höheren Präzision durchzuarbeiten, indem immer mehr Szenarien eingebaut werden, je weiter man kommt. In BDD würde das bedeuten, mit den Geschäftszielen zu beginnen und in hochfunktionalen Bereichen zu arbeiten, um in spezifische Stories mit Akzeptanzkriterien einzutauchen.
In der Realität ist es unerheblich, wie Ihr Prozess zur Identifikation und Erarbeitung von Anforderungen läuft. Es ist in Ordnung, wenn Sie Anforderungsdokumente verfassen, die Ihnen helfen, Ihre Gedanken zu ordnen. Was nicht in Ordnung wäre, diese Dokumentationen weiterzuverbreiten, als würden diese all Ihre Gedanken enthalten, denn das tun sie nicht. Stattdessen sollten Sie Ihr Anforderungsdokument oder den Stapel Use Cases auf die Seite legen und anfangen, Stories aus Geschäftszielen zu definieren, mit der Sicherheit, dass all Ihre harte Arbeit dazu führt, dass Sie alle Antworten im Kopf haben - oder zumindest ein ausreichendes Verständnis dafür, die Arbeit zu umschreiben, wie Sie sie gerade sehen.
Zusammenfassung
BDD verwendet eine Story als Basiseinheit der Funktionalität und dadurch der Entwicklung. Die Akzeptanzkriterien sind ein intrinsischer Teil der Story - sie definieren den Umfang des Verhaltens und führen zu einer gemeinsamen Definition von "erledigt". Sie werden außerdem als Basis verwendet, um abzuschätzen, wann man mit der Planung beginnen kann.
Das wichtigste ist, dass die Stories ein Ergebnis von Besprechungen aller Projekt-Beteiligten sind. Bei BDD geht es viel mehr um die Interaktion zwischen verschiedensten Menschen im Projekt als um die Ergebnisse des Entwicklungsprozesses.
Anmerkung: arocom nutzt Behat Tests (BDD) für alle Projekte, unter anderem auch das Reichweitenportal haustec.de.
