Post on 21-Jun-2015
description
transcript
Hier soll der Titel rein Testorganisation State of the Art
www.qs-tag.de
Veranstalter: imbus AG www.qs-tag.de
Workshop: Agile Planung
Stefan Roock it-agile GmbH stefan.roock@it-agile.de Twitter: @StefanRoock
AngebotBeyond
autonomes Team
empirisches Management und
Lernen
Mechanik der Releaseplanung
Release- Controlling
Varianz- quellen
Schätzungen
Little’s Law
Klassische sequenzielle Entwicklung
Scrum
Überlappende Phasen
Scrum-Team
Nonaka, Takeuchi: „The New New Product Development Game“
Das Scrum-Team
cross-funktional autonom
inspect&adapt
Agilität
cross-funktional autonom
inspect&adapt
business-orientierte autonome
Teams, die ihren Prozess in Besitz und
Verantwortung nehmen
Lieferbar
Produkt ist lieferbar, wenn vor
Auslieferung nichts mehr getan werden muss (auch
kein Testen).
braucht QS-/Test-Skills
Geht nicht? Wer Scrum anpasst, sollte die Konsequenzen kennen!
Empirisches Management
Transparenz
Adaption
Inspektion
Empirisches Management im Review
Transparenz
Adaption
Inspektion
Demo
Produktinkrement
Feedback,
Wert?, ROI?
Product
Backlog
anpassen
Kleinere Batches, !kürzere Queues
Kürzere !Time-to-Market
Früheres Feedback
Höhere Qualität
Weniger !Overhead
Größere !Effizienz
erwartet
unerwartet
vollkommen
unerwartet
nach D. Reinertsen
Warum ist Little’s Law relevant?
Vom Wasserfall zu Scrum 1/2
Activity 1 Activity 2 ... Activity n
...Sprint 1 Sprint n
Activity 1
Activity n
Wasserfall
Eingebettete Iterationen
Work-in-Progress ist beiden Fällen
gleich hoch
Activities 1 - n
...Sprint 1 Sprint n
Sprint 2Sprint 1 Sprint 3
Sprint 1 Sprint 2
Sprint 1
Sprint 3
Sprint 2 Sprint 3
Vom Wasserfall zu Scrum 2/2Pipeling
Scrum
Work-in-Progress minimal
Work-in-Progress
vielfach so hoch wie in Scrum
Pipelining-Konsequenzen 1/2
Sprint 2Sprint 1 Sprint 3
Sprint 1 Sprint 2
Sprint 1
Sprint 3
Sprint 2 Sprint 3
Feedback Cycle Length
Pipelining-Konsequenzen 1/2
Sprint 2Sprint 1 Sprint 3
Sprint 1 Sprint 2
Sprint 1
Sprint 3
Sprint 2 Sprint 3
?
?
?
Rückläufer (Failure Demand)
zerstören das Konzept
PDCA-Zyklus nach Sheward/Deming
Scrum-Produktzyklus Sprint Planning
Sprint
Sprint Review
Diskutiert: Warum braucht man Releaseplanung? Wer braucht wann welche Informationen?
Aufgabe
5 Minuten
Releaseplanung - wozu?
Rendezvous
-Planung
€
Imvestitions
-
Planung
Kann man m
it den
Rendezvo
uspartne
rn
neue Arte
n der
Zusammenar
beit
etabliere
n?
(inkremente
lle
Releasep
lanung)
Wie genau
muss der
Scope bek
annt sein
?
Reicht nic
ht ein Ziel?
Ökonomie des Front Loading 1/3
Bsp.:
Einfaches Lotto: 4 Ziffern von 0-9 zu tippen.
Gewinn bei 4 Richtigen: 1 Mio. EUR
Wieviel darf der Lotto-Schein kosten, damit es ökonomisch sinnvoll ist, Lotto zu spielen?
angelehnt an Don Reinertsen: „Flow“
Ökonomie des Front Loading 2/3
Bsp.:
Einfaches Lotto: 4 Ziffern von 0-9 zu tippen.
Gewinn bei 4 Richtigen: 1 Mio. EUR
Wieviel darf der Lotto-Schein kosten, damit es ökonomisch sinnvoll ist, Lotto zu spielen?
Antwort: weniger als 100 EUR (1 Mio. / 10.000)
Jemand bietet mir an, dass ich für 50 EUR meine erste Ziffer testen kann. Ist es ökonomisch sinnvoll, dieses Angebot zu nutzen?
angelehnt an Don Reinertsen: „Flow“
Ökonomie des Front Loading 3/3Bsp.:
Einfaches Lotto: 4 Ziffern von 0-9 zu tippen.
Gewinn bei 4 Richtigen: 1 Mio. EUR
Wieviel darf der Lotto-Schein kosten, damit es ökonomisch sinnvoll ist, Lotto zu spielen?
Antwort: weniger als 100 EUR (1 Mio / 10.000)
!Jemand bietet mir an, dass ich für 50 EUR meine erste Ziffer testen kann. Ist es ökonomisch sinnvoll, dieses Angebot zu nutzen?
Antwort: Definitiv. Ich kann für durchschnittlich 250 EUR herausfinden, wie die erste Ziffer lautet. Danach habe ich nur noch 1.000 Möglichkeiten, kann also durch Investition von 100.000 EUR (100 EUR * 1.000 Möglichkeiten) garantieren, dass ich den Gewinn von 1 Mio. EUR bekommen.
!Erkenntnis: Informationsgewinn hat einen ökonomischen Wert! Projektstart mit festem Featureset ist ökonomisch unsinnig. Wie kann ich günstig wertvolle Informationen beschaffen (Prototypen, MVPs, etc.)?
angelehnt an Don Reinertsen: „Flow“
Steuerungsgrößen
Scope
Ressourcen Zeit
Releaseplanung
Scope
Ressourcen Zeit
Scopebasierte Planung
zeitbasierte Planung
ReleaseplanungProduct Backlog
1 2 3
Velocity10
Summe: 400 Story Points
Story Points
10 Story Points
scopebasierte
Planung
400 Story Points
10 Story Points per Sprint
= 40 Sprints
gegebene Deadline: in 30 Sprints
30 Sprints * 10 Story Points je Sprint
= 300 Story Pointsze
itbas
ierte
Planun
g
100 Story Points aus Backlog entfernen
Feste ContainergrößenScope
Ressourcen Zeit
3 Monate 3 Monate 3 Monate 3 Monate 3 Monate•begrenzt Investitionsrisiken •erleichtert Planung •erleichtert Team-Änderungen
•erzeugt Fokus
Roadmap Planung
Name/versionName/versionName/versionName/version
DATEThe launch date or timeframe
GOALThe reaon for creating the new version
FEATURES7KH�WKUHH�WR�ȴYH�IHDWXUHV�necessary to meet the goal
METRICSThe metrics/ KPIs to determine if the goal has been met
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License
THE GO PRODUCT ROADMAPDate or timeframe
Features
Metrics
Goal
Date or timeframe
Features
Metrics
Goal
Date or timeframe
Features
Metrics
Goal
Date or timeframe
Features
Metrics
Goal
NAMEThe name of the new product version or major release
www.romanpichler.comTemplate version 12/13
Release Burnup Chart
Sprint
Verbleibender Aufw
and
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Scope
Rescoping
Feature Creep
Nach Sprint
Release Burndown Bar Chart
Restaufwand
1 2 3 4 5
Cumulative Flow Diagram (CFD)geplant
integrations-getestet (lieferbar)
modul-getestet
konzipiert
programmiert
Parking Lot Diagram
Sammelt Varianzquellen, die bei Euch Schätzungen und Planungen falsch bzw. instabil machen.
Aufgabe
5 Minuten
Varianzquellen
unerwünschterwünschtunvermeidbar vermeidbar
Impediments
Sprint-Review
Sprint- Retrospektive
Teamdynamik
…
Störungen durch Vorgesetzte
Bugs
……
Krankheit
Gesetzgebung
Kündigung
FeueralarmErdbeben
neue Technologien
MissverständnisseLangsame PCs
fehlende Testumgebung
unerwünschterwünschtunvermeidbar vermeidbar
Impediments
Sprint-Review
Sprint- Retrospektive
Teamdynamik
…
Störungen durch Vorgesetzte
Bugs
……
Krankheit
Gesetzgebung
Kündigung
FeueralarmErdbeben
neue Technologien
MissverständnisseLangsame PCs
fehlende Testumgebung
Großer Hebel zur Verbesserung der Release-Planung:
guter Scrum-Master, der Impediments beseitigt.
Varianzquellen
Varianzquellen
unerwünschterwünschtunvermeidbar vermeidbar
Impediments
Sprint-Review
Sprint- Retrospektive
Teamdynamik
…
Störungen durch Vorgesetzte
Bugs
……
Krankheit
Gesetzgebung
Kündigung
FeueralarmErdbeben
neue Technologien
MissverständnisseLangsame PCs
fehlende Testumgebung
Die richtigen Varianzen sind ökonomische
Optionen!
Geschäfts- system
Innovations- system
Effizienz optimieren
Lernen maximieren
Stabilität
Instabilität
Schätzmaße
Impact of sources of variability
lowhigh
high
low
Appropriate precision of estimation
Story Points
Counting
T-Shirt sizes
Hours
Days
Function Points
Schätzgenauigkeit
effort for estimationhighlow
high
low
precision of estimation
Story Points
3 81 213
3 5
•meist guter Kompromiss aus Schätzaufwand und Genauigkeit
•weniger abhängig vom Individuum als Personentage
•schnellere Einigkeit bei Team-Schätzung
•insgesamt schneller (weil weniger Commitment mitschwingt)
Tipps zu Varianzquellen
•Varianzquellen verstehen (Workshop)
•klassisches Risikomanagement
•fähigen Scrum-Master integrieren
•positive Varianzen nutzen
Messen statt schätzen (Beyond Estimating), z.B. mit Lean Forecasting Inkrementelle Relaseplanung keine Releaseplanung (für bestimmte Kontexte)
Trends
Agile Planung ist ehrlicher und verlässlicher als klassische Planung. Realitätsferne Planungen werden früh sichtbar. Genaue Vorhersagbarkeit für Zeit und Scope widerspricht dem Wunsch nach Flexibilität und Innovation. Planung muss kontinuierlich angepasst werden.
Zusammenfassung
Vielen Dank für die Aufmerksamkeit
Stefan Roock stefan.roock@it-agile.de Twitter: @StefanRoock
Agil auf allen Ebenen