Einblick in Job Stories: Das Situative Anforderungsformat 💼

Job Stories sind ein Format für die Anforderungsdefinition in der Produktentwicklung, das sich darauf konzentriert, die spezifischen Situationen, in denen Benutzer handeln, zu verstehen. Im Gegensatz zu User Stories, die sich oft auf die Merkmale und Eigenschaften der Benutzer konzentrieren, richten sich Job Stories nach dem Prinzip: „Wenn [Situation], möchte ich [Motivation], damit ich [Ergebnis] erreiche“. Diese Formulierung zielt darauf ab, die zugrundeliegenden Motivationen und den Kontext des Benutzers zu erfassen.

Kontrastierung: Job Stories und User Stories im Vergleich 🤲

Im Vergleich zu User Stories, die typischerweise im Format „Als [Nutzerrolle] möchte ich [Aktion], um [Ziel]“ formuliert sind, fokussieren sich Job Stories mehr auf die situativen Aspekte. Während User Stories dazu neigen, eine Benutzerrolle in den Vordergrund zu stellen, betrachten Job Stories die spezifischen Bedingungen, unter denen eine Aufgabe erfüllt wird. Diese Unterscheidung führt zu einem tieferen Verständnis der Benutzeranforderungen, da der Kontext und die spezifischen Auslöser für Aktionen stärker berücksichtigt werden.

Die Stärken von Job Stories: Vorteile im Fokus 🧘

Job Stories bieten mehrere Vorteile:

• Kontextbezogenheit: Sie fokussieren auf die Umstände, unter denen eine Aufgabe ausgeführt wird, was zu präziseren Anforderungen führt.
• Flexibilität: Sie sind weniger an spezifische Nutzerrollen gebunden und ermöglichen so eine breitere Anwendbarkeit.
• Klarheit: Durch die Konzentration auf das ‚Warum‘ hinter einer Aktion ermöglichen sie ein tieferes Verständnis der Benutzerbedürfnisse.

Herausforderungen und Limitationen: Kritische Betrachtung von Job Stories ⚠️

Trotz ihrer Vorteile haben Job Stories auch Grenzen:

• Weniger Nutzerfokus: Sie könnten weniger Informationen über die Benutzer selbst liefern.
• Komplexität in vielfältigen Szenarien: In komplexen Systemen mit vielen Benutzerrollen können Job Stories weniger effektiv sein.

Abschlussbewertung: Einsatzgebiete und Entscheidungshilfen 🧭

Es gibt kein universelles „Besser“ oder „Schlechter“ zwischen Job Stories und User Stories. Die Wahl hängt stark vom Kontext des Projekts ab:

• Job Stories eignen sich hervorragend für Situationen, in denen der Kontext und die spezifischen Auslöser einer Aktion entscheidend sind.
• User Stories sind effektiver, wenn die Charakteristika und Bedürfnisse der Benutzer im Vordergrund stehen.

Deine Praxis-Tipps 🛠️

– Beziehe den spezifischen Kontext deines Projekts in die Entscheidung ein.
– Nutze eine Kombination beider Ansätze, um die Vorteile zu maximieren.
– Bleibe flexibel in deiner Anforderungsdefinition, um die besten Ergebnisse zu erzielen.

Schlusswort 🎯

Die Wahl zwischen Job Stories und User Stories sollte immer im Kontext der spezifischen Anforderungen deines Projekts getroffen werden. Beide Ansätze bieten einzigartige Perspektiven und können, wenn geschickt eingesetzt, zu einer reicheren und umfassenderen Produktentwicklungsstrategie beitragen.

Weiterführende Quellen 📚

• Christensen, Clayton M., Taddy Hall, Karen Dillon, and David S. Duncan. Competing Against Luck: The Story of Innovation and Customer Choice. New York: Harper Business, 2016.
• Replacing The User Story With The Job Story, Alan Klement

Die Grundlagen: Was sind User Stories? 👨‍💻👩‍💻

User Stories beschreiben eine Funktion einer Applikation, die für den Anwender oder Käufer der Software wertvoll ist. Sie bestehen aus einer schriftlichen Beschreibung, Gesprächen über die Story und aus Akzeptanzkriterien. Diese dreigliedrige Struktur, bekannt als „Card, Conversation, and Confirmation“, wurde von Ron Jeffries geprägt.

Die Herausforderung: Balance im Umfang ⚖️

Der Umfang einer User Story ist immer ein strittiges Thema. Entwickler haben unterschiedliche Bedürfnisse und Vorstellungen, was den idealen Umfang einer Story betrifft. Manche bevorzugen detaillierte Beschreibungen, während andere minimale Ein-Wort-Beschreibungen wie „Login“ oder „Sichtbarkeitsregeln“ bevorzugen. Der ideale Umfangs ist letztlich Team-spezifisch und hängt von der Teamgröße und letztlich von deren Kommunikationstärke ab.

Mündliche Kommunikation: Ein Schlüsselaspekt 💬

Ein wichtiger Aspekt einer User Story ist das Gespräch. Es ist entscheidend, dass die Erwartungen an den Entwickler klar definiert sind, oft in Form von Akzeptanzkriterien. Diese Gespräche sind ein integraler Bestandteil des Prozesses und tragen dazu bei, die Story zu verfeinern und zu klären.

Praktische Umsetzung: Größe und Strukturierung 📐

User Stories sollten idealerweise in einem Umfang gehalten werden, der in einer Implementierungsiteration umsetzbar ist. Zu umfangreiche Stories, bekannt als Epics, können in kleinere, handhabbare Teile aufgeteilt werden.

Schreiben von User Stories: Ein praktischer Ansatz ✍️

Eine gute User Story sollte klar, präzise und fokussiert sein. Sie sollte den Nutzer und den Wert der Funktion in den Vordergrund stellen. Ein bewährtes Format lautet: „Als [Nutzerrolle] möchte ich [Funktion], sodass [Vorteil/Zweck].“ Wesentliche, im Gespräch erarbeitete Elemente sollten in die Details der User Story einfließen.

Checkliste für effektive User Stories ✅

• Verständliche Sprache: Vermeide Fachjargon und bleibe klar und prägnant.
• Nutzerzentriert: Fokussiere auf den Nutzer und den Wert der Funktion.
• Klare Ziele: Definiere, was erreicht werden soll (Funktion) und auch warum (Zweck).
• Flexibilität: Sei offen für Anpassungen und Ergänzungen.
• Feedback einholen: Nutze die Stärke von Teamdiskussionen und Feedback und ergänze Erkenntnisse und Entscheidungen.

Diskussion und Austausch 🗣️

Wie gehst du mit User Stories um? Welche Herausforderungen und Lösungen hast du in der Praxis erlebt? Teile deine Erfahrungen und Gedanken in den Kommentaren. Und bleib dran für weitere Artikel mit agilen Methoden und praktischen Tipps zum Schreiben von guten User Stories!

Zusätzliche Ressourcen 📚

Für weitere Vertiefung empfehle ich das Standardwerk zu User Stories von Mike Cohn. Es bietet wertvolle Tipps und Einblicke in die Praxis der agilen Softwareentwicklung.

Unabhängig

Zunächst sollte beim „schneiden“ der Anforderungen in User Stories darauf geachtet werden, dass es zwischen den Stories keine Abhängigkeiten gibt. Eine Story sollte in der Regel losgelöst von anderen Stories bearbeitet und umgesetzt werden können, andernfalls ergeben sich sehr schnell Probleme bei der Priorisierung. Oft findet sich ein passender Weg, die Stories geschickt aufzuteilen, so dass diese tatsächlich unabhängig voneinander sind. Manchmal lässt es sich nicht vermeiden und es bleiben zwei Möglichkeiten: Die voneinander abhängigen Stories werden zu einer größeren Story zusammengefasst oder – wenn man das nicht möchte – wird der Aufwand der abhängigen Story mit zwei unterschiedlichen Werten geschätzt – einmal unter der Annahme, dass die andere Story davor bearbeitet wurde und einmal danach. Diese Optionen sollten jedoch die Ausnahme sein, nicht die Regel.

Verhandelbar

Die Beschreibung einer Story dient der Erinnerung an die geforderte Funktionalität und enthält damit nicht alle relevanten Details. Diese werden im Gespräch mit dem Kunden oder dem diesen vertretenden Product Owner verhandelt. Sind bereits bei der Erfassung einer Story wichtige Details bekannt, dann sollten diese natürlich auch als Anmerkung notiert werden und dienen dann als Gedächtnisstütze für das Gespräch. In der agilen Softwareentwicklung sind das Backlog Grooming und bei Scrum der erste Teil des Sprint Planning Meetings der richtige Zeitpunkt, um Details auszuhandeln. Die Herausforderung beim Schreiben von User Stories ist, die richtige Menge an Details in die Beschreibung (und die Anmerkungen) aufzunehmen. Werden Details dann in der Besprechung beschlossen, werden diese zu Akzeptanztests.

Hier ein Beispiel für eine Story samt Anmerkungen und Akzeptanztests:

Im Onlineshop kann ein Kunde seinen Warenkorb mit Kreditkarte bezahlen.

Anmerkung: Werden Barclaycards akzeptiert?
Anmerkung zur UI: Der Kartentyp kann anhand der Nummer abgeleitet werden, daher ist keine separate Auswahl notwendig.

Akzeptanztests:

• Teste, dass Bezahlung mit Visa, MasterCard und AmEx möglich ist
• Teste, dass die Bezahlung mit Diners Club abgewiesen wird
• Teste, dass mit korrektem Card Validation Code (CVC) bezahlt werden kann, nicht jedoch mit falschem oder fehlendem CVC
• Teste, dass abgelaufene Karten abgewiesen werden
• Teste, dass sowohl Beträge unter als auch über 100 EUR akzeptiert werden

Werthaltig für Anwender oder Käufer

Häufig spricht man beim Wert einer Story vom Business Value bzw. vom Geschäftswert. Dieser Wert spiegelt nicht immer den Wert einer Story für den Endanwender wieder. Oft ist es so, dass eine große Anzahl an Stories für den Endanwender nicht oder kaum von Bedeutung sind, wohl aber im Interesse des Käufers der Software sind. Eine verschlüsselte Dateiablage oder eine Mandantenfähigkeit sind für den Anwender der Software in der Regel unwichtig, ihn interessiert eher, dass er nach den gewünschten Daten suchen kann oder eine übersichtliche Darstellung von Informationen hat und diese ausdrucken kann. Der Käufer einer Software, zum Beispiel die Firma oder deren IT-Abteilung, könnte dagegen sehr großes Interesse daran haben, dass die Dateien vor Fremdzugriff geschützt sind. Um verschiedene Interessensgruppen zu berücksichtigen, diese Berücksichtigung sichtbar zu machen und auch um bei der Erfassung die verschiedenen Interessen abzudecken kann in den Stories mit „Personas“ gearbeitet werden. Ich werde an dieser Stelle jedoch verzichten, detaillierter auf Personas einzugehen und verweise auf die Artikel von Alan Cooper [2] und Jared M. Spool [3].

Unbedingt zu Vermeiden sind dagegen Stories, die sich nur auf die Technik und die Belange des Entwicklers beschränken und damit nur von ihnen bewertet werden können. Auch wenn die Intention für diese Stories eine gute ist, dann sollten diese dennoch so formuliert werden, dass der Wert für den Kunden ersichtlich wird. Mike Cohen führt in seinem Buch [1] folgendes Beispiel an: 

Alle Verbindungen zur Datenbank erfolgen über einen Connection Pool.

Diese offensichtlich rein technische Story kann aus Kundensicht nicht bewertet werden. Cohen schlägt als Alternative beispielsweise folgende Formulierung vor:

Bis zu 50 User sollten die Anwendung mit einer Datenbanklizenz für fünf Plätze nutzen können.

Mit dieser Formulierung kann der Kunde durchaus etwas anfangen – er ist dadurch in der Lage, die Story zu bewerten und zu priorisieren. Ebenso wie technische Annahmen (z.B. die Nutzung eines Connection Pools) aus den Stories herausgehalten werden sollten, sollte auch versucht werden, auf Angaben zur Benutzeroberfläche (möglichst lange) zu verzichten.

Schätzbar

Auch von Entwicklern wird gefordert, ihre Arbeit zu planen und zurückzumelden, bis wann bzw. mit welchem Aufwand die Umsetzung erfolgen kann. Dies erfolgt dann in einer Schätzung von Dauer oder Aufwand, z.B. in Form von Story Points. Ich selbst bin kein großer Freund von Zeitschätzungen, sondern präferiere die Schätzung des Aufwands in einer abstrakten, relativen Größe. Dem Einwand, dass dann nicht geplant werden kann, was bis wann umgesetzt wird, kann man mit der „Velocity“ des Entwicklungsteams begegnen. Die Velocity eines Teams ist die Summe an Story Points, die von diesem in einer Entwicklungsiteration abgearbeitet werden kann. Somit lässt sich indirekt wieder eine zeitliche Abschätzung ableiten.

Aus Sicht eines Entwicklers kann es jedoch drei Gründe geben, weshalb eine Story nicht schätzbar ist:

1. Dem Entwickler fehlt das Domänenwissen
2. Dem Entwickler fehlt das technische Wissen
3. Die Story ist zu groß/umfangreich

Dem fehlenden Domänenwissen kann mit einem Gespräch mit dem Kunden begegnet werden und wenn eine Story zu groß ist, dann bleibt sie so lange ungeschätzt, bis sie in kleinere Stories aufgeteilt wurde. Dem fehlenden technischen Wissen dagegen lässt sich nur begegnen, indem dieses Wissen zumindest soweit aufgebaut wird, dass man eine Idee davon erhält, mit welchem Aufwand sich die Story umsetzen lässt. Von einem oder mehreren Entwicklern wird dann in einem kleinen, zeitlich beschränkten (timeboxed) Experiment das notwendige Wissen aufgebaut – im Extreme Programming wird ein solches Experiment „Spike“ genannt. Somit werden aus der nicht abschätzbaren Story zwei, da noch die Story für den Spike hinzukommt. Da der Spike durch eine maximale Zeitdauer limitiert ist, lässt sich die Spike-Story auch schätzen und somit einplanen.

Klein

Die Größe einer Story ist entscheidend, ob sie in eine Entwicklungsiteration eingeplant werden kann. Ist die Story zu groß, kann sie entweder nicht abgeschätzt werden oder sie passt womöglich nicht (sinnvoll) in eine Iteration. Eine große Story (bzw. ein Epic) ist entweder eine zusammengesetzte Story oder eine komplexe Story.

Eine zusammengesetzte Story besteht aus mehreren kürzeren Einzelstories und kann somit weiter aufgeteilt werden. Es kann durchaus passieren, dass man erst im Verlauf des Entwicklungsprojekts erkennt, dass es sich bei einer Story mit vermeintlich angemessenen Umfang, doch um eine große zusammengesetzte Story handelt. Bei der Aufteilung muss man jedoch wieder aufpassen, dass die Granularität angemessen bleibt und die Stories nicht zu klein werden. Sehr kleine Stories können dagegen in einer größeren zusammengefasst werden. Eine angemessene Größe ist erreicht, wenn die Story innerhalb von einem halben Tag bis zwei Wochen von ein bis zwei Entwicklern umgesetzt werden kann.

Komplexe Stories dagegen sind häufig anzutreffen, wenn es um die Entwicklung von neuen Algorithmen oder die Erweiterung bestehender geht. Hier hat es sich bewährt, diese Story mit einer Recherche in Form eines Spikes zu ergänzen. Mit Hilfe der Recherchestory lässt sich dann die Durchführbarkeit ermitteln, neue Erkenntnisse über eine mögliche Implementierung gewinnen und somit erfolgt eine Vorarbeit zur eigentlichen Story, die nach der Recherche (besser) abgeschätzt werden kann. Es liegt auf der Hand, dass die Recherche nicht in der selben Iteration durchgeführt werden soll, in der auch die Umsetzung der Story eingeplant ist – idealerweise liegt der Spike in einer vorherigen Story.

Testbar

Die Akzeptanztests einer User Story definieren die Erwartungen an die Umsetzung. Erst anhand der Tests kann somit nachvollzogen werden, ob eine Story vollständig und erfolgreich implementiert wurde. Diese Tests sollten auch möglichst automatisiert ausgeführt werden – ein Automatisierungsgrad von 99% ist erstrebenswert. Lediglich sehr wenige Tests lassen sich nicht oder nicht mit verhältnismäßigem Aufwand automatisieren. Bei Anforderungen an die intuitive Bedienbarkeit, zum Beispiel, sind automatisierte Tests nicht möglich – mittels repräsentativer User-Tests in Testlaboren wäre solch eine Story jedoch durchaus testbar. Solche Tests sind dann aber oft zeitintensiv und kostspielig, für manche Projekte und Produkte jedoch notwendig.

In der Praxis entstehen nicht testbare Stories häufig bei den nicht-funktionalen Anforderungen, bei denen Erwartungen nur vage formuliert werden. Ein Beispiel dafür wäre „Das System hat geringe Antwortzeiten“. So formuliert kann diese Story nie erfüllt werden. Deutlich besser und sogar automatisiert testbar wäre dagegen folgende Formulierung: „Die visuelle Rückmeldung für alle Interaktionen eines Users mit dem System sind in 98% der Fälle unter einer Sekunde.“

Akronym

Diese sechs Eigenschaften ins englische Übersetzt ergeben ein Akronym:

• Independent
• Negotiable
• Valueable
• Estimable
• Small
• Testable

… INVEST.

Literatur:

[1] Mike Cohen, „User Stories Applied: For Agile Software Development“, Addison-Wesley Professional; 1 edition (11. März 2004)

[2] Alan Cooper, „The Origin Of Personas“, cooper.com Journal, http://www.cooper.com/journal/2008/05/the_origin_of_personas (15. Mai 2008)

[3] Jared M. Spool,„Three Important Benefits of Personas“, uie.com Articles, https://articles.uie.com/benefits_of_personas/ (8. Mai 2007)

Grafik:

• by kschneider2991, CC0, pixabay.com

Ich werde im Folgenden beschreiben, was User Stories sind, wie man mit ihnen plant und warum man sie einsetzen sollte. Ich werde dabei jedoch nicht in die Tiefe gehen, denn damit ließen sich durchaus ein paar Kapitel eines Buch füllen. Statt dessen verweise ich bereits hier auf das Standardwerk zu User Stories von Mike Cohen (siehe Quellen, [1]). Mike Cohen gibt neben einer Abgrenzung zu alternativen „klassischen“ Methoden der Anforderungserfassung in seinem Buch vor allem wertvolle Tipps für den Praxiseinsatz. Für einen ersten Eindruck soll dieser Artikel hier genügen.

Was ist eine User Story?

Grundsätzlich kann man sagen, dass eine User Story eine Funktion einer Applikation beschreibt, die „wertvoll“ für einen Anwender oder für den Käufer der Software ist. Sie besteht aus einer schriftlichen Beschreibung, aus Gesprächen über die Story und aus Akzeptanztests. Die Beschreibung dient zur Planung und zur Erinnerung; sie ist letztlich eine Zusammenfassung der Anforderung in einem Satz und wird entweder handschriftlich auf Karteikarten verfasst oder in ein elektronisches System wie beispielsweise JIRA eingepflegt. In den Gesprächen werden dann die Einzelheiten der benötigten Funktion herausgearbeitet und schließlich in den Akzeptanztests dokumentiert. Letztere legen auch fest, wann eine Story vollständig implementiert ist. Nicht zu verwechseln ist dies mit einer „Definition Of Done“ (DoD, [2]), in der festgehalten wird, wann eine Story als abgeschlossen gilt. Diese drei Aspekte einer User Story hat Ron Jeffries als „Card, Conversation, and Confirmation“ bezeichnet [3].

Der Umfang einer Story ist immer ein strittiges Thema. Mir sind schon Entwickler begegnet, die sich beschwert haben, dass nicht alle Details in der Story beschrieben sind. Dann gab es wieder Entwickler, die eine „Story“ bearbeitet haben, die die Bezeichnung als solche nicht verdient hat: Die Beschreibung bestand aus einem einzigen Wort und statt Akzeptanztests der Vermerk „wie besprochen“ festgehalten wurde. Nun gab es auch Stories, an denen wurde entwickelt und entwickelt und entwickelt … und irgendwann endlich nach einigen Wochen oder Monaten wurde sie als abgeschlossen erklärt. Wie ihr es euch sicher denken könnt, waren das alles Symptome, die auf – sagen wir einmal – nicht optimale User Stories zurückzuführen sind, sei es in ihrer Vollständigkeit oder in ihrem Umfang.

Beschreibung

Fangen wir mit dem zweiten Beispiel an, der Ein-Wort-Story: Sie hätte zum Beispiel lauten können „Sichtbarkeitsregeln“, „Login“ oder „Dokumentenähnlichkeit“. Ja, die Beschreibung einer Story soll nur eine Erinnerung sein an die Funktionalität, die implementiert werden soll. Allerdings ist in diesen Ein-Wort-Beispielen der Informationsgehalt doch sehr beschränkt. Wichtig an einer User Story ist, dass bereits in der Beschreibung grob erkennbar wird, was die Funktion ist und dass sie auch einen Wert für den User, also den Anwender und/oder den Käufer der Software hat. Deutlich bessere Formulierungen wäre daher zum Beispiel: „Ein User kann nur Inhalte sehen, die für ihn aufgrund von Regeln sichtbar sind“ oder „Das System kann Sichtbarkeitsregeln verarbeiten um dem User nur die Inhalte anzuzeigen, für die er leseberechtigt ist“. In beiden Beispielen lässt sich jetzt bereits in der Beschreibung ablesen, dass es um die Verarbeitung von Regeln geht, die die Sichtbarkeit von Inhalten für den Anwender steuern und diese Steuerung der Sichtbarkeit scheint für den Anwender oder vermutlich eher den Käufer von Wert zu sein. An den beiden Varianten der Formulierung kann man auch schon sehen, das es eine Vielzahl an Möglichkeiten gibt, eine Funktion in einem Satz zusammenzufassen und längst sind damit noch lange nicht die Details geklärt. Manche Varianten sind besser, andere schlechter; jedoch sollte man sich nicht zu lange an der Beschreibung aufhalten und wieder und wieder an der Formulierung feilen – zu Beginn ein gern gemachter Fehler.  Solange eine Funktion beschrieben ist und der Wert für den User erkennbar wird, ist das meiner Meinung nach völlig in Ordnung – schließlich gibt es ja noch zwei weitere Aspekte einer User Story.

Gespräch

Kommen wir nun zum ersten Beispiel, dem Entwickler, dem die Story nicht ausführlich genug beschrieben ist. Hier vertrete ich die Meinung: „Mut zur Lücke“, denn alle Einzelheiten sind beim Erfassen einer Story oft nicht bekannt. Und statt alle Einzelheiten aufzuschreiben macht es viel mehr Sinn, wenn das Entwicklungsteam diese mit dem Kunden oder dem den Kunden vertretenden Product Owner bespricht. Dass dann aus diesem Gespräch wiederum Notizen entstehen, die der User Story hinzugefügt werden (entweder rückseitig auf Karteikarten oder in einem Notizfeld in einem elektronischen System), dagegen spricht überhaupt nichts – im Gegenteil: da sie der Erinnerung an die besprochenen Einzelheiten dienen, sind sie erstrebenswert – dokumentieren allerdings keine vertragliche Verpflichtung. Eine solche Vereinbarung wird mit dem dritten Aspekt der User Story abgedeckt.

Akzeptanztests

Wir sind nun wieder bei der Ein-Wort-Story, genauer gesagt bei deren Vermerk „wie besprochen“. Das Gespräch ist mitunter ein wichtiger, wenn nicht sogar dar wichtigste Aspekt einer User Story. Und doch gibt es berechtigten Zweifel an dem Mehrwert der angesprochenen Notiz. Viel schlimmer ist jedoch, dass nirgends definiert wurde, wann die umzusetzende Funktion als vollständig implementiert akzeptiert wird: die Erwartung an den Entwickler ist somit unklar und die Gefahr besteht, dass wir dadurch eine Story erhalten, die entweder unvollständig implementiert wird oder bei der vom Entwickler hier noch ein Schleifchen und dort noch ein Schleifchen und da auch noch ein bisschen Bling-Bling dazu implementiert wird. Um dem zu begegnen ist die Beschreibung der Erwartung an den Entwickler unbedingt notwendig. Oft wird an dieser Stelle auch von Akzeptanzkriterien gesprochen, die es zu definieren gilt. Da diese Kriterien schlussendlich auch überprüft werden müssen – in der Regel durch automatisierte Tests – spreche ich lieber von Akzeptanztests und auch in der Praxis hat es sich bewährt, die Erwartungen in Form von Aufforderung zu beschreiben, was in dieser Story getestet werden soll. Möglichst vor Beginn der Implementierung sollten diese Erwartungen beschrieben werden: sei es bereits beim Story schreiben, beim Refinement (also der Verfeinerung/Überarbeitung einer Story) oder im Gespräch mit dem Entwicklungsteam. Grundsätzlich können Akzeptanztests jederzeit ergänzt werden – doch sobald die Story von Entwicklern in Bearbeitung ist, dann ist es nur unter Rücksprache legitim und sollte nur erfolgen, solange sich dabei der Umfang einer Story nicht oder nur marginal erhöht. Ist dies nicht der Fall oder wird das durch die Entwickler (begründet) nicht akzeptiert, dann hat es sich bewährt, die neuen Akzeptanzkriterien in einer neuen, ergänzenden Story festzuhalten.

Umfang

Nachdem wir uns mit den drei Aspekten von User Stories beschäftigt haben, möchte ich noch den Umfang einer User Story betrachten. Das obige Beispiel der Story, deren Implementierung sich über Wochen oder Monate hinzieht könnte als Ursache fehlende Akzeptanzkriterien haben. Viel Wahrscheinlicher jedoch ist, dass die Story viel zu umfangreich war, um sie in einer Implementierungsiteration umzusetzen. Umfangreiche und vor allem zu umfangreiche Stories werden häufig als Epics bezeichnet.

Zu Beginn der Erfassung von User Stories sind die Anforderungen an das Gesamtsystem noch unscharf. Epics spiegeln genau diese Unschärfe und sind daher sinnvoll als Platzhalter einzusetzen. Damit können dann größere Teile des Systems solange ausgeblendet werden, bis man sich mit deren Einzelheiten beschäftigen möchte und bis das Verständnis über die Anforderung an diesen Teil klarer geworden sind.

Mit der Zeit können die Epics und andere umfangreich Stories in kleinere Stories aufgeteilt werden. Komplexe Anforderungen werden somit in beherrschbare Teile aufgegliedert. Jedoch sollte man auch darauf achten, Stories nicht zu klein aufzuteilen. Idealerweise sind User Stories für den Entwickler abschätz- und damit auch planbar, wenn deren Umfang in einem halben Tag bis zwei Wochen für Implementierung und Tests von ein bis zwei Entwicklern zu bewerkstelligen ist.

Warum User Stories?

Es gibt einige Gründe dafür, die Anforderungen in Form von User Stories zu erfassen. Wesentlich ist unter anderem der Fokus auf der mündlichen statt schriftlichen Kommunikation. Im Dialog werden in kürzerer Zeit wesentlich mehr Informationen weitergetragen als es mit Dokumenten möglich wäre. Zudem wird auch weniger unnütze Dokumentation erstellt – unnütz ist sie nämlich dann, wenn sie eh keiner liest. Ein weiterer Grund für die Verwendung von User Stories ist, dass sie sowohl vom Kunden, vom Produkt Owner und auch den Entwicklern verstanden werden. Als nächstes wäre da noch aufzuführen, dass sie den richtigen Umfang für eine Planung haben und sie eignen sich für die iterative Entwicklung. Last but not least: User Stories ermutigen zum Auslassen von Details – zumindest solange, bis klar ist, was der Kunde tatsächlich möchte und bis das bestmögliche Verständnis darüber erreicht wurde, was gefordert wird.

In der Softwareentwicklung nach Scrum sind User Stories die meiner Meinung nach geeignetste Form Backlog-Items mit einem Wert für den Kunden oder den Product Owner zu formulieren. In einem meiner nächsten Artikel werde ich noch eine alternative Form von Stories vorstellen, doch zuvor wird es hier noch einen Artikel geben, der sich mit den Eigenschaften einer guten Story beschäftigt und euch auch Tipps gibt, wie man eine gute Story schreibt.

Literatur:

[1] Mike Cohen, „User Stories Applied: For Agile Software Development“, Addison-Wesley Professional; 1 edition (11. März 2004)

[2] Ian Mitchell, „Definitions of Done in Practice“, DZone Agile, https://dzone.com/articles/definitions-done-practice (13. Mai 2015)

[3] Ron Jeffries, „Essential XP: Card, Conversation, and Confirmation“, XP Magazin (30. August 2001)

Grafik:

• „Fairy Tales“ by Comfreak [Creative Commons CC0], via Pixabay

Normal mode of operation is partial failure.

Also verfolgen wir doch bei der Erstellung von Software doch diesen Ansatz und gehen davon aus, dass der normale Betriebsmodus ein teilweiser Ausfall des Gesamtsystems bedeutet. Doch wie kommen wir zu dieser Annahme?

Verfügbarkeit

Bei dem Betrieb von Softwaresystemen dreht sich doch alles um die Verfügbarkeit. Man spricht von Availability bzw. oft sogar von High Availability wenn Anforderungen an Softwaresysteme gestellt werden und bemisst sie in einer prozentualen Wertangabe. Gefordert werden dann oft Werte von 99% oder sogar mehr, denn schon eine Nicht-Verfügbarkeit von einem Prozent bedeutet bei Betrachtung eines Gesamtsystems einen totalen Ausfall von 3,65 Tagen. Und wie du dir sicher denken kannst, bedeutet jeder Ausfall letztendlich Kosten; für die einen mehr, für die anderen weniger.

Wie sieht es nun aber aus, wenn mehrere Einzelsysteme am Gesamtsystem beteiligt sind? Angenommen wir haben ein Gesamtsystem, dass sich aus 5 einzelnen Sub-Systemen zusammensetzt. Jedes der Sub-Systeme garantiert eine Verfügbarkeit von 99,9%. Das Gesamtsystem letztendlich kann diese Verfügbarkeit nicht mehr sicherstellen, sondern erreicht nur noch einen Wert von 99,9%^5 = 99,5%. Damit ergibt sich eine voraussichtliche Ausfallzeit von 1 Tag 19 Stunden und 48 Minuten für das Gesamtsystem.

Wie berechnet sich Verfügbarkeit? Hierzu betrachten wir zunächst die Gesamtzeit, die sich einerseits zusammensetzt aus der mittleren Zeit die vergeht, bis ein Fehler auftritt; man spricht dann von Mean-Time-To-Failure (MTTF) oder manchmal auch von Mean-Time-Between-Failures (MTBF). Andererseits ergibt sich die Gesamtzeit aus dem Komplementär von MTTF, nämlich aus der Zeit die man benötigt, um den ordentlichen Betriebszustand wiederherzustellen. Diese Größe nennt sich dann Mean-Time-To-Recovery (MTTR) oder auch Mean-Time-To-Repair. Die Verfügbarkeit ist letztendlich der Quotient aus der Mean-Time-To-Failure und der Gesamtzeit:

Availability := MTTF / (MTTF + MTTR)

Der klassische Ansatz

Angenommen ein System fällt einmal im Monat aus (MTTF ~26,42h) und man benötigt vom Fehlereintritt bis zur Wiederhestellung des Betriebszustands im Schnitt 4 Stunden, dann hätte das System eine Verfügbarkeit von knapp 87%. Um eine besonders hohe Verfügbarkeit zu erreichen hat man in der Vergangenheit stets versucht, die Zeit bis zum Fehlereintritt (MTTF) zu maximieren. Folglich hätte eine verbesserte Variante des Systems nur noch mit einem Ausfall in 3 Monaten zu kämpfen (MTTF=87,25h, MTTR=4h) und die Verfügbarkeit läge dann bereits bei knapp 96%. Um eine Verfügbarkeit von 99% zu erreichen, wäre bei diesem System nicht einmal ein Ausfall pro Jahr vertretbar. Über Redundanz und andere Ansätze lässt sich die MTTF für das Gesamtsystem und damit die Verfügbarkeit noch weiter erhöhen.

Weiter oben bereits erwähnt habe ich jedoch die Problematik, die entsteht, wenn mehr als nur eine Systemkomponente existiert, also wenn sich das Gesamtsystem zusammensetzt aus mehreren Einzelsystemen, bei denen jedes eine andere Teilaufgabe erledigt. Dies Komposition eines Gesamtsystems aus einzelnen, verteilten Sub-Systemen und die Abhängigkeiten der Systeme untereinander ist jedoch genau das, was uns heute immer mehr begegnet. Gerade bei einer Ausrichtung hin zu Microservice Architekturen wird man bezüglich der Verfügbarkeit mit klassischen Ansätzen schnell an seine Grenzen stoßen.

Natürlich erhöht sich in der Softwareentwicklung die MTTF in der Regel mit jedem Bugfix, jedoch erhöht sich im Gegenzug auch immer wieder die Wahrscheinlichkeit für einen Fehler mit jedem zusätzlichen Feature. Es ist auch (nahezu?) unmöglich bzw. extrem kostspielig geworden in den heutigen komplexen Systemen alle möglichen Fehlerquellen zu identifizieren und sämtliche Fehler zu vermeiden. Hinzu kommt, dass während heutige Systemlandschaften immer größer werden, immer weiter verteilt sind und immer komplexere Abhängigkeitsstrukturen haben, auch die Verfügbarkeitsanforderungen immer weiter steigen.

Der Resilience-Ansatz

Erinnern wir uns an meinen letzten Artikel „Shit happens …“ und dem damit verbundenen Aufruf umzudenken und Fehler in Systemen zu akzeptieren. Wenn wir also davon ausgehen, dass es immer irgendwo einen Fehler geben wird und wir den Eintritt auch nicht verhinden können, dann sind wir auch nicht in der Lage, die Verfügbarkeit zu erhöhen indem wir die MTTF maximieren. Im Gegenzug müssen wir die MTTF als gegeben hinnehmen und demnach die MTTR minimieren, um eine hohe Verfügbarkeit zu erreichen. Beim Resilient Software Design geht es also darum, ein System zu erschaffen, das mit allen möglichen erwarteten und vor allem auch unerwarteten Fehlern umgehen kann. Im besten Fall gelingt dies so, dass der Endanwender letztendlich nichts von den Fehlern mitbekommt.

Ausblick: In den kommenden Artikeln möchte ich mich mit den Grundprinzipien von Resilient Software Design beschäftigen, Anti-Patterns beleuchten und einen Überblick über Stability-Patterns geben.

Literatur:

[1] U. Friedrichsen, ‚Damit es auch morgen noch Läuft – Eine kurze Einführung in Resilient Software Design‘, Javamagazin, no. 5.2015, pp. 33-39, 2015.

[2] M. Nygard, Release it!. Raleigh, N.C.: Pragmatic Bookshelf, 2007.

[3] Z. Taylor and S. Ranganathan, Designing high availability systems. Hoboken, New Jersey: John Wiley & Sons Inc., 2014.

Grafik:

• „img_0001“ by Jannis, https://www.flickr.com/photos/52336371@N07/12296754993, Bestimmte Rechte vorbehalten

re·sil·ience (rĭ-zĭl′yəns), noun

1. The ability to recover quickly from illness, change, or misfortune; buoyancy.
2. The property of a material that enables it to resume its original shape or position after being bent, stretched, or compressed; elasticity.

http://www.thefreedictionary.com/resilience [1]

Der erste Schritt in Richtung Resilient Software Design ist, zu akzeptieren, dass jede Software „fehlerhaft“ ist.  Erst wenn man akzeptiert, dass Fehler auftreten werden, ist man in der Lage darüber nachzudenken, wie man dieser Tatsache begegnen kann, um stabile, robuste, verlässliche Softwaresysteme zu erschaffen. Frei übersetzt nach Micheal T. Nygard [4] benötigt Unternehmenssoftware die folgende Eigenschaft: Software muss zynisch sein. Zynische Software erwartet immer das Schlimmste und ist nicht überrascht, wenn der schlimmste Fall auch eintritt. Zynische Software vertraut nicht einmal sich selbst; sie erstellt interne Barrieren um sich selbst vor Fehlern zu schützen. Zynische Software lehnt es ab mit anderen Systemen eine zu intime Beziehung einzugehen, da sie verletzt werden könnte.

Wenn ich hier von Fehlern spreche, dann sind es nicht nur Bugs im Code die zu Systemabstürzen führen, sondern auch Fehler, die man bei der Erstellung der Softwarearchitektur und dem Design der Systemkommunikation gemacht hat, indem man eine Entscheidung getroffen hat, die zwar den funktionalen Anforderungen genügt, jedoch zu Systemausfällen führen kann und damit auch zwangsläufig zu Systemausfällen führt. Daher sollte man stets sowohl in der Softwarearchitektur und dem Design als auch bei der Implementierung immer einen Blick in Richtung Systemstabilität werfen.

Uwe Friedrichsen zitiert die folgenden Fehlertypen, die man bei Resilient Software Design berücksichtigen sollte und verweist darauf, dass man sich nicht nur auf die „einfachen“ Absturzfehler beschränken darf [2, 3]:

1. Crash Failure (Absturzfehler)
   ein System antwortet permanent nicht mehr, hat bis zum Zeitpunkt des Ausfalls aber korrekt gearbeitet
2. Omission Failure (Auslassungsfehler)
   ein System reagiert auf (einzelne) Anfragen nicht, sei es, dass es die Anfragen nicht erhält oder keine Antwort sendet
3. Timing Failure (Antwortzeitfehler)
   die Antwortzeit eines Systems liegt außerhalb eines festgelegten Zeitintervalls
4. Response Failure (Antwortfehler)
   die Antwort, die ein System gibt, ist falsch
5. Byzantine Failure (Byzantinischer/zufälliger Fehler)
   ein System gibt zu zufälligen Zeiten zufällige Antworten („es läuft Amok“)

Wie gesagt, shit happens … und das ist auch der Grund, weshalb wir uns mit Resilient Software Design beschäftigen sollten. In einem meiner nächsten Artikel möchte ich das Thema vertiefen und mich dabei auf den Punkt „Verfügbarkeit“ (Availability) konzentrieren.

Literatur:

[1] American Heritage® Dictionary of the English Language, Fifth Edition. Copyright © 2011 by Houghton Mifflin Harcourt Publishing Company. Published by Houghton Mifflin Harcourt Publishing Company. All rights reserved.

[2] U. Friedrichsen, ‚Unkaputtbar, Eine kurze Einführung in Resilient Software Design‘, Business Technology, no. 414, 2014 [Online]. Available: https://www.codecentric.de/files/2015/02/Sonderdruck_Codecentric_BT4_14_27964_mon.pdf. [Accessed: 04- Aug- 2015]

[3] U. Friedrichsen, ‚Eine kurze Einführung in Resilient Software Design‘, jaxenter.de, 2015. [Online]. Available: https://jaxenter.de/unkaputtbar-einfuehrung-resilient-software-design-15119. [Accessed: 04- Aug- 2015]

[4] M. Nygard, Release it!. Raleigh, N.C.: Pragmatic Bookshelf, 2007.

Grafiken:

• „Tennis ball“ by Lemsipmatt, https://www.flickr.com/photos/lemsipmatt/2470490055, Bestimmte Rechte vorbehalten