Agil, Anforderungserhebung, Anforderungsmanagement, Schätzen, Selbstorganisation

Vom Geist zur Materie

Klare Aufgaben geben Selbstorganisationskräften eine Richtung – vom Umgang mit Anforderungen in agilen Projekten.

Zurück zu den Grundlagen. In agilen Projekten werden zu jedem Ende einer Iteration Produkterweiterungen geliefert. Eine Produkterweiterung stiftet den Anwendern des Produktes Nutzen. Sie kann potentiell an die Kunden ausgeliefert werden, wird möglicherweise aber auch mit anderen Produkterweiterungen gebündelt und den Kunden im Rahmen eines Release bereitgestellt.

Weiterlesen

Standard
Agil, Anforderungserhebung

Der erste Knopf

Die strategische Ausrichtung, die Blickrichtung der Mitglieder eines agilen Projektes, wird durch die Produktvision vorgegeben. Die Produktvision skizziert das neue Produkt, für das die Teammitglieder ihre Arbeitskraft einsetzen. Die Produktivison ist kurz, klar und einfach und wird durch alle Beteiligten verstanden.

Die Produktvision liefert eine Begründung dafür, warum eine Organisation sich den Schwierigkeiten einer Produktentwicklung aussetzen und daran festhalten sollte. Entscheidungen während des Projektverlaufs werden gegen die Vision geprüft – insbesondere sollten keine Entscheidungen getroffen werden, die der Vision widersprechen. Mit der Produktvision wird das Produkt organisationsintern und -extern vermarktet.

Die umzusetzenden Anforderungen, die als User Stories im weiteren Projektverlauf detailliert werden, haben ihren Ausgangspunkt in den Produktmerkmalen, die in der Produktvision festgehalten sind.

Für die Miglieder des Entwicklungsteams ist die Produktvision wesentlich. Das Team benötigt eine gemeinsame Vorstellung davon, welches Produkt erstellt wird, da anderenfalls den Selbstorganisationskräften, die für komplexe Aufgabenstellungen essenziell sind, die Richtung fehlt. Eine gemeinsame Vision inspiriert und verbindet die Menschen und erlaubt die Bündelung und Zusicherung von Energie für ein gemeinsames Ziel. Dabei wird der Blick auf das Ganze, auf das strategische Ziel, gerichtet. Diana Larsen formuliert dazu „Es ist eigentlich paradox, dass wir erst dadurch mehr Kontrolle über komplexe Ergebnisse bekommen, dass wir auf die Kontrolle über die Teile verzichten“. Die Produktvision schafft Freiräume zur Entstehung von Kreativität und belässt die detaillierte Produktumsetzung weitgehend offen.

Es lohnt sich, zu Beginn eines Projektes Zeit zu investieren, um die richtigen Fragen zu stellen und um abzugrenzen, was für ein Produkt eigentlich zu erstellen ist. Es gilt nach Johann Wolfgang von Goethe: „Wer das erste Knopfloch verfehlt, kommt mit dem Zuknöpfen nicht zu Rande.“

Die Frage ist, wie kommt man zu einer Produktvision, die das leistet?

Der nachfolgend beschriebene Prozess ist ein möglicher Weg, eine Produktvision zu erarbeiten und kann von einem Team innerhalb eines Tages durchlaufen werden. Es handelt sich um die Zusammenstellung verschiedener Techniken und Verfahren, die unterschiedliche Perspektiven auf das Produkt forcieren. In ihrer Kombination verdichten sie die gesuchte Zielsetzung auf das Wesentliche. Neben dem Entwicklungsteam und ggf. Kundenvertretern muss die für die geschäftlichen Aspekte des Produktes verantwortliche Person (im Scrum z.B. der Product Owner, oder allgemein der Produktverantwortliche) an dem Prozess teilnehmen. Für den Produktverantwortlichen bietet das Vorgehen die Chance, mehr Sichtweisen auf das Produkt zu erhalten. Das Entwicklungsteam bekommt die Möglichkeit, Kontakt mit dem zu lösenden Problem aufzunehmen und Kunden sowie Benutzer haben bestmöglichen Einfluss auf die Gestaltung des Produktes.

Es wird kreative Höchstleistung erbracht. Die dazu nötige hohe Konzentration lässt sich generell für ungefähr 40 Minuten halten. Daher sollten genug Pausen eingeplant werden – jede Stunde fünf bis zehn Minuten und mittags eine Stunde.

1. Elevator Framework

Das von Geoffrey Moore vorgeschlagene Framework hilft dem Team, durch die Beantwortung vorformulierter Fragen eine erste gemeinsame Sicht auf das Produkt zu erarbeiten. Folgende Fragen sind zu beantworten:

Für <Käufer, Benutzer>

mit <Bedürfnissen>

ist <Produktname>

ein <Produktkategorie>

das <Attribute, Nutzen, Kaufgrund>.

Anders als <Alternative des Wettbewerbs>

ist <Produktname> <Differenzierung des Produktes>

Im Team kann man zur Beantwortung der Fragen mit Metaplankarten arbeiten. Es gibt Fragekarten in einer Farbe und Antwortenkarten in einer anderen Farbe. Die Fragestellungen Für, mit, ist, usw. werden auf Metaplankarten geschrieben und an der Metaplanwand angeheftet. Die Beantwortung dieser Fragen findet auf Metaplankarten einer anderen Farbe statt. Die Antwortkarten werden neben die Fragekarten geheftet.

Der Produktverantwortliche beginnt. Er beantwortet aus seiner Sicht die erste Frage. Dazu schreibt er die Antworten auf die Karten, heftet sie an und erläutert sie. Das Team kann nachfragen und weitere Vorschläge machen, die der Produktverantwortliche ggf. als weitere Antwortkarten aufnimmt. So bewegt sich das Team schrittweise durch die einzelnen Fragestellungen und erarbeitet sich eine erste gemeinsame Sicht auf das Produkt. Die Moderation kann im Scrum durch den Scrum Master erbracht werden. Das ersetzt aber nicht die aktive Rolle des Produktverantwortlichen (bzw. Product Owners).

Informationen zu wesentlichen Terminen und zum Budget können durch den Produktverantwortlichen zusätzlich an die Metaplanwand geheftet werden.

2. Erinnere die Zukunft

In dieser Arbeitssitzung wird eine andere Perspektive auf das Produkt eingenommen. Es geht darum, aus Sicht des Kunden die Definition für den Erfolg des Produktes zu erkennen (die Teilnahme von Kundenvertretern und Benutzern kann also hilfreich sein). Das Verfahren schlägt Luke Hohmann in seinem Buch „Innovation Games“ unter dem Namen „Remember the Future“ vor. Alle Teilnehmer der Sitzung beantworten nur eine Frage:

Stellen Sie sich vor, wir befinden uns in der Zukunft, ein Jahr nach der Auslieferung des Produktes an den Kunden und die Benutzer. Wie hat das Produkt den Kunden und die Benutzer glücklich gemacht?

Erneut wird eine Metaplanwand benötigt. Dort wird ein Zeitstrahl eingetragen, der vom Zeitpunkt der Auslieferung des Produktes (oder kurz vor der Auslieferung) bis zu dem in der Zukunft liegenden Zeitpunkt der obigen Fragestellung reicht. Jedes Teammitglied schreibt seine Antworten auf Metaplankarten. Nach einer kurzen Zeitspanne treten die Teilnehmer nacheinander an die Metaplanwand und heften ihre Aussagen an die Position im Zeitstrahl, der die Aussage zugeordnet sein soll. Dabei erläutert jeder Teilnehmer dem Team seine Antworten. Das Verfahren geht reihum, bis die Teilnehmer keine weiteren Antworten mehr liefern können.

Das Verfahren kann durch Veränderung des zeitlichen Horizonts und durch parallel arbeitende Gruppen, die sich gegenseitig ihre Ergebnisse präsentieren, variiert werden.

3. Produktverpackung

Die Produktverpackung (Vision Box od. Product Box) hilft, die gesammelten Ideen zu verdichten und die wesentlichen Produktmerkmale herauszustellen. Die Produktverpackung bietet wenig Raum für komplizierte Aussagen, die Teilnehmer müssen sich also beschränken.

Bei dieser Arbeitssitzung stellen die Teilnehmer eine Produktverpackung her, in der das Produkt verkauft werden kann (mit dem Namen des Produktes und wesentlichen Produktmerkmalen).

Jim Highsmith hat das Verfahren unter dem Titel Vision Box beschrieben. Die Vision Box hat eine interne Perspektive, das Entwicklungsteam arbeitet für sich. Luke Hohmann hingegen beschreibt mit der Product Box ein ganz ähnliches Verfahren, bei dem eine externe Perspektive, also aus Sicht des Kunden und unter Teilnahme des Kunden eingenommen wird. Welche Sicht benötigt wird, entscheidet der Produktverantwortliche.

Es kann hilfreich sein, in mehreren Gruppen zu arbeiten, um die möglicherweise verschiedene Sichten auf die relevanten Merkmale des Produktes zu erheben.

Zur Durchführung benötigen die Arbeitsgruppen weisse Kartons in der Größe von Waschmittelverpackungen sowie verschiedenfarbige Stifte. Stehen solche Kartons nicht zur Verfügung, kann auch auf Flipchart-Blättern gearbeitet werden. Jede Arbeitsgruppe entwirft nun innerhalb von 30 bis 45 Minuten eine Produktverpackung und stellt diese abschließend dem gesamten Team vor.

4. Diskussion und Würdigung aller Ergebnisse

Zum Abschluss findet eine offene Diskussion des gesamten Prozesses und der erzielten Ergebnisse durch die Beteiligten statt. Es wird besprochen, welche Ideen gut sind und an welchen Themen eine weitergehende und vertiefende Arbeit erforderlich ist.

5. Nächste Schritte

Es wird entschieden, in welcher Form an der Produktvision weitergearbeitet wird und zu welchem Termin die Produktvision fertiggestellt sein wird. Der Produktverantwortliche hat das letzte Wort über die Gestaltung des Produktes und ist damit verantwortlich für die Produktvision. Es ist seine Aufgabe, die erarbeiten Ergebnisse in eine endgültige Produktvision einfließen zu lassen. In jedem Fall wird die fertiggestellte Produktvision allen Projektteilnehmern zugänglich gemacht und durch den Produktverantwortlichen den Teilnehmern präsentiert. Fotos der Metaplanwände und der erzielten Arbeitsergebnisse werden zur Herleitung des Ergebnisses ebenfalls so abgelegt, dass die Projektteilnehmer auf diese Informationen zugreifen können.

Siehe auch http://www.scrumalliance.org/articles/115-the-product-vision

Standard
Agil, Anforderungserhebung, Referenzen, Scrum

Kurzweilige Geschichten

Angelika Drach, Christoph Mathis und Andreas Wintersteiger haben im Java Magazin 08/2011 auf S. 108 ff. den sehr gelungenen Artikel „Kurzweilige Geschichten, Agile Entwicklung mit User Stories“ veröffentlicht. Besonders die Hinweise zum Zergliedern von User Stories mit den Verweisen auf Richard LawrenceLasse Koskela und Bill Wake finde ich hilfreich und im Artikel sehr gut zusammengefasst. Natürlich fehlt auch nicht der Hinweis auf das Story Mapping von Jeff Patton zur Verfeinerung von User Stories. Es ist alles drin:

  • User Story versus Use Case
  • User Stories und Product Backlog
  • Story Maps
  • Planen und Schätzen mit User Stories
  • Das Beispiel einer guten User Story
  • Priorisieren
  • Relative Schätzung mit Story Points
  • INVEST Kriterien
  • Lebenszyklus von User Stories
  • User Stories splitten
Standard