Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen

Geschnitten oder am Stück Von der Produktvision zu guten Anforderungen

Berlin, 30.10.2014 Ramon Anger

Eine kurze Vorstellung bitte

�  Wer sind Sie und was tun Sie?

�  Welche Erfahrung haben Sie mit Anforderungen in einem agilen Umfeld?

�  Welche Erwartungshaltung haben Sie an den Workshop?

Inhalt

�  Was macht eine gute Produktvision aus?

�  Strukturieren von Anforderungen

�  Wie viel beschreiben?

�  Abhängigkeiten auflösen

�  Schneiden von Anforderungen

�  Schätzen von Anforderungen

Was macht eine gute Produktvision aus?

Vision gesucht: Unsere Fallschirmsprungausbildung

Beschleunigte Freifallausbildung Konventionelle Freifallausbildung

Zweitägiger intensiver Einstiegskurs in Theorie und Praxis.

7 Freifallsprünge aus 4000m 10 Sprünge mit Aufziehleine (1200 bis 1500m)

10 Freifallsprünge mit manueller Schirmöffnung

Prüfungsvoraussetzungen zur Lizenz schaffen Mindestens 23 Freifallsprünge

Prüfung Theorieprüfung 2x Prüfungssprünge

Lizenz

Product Vision Board

Vision Produktidee in wenigen Worten

Zielgruppe Wer sind die wesentlichen Kunden und Nutzer des Produkts?

Bedarf Welches Problem soll mit dem System gelöst werden?

Produkt-eigenschaften Wesentliche Features des Produkts

Nutzen Wie hilft das Produkt die Geschäftsziele zu erreichen?

(nach Roman Pichler)

Was ist eine gute Produktvision?

�  Drei bis fünf Ziele (Features) – im Zweifelsfall priorisieren

�  Hilfestellung: Was soll mein System in zwei Jahren bewirkt haben?

�  SMART �  Spezifisch �  Messbar

�  Akzeptiert

�  Realistisch

�  Terminiert*

http://de.wikipedia.org/wiki/SMART_(Projektmanagement)

Was ist eine schlechte Produktvision?

�  Beschreibt Maßnahmen, nicht Ziele ” ... Ein System zu entwickeln ...“

�  Zu viele Ziele ... ”... 23. ...“

�  Unrealistisch ”... in Echtzeit ...“

�  Platzhalter ”... universell ...“

�  Auf Basis von Personas ” ... Sachbearbeiter sollen ...“

�  Nutzen unklar ” ... um die Zukunftsfähigkeit ...“

Strukturieren von Anforderungen

Wie strukturiere ich Anforderungen?

�  Basis ist Produktvision

�  Wo kommen jetzt die Anforderungen her?

�  Wie strukturiert / gruppiert man Anforderungen in der agilen Welt? �  Erst Themes, dann Epics, dann User Stories? Wo ordne ich

Features ein? �  Gibt es noch was dazwischen?

Unsere Fallschirmsprungausbildung

Beschleunigte Freifallausbildung Konventionelle Freifallausbildung

Zweitägiger intensiver Einstiegskurs in Theorie und Praxis.

7 Freifallsprünge aus 4000m 10 Sprünge mit Aufziehleine (1200 bis 1500m)

10 Freifallsprünge mit manueller Schirmöffnung

Prüfungsvoraussetzungen zur Lizenz schaffen Mindestens 23 Freifallsprünge

Prüfung Theorieprüfung 2x Prüfungssprünge

Lizenz

Wie strukturiere ich Anforderungen?

Sprungschul verwaltung

Schüler verwaltung

... ...

Prüfungs verwaltung

... ...

Kurs verwaltung

...

Prozessstrukturplan

potentiell Komponente

potentiell Prozess

Prozessstruktur – bis in welche Tiefe?

(nach Alistair Cockburn) Quelle: Sander Hoogendoorn - Das kleine Agile Buch

Wie viel beschreiben? zwischen User Story und Use Case

Wie viel beschreiben?

�  Wer sind die Stakeholder?

�  Welche Informationen benötigen diese Stakeholder?

�  In welcher Form stiften diese Informationen den größten Nutzen?

�  Was ist OTOPOP?

Modellieren oder beschreiben?

�  Welches Problem soll mit meinen Anforderungen gelöst werden?

�  Für wen soll das Problem gelöst werden?

�  Mit welchen Maßnahmen erreiche ich das (am besten)?

�  Womit kann die Zielgruppe umgehen?

User Story vs. Huge Case?

”Als Prüfer will ich einen Überblick über die absolvierten Sprünge der Sprungschüler erhalten, um über ihre Zulassung zur Prüfung entscheiden zu können.“

�  Was fehlt noch für eine Realisierung?

�  Huge Case �  Allgemeiner Ablauf �  Elf alternative Abläufe �  Acht Ausnahmen �  200 Seiten

Use Case (Story)

User Story – Symbolischer Name ”Als XYZ ...“

Feature / Epic Schülerverwaltung

Funktionaler Hintergrund / Kontext / Rollen

Akzeptanzkriterien 1. 2. 3.

Abhängigkeiten Zu anderen Use Case Stories

Struktur und Inhalt in jedem Fall an Bedarf anpassen

Unsere Fallschirmsprungausbildung

Beschleunigte Freifallausbildung Konventionelle Freifallausbildung

Zweitägiger intensiver Einstiegskurs in Theorie und Praxis.

7 Freifallsprünge aus 4000m 10 Sprünge mit Aufziehleine (1200 bis 1500m)

10 Freifallsprünge mit manueller Schirmöffnung

Prüfungsvoraussetzungen zur Lizenz schaffen Mindestens 23 Freifallsprünge

Prüfung Theorieprüfung 2x Prüfungssprünge

Lizenz

Tools

�  Use Case Maker http://sourceforge.net/projects/use-case-maker/

�  Visual Use Case http://www.visualusecase.com

�  Case Complete http://casecomplete.com

Schneiden von Anforderungen

Gute Stories erfüllen die INVEST Kriterien

I Independent

N Negotiable

V Valuable

E Estimable

S Sized appropriately or Small

T Testable

Stories müssen dafür richtig geschnitten werden

�  Gut geschnittene Stories eröffnen die Möglichkeit Stories wegzuwerfen �  80/20 Regel

�  Gleich große Stories anstreben �  Story mit acht Story points à vier Stories mit je zwei Story

points �  Besser priorisierbar à Wert vor Aufwand

�  Never ever: horizontales Schneiden à entlang der Schichten

Stories müssen dafür richtig geschnitten werden

�  Neun Muster zum Schneiden von User Stories �  Workflow Schritte �  Hauptaufwand konzentrieren �  Komplexe Stories in einfache unterteilen �  Variation von Geschäftsregeln �  Variation von Daten �  Variation von UI �  NFA auslagern �  CRUD �  Spike herausbrechen

Muster 1: Workflow Schritte

Bildquelle: http://commons.wikimedia.org/wiki/File:Bom_parallel.jpg

�  Stories entlang der Aktivitäten eines Workflow oder einer Prozesskette schneiden �  Definierte Eingänge/Ausgänge �  In sich abgegrenzt

Muster 2: Hauptaufwand konzentrieren

�  Aufwand für ähnliche Stories in einer Story konzentrieren �  Lösung für die restlichen Stories lässt sich aus der ersten

ableiten

Bildquelle: http://commons.wikimedia.org/wiki/File:Waage_Luisenhütte_Wocklum.jpg

Muster 3: Komplexe Stories in einfache unterteilen

�  Ausnahmen und Alternativen lassen Stories „explodieren“ �  Besser mit der einfachsten Variante einer Story anfangen

à Happy Path �  Zusätzliche Bestandteile in andere Stories auslagern à

Unhappy Path

Bildquelle: http://commons.wikimedia.org/wiki/File:Mandel_zoom_11_satellite_double_spiral.jpg

Muster 4: Variation von Geschäftsregeln

�  Geschäftsregeln sind sich u.U. ähnlich �  „… flexibel suchen …“ à wird zu

�  1. nach Datum

�  2. nach Name �  3. …

�  Variationen in eigene Stories auslagern

Bildquelle: http://commons.wikimedia.org/wiki/File:Variations_of_A.JPG

Muster 5: Variation von Daten

�  Stories unterscheiden sich in Inhalt von Daten �  z.B. Sprachabhängigkeit oder Kreditkartenherausgeber �  Bei Abhängigkeiten vom Inhalt der Daten entlang der

Abhängigkeiten schneiden

Bildquelle: http://commons.wikimedia.org/wiki/File:SL_variation.svg

Muster 6: Variation von UI

�  Stories unterscheiden sich in Art und Weise, wie Daten erfasst / ausgegeben werden �  Einfache / komplexe GUI �  Einfache / detaillierte Suche

Bildquelle: http://commons.wikimedia.org/wiki/File:Adaptateur_électrique_multiprise_CEE_7_01.jpg

Muster 7: NFA auslagern

�  Stories haben explizit NFA Bezug �  … Suchergebnis innerhalb von zwei Sekunden �  Aufteilen in funktionale und nicht funktionale Anteile

Bildquelle: http://commons.wikimedia.org/wiki/File:IndianRailways.JPG

Muster 8: CRUD

�  In Stories werden Daten �  Erzeugt, gelesen, verändert, gelöscht

�  Stories eventuell entlang der Art der Manipulation schneiden

Bildquelle: http://commons.wikimedia.org/wiki/File:Plankton_creates_sea_foam_3.jpg

Muster 9: Spike herausbrechen

�  Um eine Story zu realisieren muss u.U. technologisch Neuland beschritten werden

�  Story Aufteilen �  Technologische Herausforderung als Design Spike �  Funktionaler Anteil später

Bildquelle: http://commons.wikimedia.org/wiki/File:Stone_breaking.JPG

Es gibt noch mehr Muster …

�  Schneiden nach … �  Testfällen �  Akzeptanzkriterien �  Rollen �  Externen Abhängigkeiten �  Schwierigkeitsgrad bei Umsetzung

Bildquelle: http://commons.wikimedia.org/wiki/File:Göteborg_02.jpg

Abhängigkeiten auflösen

Schätzen von Anforderungen

Wie hoch sind diese acht Gebäude zusammen? Schätzung bitte in Metern

Bildquelle: http://commons.wikimedia.org/wiki/Category:Chicago_skyline#mediaviewer/File:2009-09-18_3060x2040_chicago_skyline.jpg

Schätzklassen

Klasse/Punkte

Kurzbeschreibung Langbeschreibung

1 Kinderspiel Sehr geringe Komplexität

2 Mäßig aufwändig Geringe Komplexität

3 Normal Normale Aufgabe

5 Schwierig Komplexität im Sprint von einem Kollegen zu meistern

8 Schwierig, aber machbar

Komplexität im Sprint von mehreren Kollegen parallel zu meistern

99 Extrem Aufgabe im Sprint nicht leistbar oder nicht genug Informationen für Abschätzung

Bei längeren Sprints mehr Klassen verwenden Idealerweise Klassen gar nicht in Aufwände umrechnen, sondern ausschließlich mit der Komplexität rechnen

Jetzt noch die Feedbackrunde

Vielen Dank für die Teilnehme

Ramon Anger Capgemini Deutschland GmbH

ramon.anger@capgemini.com