Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen
1. Geschnitten oder am Stück
Von der Produktvision zu guten Anforderungen
Berlin, 30.10.2014
Ramon Anger
2. 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?
3. Inhalt
— Was macht eine gute Produktvision aus?
— Strukturieren von Anforderungen
— Wie viel beschreiben?
— Abhängigkeiten auflösen
— Schneiden von Anforderungen
— Schätzen von Anforderungen
5. 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
6. 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)
7. 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)
8. 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 ...“
10. 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?
11. 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
15. 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?
16. 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?
17. 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
18. 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
19. 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
20. Tools
— Use Case Maker
http://sourceforge.net/projects/use-case-maker/
— Visual Use Case http://www.visualusecase.com
— Case Complete http://casecomplete.com
22. Gute Stories erfüllen die INVEST
Kriterien
I Independent
N Negotiable
V Valuable
E Estimable
S Sized appropriately or Small
T Testable
23. 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
24. 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
25. 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
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
37. 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
38. 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