Eine Adaption der lean production, also der “schlanken Produktion”: LSD – das Lean Software Development. Umgelegt auf Praktiken in der Softwareentwicklung lag hier das Vorbild in der Automobilindustrie, weil das TPS (Toyota-Produktionssystem) im Automobilbau zu weitreichenden Veränderungen geführt hat. Was es mit diesem Teilbereich der Agilen Softwareentwicklung auf sich hat, erklären wir anhand der definierten Prinzipien.
Lean Software Development umfasst sieben Prinzipien, die mit Hilfe von 22 Vorgehensweisen/Praktiken umgesetzt werden können:
- Verschwendung vermeiden
- Lernen unterstützen
- So spät entscheiden wie möglich
- So früh ausliefern wie möglich
- Verantwortung an das Team geben
- Integrität einbauen
- Das Ganze sehen
Das Lean Software Development zeigt seine Stärken vor allem in den Bereichen Qualitätsmanagement (QM) und Test (T). Auch das Systemdesign (SD, auch TK für technische Konzeption oder ITK für IT-Konzept) und die Implementierung (IMPL) werden gut abgedeckt. Etwas schwächer ausgeprägt sind dagegen die Bereiche Anforderungsmanagement (AM, auch RM für Requirements Management), Integration & Einführung (INT), Wartung (W), Betrieb (B) und Projektmanagement (PM).
Wir erklären und beschreiben die sieben LSD-Prinzipien hier kurz:
1. Verschwendung vermeiden
Alles, was dem Kunden keinen Mehrwert liefert, ist Verschwendung. Das können Features sein, die zwar nett sind, aber niemand verwendet (nice-to-haves) 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. Beispiele generell dazu findet man in folgenden Bereichen:
- Unvollständige Arbeit
- Unnötige Prozesse
- Unnötige Features
- Ständiges Umschalten zwischen Projekten
- Warten
- Unnötige Bewegung zwischen Stationen
- Fehler
- Technisches Management bzw. Over-Engineering von Architekturen
2. Lernen unterstützen
Im Laufe eines Projekts lernen alle Beteiligten dazu, sowohl Kunde als auch Entwickler. Dies ist auch so erwünscht und soll unterstützt werden. Ein Hilfsmittel dazu ist das Feedback, also eine schnelle Rückmeldung auf die Arbeitsergebnisse. So kann man zB anstelle umfangreicher Architektur- und Designdokumente verschiedene Varianten direkt im Sourcecode ausprobieren und erhält unmittelbar Antwort ü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 TimeboxedTimeboxing ist eine Technik der Projektplanung. Eine Timebox ist hierbei ein fester Zeitrahmen für das Projekt oder einen Vorgang im Projekt. sind, dh 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. Damit kommen wir zum 3. LSD-Prinzip:
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 ebenso wichtig, den richtigen Zeitpunkt für eine Entscheidung zu erkennen – nämlich dann, wenn man sich keine wichtige Alternative mehr verbauen kann.
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 fachliche 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 dient ein regelmäßiges (tägliches) Meeting, sog. Daily Standup. Durch eine Art schwarzes Brett (Whiteboard) 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.
Ebenfalls ein Hilfsmittel: Verzögerungskosten. 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 LSD als Vorgehensweise, dass ein Team sein Ziele selbst festlegt. Der Grund ist ein einfacher: Ziele, die selbst festgelegt und nicht vorgegeben werden, werden häufiger erreicht. Das alleine reicht allerdings 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 kurzfristig und auf die äußere Motivation. Um eine echte, langfristige, innere Motivation zu erreichen, muss man laut Motivationsforschern folgende Faktoren adressieren:
- Zugehörigkeit
- Sicherheit
- Expertise
- Sichtbarer Fortschritt
Aber man benötigt noch etwas: nämlich 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
LSD unterscheidet zwischen interner, konzeptioneller Integrität und externer, empfundener Integrität.
Konzeptionelle Integrität beschreibt den technischen Aufbau des Systems:
- Ist die Architektur zugleich verständlich und erweiterungsfähig?
- Können neue Features ohne Probleme eingebaut werden?
- Ist das Design konsistent?
Empfundene Integrität ist dagegen eine Eigenschaft der Benutzungsoberfläche:
- Verwendet die Oberfläche möglichst wenige und eingängige Metaphern?
- Ist die Bedienung intuitiv?
- Werden gleiche Dinge auch gleich repräsentiert?
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:
- Kommunikation der Anforderungen
- Feedback
- Gerüst für weitere Methodiken wie zB Refactoring
- Dokumentation
- Wartbarkeit
7. Das Ganze sehen
Projektmanagement 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 Projektmanager 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 hoch komplexer, 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 ein letztes Hilfsmittel: 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 J. 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 Kanban-Board wird sichtbar, wo die Engpässe bei der Bearbeitung sind. Durch die Eliminierung der Engpässe wird eine Verbesserung des Durchlaufs erreicht.
Fragen, Unklarheiten, Wünsche?
Wir freuen uns auf Ihr Feedback! Bitte melden Sie sich einfach bei uns ;)
