Freitag, 24. Januar 2014

Die Geschichten der Benutzer - User Stories erstellen.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


"User Stories setzen sich aus drei Bestandteilen zusammen:
  • einer schriftlichen Beschreibung der Story, die zur Planung und als Erinnerung verwendet wird;
  • Gesprächen über die Story, um die Details der Story herauszuarbeiten;
  • Tests, die Details vermitteln und dokumentieren und mit denen festgelegt wird, wann eine Story vollständig umgesetzt ist.
" [S.26, COHN10]



Demnach ist eine User Story ein Planungsinstrument für eine beabsichtigte Funktionalität, eine Erinnerung die Anforderungen dazu detailliert auszuarbeiten und die Aufforderung die Akzeptanzkriterien zu dieser Funktionalität zu beschreiben. Nachdem die Aufgabe der Systemkontextanalyse für ein Themenobjekt abgeschlossen ist, liegen uns eine Reihe von Kontextobjekten vor. Mit Hilfe dieses Verständnisses des Systemkontextes kann für ein Themenobjekt die Aufgabe der Bildung von User Stories angesetzt werden. Zu diesem Zeitpunkt sollte eine gewisse Planungssicherheit ermöglicht werden, und außerdem wird damit die zu liefernde Funktionalität konkretisiert. Das Ergebnis dieser Aufgabe sind UserStory-Objekte.

"Eine gute User Story muss sechs Eigenschaften haben:
  • independent (unabhängig)
  • negotiable (verhandelbar)
  • valuable (werthaltig) für User oder Kunden
  • estimatable (schätzbar)
  • small (klein)
  • testable (testbar)
" [S.39, COHN10]

Diese sogenannten INVEST-Eigenschaften durchzuhalten ist nicht gerade einfach. Besonders die Unabhängigkeit bereitet große Schwierigkeiten. Wenn zwei User Stories voneinander abhängig sind, dann gilt es diese Abhängigkeit zu beachten. Das erschwert die Planung. Empfohlen wird bei abhängigen Stories die Zusammenlegung zu unabhängigen größeren Stories oder eine andere Aufteilung in Stories. Hier spielt die gemeinsame Suche im Team eine große Rolle. Zumindest sollten diese Abhängigkeiten minimiert werden.

Mit dem folgenden Template kann eine User Story formuliert werden:

"Als [Rolle] möchte ich [Wunsch], um [Nutzen]"

Das Template habe ich der deutschen Wikipedia entnommen. Im Folgenden möchte ich die drei zu ersetzenden Bestandteile erläutern. Ein [Rolle] entspricht einem User. Diese sollten in unserer Anforderungsdokumentation bereits als Kontextobjekt vorliegen. Dort wurde eine Menge von Stakeholdern analysiert. Stakeholder können auch zu Gruppen zusammengefasst werden, sogenannte Nutzerrollen wie Administratoren und Sachbearbeiter einer Software. Für diese Nutzerrollen können auch Personas und extreme Charaktere gebildet werden. Auch diese stellen wiederum Kontextobjekte dar.

"User Stories ergeben sich beim Gespräch mit Usern, bei der Beobachtung von Usern, durch Fragebögen und in Story-Workshops. Die besten Ergebnisse werden in Kombination dieser Methoden erreicht und nicht durch blindes Vertrauen in nur eine Methode." [S.73, COHN10] Mit Hilfe dieser Methoden wird also der [Wunsch] ermittelt. Viele Wünsche können aus den zuvor erfassten Ideen abgeleitet werden. Sie bilden jedoch nur eine Teilmenge der zu ermittelnden Wünsche. Eine wichtige Überlegung ist der [Nutzen] wert. In ihm dokumentiert sich der Geschäftswert. In einigen Templates kann dieser Teil auch weggelassen werden. Ich plädiere dafür, ihn in jedem Fall zu erfassen. Man sollte sich schon klar sein, welchen Geschäftswert eine Funktionalität besitzt. Man vermeidet damit die Umsetzung von Unnützem.

Zu jeder User Story können Hinweise und Randbedingungen aufgenommen werden. Sie bieten für die spätere Ausarbeitung der Anforderungen wichtige Ausgangspunkte. Die Randbedingungen werden im nächsten Post, in dem es um die Formulierung von Zielen geht, noch eine wichtige Rolle spielen. Von absoluter Wichtigkeit sind jedoch die Akzeptanztests. "Akzeptanztests dienen zur Darstellung von Details, die sich aus den Gesprächen zwischen Kunden und Entwickler ergeben." [S92, COHN10] "Akzeptanztests liefern die grundlegenden Kriterien, die feststellen sollen, ob eine Story vollständig implementiert ist." [S.93, COHN10] Im Artikel Der Kunde ist für die systematische Erarbeitung der Kundenanforderungen zuständig. plädierte ich dafür, dass der Kunde die Funktionalität bestimmen sollte, die er haben will. [COHN10] fordert für die Akzeptanztests, dass sie eher vom Kunden, als vom Entwickler geschrieben werden sollten. Es ist nur logisch, dass derjenige, der etwas haben will, bestimmt, unter welchen Umständen er es abnehmen wird. Das ist auch eine Sache der Fairness.



Die fertiggestellten User-Story-Objekte können nun als Planungsinstrumente dienen. Zuerst werden die User Stories mit Hilfe von Story Points geschätzt. "Schätzwerte und Stories müssen vom Team gemeinsam entschieden und getragen werden." [S.108, COHN10] "Setzen Sie zunächst den Kunden und die Entwickler, die die Schätzwerte erstellen sollen, an einen Tisch." [S108, COHN10] Der Kundenvertreter dient zur Beantwortung von Rückfragen bei Unklarheiten. Das Team einigt sich auf Story Points pro User Story. Es gibt verschiedene Methoden, diese Schätzungen durchzuführen. Welche Arbeitszeit ein Story Point wirklich beinhaltet, zeigt die Velocity des Teams erst nach einigen Sprints.

Ein Themenobjekt besitzt nun eine Menge von geschätzten User Stories. Kennen Sie die Velocity ihres Teams, können Sie aus der Roadmap eine Releaseplanung machen. Dazu ist es notwendig, die User Stories zu priorisieren. Im Artikel Themenobjekte ordnen Ideen in eine Roadmap wurde zum Priorisieren ein Gremium gebildet. Dieses Gremium, in dem jetzt unbedingt ein Kundenvertreter sitzen sollte, kann wieder anhand von Punkten die User Stories priorisieren. Man kann natürlich eine Priorisierungsmethode seiner Wahl verwenden. Allerdings sollte am Ende ein wirklicher Unterschied in den Prioritäten feststellbar sein. Die User Stories werden dann in der Reihenfolge ihrer Prioritäten abgearbeitet. Innerhalb gleicher Priorität werden die User Stories zuerst abgearbeitet, die ein hohes inhärentes Risiko tragen.



Nachdem wir eine relative Planungssicherheit hergestellt haben, können wir in die Tiefen der einzelnen Aufgaben gehen. Im nächsten Post werden wir verschiedene Analysen durchführen, die letztendlich ein Zielmodell ergeben.

  • [COHN10] Mike Cohn: "User Stories", 1. Auflage, mitp, Heidelberg, 2010


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen