Aufwandsschätzungen sind in der Softwareentwicklung ein Problem – Organisationen, die Software entwickeln, fragen immer wieder, wie sie ihre geschätzten Termine besser definieren und einhalten können. Ironischerweise geht das am besten, wenn Sie Ihren Prozess so umstellen, dass Schätzen überflüssig wird! Matthias Bohlen zeigt in diesem Talk, wie Sie von Blei (Personentage) zu Gold (gar keine Schätzungen mehr) kommen.

1. Matthias Bohlen
Liefern, schon vor dem Schätzen
+49 170 772 8545
mbohlen@mbohlen.de
http://www.mbohlen.de
@mbohlende

2. Kürzlich im Projekt…
Vertrags-
system
Rechnungs-
systemBuchungen
jung, noch änderbar 30 Jahre alt, nicht mehr änderbar

3. Anforderungen
1. Schick dem Rechnungssystem pro
Vertragsänderung eine Buchung
2. Fasse redundante Buchungen für denselben
Zeitraum zusammen zu einer einzigen
3. Mache das auch rückwirkend und mit Storni
(zweidimensional historisiert)
4. Identifiziere jede Buchung eindeutig, mit einem
nur 5-stelligen Code, so dass Du sie bei einem
Storno damit identifizieren kannst

4. Was passierte…
(1) wäre einfache Transformation gewesen
(2) brauchte einen üblichen Algorithmus
(3) Historisierung machte die Sache
kompliziert
(4) Eindeutigkeit mit nur 5 Stellen
warf uns völlig aus dem geschätzten
Zeitplan

5. Jedoch…
• Am Ende hatten wir wieder übersichtlichen
Code, der alles Geforderte auch tat
• Wir griffen uns an den Kopf und fragten
uns: Warum wir es denn nicht gleich so
gemacht, und zwar innerhalb von zwei
Wochen?

6. Was Entwicklung wirklich ist
• Rezept finden: Eine Woche, bis es richtig gut
schmeckt, gut aussieht und wiederholbar ist
• Dabei 15 Fehlversuche, die eben nicht gut
schmecken
• Kochen: Eine halbe Stunde bis zum
wiederholbar gut schmeckenden Gericht

7. Uns fiel die Kultur auf…
traditionelle Kultur kommende Kultur
Einstellung zukunftsorientiert,
angstbesetzt
am Schluss des Vortrags
Leistung Projekte,
Umfang-orientiert
Management deterministisch
Berichtsmedien Gantt-Chart,
Burndown-Chart
Aufgaben Manager weist sie zu
Verantwortung Kunde bestellt/befiehlt,
Team liefert
Haupt-Interaktion verhandeln

8. Legitime Projektleiterfragen
Termin: Wann können wir liefern?
Ressourcen: Wie viele Leute brauchen wir?
Kosten: Wie teuer wird das alles?
Fortschritt: Wie weit sind wir
und wie lange dauert's noch?

9. Ein Weg zur Weisheit
Blei:
Aufwand (PT) schätzen
und Rest-Aufwand verfolgen

10. PT schätzen und verfolgen
Schätzen PT pro Paket, dann PT über alle Pakete summieren
Messen Ist-PT total, Ist-PT pro Paket
Terminfrage T = PT / P
Ressourcenfrage P = PT / T
Kostenfrage EUR = EUR/PT * PT
Fortschrittsfrage % fertig = Ist-PT / (Ist-PT + Rest-PT)
Vorteile jeder glaubt, er verstünde das
Nachteile Wert eines Pakets wird nicht bemessen.
Komplexität eines Pakets wird nicht bemessen.
Team lernt nichts über seine Fähigkeit.
Schätzungen sind ungenau, besonders bei großen
Paketen.
"% fertig" ist schlechte Metrik, weil Ist-PT und geschätzte
Rest-PT verschiedene "Währungen" sind.

11. Ein Weg zur Weisheit
Bronze:
Story-Points schätzen,
Velocity messen,
Rest-Story-Points verfolgen

12. Story Points schätzen und verfolgen
Schätzen SP pro Paket, dann SP über alle Pakete summieren
Messen Velocity = SP der fertigen Pakete pro Iteration
Terminfrage T = (SPRest / Velocity) * (Tage / Iteration)
Ressourcenfrage Pneu = Pjetzt * (Velocityneu / Velocityjetzt)
Kostenfrage EUR = EUR/Iteration * Iterationen
Fortschrittsfrage % fertig = SPIst / (SPIst + SPRest)
Vorteile Komplexität wird bemessen
% fertig hat eine Chance, zu stimmen, weil SP immer SP
ist, grundsätzlich geschätzt.
Team lernt über seine Fähigkeit, Komplexität zu liefern.
Nachteile Schätzungen sind ungenau, besonders bei großen Paketen.
Velocity schwankt stark.

13. Die Emotionen schlagen hoch…
1.Sprint:Velocity 32 ➜ gut, OK…
2.Sprint:Velocity 45 ➜ prima!
3.Sprint:Velocity 57 ➜ wow, wir machen es richtig!
4.Sprint:Velocity 31 ➜ Aufregung bis ins Management
5.Sprint:Velocity 30 ➜ Tristesse,Vertrauensverlust
6.Sprint:Velocity 60 ➜ Party, Pizza für alle!
7.Sprint:Velocity 45 ➜ Schulterzucken,Angst

14. Zufall oder erkennbare Ursache?
1. Sprint: Velocity 32
2. Sprint: Velocity 45
3. Sprint: Velocity 57
4. Sprint: Velocity 31
5. Sprint: Velocity 30
6. Sprint: Velocity 60
7. Sprint: Velocity 45
Velocity
0
15
30
45
60
Sprint
1 2 3 4 5 6 7

15. Erschreckend?
• Die Hälfte Eurer Sprints müssen
"fehlschlagen", sonst macht Ihr etwas falsch!
• Frage:Wollt Ihr in einem System leben, in
dem das so sein muss?

16. Ein Weg zur Weisheit
Silber:
Story-Points schätzen,
Zykluszeit und Durchsatz messen,
Rest-Pakete verfolgen

17. Story Points, Zykluszeit, Durchsatz
Schätzen SP pro Paket
Messen Zykluszeit = Zeit für Durchlauf eines Paketes, eingeteilt
in SP-Kategorien
Durchsatz = Anzahl fertige Pakete pro Woche
Terminfrage Trestliche Pakete = PaketeRest / Durchsatz
Tein Paket = Zykluszeit ( SP-Kategorie(Paket) )
Ressourcenfrage Pneu = Pjetzt * (Durchsatzneu / Durchsatzjetzt)
Kostenfrage EUR = EUR/Woche * Wochen
Fortschrittsfrage % fertig = PaketeIst / (PaketeIst + PaketeRest)
Vorteile % fertig stimmt, weil reine Ist-Betrachtung.
Wert (fertige Pakete) steht im Vordergrund.
Team lernt über seine Fähigkeit, Wert zu liefern.
Genauigkeit der Schätzungen nicht mehr wichtig.
Nachteile Durchsatz schwankt stark.

18. Ein Weg zur Weisheit
Gold:
Ein-Wochen-Pakete bilden,
Zykluszeit und Durchsatz messen,
Rest-Pakete verfolgen,
Story-Points vergessen

19. Machbarkeit, Zykluszeit, Durchsatz
Schätzen Ist dieses Paket in einer Woche machbar?
Messen Zykluszeit = Zeit für Durchlauf eines Paketes
Durchsatz = Anzahl fertige Pakete pro Woche
Terminfrage Tausgewählte Pakete = Paketeausgewählt / Durchsatz
Tein Paket = durchschnittliche Zykluszeit
Ressourcenfrage Pneu = Pjetzt * (Durchsatzneu / Durchsatzjetzt)
Kostenfrage EUR = EUR/Woche * Wochen
Fortschrittsfrage % fertig = uninteressant
Vorteile % fertig wird unnötig, es zählt Service statt Scope.
Wert (fertige Pakete) steht im Vordergrund.
Stakeholder steuern "gut geölte Fabrik".
Schätzungen sind einfach bis unnötig.
Wenig Schwankung = Verlässliche Prognosen.
Nachteile Pakete herunterzubrechen macht Mühe

20. Wann kann
Ihr Team
liefern?

21. Einzelnes Ticket
Zykluszeit = 11 Tage
Place order
3857
Started: Nov. 12
Finished: Nov. 23

22. Messen und darstellen
Häufigkeitsverteilung der Zykluszeit
Wieoftaufgetreten?
0,0
2,5
5,0
7,5
10,0
Zykluszeit (Tage)
1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
57%
84%

23. Mit 84%
Wahrscheinlichkeit liefern
wir innerhalb von
30 Tagen!

24. Eine Frage der Kultur
traditionelle Kultur kommende Kultur
Einstellung zukunftsorientiert,
angstbesetzt
gegenwartsorientiert,
selbstbewusst
Leistung Projekte,
Umfang-orientiert
Services, Wert-orientiert
Management deterministisch statistisch
Berichtsmedien Gantt-Chart,
Burndown-Chart
Zykluszeit-Histogramm
Aufgaben Manager weist sie zu Team zieht sie sich
Verantwortung Kunde bestellt/befiehlt,
Team liefert
Team stellt Fähigkeit,
Kunde überlegt, wie er sie nutzt
Haupt-Interaktion verhandeln zusammenarbeiten

25. Mehr lesen und erfahren?
Mehr auf http://mbohlen.de !
Telefon: +49 170 772 8545
E-Mail: mbohlen@mbohlen.de
Wenn Sie diese Kultur in Ihrem Unternehmen
etablieren möchten, geben Sie mir Ihre Karte.
Wir sprechen dann miteinander.