Freitag, 14. Februar 2014

Praktisches Beispiel zu User Stories.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Der erste Post zu den praktischen Beispielen erläutert, wie Stakeholder ihre Ideen notieren, die Ideen sich zu Themen gruppieren und die Themen eine natürliche Roadmap erzeugen. Im zweiten Post zu den praktischen Beispielen wurde auf die Systemkontextanalyse eingegangen, die notwendig ist, für ein tiefes Verständnis des Umfeldes des künftigen Softwaresystems und Voraussetzung zum Verstehen des zu lösenden Problems. Das Verstehen der Domäne öffnet uns auch den Blick für die Schwierigkeiten der IST-Prozesse. Die Optimierung der Prozesse und das Herausfiltern der zu automatisierenden Prozessschritte und der künftigen Features einer zu schaffenden Software ist ein Arbeitsschritt, der im ganzen Team erfolgen sollte. In einem Post zu Explorationen zeige ich auf, wie wichtig die Explorationen in dieser Phase sind. Die gemeinsame Anstrengung führt zu optimalen Systemen, die für den Kunden von hohen Nutzen sind. Die ersten Entdeckerarbeiten finden bei der Optimierung der Prozesse statt. Weitere Entdeckungen können beim Bedenken der zukünftigen Features der Software gemacht werden, die dann für die Umsetzung in User Stories notiert werden, genau wie die umzusetzenden optimierten Prozesse.

Im Post Die Geschichten der Benutzer – User Stories erstellen können Sie nachlesen, wie sich das Anfertigen von User Stories in das Gesamtsystem meines Requirements Engineering einordnet. Der Eindruck der sequentielle Folge der Prozessschritte wird dabei nur durch die Beschreibung erzeugt. Stellen Sie sich die Folge der Prozessschritte als Kreislauf notwendig langer Schritte vor, die in Länge und Arbeitsweise das Ergebnis eines optimalen Denk- und Entwicklungsprozess sind, im Gegensatz zu genau festgelegten Abfolgen. In der Systemkontextanalyse hatten wir uns dem Thema Personas gewidmet. Stellen wir uns vor, dazu existiert zu diesem Zeitpunkt ein ausreichend großes Repertoire an Ideen, die im Thema Personas eingeordnet sind. Nach der Systemkontextanalyse existieren außerdem eine Anzahl an Kontextobjekten.



Ideen und Kontextobjekte bilden jetzt die Grundlage für die Bildung von User Stories. Dazu benutzen wir das Template Als [Rolle] möchte ich [Wunsch], um [Nutzen]. Während der Aufnahme der Ideen konnte ein Stakeholder seine Prioritätspunkte dadurch erhöhen, dass er z.B. einen Geschäftswert angegeben hat. Diese Prioritätserhöhung dient der Vorarbeit zur Bildung von User Stories. Zum Zeitpunkt der Bildung einer User Story können diese Informationen nun verwendet werden. Nehmen wir die Idee Nutzerrollengruppen können Personas zugeordnet werden. Der Stakeholder, der diese Ideen niedergeschrieben hat, wollte die Priorität dieser Idee erhöhen und setzte deshalb den folgenden Geschäftswert bzw. Nutzen hinzu: um virtuelle Personen für die Anforderungsermittlung zur Verfügung zu haben. Für die Formulierung fehlt nun nur noch die Rolle, die sich dieses Feature wünscht. In diesem Fall ist es der Entwickler A. Ist weiterhin durch die Gruppe bedacht, ob die INVEST-Eigenschaften einer User Story erfüllt sind, könnte diese User Story vermerkt werden. In diesem Fall wäre das nicht so. Zuerst müsste die Möglichkeit bestehen Nutzergruppen über Personen zu bilden, damit den Nutzergruppen Personas zugeordnet werden können. Eine Persona bildet in diesem Zusammenhang eine virtuelle Person, die die Haupteigenschaften diese Gruppe abbildet und so die Vorstellungskraft für diese Nutzergruppe stärkt. Deshalb ordnen wir alle Ideen und Kontextobjekte zu dieser User Story zu, die innerhalb dieser Story umgesetzt werden sollen. Am Ende heißt unsere User Story:

Als Entwickler A möchte ich , dass man Nutzerrollengruppen bilden kann und diesen Personas zugeordnet werden können, um virtuelle Personen für die Anforderungsermittlung zur Verfügung zu haben.



Die gebildeten User Stories dienen der Planung und als Erinnerung, Details und Akzeptanztests für diese Stories anzufertigen. Durch die Verbindung mit Kontextobjekten und Ideen sind sie bereits mit einem umfangreichen Wissen ausgestattet, dass es erlaubt, in einer Teamsitzung gemeinsam mit einem Kundenvertreter die User Stories zu diskutieren, zu schätzen und zu priorisieren. Innerhalb dieses Meeting werden außerdem erste Hinweise, Randbedingungen und Akzeptanztests aufgenommen. Die Schätzung erfolgt mit Hilfe von Story Points, die mit der Fibonacci-Funktion erzeugt wurden. [S.59, PICH08] führt folgende Werte auf: 0 (kein Aufwand), 1 (sehr kleiner Aufwand), 2 (kleiner Aufwand), 3 (mittlerer Aufwand), 5 (großer Aufwand), 8 (sehr großer Aufwand) und 13 (riesiger Aufwand). Während der Schätzklausur kann jedes Teammitglied einen Wert für eine User Story vergeben. In dieser Klausur können außerdem weitere Fragen geklärt werden, um ein besseres Schätzen möglich zu machen. Die Schätzwerte entstehen durch triangulieren. "Einen Schätzwert triangulieren heißt, eine Story in Relation zu einer oder mehreren anderen Stories zu schätzen." [S.110, COHN10] Eine Story ist also in Bezug auf eine andere Story klein oder groß und das auch nur in einem Team. Die wirkliche velocity des Teams ermittelt sich später aus der Arbeitsgeschwindigkeit des Teams bei der Abarbeitung der User Stories. Innerhalb kurzer Zeit entsteht somit ein Eindruck von der Leistungsfähigkeit eines Teams. Das gesamte Team muss sich im Planungspoker auf einen Schätzwert einigen. Ich empfehle den höchsten Wert, von dem ein Mitglied des Teams nicht abgeht.

Nachdem wir so die User Stories geschätzt haben, bestimmt ein Gremium, bestehend aus Product Owner und Kundenvertretern, möglicherweise können auch Requirements Engineer und Softwarearchitekt hinzugezogen werden, die Priorität der Stories. Dazu empfehle ich das Verfahren zur Priorisierung der Ideen aus dem ersten Post. Danach verfügen wir über eine Reihe von priorisierten und geschätzten User Stories. Haben wir erste Erfahrungen mit der Leistungsfähigkeit eines Teams gemacht, sind wir nun auch in der Lage zu bestimmen, wie viele User Stories wir innerhalb eines Sprints abarbeiten können. Das Team ist dann verpflichtet, die zugesagten Aufgaben zu erledigen, außer es treten ungewöhnliche Ereignisse ein.

Zum Erstellen von User Stories zu einem Thema wird durch den Product Owner eine Aufgabe erstellt. Nachdem die Aufgabe auf OPEN steht, werden durch den oder die festgelegten Verantwortlichen User Stories erstellt. Wenn die Verantwortlichen die Aufgabe auf IMPLEMENTED setzen, werden die User Stories dem Team zur Klausur vorgelegt. Das Team prüft und schätzt die User Stories. Ist das Team damit für alle User Stories diese Themas fertig, steht die Aufgabe im Zustand REVIEWED. Alle angelegten User Stories besitzen zu diesem Zeitpunkt den Status NEW und sie können nun durch das Gremium priorisiert werden und erlangen so den Status PRIORITIZED. Dieser Zustand ist Voraussetzung, dass die User Stories beauftragt werden. Der Product Owner kann die Stories nun in den Backlog stellen und versetzt die entsprechenden Stories in den Zustand ORDERED. Erst nun wird eine neue Aufgabe zur Umsetzung der User Story erzeugt werden. Das Zusammenspiel von anzufertigenden Objekt und umzusetzenden Aufgabe folgt ganz bestimmten Regeln, die für jedes spezifische Objekt definiert sein müssen. Im Umsetzungsteil könnte man diese als Businessregeln konzipieren. Der nächste praktische Post zum Requirements Engineering wird das Zusammenspiel von Problem, Randbedingung und Ziel beschreiben.

  • [COHN10] Mike Cohn: "User Stories", 1. Auflage, mitp, Heidelberg, 2010
  • [PICH08] Roman Pichler: "Scrum - Agiles Projektmanagement erfolgreich einsetzen", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


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