Von Toyotas Lean Production zu Lean Development
Von Philippe Jordi, publiziert am
11. Dezember 2009
Tags: Agile, Extreme Programming, Lean, Projektleitung, Scrum
Toyota hat in den achtziger Jahren mit grossem Erfolg eine neue Unternehmensphilosophie eingeführt: Weglassen aller überflüssigen Arbeitsgänge in der Produktion und in der Administration.
Die fünf Leitprinzipien des Lean Development
Lean Development ist die Adaption von Lean Production auf Entwicklungsprozesse. Lean Development stützt sich auf fünf Leitprinzipien:
- Wert: Spezifiziere präzise den Wert deines Produktes
- Wertstrom: Erkenne den Wertstrom
- Flow: Erzeuge einen Wertstromfluss ohne Unterbrechungen
- Pull: Lasse den Kunden den Takt der Bearbeitung bestimmen
- Perfektion: Verbessere die Dinge kontinuierlich
Effizienzeinbussen in Software-Entwicklungsprojekten
Soweit so gut, doch wo liegen die Stolpersteine der klassischen Ansätze? Jack Milunsky hat in seinem Blog sieben Gründe für Effizienzeinbussen aufgelistet. Diese können durch Einsatz von Lean Development und weiteren agilen Methoden (Scrum, Extreme Programming) behoben werden:
1. Partially done work
Nicht vollständig erledigte Arbeit. Entwickler müssen die selben Aufgaben mehrmals bearbeiten. Wir gehen davon aus, dass diese Einbussen mittels dem Ansatz von Scrum (Scrum-Board, Status DONE) weitgehend verhindert werden können.
2. Extra Features
Zusätzliche Erweiterungen die der Kunde nicht braucht oder wünscht. Hier stellt Scrum sicher, dass Erweiterungen nach Priorität des Kunden implementiert werden.
3. Relearning / Extra Processing
Schlecht dokumentierter Code, schlechte Planung und schlechte Qualität zwingen Entwickler zum mehrmaligen Bearbeiten von Aufgaben. Scrum (Planung) und Extreme Programming (Qualität) bieten Werkzeuge, um diesen Aufwand zu reduzieren.
4. Transportation / Handoffs
Entwickler oder ganze Teams müssen unfertige Arbeiten an Kollegen übergeben. Gleich wie bei Punkt 1 helfen hier die Mechanismen von Scrum, damit möglichst wenig Arbeit nur teilweise erledigt liegen bleibt.
5. Motion / Task Switching
Entwickler erledigen mehrere Aufgaben gleichzeitig und erleben ständige Kontextwechsel. Hier greift der Scrum Master ein: Er stellt sicher, dass die Teammitglieder ungestört an den zugewiesenen Paketen arbeiten können.
6. Delays
Potenzielle Verzögerungen (z.B. fehlende Spezifikationen) müssen früh erkannt und wenn möglich verhindert werden. Dies gelingt, indem bestehende Prozesse im Hinblick auf bekannte Verzögerungsgründe untersucht und optimiert werden.
7. Bugs / Defects
Fehler kann man als Entwickler nicht immer verhindern, aber sie sollten früh erkannt werden. Bei Scrum wird darauf geachtet die Erweiterungen in kleinen, abgeschlossenen Paketen umzusetzen. Diese sollten möglichst eindeutig spezifiziert und durch automatische Tests kontrolliert werden. Pair Programming (Extreme Programming) hilft unter anderem, die Code-Qualität auf hohem Niveau zu halten.
Schlussfolgerung
Lean Development bietet enormes Spar- und Verbesserungspotential in der Softwareentwicklung. Durch den umfassenden Einsatz von Scrum und Teilen von Extreme Programming, sind diese bei Puzzle teilweise abgedeckt. Wir versuchen das Restpotential auch noch auszuschöpfen.
Kommentare
-
Von
Patrick Weibel
am 17.12.2009:
Hallo Philippe
Ich habe diesbezüglich ebenfalls was geschrieben. Die sieben Verschwendungen oder auch Mudas genannt können auf verschiedene Weise auf die Software-Entwicklung gemappt werden. Siehe mein Blogeintrag unter:
http://blog.eweibel.net/?p=489Gruss
Patrick
-
Von
Jonas
am 18.12.2009:
Interessant ... ich habe zwei Bedenken:
Im allgemeinen Hype von Lean/Scrum/Kanban/Kaizen... geht aus meiner Sicht verloren, dass Toyota eine industriellen Produktionsprozess optimierte.
Softwareentwicklung hat jedoch meiner Meinung nach sehr wenig Ähnlichkeiten mit einem industriellen Produktionsprozess. Die Analogie der "Software-Fabrik" hat sich als unpassend erwiesen. Softwareentwicklung ist meiner Meinung nach vielmehr ein explorativer, kreativer Prozess. Die Analogie eines "Forschungslabors" passt viel besser. Daher bin ich skeptisch ob die Toyota-Ansätze wirklich für die SW-Industrie passen...
Mein zweites Bedenken ist aus der Praxis:
Ich erfahre in Projekten, dass es mit Scrum sehr einfach ist sich nicht um das "Big-Picture" zu kümmern ganz im Motto von „Embracing Change“. Dies ist im Moment bequem, zahlt Sich aber sehr oft schon sehr bald nicht aus. Aufgaben erledigen heisst in Scrum Stories erledigen. Sehr oft sehe ich aber immer wieder Stories in späteren Sprints, die „fertige“ Dinge aus vorangehenden Sprints wieder umbauen. Dies ist natürlich nicht grundsätzlich zu verhindern (sonst sind wir beim unmöglichen Wasserfall), in meiner Erfahrung dient Scrum oft als Ausrede sich zu wenig um das „Big Picture“ zu kümmern… Mit dem Fokus auf kleine User-Stories wird dies bestärkt. Grundsätzlich sind „Embracing Change“ und „Done“ zwei entgegengesetzte Kräfte und Scrum kann die Illusion geben, dass dies nicht der Fall ist.
