Quantitatives Management von Entwicklungsvorhaben

Coach/Trainer für produktive WissensarbeiterMatthias Bohlen

[email protected]

Quantitatives Management von Entwicklungsvorhaben

mailto:[email protected]



Ziel eines Projektes

Geld verdienen! Was heißt das?

Entwicklungsprojekt Wartungsprojekt

Zum Verkauf oder zur Vermietung

•Lizenzen

•Mieteinnahmen

•Wartungsgebühren

Für den internen Bedarf

•Ermöglichen neuer Geschäftsmodelle

•Einsparungen durch Automatisierung

•Umlage aus anderen Unternehmens-bereichen

2


Interessen der Beteiligten

Rolle Interesse

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

ProjektleiterVoraussagbarkeit

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

Softwareprojekt

Analyse Design Coding ProduktionTest

oE oE oE oE oE

I I I I

T

Ideen,Wissen Wert

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

Rohstoff kaufen, verarbeiten, als Wert verkaufen

9


Messgrößen genau definiert

Kürzel Benennung Definition

T Durchsatz ("throughput")

Geld, das die Fabrik durch Verkäufe generiert

IInventar

("inventory")

Geld, das die Fabrik investiert hat, um Dinge zu kaufen, die sie

verarbeiten und verkaufen will

oE

Operative Ausgaben ("operative expenses")

Geld, das die Fabrik ausgibt, um aus Inventar Durchsatz zu

machen

Siehe E.M.Goldratt: The Goal10


Return on Investment

RoI steigern heißt:

• Durchsatz (T) steigern

• Operative Kosten (oE) senken

• Inventar (I) klein halten

RoI = ( T - oE ) / I * 100%

Beispiel:1 Mio. eingenommen (T), 0,5 Mio. ausgegeben (oE),0,2 Mio. in Inventar investiert, ergibt RoI = 250%

11

Alistair Cockburn:Ein Softwareprojekt ist eine Fabrik, deren Rohstoff

und Inventar aus unvalidierten Entscheidungen besteht.


Inventar in der Wissensfabrik

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 VorgehenInvestiere 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 einsetzenI = 10.000

oE = 10.000 + 20.000 + 20.000 + 10.000 = 60.000

T = 75.000

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


DurchsatzDie am schwierigsten

zu ermittelnde Größe.

Projekttyp Mögliche Fragen

Externes Projekt,für zahlende Kunden

Vertrieb an Kunden: Wie viel würdet Ihr für neues Feature F bezahlen?

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

WartungsprojektKönnen wir die Wartungspauschale auf

einzelne Features umlegen?

17


Durchsatz-Schätzung (1)

für Projekte mit zahlenden Kunden

Feature-TypenCommodity = Feature, das alle anderen

auch habenDifferentiator = Feature, das nur einer

hatSpoiler = Feature, das der Konkurrenz

das Leben schwermachtNice 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.00019


(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öglichkeitenDie 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


100%50%

1%

Zeit

Wert

Wertschöpfung vs. LosgrößeWas 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.


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


Losgröße

Kostenpro

Einheit

OptimaleLosgröße

Gesamtkosten= Lagerkosten + Rüstkosten

Lagerkosten(z.B. schwere Dokumente)

Rüstkosten(z.B. Refactoring)

Beste Losgröße ermitteln"Einheit" = Feature, Komponente, Klasse, je nach Workflow-Schritt


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

http://bit.ly/cmx5Uu

http://bit.ly/cmx5Uu


Kanban-Tafel

Workflow-Zustände

Arbeitspakete

CFD

WIP-Limit

37

Entwicklung der Cycle Time nach Projektfortschritt

0

50

100

150

200

250

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

Datum

Cycl

e T

ime (

Tag

e)

alle Features

Linear (alle Features)


Beispiel: Cycle Time

38

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

0

50

100

150

200

250

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

Cycl

e T

ime (

Tag

e)

1 FP

2 FP

3 FP

5 FP

8 FP

13 FP

20 FP

40 FP


Genauer: Cycle Time / Komplexität

39

0

50

100

150

200

250

F-26

F-27

F-23

F-63

F-12

F-9

F-64

F-10

F-114

F-108

F-109

F-132

F-19

F-18

F-111

F-153

F-124

F-88

F-33

F-182

F-154

F-122

F-29

F-161

F-160

F-125

F-105

F-202

F-212

F-219

Features

Tage

reviewed

in review

developed

in development

analyzed

in analysis


In der Retrospektive...

40

Welchen Anteil an der Cycle Time

hat welcher Workflowschritt?


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 BlickName Bedeutung Einheit Charakter

Work in progress

Angefangene, unfertige Arbeit

wie Inventar vorlaufend

Lead TimeZeit vom Stellen einer

Anforderung bis zu deren Erfüllung

Tage nachlaufend

T Durchsatz € nachlaufend

I Inventar Story Points,Use Cases, etc.

vorlaufend

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?

[email protected]

http://www.mbohlen.de/

+49 170 772 8545

46



http://www.mbohlen.de

http://www.mbohlen.de

Quantitatives Management von Entwicklungsvorhaben

Business

Transcript of Quantitatives Management von Entwicklungsvorhaben