Quantitatives Management von Entwicklungsvorhaben

Matthias Bohlen Coach/Trainer für produktive Wissensarbeiter

mbohlen@mbohlen.de

Quantitatives Management
von Entwicklungsvorhaben


Ziel eines Projektes

Geld verdienen! Was heißt das?
Entwicklungsprojekt Wartungsprojekt

Zum Verkauf •Lizenzen •Wartungsgebühren
oder zur
Vermietung
•Mieteinnahmen

Für den •Ermöglichen neuer •Umlage aus anderen
internen Geschäftsmodelle Unternehmens-
Bedarf bereichen
•Einsparungen durch
Automatisierung

2


Interessen der Beteiligten
Rolle Interesse

IT-Vorstand (CIO) und
Return on Investment
oberes Management

Voraussagbarkeit
Projektleiter
Verlässlichkeit

Entwicklerteam Gleich bleibende Schlagzahl

3


Über CIOs macht man sich
lustig...

4


...doch CIOs stellen valide
Fragen:

Wo sollte ich das Kapital der
Anteilseigner einsetzen?

In welches Projekt sollte ich
investieren?

Welches wird sich lohnen, welches
nicht?
5


Projektleiter: Voraussagbarkeit

Welche Termine kann ich
zusagen?

Wie viele Features pro
Release?

Können wir die Termine
halten und genügend
Features lauffähig
bereitstellen?
6


Entwickler: Entspanntes Arbeiten

Wieviel Arbeit müssen wir
bis wann leisten?

Ist das zu schaffen?

Müssen wir immer wieder
durch Stressphasen
hindurch oder geht das
gleichmäßig schnell?
7


Hilfsmittel: Messgrößen

einfach
relevant und aussagekräftig

selbst-erzeugend
voraussagend statt hinterherhinkend

(nach Don Reinertsen: "Managing the Design Factory")

8


Das Projekt als Wissensfabrik
Rohstoff kaufen, verarbeiten, als Wert verkaufen

Softwareprojekt
T

Ideen,
Wissen Wert

I I I I
Analyse Design Coding Test Produktion

oE oE oE oE oE

I = inventory (Inventar)
oE = operational expense (operative Ausgaben)
T = throughput (Durchsatz)

9


Messgrößen genau definiert
Kürzel Benennung Definition

Durchsatz Geld, das die Fabrik durch Verkäufe
T
("throughput") generiert

Geld, das die Fabrik investiert hat,
Inventar
I um Dinge zu kaufen, die sie
("inventory")
verarbeiten und verkaufen will

Operative
Geld, das die Fabrik ausgibt, um
Ausgaben
oE aus Inventar Durchsatz zu
("operative
machen
expenses")

Siehe E.M.Goldratt: The Goal
10


Return on Investment
RoI = ( T - oE ) / I * 100%
Beispiel:
1 Mio. eingenommen (T), 0,5 Mio. ausgegeben (oE),
0,2 Mio. in Inventar investiert, ergibt RoI = 250%

RoI steigern heißt:
• Durchsatz (T) steigern
• Operative Kosten (oE) senken
• Inventar (I) klein halten
11


Inventar in der Wissensfabrik
Alistair Cockburn:
Ein Softwareprojekt ist eine Fabrik, deren Rohstoff
und Inventar aus unvalidierten Entscheidungen
besteht.

Inventar:
- Ideen, was man tun könnte
- Konzepte, die noch nicht
umgesetzt sind
- Code, der noch nicht in
Produktion ist
- Modelle, die nicht mehr mit
dem Code überein-
stimmen

12


Wie zählt man Inventar?
Eine Einheit Inventar = Eine Idee für eine
Funktion, die der Kunde wertschätzt,
beschrieben in einem Format, das Software-
Entwickler verstehen und benutzen können.

Life cycle-Modell Einheit für Inventar

RUP Use Case

XP Story Point

FDD Feature

13


Investment vs. Inventar
Eingabe für das Projekt sind Ideen
Ideen zu analysieren erfordert Investment
Durch dieses Investment werden Ideen zu
Inventar (Use Cases, Stories, Features,
etc.).
Dieses Inventar wandert durch das
Projekt, verwandelt sich in Code, Tests,
… zum Schluss in Durchsatz (Kunde
validiert, indem er bezahlt).
Verwandlung von Inventar kostet Geld (oE).
14


Operative Ausgaben (oE)
Verschiedene Arten
•Gehälter der Mitarbeiter
•Miete, Strom, Wasser, Papier, …
•Abschreibungskosten auf Inventar
Was ist Abschreibung?
•Schreibe ein Dokument für 60.000 EUR.
•Dann hast Du Inventar im Wert von 60.000 EUR.
•Nach drei Monaten (60 Arbeitstagen) weiß keiner mehr,
was mit dem Dokument gemeint war.
•Das Inventar hat dann den Wert 0 EUR.
•Das Dokument trägt ab Fertigstellung mit 1.000 EUR
pro Tag zu den operativen Kosten des Projektes bei.
15


Agilität gegen Abschreibung
Agiles Vorgehen
Investiere nur 10.000 EUR in Analyse.
Gib sofort 10.000 für Code und 20.000 für Tests aus.
Bringe alles für 20.000 in Produktion.
Kunden zahlen 75.000 für neues Feature.
Das Investment von 10.000 verfällt auf 0.

In die Formeln einsetzen
I = 10.000
oE = 10.000 + 20.000 + 20.000 + 10.000 = 60.000
T = 75.000

Also: RoI = (75 - 60) / 10 = 150%
16


Durchsatz
Die am schwierigsten
zu ermittelnde
Größe.

Projekttyp Mögliche Fragen
Externes Projekt, Vertrieb an Kunden: Wie viel würdet Ihr
für zahlende Kunden für neues Feature F bezahlen?

Wie viel könnten wir durch neues
Internes Projekt
Feature F einsparen / gewinnen?

Können wir die Wartungspauschale auf
Wartungsprojekt
einzelne Features umlegen?

17


Durchsatz-Schätzung (1)

für Projekte mit zahlenden Kunden
Feature-Typen
Commodity = Feature, das alle anderen
auch haben
Differentiator = Feature, das nur einer
hat
Spoiler = Feature, das der Konkurrenz
das Leben schwermacht
Nice to have = naja, "ganz nett"
18


Durchsatz-Schätzung (2)
Commodity = 4 Punkte
Differentiator = 3 Punkte
Spoiler = 2 Punkte
Nice to have = 1 Punkt

Alle Punkte des nächsten Releases summieren,
Ergebnis sei z.B. 100
Erwartete Lizenzgebühren für nächstes Release ermitteln,
z.B. 20 Mio. EUR
Damit ist jeder Punkt = 20 Mio. / 100 = 200.000 wert.
Also ist der erwartete Durchsatz je Feature:
Commodity = 800.000, Differentiator = 600.000,
Spoiler = 400.000, Nice to have = 200.000
19


(T, I, oE) == wirklich alles klar?

Heute heißt es noch in vielen Teams:

RoI = (Unbekannt(T) – schwer zu
schätzen(oE)) / nicht gemessen (I)

Ergebnis: nebelhaft! --> Was tun?

20


Jetzt: Projekte steuern

Mit T, oE und I beobachten

Mit angepasster Strategie steuern

Wie geht das?

21


Alle glücklich machen
Den Kunden:
Handeln Sie voraussagbar !

Ihre Entwickler:
Lasten Sie sie gleichmäßig aus !

Den CIO:
Messen und optimieren Sie den RoI !

22


Voraussagbarkeit

Zwei Möglichkeiten
Die Schlechte: Machen Sie Voraussagen
und versuchen Sie sie mit Gewalt (z.B.
durch Überstunden) einzuhalten.
Die Gute: Messen Sie, wie viel Sie leisten
können, ermitteln Sie Mittelwert und
Varianz, ziehen Sie einen Sicherheits-
puffer ein und versprechen den Rest
als Voraussage, die Sie kontinuierlich
einhalten können.
23


Wertschöpfung vs. Losgröße
Wert Was findet Ihr Kunde am besten?
100% = der gesamte Wert entsteht am Ende des Projektes.
50% = Kunde bekommt die Hälfte nach der halben Zeit.
1% = Kunde bekommt ständig ein bisschen mehr Wert.

1%

50% 100%

Zeit


Welche Losgröße ist die beste?
Möglichst klein
+ Interessant für den Kunden
-- Aufwand für Architektur steigt

Möglichst groß
+ Kosten pro Einheit sinken
-- Uninteressant für Kunde
-- Aufwand für Spezifikation steigt
-- Wahrscheinlichkeit für Fehler steigt
25


Beste Losgröße ermitteln
Kosten "Einheit" = Feature, Komponente, Klasse, je nach Workflow-Schritt
pro
Einheit
Gesamtkosten
= Lagerkosten + Rüstkosten

Lagerkosten
(z.B. schwere Dokumente)

Rüstkosten
(z.B. Refactoring)

Losgröße
Optimale
Losgröße


Beste Losgröße
Nicht mehr als Ihr
Team in 2-3 Wochen
umsetzen kann!

Erfahrung aus vielen Projekten
der letzten 15 Jahre.

27


Buchführungsarten

Kostenbuchführung
"Wie viel Geld geben wir aus?"
--> hier steht oE im Vordergrund

Durchsatzbuchführung
"Wieviel Geld nehmen wir (nicht) ein?"
--> hier dominiert T die Betrachtung

28


Durchsatz und Engpass
Zwei Definitionen von "Engpass":
Mensch, Maschine oder Verfahren,
dessen Durchsatz kleiner ist als die
Nachfrage des Marktes
Ressource, deren Durchsatz den
Durchsatz des Gesamtprojekts
wesentlich bestimmt

Wie teuer ist z.B. Ihr Test-Team?

29


Test-Team: Kosten pro Stunde
Kostet es so viel wie die Summe der
Stundenlöhne (oE) seiner Mitglieder?
Oder kostet es so viel wie der
entgangene Durchsatz (T) des
gesamten Projektes, wenn es wegen
Serverausfall eine Stunde lang nicht
arbeiten kann?
20 Mio. Lizenzeinnahmen, geteilt
durch 800 Stunden = 25.000 € / h
30


Der Fall Off-Shore (im alten Sinne)
Optimierung von oE durch
Verlagerung in Länder mit geringem
Lohn-Niveau (China, Indien, …)
T sinkt aufgrund von
Kommunikationsproblemen
I steigt, weil man durch "gründliche"
Spezifikation gegensteuern will

Pech gehabt: RoI sinkt!
31


Optimieren Sie ganzheitlich
Behalten Sie alle drei
Variablen im Blick:
T, I und oE

Ihre Controller sind an oE
gewöhnt, deshalb:
Achten Sie als Manager
verstärkt auf T und I !

32


Arbeitsfähig werden
Team muss Software entwickeln und
freigeben können
Entwicklung muss schnell gehen
--> T wird groß
Qualität muss hoch sein
--> Geht umso leichter, je kleiner I ist
--> oE für Nacharbeit wird klein

33


Voraussagbarkeit erreichen
Indikator: Lead Time
= Zeit vom Stellen einer neuen
Anforderung bis zu deren Erfüllung
Schätzen Sie die Komplexität von
Anforderungen (S, M, L, XL)
Messen Sie die mittlere Lead Time in
jeder Kategorie
Verringern Sie die Varianz der Lead Time
Wenn diese klein wird, haben Sie einen
voraussagbaren Prozess erreicht.
34


Inventar verringern
Möglichst wenige gleichzeitige Aufgaben
(WIP = work in progress) für Ihr Team
Jeder arbeitet nur an einer Aufgabe
Zuerst Altes fertigstellen, dann Neues
beginnen
Pull-Prinzip anwenden
"Ich hole mir Arbeit anstatt sie zugewiesen
zu bekommen"
...oder gleich Kanban-System einführen!
35


A propos Kanban-System...
<plug kind="shameless">
Kanban-Workshop am 10. März
in Köln --> http://bit.ly/cmx5Uu
</plug>

36


Kanban-Tafel
Workflow-Zustände
Arbeitspakete
CFD

WIP-Limit

37


Beispiel: Cycle Time
Entwicklung der Cycle Time nach Projektfortschritt

250

200
Cycle Time (Tage)

150
alle Features
Linear (alle Features)
100

50

0
Feb 10 Mär 10 Mai 10 Jul 10 Aug 10 Okt 10 Nov 10 Jan 11
Datum

38


Genauer: Cycle Time / Komplexität
Cycle Time in Abhängigkeit von Projektfortschritt und Feature-Komplexität (in FP)

250

200 1 FP

2 FP
Cycle Time (Tage)

3 FP
150
5 FP

8 FP

100 13 FP

20 FP

40 FP
50

0
Feb 10 Mär 10 Mai 10 Jul 10 Aug 10 Okt 10 Nov 10 Jan 11
Start-Datum der Entwicklung des Features

39


In der Retrospektive...
250

200
Welchen Anteil an der Cycle Time
hat welcher Workflowschritt? reviewed

in review

150
developed

Tage in development

analyzed
100

in analysis

50

0
F-26

F-27

F-23

F-63

F-12

F-9

F-64

F-10

F-19

F-18

F-88

F-33

F-29
F-114

F-108

F-109

F-132

F-111

F-153

F-124

F-182

F-154

F-122

F-161

F-160

F-125

F-105

F-202

F-212

F-219
Features

40


Maßnahmen aus Retrospektive

Zu lange in developed oder in Review
➯ Wir reduzieren WIP von 45 FP auf 35 FP
➯ Wir unterbrechen Entwicklung für Reviews
➯ Wir machen öfters 10-Minuten-Reviews

Features ab 13 FP geraten außer Kontrolle
➯ Wir splitten auf maximal 8 FP

41


Alle Indikatoren auf einen Blick
Name Bedeutung Einheit Charakter

Work in Angefangene,
wie Inventar vorlaufend
progress unfertige Arbeit

Zeit vom Stellen einer
Lead Time Anforderung bis zu Tage nachlaufend
deren Erfüllung

T Durchsatz € nachlaufend

Story Points,
I Inventar vorlaufend
Use Cases, etc.

oE Kosten € nahezu fix

42


Die Strategie
1. Team arbeitsfähig machen
2. Voraussagbarkeit erreichen
3. Inventar verringern durch Einsatz
eines WIP-limitierenden Pull-Systems
(z.B. Kanban)
4. Engpässe finden und auflösen
5. Alte Regeln prüfen und aufheben
6. Zurück zu Schritt 1

43


Literatur (1)
M. Bohlen: Softwareprojekte quantitativ managen,
OBJEKTspektrum Nr. 4, Juli/August 2010

D.J. Anderson: Agile Management for Software
Development: Applying the Theory of Constraints
for Business Results, Prentice Hall, 2003
D.J. Anderson: Kanban – Successful Evolutionary
Change for Your Technology Business, Blue Hole
Press, 2010

A. Cockburn, Effektive Softwareentwicklung im 21.
Jahrhundert: Das neue Gesicht des Software-
Engineering, in: OBJEKTspektrum 06/2008


Literatur (2)
W.E. Deming, The New Economics for Industry,
Government, Education, MIT Press, Oktober
2000

E.M. Goldratt, J. Cox, D. Whitford, The Goal: A
Process of Ongoing Improvement, 3rd revised
Edition, North River Press Inc., 2004

D. Reinertsen, The Principles of Product
Development Flow, Celeritas Publishing, 2009


Fragen?

mbohlen@mbohlen.de
http://www.mbohlen.de/
+49 170 772 8545

46

Quantitatives Management von Entwicklungsvorhaben

Weitere ähnliche Inhalte

Andere mochten auch

Ähnlich wie Quantitatives Management von Entwicklungsvorhaben

Mehr von Matthias Bohlen

Quantitatives Management von Entwicklungsvorhaben