Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Zusätzliche Funktionen wie Papierkram und Funktionen, die von den Kunden nicht oft genutzt werden, sind Verschwendung. Das Wechseln von Mitarbeitern zwischen Aufgaben ist Verschwendung. Das Warten auf andere Aktivitäten, Teams, Prozesse ist Verschwendung. Umlernen, um die Arbeit abzuschließen, ist Verschwendung. Defekte und geringere Qualität sind Verschwendung. Management-Overhead, der keinen wirklichen Wert schafft, ist Verschwendung.
Zur Identifizierung von Verschwendung wird die Technik der Wertstromanalyse eingesetzt. Der zweite Schritt besteht darin, die Quellen der Verschwendung aufzuzeigen und sie zu beseitigen. Die Beseitigung von Verschwendung sollte iterativ erfolgen, bis selbst scheinbar wesentliche Prozesse und Verfahren liquidiert sind.
Lernen verstärkenBearbeiten
Softwareentwicklung ist ein kontinuierlicher Lernprozess, der auf Iterationen beim Schreiben von Code beruht. Das Softwaredesign ist ein Problemlösungsprozess, an dem die Entwickler, die den Code schreiben, und das, was sie gelernt haben, beteiligt sind. Der Wert einer Software wird an ihrer Gebrauchstauglichkeit und nicht an der Übereinstimmung mit den Anforderungen gemessen.
Anstatt mehr Dokumentation oder detaillierte Planung hinzuzufügen, könnten verschiedene Ideen durch das Schreiben von Code und das Erstellen von Gebäuden ausprobiert werden. Der Prozess der Erfassung von Benutzeranforderungen könnte vereinfacht werden, indem man den Endbenutzern Bildschirme vorlegt und ihre Eingaben einholt. Die Anhäufung von Fehlern sollte verhindert werden, indem Tests durchgeführt werden, sobald der Code geschrieben ist.
Der Lernprozess wird durch die Verwendung kurzer Iterationszyklen beschleunigt – jeweils gekoppelt mit Refactoring und Integrationstests. Ein verstärktes Feedback durch kurze Feedback-Sitzungen mit Kunden hilft bei der Bestimmung des aktuellen Entwicklungsstandes und der Anpassung der Bemühungen für zukünftige Verbesserungen. In diesen kurzen Sitzungen erfahren sowohl die Kundenvertreter als auch das Entwicklungsteam mehr über das Problem in der Domäne und überlegen sich mögliche Lösungen für die weitere Entwicklung. Auf diese Weise verstehen die Kunden ihre Bedürfnisse auf der Grundlage der bisherigen Entwicklungsergebnisse besser, und die Entwickler lernen, wie sie diese Bedürfnisse besser erfüllen können. Eine weitere Idee im Kommunikations- und Lernprozess mit dem Kunden ist die Set-basierte Entwicklung – diese konzentriert sich auf die Kommunikation der Einschränkungen der zukünftigen Lösung und nicht der möglichen Lösungen und fördert so die Entstehung der Lösung durch den Dialog mit dem Kunden.
Entscheiden Sie so spät wie möglich
Da Softwareentwicklung immer mit einer gewissen Unsicherheit verbunden ist, sollten bessere Ergebnisse mit einem Set-basierten oder optionsbasierten Ansatz erzielt werden, indem Entscheidungen so lange wie möglich hinausgezögert werden, bis sie auf der Grundlage von Fakten und nicht von unsicheren Annahmen und Vorhersagen getroffen werden können. Je komplexer ein System ist, desto mehr Kapazität für Veränderungen sollte in das System eingebaut werden, so dass wichtige und entscheidende Verpflichtungen aufgeschoben werden können. Der iterative Ansatz fördert dieses Prinzip – die Fähigkeit, sich an Änderungen anzupassen und Fehler zu korrigieren, die sehr kostspielig sein können, wenn sie erst nach der Freigabe des Systems entdeckt werden.
Mit der setbasierten Entwicklung: Wenn zum Beispiel ein neues Bremssystem für ein Auto benötigt wird, können drei Teams Lösungen für dasselbe Problem entwerfen. Jedes Team lernt den Problemraum kennen und entwirft eine mögliche Lösung. Wenn eine Lösung als unangemessen erachtet wird, wird sie gestrichen. Am Ende einer bestimmten Zeitspanne werden die überlebenden Entwürfe verglichen, und einer wird ausgewählt, vielleicht mit einigen Änderungen, die auf den Erkenntnissen der anderen beruhen – ein großartiges Beispiel für den Aufschub von Verpflichtungen bis zum letztmöglichen Zeitpunkt. Auch Softwareentscheidungen könnten von dieser Praxis profitieren, um das Risiko zu minimieren, das durch einen großen Entwurf im Vorfeld entsteht. Darüber hinaus gäbe es dann mehrere Implementierungen, die korrekt funktionieren, sich aber (in Bezug auf die interne Implementierung) unterscheiden. Diese könnten für die Implementierung fehlertoleranter Systeme verwendet werden, die alle Eingaben und Ausgaben gleichzeitig auf ihre Korrektheit überprüfen, und zwar über mehrere Implementierungen hinweg.
Ein agiler Softwareentwicklungsansatz kann den Aufbau von Optionen für die Kunden vorverlegen und so bestimmte wichtige Entscheidungen hinauszögern, bis die Kunden ihre Bedürfnisse besser erkannt haben. Dies ermöglicht auch eine spätere Anpassung an Veränderungen und die Vermeidung kostspieliger früherer technologiegebundener Entscheidungen. Dies bedeutet nicht, dass keine Planung erfolgen sollte – im Gegenteil, die Planungstätigkeit sollte sich auf die verschiedenen Optionen und die Anpassung an die aktuelle Situation konzentrieren sowie verwirrende Situationen durch die Festlegung von Mustern für schnelles Handeln klären. Die Bewertung verschiedener Optionen ist effektiv, sobald man erkennt, dass sie nicht kostenlos sind, sondern die nötige Flexibilität für eine späte Entscheidungsfindung bieten.
So schnell wie möglich liefern
Im Zeitalter der rasanten Technologieentwicklung überlebt nicht der Größte, sondern der Schnellste. Je schneller das Endprodukt ohne größere Mängel geliefert wird, desto eher kann Feedback eingeholt und in die nächste Iteration eingearbeitet werden. Je kürzer die Iterationen, desto besser der Lernprozess und die Kommunikation innerhalb des Teams. Durch die Schnelligkeit können Entscheidungen hinausgezögert werden. Schnelligkeit gewährleistet, dass die aktuellen Bedürfnisse des Kunden erfüllt werden und nicht das, was er gestern benötigt hat. Dies gibt ihnen die Möglichkeit, ihre Entscheidung darüber, was sie wirklich brauchen, aufzuschieben, bis sie bessere Kenntnisse haben. Die Kunden schätzen die schnelle Lieferung eines Qualitätsprodukts.
Die Ideologie der Just-in-Time-Produktion könnte auf die Software-Entwicklung angewandt werden, wobei die spezifischen Anforderungen und das Umfeld berücksichtigt werden. Dies wird erreicht, indem man das benötigte Ergebnis vorstellt und das Team sich selbst organisieren und die Aufgaben zur Erreichung des benötigten Ergebnisses für eine bestimmte Iteration aufteilen lässt. Zu Beginn liefert der Kunde den benötigten Input. Dieser kann einfach in kleinen Kärtchen oder Geschichten präsentiert werden – die Entwickler schätzen die Zeit, die für die Umsetzung jedes Kärtchens benötigt wird. Auf diese Weise wird die Arbeitsorganisation zu einem sich selbst ziehenden System: Jeden Morgen bespricht jedes Teammitglied im Rahmen eines Stand-up-Meetings, was gestern getan wurde, was heute und morgen zu tun ist, und fordert die Kollegen oder den Kunden auf, ihm Input zu geben. Dies erfordert Transparenz des Prozesses, was auch der Kommunikation im Team zugute kommt.
Der Mythos, der diesem Prinzip zugrunde liegt, lautet: Eile macht Verschwendung. Die Lean-Implementierung hat jedoch gezeigt, dass es eine gute Praxis ist, schnell zu liefern, um den Output frühestmöglich zu sehen und zu analysieren.
Das Team befähigen
In den meisten Unternehmen gibt es eine traditionelle Vorstellung über die Entscheidungsfindung in der Organisation – die Manager sagen den Arbeitern, wie sie ihre eigene Arbeit machen sollen. Bei der Workout-Technik werden die Rollen umgedreht – die Manager lernen, den Entwicklern zuzuhören, damit sie besser erklären können, welche Maßnahmen zu ergreifen sind, und auch Verbesserungsvorschläge machen können. Der Lean-Ansatz folgt dem agilen Prinzip: „Baue Projekte um motivierte Personen herum auf und vertraue darauf, dass sie die Arbeit erledigen“, indem er Fortschritte fördert, Fehler aufdeckt und Hindernisse beseitigt, aber kein Mikromanagement betreibt.
Ein weiterer Irrglaube ist die Betrachtung von Menschen als Ressourcen. Menschen mögen aus der Sicht eines statistischen Datenblatts Ressourcen sein, aber in der Softwareentwicklung, wie auch in jedem anderen organisatorischen Bereich, brauchen Menschen mehr als nur eine Liste von Aufgaben und die Gewissheit, dass sie bei der Erledigung der Aufgaben nicht gestört werden. Die Menschen brauchen Motivation und einen höheren Zweck, für den sie arbeiten – einen Zweck innerhalb der erreichbaren Realität, mit der Gewissheit, dass das Team seine eigenen Verpflichtungen wählen kann. Die Entwickler sollten Zugang zum Kunden haben; der Teamleiter sollte Unterstützung und Hilfe in schwierigen Situationen bieten und dafür sorgen, dass die Skepsis nicht den Geist des Teams zerstört. Menschen zu respektieren und ihre Arbeit anzuerkennen ist eine Möglichkeit, das Team zu stärken.
Integrität inEdit aufbauen
Der Kunde muss eine Gesamterfahrung mit dem System machen. Dies ist die so genannte wahrgenommene Integrität: wie es beworben wird, wie es geliefert wird, wie es eingesetzt wird, wie es zugänglich ist, wie intuitiv es zu bedienen ist, wie hoch der Preis ist und wie gut es Probleme löst.
Konzeptionelle Integrität bedeutet, dass die einzelnen Komponenten des Systems als Ganzes gut zusammenarbeiten und ein Gleichgewicht zwischen Flexibilität, Wartbarkeit, Effizienz und Reaktionsfähigkeit besteht. Dies kann dadurch erreicht werden, dass der Problembereich verstanden und gleichzeitig und nicht nacheinander gelöst wird. Die benötigten Informationen werden in kleinen Stücken – nicht in einem einzigen großen Stück – erhalten, vorzugsweise durch persönliche Kommunikation und nicht durch schriftliche Dokumentation. Der Informationsfluss sollte in beide Richtungen konstant sein – vom Kunden zu den Entwicklern und zurück, wodurch die große stressige Menge an Informationen nach langer isolierter Entwicklung vermieden wird.
Einer der gesunden Wege zu einer integralen Architektur ist das Refactoring. Je mehr Funktionen zur ursprünglichen Codebasis hinzugefügt werden, desto schwieriger wird es, weitere Verbesserungen hinzuzufügen. Beim Refactoring geht es darum, Einfachheit, Klarheit und eine minimale Anzahl von Funktionen im Code zu erhalten. Wiederholungen im Code sind Anzeichen für schlechtes Code-Design und sollten vermieden werden. Der vollständige und automatisierte Erstellungsprozess sollte von einer vollständigen und automatisierten Suite von Entwickler- und Kundentests begleitet werden, die dieselbe Versionierung, Synchronisation und Semantik aufweisen wie der aktuelle Zustand des Systems. Am Ende sollte die Integrität durch gründliche Tests überprüft werden, um sicherzustellen, dass das System das tut, was der Kunde von ihm erwartet. Automatisierte Tests werden ebenfalls als Teil des Produktionsprozesses betrachtet, und wenn sie keinen zusätzlichen Nutzen bringen, sollten sie als Verschwendung betrachtet werden. Automatisierte Tests sollten kein Ziel sein, sondern eher ein Mittel zum Zweck, nämlich die Reduzierung von Fehlern.
Optimize the WholeEdit
Moderne Softwaresysteme sind nicht nur die Summe ihrer Teile, sondern auch das Produkt ihrer Interaktionen. Fehler in Software neigen dazu, sich während des Entwicklungsprozesses anzuhäufen – durch die Zerlegung der großen Aufgaben in kleinere Aufgaben und durch die Standardisierung verschiedener Entwicklungsphasen sollten die Ursachen für Fehler gefunden und beseitigt werden. Je größer das System ist, je mehr Organisationen an seiner Entwicklung beteiligt sind und je mehr Teile von verschiedenen Teams entwickelt werden, desto wichtiger sind gut definierte Beziehungen zwischen den verschiedenen Anbietern, damit ein System mit reibungslos zusammenwirkenden Komponenten entsteht. Während eines längeren Entwicklungszeitraums ist ein stärkeres Netz von Unterauftragnehmern weitaus vorteilhafter als kurzfristige Gewinnoptimierung, die keine Win-Win-Beziehungen ermöglicht.
Das schlanke Denken muss von allen Mitgliedern eines Projekts gut verstanden werden, bevor es in einer konkreten, realen Situation umgesetzt wird. „Think big, act small, fail fast; learn rapidly“ – diese Slogans fassen zusammen, wie wichtig es ist, das Feld zu verstehen und die Eignung der Lean-Prinzipien entlang des gesamten Softwareentwicklungsprozesses zu implementieren. Nur wenn alle Lean-Prinzipien zusammen umgesetzt werden, kombiniert mit einem ausgeprägten „gesunden Menschenverstand“ in Bezug auf das Arbeitsumfeld, ist eine Basis für den Erfolg in der Softwareentwicklung gegeben.