Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen
•
1 gefällt mir•1,129 views
Das ist der Foliensatz zu meinem Workshop zu Agiler Anforderungserhebung auf der ManageAgile 2014.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen
Ähnlich wie Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen (20)
Mehr von Ramon Anger
Mehr von Ramon Anger (15)
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
- 4. Was macht eine gute Produktvision aus?
- 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
- 12. Wie strukturiere ich Anforderungen? Sprungschul verwaltung Schüler verwaltung ... ... Prüfungs verwaltung ... ... Kurs verwaltung ... Prozessstrukturplan potentiell Komponente potentiell Prozess
- 13. Prozessstruktur – bis in welche Tiefe? (nach Alistair Cockburn) Quelle: Sander Hoogendoorn - Das kleine Agile Buch
- 14. Wie viel beschreiben? zwischen User Story und Use Case
- 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
- 40. Vielen Dank für die Teilnehme Ramon Anger Capgemini Deutschland GmbH ramon.anger@capgemini.com