mbohlen@mbohlen.de Quantitatives Management von Entwicklungsvorhaben 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 Unternehmensbereichen 2
Interessen der Beteiligten Rolle Interesse IT-Vorstand (CIO) und oberes Management Return on Investment Projektleiter Voraussagbarkeit 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 T Durchsatz ("throughput") Geld, das die Fabrik durch Verkäufe generiert I oe Inventar ("inventory") Operative Ausgaben ("operative expenses") Geld, das die Fabrik investiert hat, um Dinge zu kaufen, die sie verarbeiten und verkaufen will Geld, das die Fabrik ausgibt, um aus Inventar Durchsatz zu machen 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 übereinstimmen 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 RUP XP FDD Einheit für Inventar Use Case Story Point 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 schwersten zu ermittelnde Größe. Projekttyp Externes Projekt, für zahlende Kunden Mögliche Fragen 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? Wartungsprojekt Können wir die Wartungspauschale auf 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 besser ist als das, was die Konkurrenz hat 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 Sicherheitspuffer 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 pro Einheit "Einheit" = Feature, Komponente, Klasse, je nach Workflow-Schritt Gesamtkosten = Lagerkosten + Rüstkosten Lagerkosten (z.b. schwere Dokumente) Rüstkosten (z.b. Refactoring) Optimale Losgröße 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
Engpässe beseitigen Engpass finden Alles dem Engpass unterordnen Engpass beschützen und voll ausnutzen Engpass auflösen unnötige Arbeit abnehmen gleichartige Kapazität hinzufügen "Spülen und wiederholen" Achtung: Flexibel bleiben! 37 Alle Indikatoren auf einen Blick Name Bedeutung Einheit Charakter Work in progress Angefangene, unfertige Arbeit wie Inventar vorlaufend Lead Time Zeit 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 38
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 39 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 P. Kruchten, The Rational UnifiedProcess. An Introduction, Addison-WesleyLongman, 2003 D. Reinertsen, Managing the DesignFactory: A Product Developers Tool Kit, FreePress, 1997 Fragen? mbohlen@mbohlen.de http://www.mbohlen.de/ +49 170 772 8545 42