Agile Softwareentwicklung

Lean Software Development

24.08.2010
Lean Software Development (LSD) wurde 2003 von Mary und Tom Poppendieck entwickelt. Vorbild war das Lean Development, was vor allem im Automobilbau zu weitreichenden Veränderungen geführt hat.

Lean Software Development umfasst sieben Prinzipien, die mit Hilfe von 22 Vorgehensweisen umgesetzt werden. Die sieben Prinzipien sind:

Eine Beschreibung dieser Prinzipien finden Sie auf den folgenden Seiten. Hier zunächst die Bewertung durch BQI Research.

Bewertung BQI Research

Foto: BQI

Lean Software Development zeigt seine Stärken vor allem in den Bereichen Qualitäts-Management (QM) und Test (T). Auch das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) sind gut abgedeckt. Vergleichsweise schwach ausgeprägt sind dagegen die Bereiche Requirements-Management (RM), Integration und Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).

1. Verschwendung vermeiden

Alles, was dem Kunden keinen Mehrwert liefert, ist Verschwendung. Das können Features sein, die niemand verwendet oder Dokumente, die ungelesen im Schrank stehen. Um Verschwendung vermeiden zu können, muss man sie zunächst erkennen. Das ist auch das erste Vorgehen im Lean Software Development: Verschwendung sehen. Folgende sieben Punkte sind klassische Quellen:

2. Lernen unterstützen

Im Laufe eines Projekts lernen alle Beteiligten dazu - sowohl der Kunde als auch die Entwickler. Dies ist erwünscht und soll unterstützt werden. Ein Hilfsmittel dazu ist das Feedback, eine schnelle Rückmeldung auf die Arbeitsergebnisse. So kann man zum Beispiel anstelle umfangreicher Architektur- und Designdokumente verschiedene Varianten direkt im Sourcecode ausprobieren und erhält unmittelbar Feedback über die Lauffähigkeit. Und anstatt Anforderungen vollständig zu erheben, ist es besser, ein paar Bildschirmmasken zu entwerfen und mit dem Kunden zu diskutieren.

Damit das Feedback zielgerichtet ist, wird die Iteration eingesetzt. Wichtig ist allerdings, dass die Iterationen "Time-boxed" sind, also der Endtermin feststeht. Sollte es zu einem Engpass kommen, so wird der Umfang der Iteration verändert, nicht der Termin.

Als weiteres Hilfsmittel zur Unterstützung des Lernens dient das Set based Design. Dahinter steckt die Idee, sich möglichst lange möglichst viele Alternativen offen zu lassen. Die Festlegung auf eine Alternative erfolgt erst, wenn man meint genug gelernt zu haben, um eine Entscheidung zu treffen. Dies unterstützt auch ein weiteres Prinzip des Lean Software Developments, nämlich:

3. So spät entscheiden wie möglich

Im Lean Software Development wird gefordert, die Entwicklung in allen betroffenen Bereichen voranzutreiben, bis man die nötigen Informationen hat, um die richtige Entscheidung zu treffen. Insbesondere werden fachliche Analyse, Architektur, Design und Realisierung parallel weiter getrieben. Das wird als Concurrent Development bezeichnet.

Ein Hilfsmittel zur Unterstützung ist das Denken in Optionen. Solange man nicht alle nötigen Informationen für eine Entscheidung hat, legt man sich auch nicht fest und lässt sich verschiedene Optionen offen. Dabei ist es allerdings ebenso wichtig, den richtigen Zeitpunkt für eine Entscheidung zu erkennen. Der richtige Zeitpunkt für eine Entscheidung ist dann, wenn man sich sonst eine wichtige Alternative verbauen würde.

Entscheidungen werden aus Erfahrung und aus dem Bauch heraus getroffen. Wichtig dabei ist, dass an der Entscheidung diejenigen Personen beteiligt sind, die sie auch umzusetzen haben.

4. So früh ausliefern wie möglich

Entscheidungen zu verzögern, betrifft nicht nur technische Entscheidungen. Auch die fachlichen Entscheidungen sollten erst dann gefällt werden, wenn die Fachexperten die Implikationen zur Genüge verstanden haben. Oft genug benötigen alle Beteiligten dafür die Erfahrung mit lauffähiger Software. Daher ist es notwendig, Software so früh wie möglich auszuliefern, was erhöhte Anforderungen an die Aufgabenverwaltung stellt.

Auch hierfür gibt es Hilfsmittel. Ein solches ist das Pull System, in dem anstehende Tätigkeiten wie in einem Karteikasten gesammelt werden. Die Tätigkeiten sind priorisiert, die Entwickler entnehmen aus diesem Kasten die Aufgaben nach der Priorität und ihren eigenen Fähigkeiten.

Zur Koordination der Aufgaben dienen regelmäßige (tägliche) Meetings. Durch eine Art schwarzes Brett wird transparent gemacht, wer an welchen Aufgaben arbeitet und welche Aufgaben als nächstes anstehen. Das Pull System kann dabei als Kette von Warteschlangen aufgefasst werden.

Die Warteschlangentheorie ist auch ein Hilfsmittel des Lean Software Developments und ein Teilgebiet des systemischen Denkens. Für Warteschlangen gibt es diverse Optimierungsverfahren.

Die Kosten von Verzögerungen sind ebenfalls ein Hilfsmittel. Nicht immer ist schnelle Entwicklung auch die günstigere Alternative. Möglicherweise müssen teure Werkzeuge angeschafft werden, die mehr kosten, als an Arbeitszeit eingespart werden kann. Lean Software Development empfiehlt, bei solchen Entscheidungen nicht nur die direkt eingesparte Arbeit zu berücksichtigen, sondern auch die Kosten für eine verzögerte Auslieferung.

5. Verantwortung an das Team geben

Das Lean Software Development propagiert die Idee, dass die Übergabe von Verantwortung an das Team zu den größten Motivatoren gehört. Um das Team zu motivieren, nutzt Lean Software Development als Vorgehensweise, dass ein Team sein Ziele selbst festlegt. Ziele, die nicht vorgegeben werden, sondern selbst festgelegt sind, werden häufiger erreicht. Allerdings reichen selbst gesteckte Ziele noch nicht aus. Die Teammitglieder müssen auch motiviert sein. Oftmals wird versucht, die Mitarbeiter mit Belohnungen (meist finanzieller Art) zu motivieren. Dies wirkt aber nur auf die äußere Motivation. Um eine echte innere Motivation zu erreichen, muss man laut Motivationsforschern folgende Faktoren adressieren:

Aber man benötigt mehr: Führung. Eine Führungspersönlichkeit hilft dem Team, die Richtung zu finden und sich die Umgebung einzurichten, die es für erfolgreiche Arbeit benötigt. Sie schirmt das Team gegen Störungen von außen ab, ohne den notwendigen Informationsfluss zu behindern. Führung bewirkt, dass das Team gut ist und sich selbst aus einer Krise helfen kann, sollte es einmal in eine hineinrutschen.

6. Integrität einbauen

Dabei unterscheidet Lean Software Development zwischen interner, konzeptioneller Integrität und externer, empfundener Integrität. Die konzeptionelle Integrität beschreibt den technischen Aufbau des Systems:

Die empfundene Integrität ist dagegen eine Eigenschaft der Benutzungsoberfläche:

Integrität lässt sich nicht von Anfang an "hineinplanen”. So wie ein Text immer wieder Korrektur gelesen werden muss, so müssen auch eine Oberfläche oder ein Design immer wieder kritisch überprüft und verändert werden, zumal Integrität zu Projektbeginn meist noch kein großes Problem darstellt.

Kritisch wird es oft erst dann, wenn Änderungen kommen, die über den geplanten Umfang hinausgehen. Insbesondere der Versuch, solche Änderungen einzubauen, möglichst ohne den existierenden Code anzufassen, führt zu Rucksäcken, Spaghetticode und letztlich zum Tod des Projekts.

Somit ist der nächste wichtige Punkt die empfundene Integrität. Eine enge Zusammenarbeit zwischen Entwicklern und Anwendern ist Grundvoraussetzung, damit Anwender Integrität empfinden, wenn sie mit einem System arbeiten. Je besser diese Kommunikation funktioniert, um so eher können Fehlentscheidungen aufgedeckt und korrigiert werden. Am besten funktioniert diese Abstimmung in kurzen Iterationen mit lauffähiger Software. Bei komplexeren Aufgaben können aber auch frühere Abstimmungen sinnvoll sein.

Neben der empfundenen Integrität ist die konzeptionelle Integrität von Bedeutung. Die schönste empfundene Integrität wird kaum auf Dauer zu halten sein, wenn sie reine Fassade ist, also nicht eine innere konzeptionelle Integrität widerspiegelt. Die innere konzeptionelle Integrität sicherzustellen ist die wichtigste Aufgabe des Master Developers. Vor allem muss dafür die Kommunikation innerhalb des Teams funktionieren.

Allerdings verliert Software, die inkrementell entsteht, im Laufe der Zeit ihre konzeptionelle Integrität. Um dem entgegenzuwirken wird eine weitere Methodik angewandt, das Refactoring.

Ein weiteres, bereits bekanntes Hilfsmittel zur Sicherstellung der Integrität ist das automatisierte Testen. Neben der Sicherung der Codequalität und der Stabilität gegenüber Änderungen können automatische Tests auch folgenden Zwecken dienen:

7. Das Ganze sehen

Projekt-Management dreht sich nicht nur um die Punkte Qualität, Zeit, Umfang und Kosten. Alle diese Aspekte sind wichtig. Allerdings ist kein Punkt für sich alleine als einzige Stellgröße verwendbar. Ein erfolgreicher Projekt-Manager muss das Ganze sehen: die verschiedenen Einzelinteressen von Auftraggebern, Mitarbeitern und Zulieferern, die vielen fachlichen und technischen Einflussfaktoren und die innere Dynamik eines Projekts. Sie alle sind eng miteinander verwoben. Sie bilden keine einfachen Ursache-Wirkungsketten, sondern ein komplexes System mit Rückkopplungsschleifen, Verzögerungen und nicht vorhersehbaren Ereignissen. Diese Zusammenhänge zu verstehen und auf sie einzuwirken ist die eigentliche Aufgabe jedes Projektmanagers.

Um dieser Aufgabe nachzukommen dient das Messen. Hiermit ist allerdings nicht die Anwendung hochkomplexer, nichtssagender Metriken gemeint, sondern ganz allgemein die bewusste Beobachtung des Projekts und die Interpretation des offensichtlichen Projektverlaufs. Einfache Kennzahlen wie zum Beispiel die Anzahl offener Fehler sind vollkommen ausreichend.

Um den Rahmen für die Zusammenarbeit im Ganzen zu spannen gibt es noch das letzte Hilfsmittel, die Verträge. Verträge dienen im Wesentlichen zwei Zwecken. Zum einen sind sie Basis für die Zusammenarbeit, zum anderen verteilen sie die Verantwortung auf die Vertragspartner.

Eine dem Lean Software Development sehr ähnliche Methode ist Kanban. Kanban wurde im Jahr 2007 von David Anderson entwickelt und basiert ebenfalls auf den Prinzipien des Lean Development. Die Methode setzt dabei auf eine Limitierung des "Work in Progress" (WiP), wonach nicht mehr als eine festgelegt Anzahl von Anforderungen gleichzeitig umgesetzt werden dürfen.

Durch eine Visualisierung des WiP zum Beispiel an einem Whiteboard wird sichtbar, wo die Engpässe bei der Bearbeitung sind. Durch die Eliminierung der Engpässe wird eine Verbesserung des Durchlaufs erreicht.