Embed Size (px)
Citation preview
Lean Forecasting, Beyond Estimation @ Agile User Group Bremen, 13. Januar 2016Susanne Bartelhttp://flow.hamburg
Inhalt• Teil 1
• Warum das große Interesse am Thema? • Was ist Lean Forecasting / Beyond Estimation? • Kleine Statistik-Auffrischung :)
• Teil 2 • Lego Flow Game (und kurze Pause)
• Teil 3 • Konkrete Fragestellungen - Theorie und Praxis
1. Wie lange dauert die Umsetzung von Anforderungen? 2. Wann ist das erwartete Projektende? 3. Weiterführende Fragen
• Zu guter letzt…
WARUM?
Häufig schwache Korrelation zwischen Story Points und Aufwand oder Durchlaufzeit
Hohe Aufwände für Schätzungen und Planungen
Vielfach durch Studien belegt, wie schlecht wir im Schätzen in der Software-
Industrie sind.
0,00#
5,00#
10,00#
15,00#
20,00#
25,00#
30,00#
35,00#
40,00#
0# 1# 2# 3# 4# 5# 6#
Story&Points&zu&Lead&1me&[d]&
Lead#.me#[d]#
Faktor: 0,3
1,0$
10,0$
100,0$
1000,0$
10000,0$
0$ 2$ 4$ 6$ 8$ 10$ 12$ 14$ 16$
Aufwand$(Stunden)$ Linear$(Aufwand$(Stunden))$ Linear$(Aufwand$(Stunden))$
Faktor:0,36
Beispiel-Korrelationen
0"
20"
40"
60"
80"
100"
120"
0" 1" 2" 3" 4" 5" 6"
Story&Punkte&zu&Aufwand& Faktor:0,2
LEAN FORECASTING
Lean / „Probabilistic“ Forecasting
Projektion historischer Daten in die Zukunft zur Beantwortung planerischer Fragen
Unter Beachtung von Wahrscheinlichkeiten
Unter Nutzung von Modellen
„Klassische“ Planung: Schätzen zukünftiger Ereignisse
Vorteile• Wahrscheinlichkeitsbasierte Prognosen:
• Schnell • Billig • Zuverlässig • Entlasten die „echt“ wertschöpfenden
Mitglieder im Team
Beyond Estimation #NoEstimationLean Forecasting zur Prognose von Durchlaufzeiten und Durchsätzen Macht die Verwendung von Story Points überflüssig Angewendete Praktik besonders in reifen agilen Teams
STATISTIK VORWEG
Aufwärmen Teil 1Würfelt mit einem 6er-Würfel.
Sagt eure Ergebnisse laut an!
Aufwärmen Teil 2Würfelt mit zwei 6er-Würfeln.
Sagt die Summen beider Würfel laut an!
Monte Carlo SimuationEin stochastisches Verfahren Sehr häufig durchgeführte Zufallsexperimente Häufig genutzt zur Nachbildung komplexer Prozesse
Übung „Bereiche“Teilt euch in 3 Gruppen auf. Bestimmt einen Würfler, dieser darf die Würfel den anderen nicht zeigen.
Die SituationIhr nehmt Stichproben, um einen Bereich zu ermitteln. D.h. wir suchen die MIN und MAX Werte
Schritt 1
Würfelt 3 mal und schreibt die Summen beider Würfel untereinander
Schritt 2
Sortiert die Zahlen nach ihrer Größe. Mit welcher % liegt die vierte Zahl in diesem Bereich?
Schritt 3
Würfelt noch 8 mal und notiert eure Ergebnisse. Was ist MIN und MAX?
Schritt 4Vergleicht euer MIN und MAX mit den tatsächlichen Werten anhand der Würfel. Beobachtungen?
Vorhersagewahr-scheinlichkeit abhängig von Probenzahl
(Keine Duplikate, gleich verteilt, zufällige Proben)
Anzahl vorhandener Proben
Wahrscheinlichkeit, dass nächste Probe innerhalb des Bereichs
liegt
3 50 %
4 67 %5 75 %
6 80 %
7 83 %8 86 %
9 88 %
10 89 %11 90 %
12 91 %13 92 %
14 92 %
15 93 %16 93 %
17 94 %
18 94 %19 94 %
20 95 %
Die benötigte Stichprobengröße ist deutlich kleiner als wir denken
Wahrscheinlichkeit = 1- 1k −1
⎛⎝⎜
⎞⎠⎟
*100
–Troy Magennis
„Wenn ein Messwert sich über die Zeit ändert oder bei jeder Messung anders ist,
ist es eine Verteilung.“
VERTEILUNG (DISTRIBUTION)
Histogramm = visualisierte Verteilung
nach Karl Scotland, http://availagility.co.uk/lego-flow-game/
LEGO FLOW GAME
Euer Ziel
• Setzt so viele Lego-Figuren wie möglich anhand der Anleitung zusammen und liefert sie!
• In der Reihenfolge von 1 bis 24
• Arbeitet als Team zusammen
Workflow• Analysieren
• Beschaffen
• Bauen
• Prüfen
• Geliefert
Analysieren1. Finde die richtige Tür.
2. Nimm eine Karteikarte.
3. Schreibe die Nummer der Tür auf die Karte.
4. Lege die Tür auf die Karte, Instruktionen oben.
Analysieren
10
Zahl
Tür auf Karte
Beschaffen
1. Notiere die Zeit.
2. Finde das Beutelchen mit den passenden Teilen.
3. Hefte es mit der Büroklammer an die Tür.
Beschaffen
10Tüte auf Karte
1:201:20
Zeitstempel
BauenBaue die Lego-Figur entsprechend der Anleitung auf der Tür.
BauenBau es :)
Prüfen1. Überprüfe dass die Figur • GENAU dem Bild entspricht • ROBUST ist
2. Wenn ja, dann akzeptiere • Notiere die Zeit! • LIEFERE zum Marktplatz!
3. Wenn nicht, zurück an die entsprechende Station
Prüfen
?
10
1:20 3:50
Zweiter Zeit-Stempel
Manager1. Auf die Zeit achten
2. Auf die Prozesseinhaltung achten
3. Daten sammeln • Wie viele Figuren je Status • Zählen und alle 30s aufschreiben
Manager
00:30 01:00 01:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00
Analysis 2 1
Supply 3 2
Build 5 6
Accept 1 2
Done 2 4
Alle 30s zählen je Arbeitsstation
„Done“ sollte niemals weniger werden, muss
ansteigen
Flussbasierte Arbeit• Besprecht euch als Team.
• Markiert eure Arbeitsstationen
• Ihr arbeitet kontinuierlich, wir unterbrechen gelegentlich für Systemverbesserungen (Inspect & Adapt)
• Start!
5 min Timebox
Debrief Lego Flow• Beobachtungen? Überraschungen?
• Seid ihr „in den Fluss“ gekommen? Wann?
• Begriffe:
• Durchlaufzeit (lead time)
• WIP (Work In Progress)
• Durchsatz (throughput)
Little’s Law & Cumulative Flow
Avg. Lead Time
Avg. Delivery RateWIP
Poolof
ideas
Ready to
deliver
Delivery Rate(from the kanban system) System Lead Time
WIP=
Durchlaufzeit (Lead time)
= WIP Durchsatz
„Anforderung“ benutzt als
Epic / User Story / Feature / MMF
die „Abarbeitungseinheit“ im System
–Troy Magennis
„Prognosen sind Antworten auf Fragen zu Ereignissen, die noch nicht eingetreten sind.“
PROGNOSE (Forecast)
Frage 1: Wie lange dauert die Umsetzung von Anforderungen?
Durchlaufzeit, „Lead Time“• In Kanban: Die Zeitdauer, in der eine Anforderung von der
ersten limitierten Spalte („Zusagepunkt“) bis zur letzten Spalte „wandert“
• Lego Flow: Beginn „Liefern“ bis zur erfolgreichen Abnahme
• Differenz zwischen 2 Zeitstempeln
• In Software-Entwicklungs-Teams typischerweise Start der Implementierung bis „Done“ oder Release
• i.d.R. OHNE Analyse / Konzipierung
Beispiel: Durchlaufzeiten-Verteilung in Lego Flow Game Beobachtungen?
00:30:00$ 01:00:00$ 01:30:00$ 02:00:00$ 02:30:00$ 03:00:00$ 03:30:00$ 04:00:00$ 04:30:00$ 05:00:00$ 03:40:00$00:00:00$ 00:30:00$ 01:00:00$ 01:30:00$ 02:00:00$ 02:30:00$ 03:00:00$ 03:30:00$ 04:00:00$ 04:30:00$ 05:00:00$
SUMME$ 1$ 5$ 5$ 4$ 8$ 5$ 2$ 3$ 1$ 1$ 0$
0$
1$
2$
3$
4$
5$
6$
7$
8$
9$
Lego%Flow%Lead%Times%Histogramm%
Durchschnitt
50% dermöglichenErgebnisse
50% dermöglichenErgebnisse
50%
Beware of this animal!
Durchschnitt, Mittelwert Average, Mean
Frage• Wie sieht eine typische Verteilung von
Durchlaufzeiten in Software-Entwicklungsprojekten aus?
• Und wie bei IT Operations Teams?
Gleichbleibende Verteilung, nicht gleich groß!
Weibull Lead Time Verteilungen
Typische Verteilungen in SW-Projekten (Magennis)siehe auch Lead Time Forecasting Cards von Alexei Zheglov
Mode: an was sich Leute gut erinnern (Achtung!üblicherweise nur 18-28% Wahrscheinlichkeit!)
Median: zur kontinuierlichenÜberprüfung des
Vorhersage-Modells
Control Limit: für SLA’s
80% percentile: 4 von 5 Items dauern max. so lange -> Planung
Durchschnitt: üblicherweise über dem Median (bis zu 50% kleinerin Operations)
Weibull Lead Time Verteilungen
Typische Verteilungen in SW-Projekten (Magennis)siehe auch Lead Time Forecasting Cards von Alexei Zheglov
Voraussetzungen• Stabiles System:
• System ist „eingeschwungen“ - Linien im CFD weitestgehend parallel
• Wir glauben die Verteilung der Anforderungen bleibt in etwa stabil
• In der Verteilung gibt es nur eine „Spitze“ (Modus, engl. mode)
Praktische TippsDurchlaufzeit = Differenz zweier Zeitstempel
Auf physischen Boards: Datumsstempel benutzen
Excel: Histogramme über den Umweg von Klassen bauen: Intervalle bilden, ZÄHLENWENN()
Wert Percen(le10% 1:19
20% 1:46
30% 2:03
40% 2:12
50% 2:25
60% 2:44
70% 2:57
80% 3:24
90% 3:52
100% 4:51
1. Werte sortieren
1:22
2:21
3:05
4:51
3:45
2:29
1:12
3:38
1:55
2:58
2:56
0:57
1:12
1:22
1:41
1:55
2:03
2:11
2:13
2:21
2:29
2:41
2:56
2:58
3:05
3:38
3:45
4:10
4:51
Berechnung von „Percentile“ (Perzentil, Quantil)
=QUANTIL(Bereich;%Wert)
Beispiele
0"
1"
2"
3"
4"
5"
6"
7"
8"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Bugs%&%Stories%(addi0v)%
Bugs"
Durchlaufzeit (Tage von/bis)
Anza
hl Vo
rkom
men
0"
1"
2"
3"
4"
5"
6"
7"
8"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Bugs%&%Stories%(addi0v)%
Bugs"
Durchlaufzeit (Tage
Anza
hl
Beispiele
0"
1"
2"
3"
4"
5"
6"
7"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Anzahl'Vorko
mmen
'
Lead'Time'in'Tagen'
Bugs'
Bugs"
0"
1"
2"
3"
4"
5"
6"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Anzahl'Vorko
mmen
'
Lead'0me'in'Tagen'
Stories'
Stories"
Recap: Durchlaufzeiten-Prognose• Erlaubt die Prognose auf z.B. Story- oder Task-Ebene • Vorteile:
• Leicht zu sammelnde Messwerte • Nutzt historische Daten (komplett oder
Stichproben) • Folgt bekannten Verteilungsmustern
• Nutzen: Zusagen für einzelne Anforderungen. Termingerechter Start der Implementierung. Analyse (z.B. Ausreißer etc.). Basis für weitere Berechnungen.
Frage 2: Wann ist das erwartete Projektende?
Einfach!
Beispiel: Projektdauer
Projektdauer= Anzahl der Anforderungen(*)
Durchsatz
Wir haben Daten über den Durchsatz unseres Teams „P“:7, 8, 2, 11, 7, 12 Anforderungen pro Woche. Wann werden die verbleibenden 100 Anforderungen umgesetzt sein?
Projektdauer =100 Anforderungen
7 Anforderungen / Woche
Projektdauer = 100 Wochen / 7
Projektdauer = 15 Wochen
16,70% 12
33,40% 11
50,10% 8
66,80% 7
83,50% 7
100,20% 2
Achtung! Umgekehrte Reihenfolge
(*) Batch Size
Durchsatz-Prognose mit Monte Carlo Simulation
basierend auf den Daten der vorherigen Folie
Praktische TippsTrick: Durchsatz aus z.B. Jira:=KALENDERWOCHE(DateClosed)dann pivotieren oder Zählenwenn()
Troy Magennis’ Sheet für Monte Carlo Throughput Forecasting:
http://focusedobjective.com/free-tools-resources/
Phase im Projekt beachten -> S-Curve
S-CurveQuelle: Project Planning using Little's Law (Dimitar Bakardzhiev)
Ausblick Weiterführende Fragen
Wieviel Kapazität für welchen Arbeitstyp?
Wie hoch ist der Durchsatz?
Auswirkungen von Verbesserungen der Durchlaufzeit
Wie viele Teams brauchen wir?
Was wir benötigen1. Lead Time Verteilung:
• Ist bekannt
• Single Mode - in Klassen unterteilt (s.u.)
• Wir glauben die Verteilung bleibt stabil
2. Anforderungen sind identifiziert und klassifiziert
• längerfristig stabile Durchschnittswerte! • Voraussetzungen:
• Durchschnittliche Output-Rate = durchschnittliche Input-Rate • Alle angefangene Arbeit wird schließlich beendet und verlässt das System • Die Menge angefangener Arbeit sollte zu Beginn und Ende des gewählten
Zeitintervalls etwa gleich sein • Die durchschnittliche Menge angefangener Arbeit (WIP) ist stabil • In der Berechnung müssen konsistente Einheiten genutzt werden
• siehe auch „Little’s Flaw“ (Dave Vacanti)
Little’s Law
Lieferrate = WIPDurchlaufzeit throughput = WIP
lead time
Mit auf den Weg….
Brauche ich dazu ein Kanban-System?• Nein, all diese Techniken können auch von agilen oder
„klassischen“ Teams angewendet werden.
• Aber: Ein Kanban-System hilft, die Vorhersagegenauigkeit (predictability) zu verbessern:
• Verschiedene Arbeitstypen / Serviceklassen, um mehrere Modes zu vermeiden
• Ist Hilfsmittel für kontinuierliche Verbesserung (Zuverlässigkeit, Durchsatz, etc.)
–George E. P. Box
„Essentially, all models are wrong, but some are useful“
Kontinuierliche Anpassung, aktives Steuern
Prognose erstellen
Modell aufstellen / anpassen
Kontinuierliche Überprüfung der Gültigkeit des Modells mit Anpassung der Vorhersage— ermöglicht aktives Steuern!
Überprüfung der Hypothesen
historischeDaten
Danke für eure Aufmerksamkeit!
• Susanne [email protected]
• Twitter @projectzone
• http://flow.hamburg
Credits und Referenzen• Basiert auf der Arbeit von Troy Magennis, David J. Anderson, Alexei Zheglov,
and Dan Brown in diesem Bereich. Siehe auch deren Blogs.
• German Tanks: http://www.spiegel.de/wissenschaft/mensch/rechentrick-der-alliierten-wie-seriennummern-die-nazi-industrie-verrieten-a-728211.html
• Für mehr:
• Twitter: #noestimates
• noestimatesbook.com
• Blogs of the above
• Limited WIP Society
Bilder• Würfel: https://www.flickr.com/photos/dskley/6196133034 • fliegende Würfel: https://www.flickr.com/photos/dskley/6195620885 • Pause: <a href="https://www.flickr.com/photos/finklez/3059185823"
title="Pause - השהיה by Eran Finkle, on Flickr"><img src="https://farm4.staticflickr.com/3190/3059185823_ce8570bdd2_s.jpg" width="75" height="75" alt="Pause - השהיה“></a>
• Wall: https://www.flickr.com/photos/dg_pics/3937990893/ • Umbrella: https://www.flickr.com/photos/dskley/9666364180 • Fragezeichen: https://www.flickr.com/photos/eleaf/2536358399 • Mind the gap: https://www.flickr.com/photos/simone_brunozzi/2643200238/ • Easy: https://www.flickr.com/photos/catharticflux/2484317019/ • Monkey bento: https://www.flickr.com/photos/buzzymelibee/8598689804
Backup
FlusseffizienzFlusseffizienz = Arbeitszeit
(Arbeitszeit +Wartezeit)
Story&/&Feature&Incep0on&5&Days&
Wai0ng&in&Backlog&25&days&
System&Regression&Tes0ng&&&Staging&&5&Days&
Wai0ng&for&Release&Window&5&Days&
“Ac0ve&Development”&30&days&To
tal&Cycle&Tim
e&
Pa.ern:&Total&Cycle&Time&In Software- Entwicklungs- Projekten liegt die Flusseffizienz in der Regel bei max. 15%-20%.
