Product Canvas

Transcription

Product Canvas

Product Canvas
Werkzeugkasten und Tools für den Agilen Requirements Engineer
8. Projektmanagement-Tag
GPM Region Karlsruhe
3. Juli 2015
Benjamin Seidler, Mustafa Yilmaz
© 2015 andrena objects ag
3
Experts in agile software engineering
www.andrena.de
[email protected]
Benjamin Seidler
Mustafa Yilmaz
5
Agile Requirements Engineering
Agenda
• Agiles Requirements Engineering
• Business Model Canvas
Werkzeugkasten Product Canvas
•
•
•
•
Produktvision
Rollen, Personas und Szenarien
User Stories & Epics
Design-Entwürfe & Nichtfunktionale Anforderungen
6
Weitere Werkzeuge
•
•
•
•
•
•
•
•
Specification by Example / Automatisierte Akzeptanztests
Refinement & Product Backlog
Zerlegen von User Stories
Agiles Schätzen
Priorisieren
Story Maps
Velocity & Release Planung
Impact Mapping
7
8
Was ist Requirements Engineering (RE)
ein systematischer und disziplinierter Ansatz zur Spezifikation und zum
Management von Anforderungen mit den folgenden Zielen:
1. Die relevanten Anforderungen zu kennen, Konsens unter den
Stakeholdern über die Anforderungen herzustellen, die Anforderungen
konform zu vorgegebenen Standards zu dokumentieren und die
Anforderungen systematisch zu managen.
2. Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu
dokumentieren sowie die Anforderungen zu spezifizieren und zu
managen, um das Risiko zu minimieren, dass das System nicht den
Wünschen und Bedürfnissen der Stakeholder entspricht.
Definition: International Requirements Engineering Board (IREB)
Agilitätsdreieck
10
Prinzipien hinter dem Agilen Manifest
1.
Unsere höchste Priorität ist es, den Kunden durch frühe und
kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
2.
Anforderungsänderungen selbst spät in der Entwicklung willkommen
heißen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil
des Kunden.
6.
Die effizienteste und effektivste Methode, Informationen an und
innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von
Angesicht zu Angesicht.
11
Das Projektmanagementdreieck
Vom planbasierten zum nutzwertbasierten Ansatz
Kosten
Umfang
festgelegt
Planbasiert
Dauer
Wertbasiert
geschätzt
Kosten
Dauer
Nach: Dean Leffingwell: Agile Software Requirements
Umfang
(durch Priorisierung)
12
Empirischer bzw. agiler Ansatz
• Iterativ, inkrementell, Just in Time.
• Überprüfen und Anpassen, Selbstorganisation
Scrum
SPRINT
1 Tag
≤ 30 Tage
Sprint
Backlog
Product
Backlog
Product
Increment
14
Agile Requirements Engineering – was muss es leisten?
•
•
•
•
Wert-/Nutzenorientierung
Iterativ und inkrementell
Anforderungen Just-in-time
Direkte Kommunikation
16
Werkzeuge des Agilen RE
17
Business Model Canvas
18
Business Model
• Geschäftsmodelle beschreiben, wie eine Organisation bzw. ein
Unternehmen Mehrwert für Kunden erzeugt und einen Ertrag
für die Organisation sichern kann.
• Geschäftsmodelle helfen, die Schlüsselfaktoren des
Unternehmenserfolges oder -misserfolges zu verstehen, zu
analysieren und zu kommunizieren.
19
Eine Methode zur Visualisierungen von Geschäftsmodellen
• Erarbeitung eines Geschäftsmodells für eine Firma,
ein Produkt oder einen Service.
• Strukturierung der wesentlichen Fragen eines
Geschäftsmodells und seiner Abhängigkeiten.
• Konzentration auf die Stärken und damit den Wert,
der sich mit dem Geschäftsmodell generieren lässt.
http://fa.ltings.de/geschaeftsmodelle-visualisieren/
20
• Erleichtert die Erfassung gesamter Geschäftsmodelle
• Hilft dabei, stillschweigende Annahmen in eindeutige
Informationen zu verwandeln.
• Geschäftsideen werden greifbar und erlauben eine
zielführende, klare Diskussion und Anpassungen.
• Die Visualisierung haucht jedem Geschäftsmodell Leben ein
und erleichtert die gemeinsame Ideenfindung.
http://fa.ltings.de/geschaeftsmodelle-visualisieren/
21
© 2015
andrena objects ag
Quelle:
http://www.businessmodelgeneration.com
22
23
24
25
26
27
Produktidee (Beispiel): Shirt-Creator
• Firma verkauft bereits T-Shirts, Polo-Shirts, …
• Bisher werden nur feste Varianten davon angeboten
• Idee: Individuell konfigurierbare Varianten (bedruckbar)
Personalisierte, qualitativ hochwertige Shirts
•  „Konfigurator“ für die Bestellseite
28
Product Canvas
30
Produktplanung: Von der Erhebung bis zur Umsetzung
Vision
Sprintplan
Übergeordnete Ziele
(Taktik)
Personas &
Szenarien
Releaseplan
(Strategie)
Epen &
User Stories
Refinement
Product
Backlog
34
Das Product Canvas
Name
Vision / Ziel
Metriken
Zielgruppe:
„Big Picture“:
•
•
•
•
•
•
Product
Details:
Rollen
Personas
Szenarien
Epen / User Stories
Design-Skizzen
Einschränkungen /
NFAs
• Sprintziele
• „Ready“
Stories
35
Produktvision
36
Produkt Vision
• Kurz und prägnant
• Emotional und mitreißend
• Sichtbar als Text oder Bild
Vision
F ü r we n ?
Wa s ?
Wie?
Besser als?
37
Elevator
Elevator
Pitch
Pitch
38
Vision (Beispiel)
Mit dem Shirt-Creator können modebewusste Individualisten mit
selbstgestalteten hochwertigen Shirts auffallen.
Kunde: Reseller, Designer, Individualisten
Bedarf: hochwertiges individuelles Kleidungsstück
Hauptvorteil: Kleinserien für Designer
Produkt: Bedrucken von Shirts für alle
über die Bestellplattform für jeden zugänglich machen.
39
Formulierung einer Vision
Für Kunde
die Beschreibung des Bedarfs
ist das Produktname
eine Produktkategorie,
die Hauptvorteil, Grund dieses Produkt zu kaufen;
anders als Alternative des Wettbewerbs
kann unser Produkt Beschreibung des Hauptunterschieds.
40
Vision (Beispiel)
Für Reseller, Designer und Individualisten, die sich nach hochwertigen
individuellen Kleidungsstücken sehnen, ist der Shirt-Creator ein
Produktkonfigurator, der es modebewussten Individualisten gestattet,
mit selbstgestalteten hochwertigen Shirts aufzufallen.
Im Gegensatz zu vergleichbaren Angeboten steht der Shirt Creator
Resellern zur Verfügung und gestattet neben der Auswahl
vorgefertigter auch die Verwen-dung und Bereitstellung selbst
erstellter Motive.
41
Rollen & Personas
42
Stakeholder
• Stakeholder sind alle Menschen, die von Entwicklung, Einsatz
und Betrieb des Systems betroffen sind (Projektbetroffene)
• Alle mit Einfluss auf die Anforderungen
• Anforderungen/Bedürfnisse aus Nutzersicht
 Kundennutzen (in den Nutzer hineinversetzen)
• Ein vergessener Stakeholder ist eine vergessene Anforderung
• Stakeholder identifizieren und mit ihren Rollen
dokumentieren
43
Rollen (Beispiele)
Kunden
Bestandskunde
Händler
Neukunde
Reseller
Auftragsbearbeitung
Designer
Admin
Marketing
Support
44
Personas
• Personas sind am lebenden Menschen orientierte, imaginierte
Personen, die unsere Produkte benutzen.
• Sie stehen stellvertretend für Mitglieder realer
Nutzergruppen.
• Sie erhalten fiktive, persönliche Eigenschaften.
• Sind wirklickkeitsnah.
45
Personas
• Personas leisten einen wichtigen Beitrag zum besseren
Verständnis der Nutzer-Anforderungen.
• Sie helfen, sich in die Situation der Nutzer zu versetzen.
• Sie fokussieren die Entwicklungsarbeiten auf die Ziele und
Bedürfnisse der Nutzer (statt auf die der Projektentscheider,
oder auf technische Restriktionen).
46
Vorlage einer Persona
•
•
•
•
•
•
•
Name
Beruf und Position im Unternehmen
Erscheinungsbild (Foto bzw. Avatar/Skizze oder Beschreibung)
Berufserfahrung
Tägliche Aufgaben (auch außerhalb der Applikation)
Vorlieben und Hobbys, Abneigungen
Ziele
47
Persona (Beispiel)
Lisa
•
•
•
•
•
•
Ich wünsche mit
33 Jahre, weiblich
die Möglichkeit,
eigene Shirts zu
Alternativ, qualitätsbewusst
Keine Lust auf „Standardmode“ gestalten.
Ideen dazu
Kreativ: Basteln, Einrichten, …
entwickle ich
Beruf: Marketing
selbst und meide
Familie, 1 Kind
Standardmode.
48
Rollen und Personas
• Keine allgemeinen Begriffe wie „Nutzer“ oder „Kunde“.
• Möglichst konkret:
• Konkretes Individum
• Persona
• Rolle oder Jobtitel
• Gruppe oder Abteilung
49
Szenarien
50
Szenarien
• Realistisches Beispiel, wie ein Benutzer mit dem geplanten
System interagieren wird.
• Einfache Sätze beschreiben einen konkreten Ablauf aus
Benutzersicht.
• Inhaltlich richtige Aussagen sind wichtiger als formale
Korrektheit.
51
Szenarien
• Motivation: den Benutzer verstehen.
• Szenarien können iterativ oder zusammen mit den Benutzer
erarbeitet werden.
• Die Reflektion am konkreten Beispiel erlaubt es
Auftraggebern und Benutzern, Anforderungen in der
konkreten Anwendungssituation zu vergegenwärtigen, zu
überprüfen und zu ergänzen.
• Gute Grundlage für den Entwurf von User Stories.
52
Szenarien (Beispiel)
Lisa, individuelles Shirt erstellen
20:00 Uhr Abends, Lisa ist zu Hause und surft im Internet
Lisa hat eine gute Idee für ein individuelles Shirt
Sie ruft den Shop auf und sucht sich mehrere Shirts aus
Ihr „Design“ lädt sie im Shirt-Creator hoch und betrachtet sich ihre ShirtModelle
Sie wählt ein Shirt aus und legt es in den Warenkorb, um es zu kaufen
Zwei Tage später wird ihr das Poloshirt nach Hause geliefert
53
Weitere Darstellungsformen für Szenarien
• Workflow
• Ereignisgesteuerte Prozesskette (EPK)
• Use Case
54
User Stories
55
Begrifflichkeiten
• Verschiedene Begriffe werden üblicherweise genutzt, um den
relativen Umfang einer Anforderung zu beschreiben
• Die Verwendung ist nicht einheitlich geregelt
• Epic bzw. Epos
• Thema / Feature
• User Story
• Task
56
Epics / grobe User Stories (Beispiele)
• Lisa möchte individuelle Shirts erstellen können
• Als Designer möchte ich meine Designs anderen Benutzern
zur kostenpflichtigen Nutzung bereitstellen können.
• Als Kunde möchte ich Unterstützung bei der Text- bzw.
Bildgestaltung der Poloshirts (z.B. Transparenz,
Farbgestaltung, …).
• Als Shop-Betreiber möchte ich Auswertungen über die
Anwendung haben, damit ich die Kundenwünsche besser
erfüllen kann.
57
User Story: Definition
„Eine User Story beschreibt eine Funktionalität,
die entweder für einen User oder Käufer […]
von Wert ist.“
Mike Cohn, User Stories applied
58
Format einer User Story
Als
Wer
macht was,
warum?
Benutzerrolle
will ich das Ziel
so dass Grund für das Ziel
59
User Stories (Beispiele)
Als Kunde Lisa
möchte ich eine Vorschau angezeigt bekommen,
damit ich einen Eindruck des Poloshirts erhalte.
Der Käufer
möchte hochgeladene Designs speichern können,
damit diese später wiederverwendet werden können.
60
Vorteil von User Stories
Beim Schreiben von User Stories nehmen wir bewusst die
Sichtweise des Nutzers bzw. Kunden ein.
Jede User Story zielt darauf ab, den Nutzer bzw. Kunden
zufriedener zu machen.
62
Card, Conversation, Confirmation
User Stories bedeuten, miteinander zu sprechen und zu wissen,
wann ein Anforderung umgesetzt ist.
Conversation & Confirmation
Product
Owner
Team
64
Confirmation durch Akzeptanzkriterien
•
•
•
•
„Überprüfbare“ Anforderungen
Gemeinsam erstellt vom Scrum-Team und den Stakeholdern
Legen fest, ob ein Feature fertig umgesetzt ist
Bilden die Basis für Akzeptanztests
65
Akzeptanzkriterien (Beispiele)
Als Kunde möchte ich Bilder hochladen,
um diese in meinen Designs zu verwenden.
Akzeptanzkriterien:
• Der Kunde kann ein Bild auswählen und hochladen.
• Die Webshop zeigt das hochgeladene Bild in der Liste verfügbarer
Bilder für Designs an.
• Wählt ein Kunde ein anderes Format als JPG und PNG aus, wird
eine Fehlermeldung angezeigt.
• Bei Dateien größer als 2 MB wird eine Fehlermeldung angezeigt.
67
Akzeptanztest
Ein Akzeptanztest ist ein Ablauf,
wie die Akzeptanzkriterien überprüft werden kann.
Besteht aus:
• Vorbedingungen
• Ablauf eines Szenarios / Beispiels
• Nachbedingungen bzw. erwartetes Ergebnis
68
Akzeptanztest (Beispiel)
Als Kunde möchte ich Bilder hochladen,
um diese in meinen Designs zu verwenden.
Akzeptanztest:
Vorbedingung: Bild test.PNG auf Kundenrechner
1. Der Kunde wählt „Bild hochladen“.
2. Der Browser öffnet den Dateiauswahldialog.
3. Der Kunde wählt Bild test.PNG aus und wählt „Öffnen“
4. Der Webshop lädt das ausgewählte Bild hoch.
Nachbedingung: Der Webshop zeigt das hochgeladene Bild
in der Liste verfügbarer Bilder für Designs an.
70
User Stories in Kürze
• De-facto Standard für agiles Anforderungsmanagement
• Kurze Beschreibung der Anforderung aus Benutzersicht
• Details werden per Konversation ausgearbeitet und in den
Akzeptanzkriterien festgehalten
71
Design-Entwürfe
72
Design-Entwürfe
• Skizzen
• Wireframes / Mockups
• Ablaufbäume/
-diagramme
73
Nichtfunktionale Anforderungen
74
Nicht funktionale Anforderungen (NFA)
•
•
•
•
•
•
•
Performance
Sicherheit
Wartbarkeit
Wiederverwendbarkeit
Verfügbarkeit
Datenschutz
…
75
Definition of „Done“
Sorgt für ein gemeinsames Verständnis, ob eine Arbeit
abgeschlossen ist.
Was muss alles getan werden, damit eine Story als „fertig“
angesehen wird?
„Done“ – Es ist nichts mehr zu tun!
77
Das Product Canvas
Name
Vision / Ziel
Metriken
Zielgruppe:
„Big Picture“:
•
•
•
•
•
•
Product
Details:
Rollen
Personas
Szenarien
Epen / User Stories
Design-Skizzen
Einschränkungen /
NFAs
• Sprintziele
• „Ready“
Stories
78
Anforderungsworkshop mit Product Canvas
79
Weiteres
Beispiel
80
Weitere Werkzeuge
Welche Themen interessieren Sie am meisten?
1. Specification by Example
2. Refinement & Backlog
3. Zerlegen von User
Stories
4. Agiles Schätzen
5. Priorisieren
6. Story Maps
7. Velocity &
Release Planung
8. Impact Mapping
82
Specification by Example
83
Häufige Probleme
• Anforderungen sind unklar oder mehrdeutig
• Anwender und Entwickler sprechen unterschiedliche
Sprachen
• Domänen-Experten können keine Unit Tests schreiben bzw.
überprüfen
• Die Dokumentation ist bei Änderungen am Produkt nicht
mehr aktuell
84
Idee
• Konkrete Beispiele beschreiben das Verhalten
• Gemeinsame domänenspezifische Sprache verbessert die
Kommunikation
• Ausführbare Beispiele als „Lebende Dokumentation“
85
Beispiele
erzeugen
beschreiben
Tests
prüfen
Anforderungen
Quelle: Gojko Adzic
86
Vorteile
• Bessere Zusammenarbeit der verschiedenen Rollen
• Besseres gemeinsames Verständnis der Anforderungen
• Automatisiertes Testen der fachlichen Anforderungen möglich
• Dokumentation passt zum Produkt (Living Documentation)
87
Quelle: Specification by Example:
How Successful Teams Deliver
the Right Software, Gojko Adzic
88
Spezifikation mit Beispielen
1. Use Context: Als ein _ will ich, _ so dass _
2. Allgemeine Regeln des Features
3. Beispiele zu den Regeln
•
•
•
•
•
Präzise, testbar, selbsterklärend
Geschäftsfunktionalität, in Domänensprache
„Was“, nicht „Wie“
Weitere Fälle lassen sich ableiten
Given - When - Then Sprache
89
Automatisierte Akzeptanztests
91
the Right Software, Gojko Adzic
92
© 2015 andrena objects agthe Right Software, Gojko Adzic
93
© 2015 andrena objects agthe Right Software, Gojko Adzic
94
Werkzeuge für die Automatisierung
http://cukes.info/
http://robotframework.org/
http://fitnesse.org/
95
Selenium Tests
97
Product Backlog
98
Product Backlog
•
•
•
•
•
Enthält alle Anforderungen (Backlog Items)
Geordnet und geschätzt
Grundlage für die Releaseplanung
Kommunikationsgrundlage
Verantwortet durch Product Owner
SPRINT
1 Tag
Product
Backlog
≤ 30 Tage
Sprint
Backlog
Product
Increment
99
Eisberg der Anforderungen
… als
nächstes
umsetzen
… danach
umsetzen
… später
umsetzen
Priorität
100
Refinement
101
Refinement
„Als Verfeinerung [Refinement] des Product Backlogs wird der
Vorgang angesehen, in dem Details zu Einträgen hinzugefügt,
Schätzungen erstellt, oder die Reihenfolge der Einträge im
Product Backlog bestimmt werden. Die Verfeinerung ist ein
kontinuierlicher Prozess, in dem der Product Owner und das
Entwicklungsteam gemeinsam die Product Backlog-Einträge
detaillieren. „
(Scrum Guide)
102
Refinement
Product Backlog
Product Backlog Items
• Überprüfen
• Überarbeiten
• Priorisieren
• Analysieren & Klären
• Zerlegen
• Schätzen
Die Verfeinerung des Product Backlog ist ein kontinuierlicher Prozess.
Das Entwicklungsteam wendet dafür bis zu 10% der Sprintzeit auf.
103
Iterative Detailierung
Aktueller Sprint
Nächster Sprint
Nächster
nächster Sprint
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
Spike
UserStory
UserStory
UserStory
UserStory. PO clarification
UserStory
UserStory
UserStory
UserStory
UserStory
UserStory
Sprint 4 -8
UserStory
UserStory
UserStory
105
Refinements - Ziele
• Kleine und gut verstandene Backlog Items für die nächsten
Sprints („Ready“)
• Verstandene Backlog Items bis zum nächsten Release
• Geschätztes und geordnetes Backlog
• Entwickeln und Anpassen des Release Plans
109
110
Gründe für das Zerlegen
• User Stories müssen in einem Sprint fertigzustellen sein.
• Kleinere User Stories lassen sich besser schätzen.
• Kleinere User Stories gestatten eine detailliertere
Priorisierung.
112
Negativ-Beispiele
Teilaufgaben
Schichten
Schneiden anhand von
Unteraufgaben wie Analyse,
Implementierung, Tests etc.
Schneiden anhand von Architekturschichten wie Datenhaltung, Applikationslogik und Nutzerschnittstelle.
 Hinterlässt kein
inspizierbares und
bewertbares
Softwareinkrement.
 Hinterlässt kein inspizierbares und
bewertbares Softwareinkrement.
 Besser „Durchstich“ mit wenig
Funktionalität.
113
Etablierte Muster für das Zerlegen von User Stories
1. Workflow-Schritte
2. Variation der
Geschäftsregeln
3. Größter Aufwand
4. Komplexität
5. Datenvariation
6.
7.
8.
9.
Schnittstellenvariation
Nachlagern von NFRs
Operationen
Spike herausbrechen
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
123
Praxistipps
•
•
•
•
Geeignete Methode zum Zerlegen verwenden
In wichtigere und weniger wichtige User Stories zerlegen
Stories nicht in Taskgröße zerlegen
Ein Spike ist die letzte Möglichkeit
•  Stories in einem Sprint umsetzbar
 Stories besser schätzbar
 Detaillierter zu priorisieren
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
125
Agiles Schätzen
126
Agiles Schätzen
•
•
•
•
•
•
„Nur“ eine Schätzung!
Entwicklungsteam schätzt
Schätzen der Größe
Abstrakte Einheit: Story Points
Relatives Schätzen (Referenz)
Nichtlineare Skala:
1, 2, 3, 5, 8, 13, 20, 40, 100
S
M
L
130
Magic Estimation
• Schätzwerte ausgelegt
• Keine Kommunikation!
3
2
1
• Reihum:
1. Neue Story nehmen & auslegen (schätzen)
2. Oder Story umlegen
• Mehrfach umgelegte Stories raus
5
8
13
20
132
Planning Poker
•
•
•
•
•
•
Jeder Planning-Pokerkarten
Diskussion der User Story
Jeder wählt eine Karte
Karten gleichzeitig aufdecken
Unterschiede diskutieren
Dann ggf. erneut schätzen
135
Priorisieren
136
Mögliche Einflüsse auf die Priorisierung
•
•
•
•
•
Aufwand
Nutzen, Geschäftswert
Risiko (z.B. Risikomatrix)
Abhängigkeiten
Cost of Delay (COD)
(Kosten einer späteren Umsetzung)
137
Priorisierungsmöglichkeiten
•
•
•
•
Kano-Modell (siehe nächste Folie)
Rangliste / Direkter Vergleich
Sortierung / Ping-Pong-Bälle
„Bauchgefühl“
 MVP (Minimum Viable Product)
138
Kano-Modell
Zufriedenheit
Kreativitätstechniken
Begeisterungsfaktoren
Leistungsfaktoren
Erfüllungsgrad
Beobachtung
Basisfaktoren
140
Story Map
141
Story Map
“Rückgrat”
“Lauffähiges
Gerippe”
Priorität
R1
R2
R3
142
Story Map
(Beispiele)
143
145
Releaseplanung
146
Release Planning
Backlog
Ein guter Releaseplan erfordert ein
geordnetes und geschätztes Backlog.
Velocity
Ein guter Releaseplan erfordert eine
bekannte Velocity.
147 Agile Requirements Engineering
147
Basistypen der Release Planung
Feature Target Planning
Date Target Planning
Das Produkt wird zu einem
bestimmten Datum released.
Das Produkt wird released,
wenn bestimmte Features
fertig sind.
“Wie viel des Product Backlog
wird an einem bestimmten
Datum fertig sein?”
“Wann wird Feature A, B und C
fertig sein?”
149
Velocity
Die Velocity beschreibt die Geschwindigkeit, mit der das
Entwicklungsteam Product Backlog Items pro Sprint abarbeitet.
150
Planung mit Velocity
30
Bester Fall:
Top 3 =>
Ø 23
Story Points
25
20
Wahrscheinlichster Fall:
Mittlere 3
Ø 19
15
10
5
0
1
2
3
4
5
Sprint
6
7
8
9
Schlechtester
Fall:
Unterste 3
Ø 14
152
Product Backlog
Größe: 13
Wann wird Feature A
wahrscheinlich
geliefert?
Größe: 20
Größe: 20
Größe: 3
Größe: 5
• Mittlere Team Velocity = 32
• Sprint Länge= 2 Wochen
Größe: 1
Größe: 8
Größe: 13
Größe: 3
A
Größe: 13
Größe: 3
6 Wochen
153
Product Backlog
Größe: 13
Größe: 1
Größe: 2
Größe: 8
Größe: 5
Größe: 13
Größe: 3
Größe: 13
Größe: 5
Größe: 8
Größe: 2
Das
Alles
Was wird in 8
Wochen alles
geliefert?
• Mittlere Team Velocity = 16
• Sprint Länge= 2 Wochen
154
Release Burndown
Features
Velocity:
Heute
tatsächliche
beste
durchschnittliche
schlechteste
Fertigstellung
Zeit
156
Impact Mapping
158
Impact Map
• Gemeinsam erstellt von Fachabteilung und Entwicklung
• Mind-Map aus der Diskussion um die vier Fragen
Warum? Wer? Wie? Was?
• Visualisierung von Scope und zugrundeliegenden Annahmen
 Annahmen tranparent machen und in Frage stellen
• Ausrichtung aller Aktivitäten auf die Business Ziele
 Bessere strategische Planung
160
Aufbau einer
Impact Map
Ziel
Person
Effekt
Feature
Was?
Wie?
…
Wer?
Wie?
Warum?
…
Was?
Wie?
…
Wer?
Wie?
…
161
Warum?
Wer?
Wie?
Was?
Quelle: http://impactmapping.org
164
Ziel
Person
Impact Map
(Beispiel)
Effekt
Für Freunde
bestellen
Kunde
Größere
Bestellungen
Feature
Mehrere
Adressen
Geschenkverpackung
Mengenrabatt
Top 10 Designs
anpreisen
Shirt Verkauf
verdoppeln
Spontankäufe
Rabatt-Aktion
Designer
Designs für
Freunde
Eigene Designs
teilen
165
Impact Map
•
•
•
•
•
Alles unterstützt das Ziel! (wenn die Annahmen stimmen)
Mapping von Features auf Ziele
Scope und Annahmen visualisiert
Überprüfen der Annahmen möglich
Konzentrieren auf einzelne Zweige möglich
168
Zusammenfassung
• Agiles Requirements Engineering
• Business Model Canvas
Werkzeugkasten Product Canvas
•
•
•
•
•
•
Produktvision
Rollen und Personas
Szenarien
User Stories & Epics
Design-Entwürfe
Nichtfunktionale Anforderungen
Weitere Werkzeuge
•
•
•
•
•
•
•
•
Refinement & Product Backlog
Agiles Schätzen
Priorisieren
Story Map
Velocity & Release Planung
Impact Mapping
170
Experts in agile software engineering
andrena objects ag
Albert-Nestler-Straße 9
76131 Karlsruhe
Tel. + 49 (0) 721 6105 122
Weitere Standorte:
• Frankfurt
• München
• Stuttgart
www.andrena.de
[email protected]

Product Canvas

Transcription

Similar documents

NGN Access: Multi Service System SHDSL.bis für Mietleitungen

Interaktivität in Multimedia- Anwendungen - e

Inhaltsverzeichnis

Oracle Forms Migration Framework

jBPM meets ESB

E+Z - Entwicklung und Zusammenarbeit (Nr. 6, Juni 2001, S. 192

DFKI News 31

Präsentation als PDF

The IoT Business Model Builder

ISTQB Certified Tester Foundation Level Extension Syllabus Agile

Für Alle Erfolg in Intranetprojekten dank User