SlideShare ist ein Scribd-Unternehmen logo
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

Weitere ähnliche Inhalte

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

User (Experience) Stories #iak13
User (Experience) Stories #iak13User (Experience) Stories #iak13
User (Experience) Stories #iak13
Screamin Wrba
 
MVP - Methode richtig umgesetzt
MVP - Methode richtig umgesetztMVP - Methode richtig umgesetzt
MVP - Methode richtig umgesetzt
FLYACTS GmbH
 
ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel
ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel
ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel
USECON
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
GFU Cyrus AG
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
Christian Seedig
 
Responsive Content Experience
Responsive Content ExperienceResponsive Content Experience
Responsive Content Experience
Peter Rozek
 
UX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch GrazUX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch Graz
HAnnes Robier
 
Business Analyse - eine geeignete Basis für agiles Produktmanagement?
Business Analyse - eine geeignete Basis für agiles Produktmanagement?Business Analyse - eine geeignete Basis für agiles Produktmanagement?
Business Analyse - eine geeignete Basis für agiles Produktmanagement?
microTOOL GmbH
 
Agile Spezifikation
Agile SpezifikationAgile Spezifikation
Agile Spezifikation
NEOMO GmbH
 
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Heico Koch
 
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlOOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
Thomas Moedl
 
Ergosign-Hilfekonzepte-2013
Ergosign-Hilfekonzepte-2013Ergosign-Hilfekonzepte-2013
Ergosign-Hilfekonzepte-2013
Ergosign GmbH
 
NRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile ProjectsNRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile Projects
Rainer Stropek
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
20120207 prs ib_js_libraries_v02
20120207 prs ib_js_libraries_v0220120207 prs ib_js_libraries_v02
20120207 prs ib_js_libraries_v02
Chris Palatinus
 
Business-Mehrwert durch KI
Business-Mehrwert durch KIBusiness-Mehrwert durch KI
Business-Mehrwert durch KI
OPEN KNOWLEDGE GmbH
 
UX muss in die Zukunft schauen
UX muss in die Zukunft schauenUX muss in die Zukunft schauen
UX muss in die Zukunft schauen
Me & Company GmbH
 
Dipl.-Ing. Ludwig Meyer (alysis)
Dipl.-Ing. Ludwig Meyer (alysis)Dipl.-Ing. Ludwig Meyer (alysis)
Dipl.-Ing. Ludwig Meyer (alysis)
Praxistage
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Markus Unterauer
 

Ähnlich wie Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen (20)

User (Experience) Stories #iak13
User (Experience) Stories #iak13User (Experience) Stories #iak13
User (Experience) Stories #iak13
 
MVP - Methode richtig umgesetzt
MVP - Methode richtig umgesetztMVP - Methode richtig umgesetzt
MVP - Methode richtig umgesetzt
 
ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel
ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel
ask:us - Experience Tool: Insights, Innovation und Crowd & Kunden Panel
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
 
Responsive Content Experience
Responsive Content ExperienceResponsive Content Experience
Responsive Content Experience
 
UX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch GrazUX & AGILE vom SCRUM Stammtisch Graz
UX & AGILE vom SCRUM Stammtisch Graz
 
Business Analyse - eine geeignete Basis für agiles Produktmanagement?
Business Analyse - eine geeignete Basis für agiles Produktmanagement?Business Analyse - eine geeignete Basis für agiles Produktmanagement?
Business Analyse - eine geeignete Basis für agiles Produktmanagement?
 
Agile Spezifikation
Agile SpezifikationAgile Spezifikation
Agile Spezifikation
 
Systementwurf mit UML
Systementwurf mit UMLSystementwurf mit UML
Systementwurf mit UML
 
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?Lean Startup und agile Methodiken – Hype oder Fortschritt ?
Lean Startup und agile Methodiken – Hype oder Fortschritt ?
 
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas MödlOOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
OOP 2011: Bitter Scrum Chris Rupp Thomas Mödl
 
Ergosign-Hilfekonzepte-2013
Ergosign-Hilfekonzepte-2013Ergosign-Hilfekonzepte-2013
Ergosign-Hilfekonzepte-2013
 
NRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile ProjectsNRWConf 2013 - Effort Estimation in Agile Projects
NRWConf 2013 - Effort Estimation in Agile Projects
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
20120207 prs ib_js_libraries_v02
20120207 prs ib_js_libraries_v0220120207 prs ib_js_libraries_v02
20120207 prs ib_js_libraries_v02
 
Business-Mehrwert durch KI
Business-Mehrwert durch KIBusiness-Mehrwert durch KI
Business-Mehrwert durch KI
 
UX muss in die Zukunft schauen
UX muss in die Zukunft schauenUX muss in die Zukunft schauen
UX muss in die Zukunft schauen
 
Dipl.-Ing. Ludwig Meyer (alysis)
Dipl.-Ing. Ludwig Meyer (alysis)Dipl.-Ing. Ludwig Meyer (alysis)
Dipl.-Ing. Ludwig Meyer (alysis)
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
 

Mehr von Ramon Anger

Chaos engineering applied
Chaos engineering appliedChaos engineering applied
Chaos engineering applied
Ramon Anger
 
Was Software-Entwickler von der Raumfahrt lernen können
Was Software-Entwickler von der Raumfahrt lernen könnenWas Software-Entwickler von der Raumfahrt lernen können
Was Software-Entwickler von der Raumfahrt lernen können
Ramon Anger
 
Mob Programming - Ein Erfahrungsbericht
Mob Programming - Ein ErfahrungsberichtMob Programming - Ein Erfahrungsbericht
Mob Programming - Ein Erfahrungsbericht
Ramon Anger
 
Chaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps TeamsChaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps Teams
Ramon Anger
 
Chaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps TeamsChaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps Teams
Ramon Anger
 
How to kill (software) architecture?
How to kill (software) architecture?How to kill (software) architecture?
How to kill (software) architecture?
Ramon Anger
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
Ramon Anger
 
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Ramon Anger
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Ramon Anger
 
Das Agile muss ins Klassische
Das Agile muss ins KlassischeDas Agile muss ins Klassische
Das Agile muss ins Klassische
Ramon Anger
 
Under pressure - Sozialer und Termindruck in agilen Teams
Under pressure - Sozialer und Termindruck in agilen TeamsUnder pressure - Sozialer und Termindruck in agilen Teams
Under pressure - Sozialer und Termindruck in agilen Teams
Ramon Anger
 
Vom Hybriden zu Scrum und zurück
Vom Hybriden zu Scrum und zurückVom Hybriden zu Scrum und zurück
Vom Hybriden zu Scrum und zurück
Ramon Anger
 
EAM im Spannungsfeld agiler Methoden oder Agiles EAM
EAM im Spannungsfeld agiler Methoden oder Agiles EAMEAM im Spannungsfeld agiler Methoden oder Agiles EAM
EAM im Spannungsfeld agiler Methoden oder Agiles EAM
Ramon Anger
 
Wer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Wer braucht das schon - Unternehmensarchitektur im agilen ZeitalterWer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Wer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Ramon Anger
 
Coderetreat Vorlage
Coderetreat VorlageCoderetreat Vorlage
Coderetreat Vorlage
Ramon Anger
 

Mehr von Ramon Anger (15)

Chaos engineering applied
Chaos engineering appliedChaos engineering applied
Chaos engineering applied
 
Was Software-Entwickler von der Raumfahrt lernen können
Was Software-Entwickler von der Raumfahrt lernen könnenWas Software-Entwickler von der Raumfahrt lernen können
Was Software-Entwickler von der Raumfahrt lernen können
 
Mob Programming - Ein Erfahrungsbericht
Mob Programming - Ein ErfahrungsberichtMob Programming - Ein Erfahrungsbericht
Mob Programming - Ein Erfahrungsbericht
 
Chaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps TeamsChaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps Teams
 
Chaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps TeamsChaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps Teams
 
How to kill (software) architecture?
How to kill (software) architecture?How to kill (software) architecture?
How to kill (software) architecture?
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
 
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
 
Das Agile muss ins Klassische
Das Agile muss ins KlassischeDas Agile muss ins Klassische
Das Agile muss ins Klassische
 
Under pressure - Sozialer und Termindruck in agilen Teams
Under pressure - Sozialer und Termindruck in agilen TeamsUnder pressure - Sozialer und Termindruck in agilen Teams
Under pressure - Sozialer und Termindruck in agilen Teams
 
Vom Hybriden zu Scrum und zurück
Vom Hybriden zu Scrum und zurückVom Hybriden zu Scrum und zurück
Vom Hybriden zu Scrum und zurück
 
EAM im Spannungsfeld agiler Methoden oder Agiles EAM
EAM im Spannungsfeld agiler Methoden oder Agiles EAMEAM im Spannungsfeld agiler Methoden oder Agiles EAM
EAM im Spannungsfeld agiler Methoden oder Agiles EAM
 
Wer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Wer braucht das schon - Unternehmensarchitektur im agilen ZeitalterWer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Wer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
 
Coderetreat Vorlage
Coderetreat VorlageCoderetreat Vorlage
Coderetreat Vorlage
 

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