Author
Was ist Lean-Softwareentwicklung? Unter den allgemein zitierten Softwareentwicklungsmethoden lässt sich Lean am schwersten eingrenzen. Das Agile Manifest stützte sich in hohem Maße auf die Lean-Prinzipien, doch das Buch „Lean Software Development: An Agile Toolkit“ von Mary und Tom Poppendieck, in dem die Lean-Prinzipien formell in den spezifischen Kontext der Softwareentwicklung eingeführt wurden, wurde erst zwei Jahre später veröffentlicht.
Lean oder „The Toyota Way“, wie die Methode vor ihrer Umbenennung in den späten 1980er Jahren genannt wurde, ist einer der Gründerväter des modernen Projektmanagements und der Design-Thinking-Theorie. Seine Wurzeln liegen in der Fertigung, aber seine Prinzipien haben den agilen Ansatz für die Softwareentwicklung, der mit Scrum begann, beeinflusst und geprägt.
Dieser Beitrag befasst sich mit:
- Die Rolle von Lean im Stammbaum der Softwareentwicklungsmethoden,
- seine Relevanz als nach wie vor beliebter Ansatz für die Softwareentwicklung,
- die 9 Prinzipien der Lean-Softwareentwicklung und;
- seine praktische Umsetzung durch Softwareentwicklungsteams
Können wir Ihnen bei Ihrem nächsten Softwareentwicklungsprojekt helfen?
Flexible Modelle für Ihre Bedürfnisse!
Eine kurze Geschichte zu Lean als Softwareentwicklungsmethodik
Lean wurde in den späten 1940er Jahren von Toyota als eine Reihe von Prinzipien und Praktiken entwickelt, die eine effektivere Fertigung ermöglichen sollten. Der Schwerpunkt lag dabei auf der Vermeidung von Verschwendung und Verzögerungen, um den „Wertfluss“ („flow of value“) effektiver zu gestalten. Das Kernprinzip besteht darin, dass durch die Abschaffung von nicht Werstschöpfenden Prozessen die Ressourcen optimal genutzt werden und damit die Wirtschaftlichkeit gesteigert wird. Verschwendung wird in Wertschöpfung umgewandelt.
Der Ansatz wurde zwischen den späten 1940er und den 1970er Jahren in der Toyota-Fabrik von den Wirtschaftsingenieuren Taiichi Ohno und Eiji Toyoda entwickelt, die im Unternehmen tätig waren. Das Verfahren wurde erstmals in dem 1978 von Ohno veröffentlichten Buch „Toyota Production System“ (TPS) für die breite Öffentlichkeit dokumentiert.
Erst 1988 wurde „The Toyota Way“ in „Lean“ umbenannt, wobei der Begriff durch John Krafciks 1988 erschienenen Artikel „Triumph of the Lean Production System“ geprägt wurde. Die Lean Manufacturing-Methode wurde schnell zu einer sehr einflussreichen Unternehmenskultur und -methodik, die von Unternehmen in aller Welt mit großem Erfolg übernommen wurde.
Im Jahr 2003 entwickelte sich Lean von einer Methode für die Herstellung physischer Güter zu einer Methode für die Erstellung digitaler Produkte, die im Rahmen eines Softwareentwicklungsprozesses eingesetzt wird, und zwar mit der Veröffentlichung des richtungsweisenden Buches „Lean Software Development: An Agile Toolkit“ von Mary und Tom Poppendieck.
Die beiden Autoren verfügten über einen umfangreichen Hintergrund in der IT und Produktentwicklung, wobei Mary in ihrer Laufbahn als Programmiererin für Prozesssteuerung, Leiterin der IT-Abteilung und Produktentwicklung tätig war. Tom war ursprünglich Physikprofessor und arbeitete dann in den Bereichen IT-Infrastruktur, Produktentwicklung und Fertigungsunterstützung, bevor er in Beratungsprojekten in den Bereichen Gesundheitswesen, Logistik, Hypothekenbank und Reisedienstleistungen tätig wurde.
Die Inspiration für Lean Software Development stammt aus einer Zeit, in der Mary ein Softwareprojekt der Regierung leitete und dabei zum ersten Mal mit dem Wasserfallmodell der Softwareentwicklung in Berührung kam. Der Kontrast zwischen den Problemen, auf die sie bei der Leitung eines Softwareentwicklungsprojekts in einer Organisation stieß, die an den Wasserfallansatz gewöhnt war, und ihren früheren Erfahrungen mit erfolgreichen Projekten überzeugte sie, dass „ein neues Paradigma“ erforderlich war – Lean.
Das Ergebnis war die Lean-Softwareentwicklung, die die Prinzipien der Lean-Produktion mit den agilen Softwareentwicklungsmethoden und der Philosophie von „The Agile Manifesto“ und dem Buch „Agile Software Development with Scrum“ von Ken Schwaber, Mike Beedle und Robert C. Martin (beide 2001 veröffentlicht) verknüpfte.
Die Lean-Tradition in der Produktentwicklung wurde 2011 durch das einflussreiche Buch „The Lean Startup“ von Eric Ries fortgesetzt. Ries konzentrierte sich darauf, wie seiner Meinung nach die von Mary und Tom Poppendieck im Kontext der Softwareentwicklung dargelegten Lean-Prinzipien von Startups oder etablierten Organisationen, die ein neues Produkt – digital oder physisch – entwickeln, angewendet werden können.
Die Prinzipien der Lean-Softwareentwicklung.
Als Methodik oder Denkweise hat Lean 5 Kernprinzipien, die in dem 1996 erschienenen Buch „Lean Thinking“ von James P. Womack und Daniel T. Jones beschrieben werden:
- Wert identifizieren
- Wertschöpfungsströme abbilden
- Wertefluss schaffen
- Zugkraft etablieren
- Fortlaufende Verbesserung
Mary und Tom Poppendieck stellen in ihrem Buch über die Anwendung von Lean als Toolkit für die agile Softwareentwicklung folgende 7 Grundsätze auf:
- Verschwendung eliminieren.
- Qualität integrieren.
- Wissen aufbauen.
- Engagement aufschieben.
- Schnell liefern
- Menschen respektieren
- Gesamtsystem optimieren
Das Buch „Lean Software Development: An Agile Toolkit“ untersucht die praktischen Auswirkungen jedes einzelnen Aspekts im Zusammenhang mit der Entwicklung von Software und bietet konkrete Vorschläge, wie diese umgesetzt werden können.
Verschwendung vermeiden
„The Toyota Way“ besagt, dass es zur Minimierung von Verschwendung notwendig ist, genau zu ermitteln, wo es am häufigsten zu einer Verschwendung kommt. In Fertigungsprozessen werden 7 häufige Quellen von Verschwendung (muda) identifiziert, darunter Überproduktion, Defekte, ein übermäßiger Lagerbestand und die Tatsache, dass entweder das Inventar oder die Arbeiter mehr Zeit als nötig damit verbringen, zwischen verschiedenen Bereichen einer Fabrik zu pendeln.
Im Kontext zur Softwareentwicklung zeigt „Lean Software Development“ 9 Bereiche auf, in denen sich Verschwendung besonders häufig bemerkbar machen kann:
Unnötiger Code oder überflüssige Funktionen
Das Risiko der Verschwendung, das entsteht, wenn ein Produkt hergestellt wird, bevor es benötigt wird, lässt sich auf unnötigen Code und unnötige Funktionen in der Softwareentwicklung übertragen. Beides verzögert die Lieferzeit und die Feedback-Schleifen und sollte bewusst vermieden werden. Eine Möglichkeit, dies in der Lean-Softwareentwicklung zu erreichen, ist die schnelle Bereitstellung kleiner Inkremente funktionierender Software, die von agilen Frameworks gefördert wird.
Zu viele laufende Arbeiten (Work in Progress, WIP)
Wenn in der Softwareentwicklung mehr Aufgaben begonnen werden, als in einem kurzen Entwicklungszyklus abgeschlossen werden können, führt dies zu unnötiger Komplexität, die den Arbeitsablauf stört und die Effizienz beeinträchtigt.
Verzögerung im Softwareentwicklungsprozess
Verzögerungen im Softwareentwicklungsprozess verzögern die Lieferung und beeinträchtigen die Feedback-Schleifen.
Unklare oder sich ändernde Anforderungen
Unklare oder sich ändernde Anforderungen führen dazu, dass der Fokus verloren geht, Arbeit wiederholt wird, Frustration auftritt und letztendlich die Qualität der produzierten Software leidet.
Bürokratie
Eine gute Organisation ist wichtig, aber mehr Bürokratie als nötig führt zu Verzögerungen im Softwareentwicklungsprozess.
Schlechte Kommunikation
Eine verzögerte oder schlechte Kommunikation innerhalb eines Softwareentwicklungsteams, aber auch zwischen dem Team und anderen Beteiligten sorgt für Verzögerungen und schwächt die Konzentration und den Enthusiasmus, vor allem wenn das Problem bei externen Beteiligten liegt. Ist die Kommunikation der Entwicklungsteams mit den Partnern unzureichend, kann sich auch dies negativ auf die Einstellung des Unternehmens gegenüber des Projekts auswirken.
Unvollendete Arbeit
Teilweise abgeschlossene Arbeiten, wie überflüssiger Code oder Funktionen, bringen weder einen Mehrwert für den Kunden noch bieten sie dem Team Lernmöglichkeiten.
Wechsel von Aufgaben
Wenn ein Softwareentwicklungsteam oder seine einzelnen Mitglieder aufgrund schlechter Planung unnötigerweise die Aufgaben wechseln, führt dies zu Qualitätseinbußen, Verzögerungen sowie Problemen bei der Kommunikation und kann die Arbeitsmoral negativ beeinflussen.
Qualitätsprobleme
Defekte oder mit Bugs behaftete Software führt zu Verschwendung in Form von wiederholter Arbeit und geringer Kundenzufriedenheit.
Wann funktioniert IT-Outsourcing?
Und wann nicht ?
Qualität aufbauen
Der Grundsatz, Softwarequalität aufzubauen, geht über die natürliche Neigung von Fachleuten hinaus, nur gute Arbeit zu leisten. Es muss systematisch umgesetzt werden, um effektiv zu sein und gut gemeinte, aber verschwenderische Maßnahmen wie übermäßiges Testen oder die Aufzeichnung von Fehlern zu vermeiden.
Zu den Praktiken der Lean-Softwareentwicklung, die nachweislich die Produktqualität positiv beeinflussen, gehören:
Inkrementelle Entwicklung und schnelle Feedback-Schleifen.
Testorientierte Entwicklung, wie z. B. die Dokumentation der Bedingungen, die der zu schreibende Code erfüllen muss.
Minimierung von Wartezeiten durch Reduzierung von Aufgaben- und Kontextwechseln, um Konzentrationsverluste und Wissenslücken zu vermeiden.
Automatisierung möglichst vieler manueller, wiederholbarer Prozesse, die für menschliche Fehler anfällig sind.
„Pair Coding“ oder Partnerprogrammierung, d. h. es arbeiten immer zwei Entwickler gemeinsam an einem bestimmten Teil des Codes, z. B. einer User Story. Auf diese Weise profitiert der Code von der Kombination zweier Fähigkeiten und Erfahrungen und nicht nur von einer.
Wissen ausbauen
Auch das Pair Coding wird von der Lean Entwicklung als ein geeignetes Instrument vorgestellt, um das Prinzip der Weiterentbildung im Team zu unterstützen. Dieser Grundsatz fördert die Etablierung eines Systems, mit dem die erworbenen Kenntnisse und Erfahrungen dokumentiert und aufbewahrt werden. Neben der Partnerprogrammierung gibt es noch weitere empfehlenswerte Verfahren:
- Dokumentation
- Code-Reviews
- Gut kommentierter Code
- Ausbildung
- Sitzungen zum Wissensaustausch
- Wiki-Wissensdatenbank-System
- Verwendung von Tools zur Verwaltung von Anforderungen bzw. User Stories
Commitment (Engagement) aufschieben
Es mag kontraintuitiv klingen, dass das Aufschieben von Verpflichtungen eher ein „Prinzip“ als ein Negativum ist. Aber das Aufschieben von Verpflichtungen in der Lean-Softwareentwicklung sollte nicht mit der Abwendung von Verantwortung verwechselt werden. Tatsächlich ist das Gegenteil der Fall. Das Offenhalten von Optionen ermutigt ein Lean-Software-Entwicklungsteam dazu, proaktiv Informationen und Feedback zu sammeln. Das Team wird nicht dazu gedrängt, sich auf etwas festzulegen, bevor die erforderlichen Daten vorliegen, um fundierte Entscheidungen zu treffen.
Das Aufschieben von Verpflichtungen bedeutet, dass es sich bei den Dingen, für die man sich entscheidet, um gut begründete Entscheidungen handelt. In der Praxis bedeutet die Einhaltung des Prinzips des Aufschubs von Verpflichtungen, dass man nicht schon Monate im Voraus detaillierter als nötig plant, weil sich die Dinge ändern könnten und die Planung dann neu erstellt werden muss.
Es bedeutet auch, dass man sich nicht auf Ideen und Projekte festlegen sollte, bevor man die Geschäftsanforderungen vollständig verstanden hat. Außerdem ist das Sammeln und Analysieren von Informationen, die Entscheidungen beeinflussen könnten, ein laufender, strukturierter Prozess.
Schnell abliefern
Bei der Einhaltung dieses Lean-Prinzips geht es nicht nur darum, im allgemeinen Sinne „so schnell wie möglich Ergebnisse zu liefern“. Es beruht auf der aktiven, systematischen Vermeidung von Faktoren, die Entwicklungsteams ausbremsen können, wie z. B:
- zu weit im Voraus zu denken und zu planen
- Nicht schnell und effektiv genug auf Hindernisse zu reagieren.
- Übermäßiges Ausarbeiten der Geschäftsanforderungen sowie ihrer Lösungen.
Unter Lean geht es bei der schnellen Auslieferung darum, nicht in die Falle von „more haste, less speed“ zu tappen. Es lohnt sich, im Vorfeld einige Zeit in die Dinge zu investieren, die bei Problemen zu einem späteren Zeitpunkt wertvolle Zeit kosten können, denn das tun sie in der Regel in gewissem Maße. Das Konzept der Lean-Softwareentwicklung, eine einfache Lösung schnell zu erstellen und freizugeben und sie dann auf der Grundlage von Kundenfeedback schrittweise zu verbessern, beruht auf der Erkenntnis, dass eine schnelle Markteinführung ein ungeheurer Wettbewerbsvorteil ist.
Mitmenschen respektieren
Der Respekt vor den Menschen ist der Lean-Grundsatz, der wahrscheinlich am häufigsten übergangen und auf abstrakte Verpflichtungen reduziert wird, anstatt die systematischen Praktiken und die Verantwortlichkeit für deren Einhaltung zu fördern, die der Lean-Ansatz verlangt. Lean-Softwareentwicklung schlägt vor, dass Lean-Teams die Einhaltung des Grundsatzes des Respekts vor den Menschen durch folgende Maßnahmen fördern:
- proaktiv und effektiv kommunizieren
- Ermutigung zu konstruktiven Meinungsverschiedenheiten, um Gruppendenken zu vermeiden
- alle arbeitsbezogenen Probleme der Teammitglieder im Team angehen.
- gegenseitige Ermutigung, gute Arbeit zu leisten.
Einige der spezifischen Werkzeuge, die Lean-Teams einsetzen können, um systematisch sicherzustellen, dass diese Dinge effizient erledigt werden, sind:
- Effiziente Einbindung der Gelegenheit, diese Dinge anzusprechen, in regelmäßige Besprechungen.
- Pair Programming, Code-Reviews, kommentierter Code und andere sich gegenseitig unterstützende und wissensfördernde Teamaktivitäten.
- Sorgfältige Rekrutierung auf organisatorischer Ebene, bei der die Soft Skills ebenso im Vordergrund stehen wie die Hard Skills.
- Überlegungen zum Teambuilding und zur Kompatibilität zwischen den Soft- und Hard Skills der Teammitglieder.
Gesamtsystem optimieren
Die Lean-Softwareentwicklung zeigt zwei Fallen auf, in die Lean-Entwicklungsteams häufig geraten. Die erste besteht darin, die Qualität des Codes im Streben nach einer schnelleren Veröffentlichung zu beeinträchtigen. Ein klassischer „more haste, less speed“-Fehler: minderwertiger Code erhöht die Komplexität der gesamten Codebasis der Software.
Das wiederum erhöht die Wahrscheinlichkeit von Fehlern und den Zeitaufwand für deren Behebung, was das Gesamtvolumen der Arbeit verstärkt und unwillkürlicherweise mehr Zeitdruck erzeugt – ein Teufelskreis.
Zu vermeiden ist auch der zweite Teufelskreis, dem sich Lean-Teams bewusst sein müssen: übermäßiges Testen. Wenn die Prüfenden überlastet sind, verlängern sich die Prüfzyklen und Feedbackschleifen. Längere Feedback-Schleifen erhöhen die Wahrscheinlichkeit, dass in der Zwischenzeit weiterhin mangelhafter Code produziert wird. Mehr minderwertiger Code oder andere Mängel bedeuten mehr Tests und noch längere Feedback-Schleifen von zunehmend überlasteten Testern.
Lean-Teams sollten versuchen, diese Art von Teufelskreisen durch ein besseres Verständnis der Teamkapazität und der nachgelagerten Auswirkungen der Arbeit aktiv zu vermeiden. Teams, die von Anfang an besser ausbalanciert sind und dazu ermutigt werden, bei der Verwaltung der Arbeitsabläufe ständig die gegenseitigen Abhängigkeiten zu berücksichtigen, vermeiden diese wertmindernden Fallen.
Die Entwicklung, das Testen und die Betriebsabläufe sind in ihrer gegenseitigen Beeinflussung im vor- und nachgelagerten Softwareentwicklungsprozess miteinander verbunden. Lean-Software-Entwicklungsteams sind sich bewusst, dass das Gesamtsystem optimiert und in seiner Zielsetzung vereinheitlicht werden muss, bevor ein einzelner Teil dies tun kann. Das ist auch der Grund, warum sich die Lean-Softwareentwicklung so gut und komplementär mit DevOps ergänzen lässt.
Lean vs. Agile Softwareentwicklung – konkurrierend oder ergänzend?
Doch was ist mit Lean und Agile und wie ergänzen diese beiden Konzepte sich untereinander oder nicht? Das Konzept der Lean-Softwareentwicklung wurde in einem Buch mit dem Titel „Lean Software Development: An Agile Toolkit“ vorgestellt und formalisiert.
Daraus geht hervor, dass die beiden Ansätze nebeneinander bestehen und sich gegenseitig ergänzen können, auch wenn beide von verschiedenen Personen unter verschiedenen Aspekten im Sinne von Kultur, Philosophien, Methodik und Frameworks bezeichnet werden.
Doch wie sieht die Beziehung zwischen Agile und Lean im Zusammenhang mit der Softwareentwicklung aus?
https://www.youtube.com/watch?v=aUd3xTdtXqI
Die agile Softwareentwicklung basiert auf dem Agilen Manifest. Sie zielt darauf ab, Teams zu befähigen und zu verpflichten, den Kunden auf iterative und inkrementelle Weise einen Mehrwert zu liefern.
Sowohl bei Lean als auch bei Agile geht es darum, eine bestimmte Denkweise zu vermitteln. Bei der agilen Denkweise geht es darum, anpassungsfähig zu sein und die Richtung auf der Grundlage der Kunden- und Marktanforderungen zu ändern. Bei Agile geht es darum, die Zusammenarbeit zu verbessern und schnell funktionierende Lösungen freizugeben.
Das Agile Mindset ermutigt Teams dazu, die Wertschöpfung eines Unternehmens aus einer Systemperspektive zu betrachten und den Arbeitsfluss zu rationalisieren.
Die Lean-Softwareentwicklung wird üblicherweise als agile Methodik bezeichnet. Lean ist jedoch wesentlich älter als das im Jahr 2001 verfasste „Agile Manifest„.
Das Hauptziel von Lean ist es, durch die Reduzierung von Verschwendung den Wert für den Verbraucher zu maximieren (Poppendieck, M. & Poppendieck, T., 2003).
Das Agile Manifest wurde stark von den Konzepten des Lean-Ansatzes für die Fertigung beeinflusst und übernahm viele dieser Konzepte in die Betrachtung der optimalen Vorgehensweise bei der Erstellung von Software. „Lean Software Development: an Agile Toolkit„, das 2003 veröffentlicht wurde, berücksichtigt in seinem Titel ausdrücklich den Einfluss des Agilen Manifests.
Agile und Lean werden im Kontext der Softwareentwicklung und inzwischen auch anderswo, vom Marketing bis zur Technik, in einer Feedback-Schleife voneinander beeinflusst. Die Schleife lässt sich in einer Weise darstellen, die dem Unendlichkeitssymbol von DevOps verblüffend ähnlich ist. DevOps ist ein weiterer Softwareentwicklungsansatz, der sich sowohl auf Agile als auch auf Lean stützt und dessen Beziehung zu beiden verwirrend sein kann.
Die Eckpfeiler aller drei Softwareentwicklungsmethoden, -philosophien, -kulturen oder systematischen Verfahrensweisen sind ein reduzierter Prozessaufwand, die Befähigung der Mitarbeiter und eine starke Fokussierung auf die Ergebnisse im Streben nach kontinuierlicher Verbesserung und Wertschöpfung.
Kann Lean als eigenständige Softwareentwicklungsmethodik eingesetzt werden?
Lean wird meist als eine Reihe von Prinzipien bzw. einer Philosophie betrachtet, die praktisch anwendbare agile Softwareentwicklungs-Frameworks wie Scrum oder Kanban untermauert. Es handelt sich dabei weniger um einen eigenständigen Prozess, der von Softwareentwicklungsteams angewandt wird. Das liegt wahrscheinlich daran, dass die meiste Literatur über Lean keine spezifischen Praktiken in der gleichen Weise definiert, wie es die agilen Frameworks tun.
Lean-Softwareentwicklungsteams bleibt es überlassen, ihre eigenen Praktiken auf der Grundlage der spezifischen Anforderungen des Projekts zu bestimmen, solange sie die Anwendung der Lean-Prinzipien fördern. Da die agilen Frameworks mit den Grundsätzen der Lean-Softwareentwicklung kompatibel sind, dienen sie dem Zweck, einen Prozess mit etablierten Praktiken bereitzustellen.
Das hier gezeigte Schaubild zeigt, dass nur 1 % der Softwareentwickler angibt, in ihrem Team eine Lean-Methodik zu nutzen.
Man könnte auch sagen, dass sie alle eine Lean-Methode anwenden. Oder zumindest einer agilen Methodik oder einem agilen Rahmen, der sich an den Lean-Prinzipien orientiert und mit ihnen vereinbar ist.
Im Jahr 2006 veröffentlichten Mary und Tom Poppendieck einen Nachfolger ihres ursprünglichen Buches „Lean Software Development“. „Implementing Lean Software Development: From Concept to Cash“ (Lean-Softwareentwicklung umsetzen – vom Konzept bis zur Umsetzung) befasste sich im ersten Buch, in erster Linie mit dem Mangel an einfach zu befolgenden Praktiken und stellte praktische Ratschläge und gebrauchsfertige Techniken vor, die Lean-Software-Entwicklungsteams anwenden können.
Es beinhaltet mehrere Best Practices zur Unterstützung der drei Jahre zuvor aufgestellten Grundsätze der Lean-Softwareentwicklung:
Versionsverwaltung und skriptgesteuerte Erstellung von Projekten
Versionsverwaltung und skriptgesteuerte Entwicklung schaffen Wissen, indem sie das gesamte Projektwissen des Teams an einem einzigen Ort zusammenfassen. Sie eliminieren Verschwendung, da durch die Automatisierung von Versionserstellungen manuelle Arbeit eingespart wird. Außerdem wird die Qualität verbessert, da durch die Automatisierung von Versionserstellungen eine Fehlerquelle eliminiert wird.
Tägliche Standups
Die Einführung täglicher Standup-Meetings fördert das Lean-Prinzip „Respekt vor den Menschen„, da diese Meetings eine teamorientierte Einstellung fördern. Die Teammitglieder wissen, was die anderen tun, und können bei Bedarf Hilfe leisten oder um Hilfe bitten, damit das Projekt effizient vorankommt. Sie schaffen Wissen, denn der Austausch von Informationen fördert das organisatorische Lernen durch den Wissensfluss von Einzelpersonen zu Gruppen.
Automatisiertes Testen
Automatisiertes Testen ist eine qualitätsfördernde Praxis, die sicherstellt, dass Tests regelmäßig und konsequent durchgeführt werden, wodurch Fehler vermieden und Probleme in einem früheren Stadium des Prozesses schnell erkannt werden. Die frühere Erkennung von Fehlern und Problemen bedeutet, dass sie leichter zu korrigieren sind, ehe sie sich auf andere Teile des Prozesses ausgewirkt haben, wodurch Zeitverschwendung vermieden wird. Außerdem schaffen regelmäßige Tests Erkenntnisse, da sie die Funktionsweise des Codes dokumentieren und die Teammitglieder beim Lernen unterstützen. Automatisierte Tests ermöglichen einen viel größeren Umfang und eine größere Tiefe der Untersuchungen, was wiederum mehr Lernmöglichkeiten bietet.
Kontinuierliche Integration
Die kontinuierliche Integration als Best Practice der Lean-Softwareentwicklung unterstützt das Prinzip der Qualitätssteigerung, da sie in Verbindung mit Tests die Qualität und Funktionalität des Codes sicherstellt. Die größere Effizienz der häufigen, kleinen Integrationen, die mit der kontinuierlichen Integration einhergehen, trägt im Vergleich zu längeren Integrationsphasen dazu bei, Verschwendung zu vermeiden.
Die kontinuierliche Integration unterstützt auch das Prinzip der schnellen Lieferung, indem sie die Vorlaufzeit für die Bereitstellung von Funktionen verkürzt.
Kurze Iterationen
Kurze Iterationen vermeiden Verschwendung, da sie effizienter sind als längere Integrationsphasen und kurze Iterationen bedeuten, dass neue funktionale Software schnell geliefert wird. Außerdem wird die Qualität dadurch gesteigert, dass den Kunden die Funktionen schnell und in Übereinstimmung mit den tatsächlichen Anforderungen geliefert werden.
Kundenbeteiligung
Bei der Lean-Software-Entwicklung ist die Beteiligung des Kunden eine der besten Vorgehensweisen. Die Einbeziehung des Kunden trägt zur Erkenntnisgewinnung bei, da sich durch die Zusammenarbeit die Anforderungen iterativ ermitteln und dann kontinuierlich verbessern lassen. Die Einbeziehung des Kunden bedeutet, dass das Endergebnis direkt mit den Anforderungen des Kunden übereinstimmt und somit die gewünschte Qualität gewährleistet wird. Die Beteiligung der Kunden während des gesamten Prozesses bedeutet außerdem, dass Entscheidungen nicht im Voraus getroffen werden müssen, was das Lean-Prinzip der Engagement Verschiebung unterstützt.
Lean kann als eigenständige Softwareentwicklungsmethodik eingesetzt werden. Die beiden Bücher The Lean Startup und Implementing Lean Software Development bieten beide einen solchen Bezugsrahmen. Normalerweise ist das aber nicht der Fall. Die meisten Softwareentwicklungsteams huldigen stattdessen den Lean-Prinzipien, indem sie nach einem der beliebten agilen Softwareentwicklungs-Frameworks arbeiten, über die das ursprüngliche Lean-System der Fertigung informiert.
K&C - Wir schaffen innovative Tech-Lösungen seit über 20 Jahren.
Kontaktieren Sie uns, um Ihre individuellen Bedürfnisse oder Ihr nächstes Projekt zu diskutieren.
