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
a...
Inhalt
—  Was macht eine gute Produktvision aus?
—  Strukturieren von Anforderungen
—  Wie viel beschreiben?
—  Abhäng...
Was macht eine gute
Produktvision aus?
Vision gesucht:
Unsere Fallschirmsprungausbildung
Beschleunigte Freifallausbildung Konventionelle Freifallausbildung
Zweit...
Product Vision Board
Vision Produktidee in wenigen Worten
Zielgruppe
Wer sind die
wesentlichen
Kunden und
Nutzer des
Produ...
Was ist eine gute Produktvision?
—  Drei bis fünf Ziele (Features) – im Zweifelsfall priorisieren
—  Hilfestellung: Was ...
Was ist eine schlechte Produktvision?
—  Beschreibt Maßnahmen, nicht Ziele ” ... Ein System zu
entwickeln ...“
—  Zu vie...
Strukturieren von
Anforderungen
Wie strukturiere ich Anforderungen?
—  Basis ist Produktvision
—  Wo kommen jetzt die Anforderungen her?
—  Wie struktu...
Unsere Fallschirmsprungausbildung
Beschleunigte Freifallausbildung Konventionelle Freifallausbildung
Zweitägiger intensive...
Wie strukturiere ich Anforderungen?
Sprungschul
verwaltung
Schüler
verwaltung
... ...
Prüfungs
verwaltung
... ...
Kurs
ver...
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 F...
Modellieren oder beschreiben?
—  Welches Problem soll mit meinen Anforderungen gelöst
werden?
—  Für wen soll das Proble...
User Story vs. Huge Case?
”Als Prüfer will ich einen Überblick über die absolvierten
Sprünge der Sprungschüler erhalten, u...
Use Case (Story)
User Story – Symbolischer Name
”Als XYZ ...“
Feature / Epic
Schülerverwaltung
Funktionaler Hintergrund / ...
Unsere Fallschirmsprungausbildung
Beschleunigte Freifallausbildung Konventionelle Freifallausbildung
Zweitägiger intensive...
Tools
—  Use Case Maker
http://sourceforge.net/projects/use-case-maker/
—  Visual Use Case http://www.visualusecase.com
...
Schneiden von Anforderungen
Gute Stories erfüllen die INVEST
Kriterien
I Independent
N Negotiable
V Valuable
E Estimable
S Sized appropriately or Smal...
Stories müssen dafür richtig
geschnitten werden
—  Gut geschnittene Stories eröffnen die Möglichkeit
Stories wegzuwerfen
...
Stories müssen dafür richtig
geschnitten werden
—  Neun Muster zum Schneiden von User Stories
—  Workflow Schritte
—  H...
Muster 1: Workflow Schritte
Bildquelle: http://commons.wikimedia.org/wiki/
File:Bom_parallel.jpg
—  Stories entlang der A...
Muster 2: Hauptaufwand
konzentrieren
—  Aufwand für ähnliche Stories in einer Story
konzentrieren
—  Lösung für die rest...
Muster 3: Komplexe Stories in
einfache unterteilen
—  Ausnahmen und Alternativen lassen Stories
„explodieren“
—  Besser ...
Muster 4: Variation von
Geschäftsregeln
—  Geschäftsregeln sind sich u.U. ähnlich
—  „… flexibel suchen …“ à wird zu
—...
Muster 5: Variation von Daten
—  Stories unterscheiden sich in Inhalt von Daten
—  z.B. Sprachabhängigkeit oder Kreditka...
Muster 6: Variation von UI
—  Stories unterscheiden sich in Art und Weise, wie Daten
erfasst / ausgegeben werden
—  Einf...
Muster 7: NFA auslagern
—  Stories haben explizit NFA Bezug
—  … Suchergebnis innerhalb von zwei Sekunden
—  Aufteilen ...
Muster 8: CRUD
—  In Stories werden Daten
—  Erzeugt, gelesen, verändert, gelöscht
—  Stories eventuell entlang der Art...
Muster 9: Spike herausbrechen
—  Um eine Story zu realisieren muss u.U. technologisch
Neuland beschritten werden
—  Stor...
Es gibt noch mehr Muster …
—  Schneiden nach …
—  Testfällen
—  Akzeptanzkriterien
—  Rollen
—  Externen Abhängigkeit...
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/Categor...
Schätzklassen
Klasse/
Punkte
Kurzbeschreibung Langbeschreibung
1 Kinderspiel Sehr geringe Komplexität
2 Mäßig aufwändig Ge...
Jetzt noch die
Feedbackrunde
Vielen Dank für die
Teilnehme
Ramon Anger
Capgemini Deutschland GmbH
ramon.anger@capgemini.com
Nächste SlideShare
Wird geladen in …5
×

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

638 Aufrufe

Veröffentlicht am

Das ist der Foliensatz zu meinem Workshop zu Agiler Anforderungserhebung auf der ManageAgile 2014.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
638
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

  1. 1. Geschnitten oder am Stück Von der Produktvision zu guten Anforderungen Berlin, 30.10.2014 Ramon Anger
  2. 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. 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. 4. Was macht eine gute Produktvision aus?
  5. 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. 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. 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. 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 ...“
  9. 9. Strukturieren von Anforderungen
  10. 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. 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. 12. Wie strukturiere ich Anforderungen? Sprungschul verwaltung Schüler verwaltung ... ... Prüfungs verwaltung ... ... Kurs verwaltung ... Prozessstrukturplan potentiell Komponente potentiell Prozess
  13. 13. Prozessstruktur – bis in welche Tiefe? (nach Alistair Cockburn) Quelle: Sander Hoogendoorn - Das kleine Agile Buch
  14. 14. Wie viel beschreiben? zwischen User Story und Use Case
  15. 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. 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. 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. 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. 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. 20. Tools —  Use Case Maker http://sourceforge.net/projects/use-case-maker/ —  Visual Use Case http://www.visualusecase.com —  Case Complete http://casecomplete.com
  21. 21. Schneiden von Anforderungen
  22. 22. Gute Stories erfüllen die INVEST Kriterien I Independent N Negotiable V Valuable E Estimable S Sized appropriately or Small T Testable
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  35. 35. Abhängigkeiten auflösen
  36. 36. Schätzen von Anforderungen
  37. 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. 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
  39. 39. Jetzt noch die Feedbackrunde
  40. 40. Vielen Dank für die Teilnehme Ramon Anger Capgemini Deutschland GmbH ramon.anger@capgemini.com

×