WikiDer > Schlanke Softwareentwicklung

Lean-softwareontwikkeling

Schlanke Softwareentwicklung, oder der englische Originalbegriff schlanke Softwareentwicklung (LSD), ist eine Kombination aus empfohlene Vorgehensweise von schlanke Fertigung, schlanke IT und der Agile Software Entwicklung.

Ursprung

Der Name schlanke Softwareentwicklung stammt aus einem gleichnamigen Buch aus dem Jahr 2003 von Maria Poppendieck und Tom Poppendieck.[1] das buch beschreibt das traditionelle schlanke Prinzipien in modifizierter Form, sowie die 22 Werkzeuge, die ihrer Meinung nach dafür verwendet werden können. Sie vergleichen diese Tools mit den Best Practices von Agile. Das Engagement der Poppendiecks in der agilen Community, ergänzt durch ihre Präsenz und Präsentationen auf Konferenzen aller Art, einschließlich ihrer Videos[2], trugen zur Verbreitung ihrer Ideen bei. Auch deshalb entsteht derzeit eine pro-schlanke Subkultur innerhalb der agil Gemeinschaft.

Schlanke Prinzipien

Lean Software Development lässt sich in sieben Prinzipien zusammenfassen, die den Prinzipien der Lean Production sehr ähnlich sind:

  1. Verschwendung vermeiden
  2. Den Lerneffekt verstärken
  3. Entscheide dich so spät wie möglich
  4. Liefere so schnell wie möglich
  5. Geben Sie dem Team Verantwortung
  6. Qualität
  7. Sehen Sie das Ganze

Abfall vermeiden

Alles, was für den Kunden keinen Mehrwert bringt, wird als Verschwendung angesehen (Muda). Unter anderem:

Um Abfall beseitigen zu können, muss dieser erst erkannt werden. EIN Wertstromanalyse Technik wird häufig verwendet, um Abfall zu erkennen und dann zu entfernen. Dies muss so oft wiederholt werden, bis auch anfangs essentiell erscheinende Prozesse entfernt werden können. Beispielsweise; wenn einige Aktivitäten übersprungen werden können oder das Ergebnis auch ohne diese Aktivität auf andere Weise erreicht werden kann, kann dieser Vorgang entfernt werden. Teilweise erledigte und unvollendete Programmierarbeit ist verschwenderisch und kann gelöscht werden. Das Erstellen und Verwalten zusätzlicher unerwünschter Funktionen und Funktionen, die selten verwendet werden, ist eine Verschwendung. Auf andere Aktivitäten, Teams, Personen oder Prozesse zu warten ist eine Verschwendung. Fehler und schlechte Qualität sind Verschwendung. Management-Overhead, der keinen echten Mehrwert schafft, ist Verschwendung.

Den Lerneffekt verstärken

Die Entwicklung von Software ist ein kontinuierlicher Lernprozess, der durch die Zusammenarbeit in Teams noch verstärkt wird. Der beste Ansatz zur Verbesserung der Softwareentwicklung besteht darin, den Lerneffekt zu verstärken. Anhäufung von Fehlern sollte durch möglichst frühzeitiges Testen, vorzugsweise vor der Programmierung, verhindert werden. Anstatt mehr Dokumentationen oder eine detaillierte Planung zu machen, ist es besser, verschiedene Ideen auszuprobieren. Indem man diese dem Nutzer zeigt, wird schneller klar, was seine Wünsche sind.

Der Lernprozess wird durch kurze Verbesserungszyklen beschleunigt, verbunden mit Refactoring und Integrationstests. Durch kurze Feedbackgespräche mit jedem kurzen Verbesserungszyklus/Iteration wird schnell jedem klar, welche Möglichkeiten und Wünsche bestehen, was dem Lerneffekt und zukünftigen Verbesserungen zugute kommt. Während dieser kurzen Sitzungen lernen sowohl die Kunden-/Anwendervertreter als auch das Entwicklungsteam mehr über das Problemfeld, um sich auf mögliche Lösungen zu konzentrieren. Auf diese Weise verstehen die Kunden besser, was sie wollen, basierend auf dem, was ihnen geliefert wird, und die Entwickler lernen besser, diese Wünsche zu verwirklichen.

Ein anderer Ansatz zur Kommunikation und zum Lernprozess ist die sogenannte "setbasierte Entwicklung" oder die Theorie der Beschränkungen. Bei diesem Vorgehen werden die Voraussetzungen der zukünftigen Lösung aufgezeigt und dem Entwicklungsteam die Möglichkeit gegeben, nach Lösungen zu suchen, ohne dass dies vom Kunden sofort weiter eingeschränkt wird. Dies fördert die Lösungsentwicklung durch Kundendialog statt durch Kundendiktat. Es fördert die Nutzung der kreativen Lösungskompetenz der Entwickler und steigert so deren Motivation.

Entscheide dich so spät wie möglich

Die Entwicklung von Software ist immer mit Unsicherheit behaftet. Bessere Ergebnisse können erzielt werden, indem man eine mehrgleisige Politik verwendet, gleichzeitig an mehreren möglichen Lösungsrichtungen arbeitet und die endgültigen Entscheidungen so lange wie möglich hinauszögert, bis sie auf Fakten statt auf unsicheren Annahmen und Vorhersagen getroffen werden können. Je komplexer das System ist, desto flexibler muss der Entwicklungsprozess sein, damit möglichst spät irreversibel teure Entscheidungen getroffen werden können. Der schrittweise iterative Ansatz basiert auf diesem Prinzip; die Fähigkeit, auf Änderungen zu reagieren und Fehler zu korrigieren, Fehler, die sehr teuer werden können, wenn sie spät im Prozess erkannt werden.

Beim flexiblen agilen Vorgehen werden dem Kunden frühzeitig Zwischenschritte und Optionen aufgezeigt, so dass er die Möglichkeiten und Unmöglichkeiten besser überblicken kann, wobei endgültige Entscheidungen aufgeschoben werden, bis der Kunde sich seiner Wünsche bewusster ist. Dadurch ist es auch möglich, relativ spät auf veränderte Anforderungen zu reagieren, um teure technische Frühentscheidungen zu vermeiden. Das heißt nicht, dass man gar nicht planen sollte, im Gegenteil, man sollte sich auf die verschiedenen Möglichkeiten konzentrieren und sich der aktuellen Situation anpassen. Pläne sollten auch Einblicke in die verschiedenen Möglichkeiten des schnellen Handelns geben. Die Bewertung verschiedener Optionen ist ein effektiver Ansatz, wenn man versteht, dass das Offenhalten der verschiedenen Optionen auch Geld kostet, aber Flexibilität bietet, um späte Entscheidungen zu treffen.

Liefere so schnell wie möglich

Im Zeitalter der rasanten technischen Entwicklung überlebt nicht der Größte, sondern der Schnellste. Je schneller das Endprodukt ohne größere Fehler geliefert wird, desto schneller kommt Feedback und desto schneller kann es in das nächste aufgenommen werden Verbesserung. Je kürzer die Iterationen, desto schneller erfolgt die Kommunikation und desto schneller lernt das Team. Aufgrund dieser Geschwindigkeit können Entscheidungen verschoben werden. Geschwindigkeit sorgt für die Umsetzung der aktuellen Wünsche des Kunden und nicht das, was er gestern brauchte. Dies gibt ihnen die Möglichkeit, die Entscheidungsfindung zu verzögern, bis sie ein besseres Verständnis dafür haben, was sie wollen. Kunden schätzen es in der Regel, wenn (Zwischen-)Ergebnisse schnell geliefert werden.

Das gerade rechtzeitig Produktionsideologie kann auch auf die Softwareentwicklung angewendet werden. Dies kann erreicht werden, indem das Team sich selbst organisieren und die Aufgaben untereinander aufteilen lässt. Zu Beginn des Prozesses und der Iteration liefert der Kunde den notwendigen Input. Dies kann in Form von kleinen Karten mit benutzergeschichten – dann schätzen die Entwickler, wie viel Zeit dafür benötigt wird. Dadurch wird die Arbeitsorganisation zu einem selbstziehendes System – Jeden Morgen während des „Stand-up-Meetings“ erzählt jedes Teammitglied, was er gestern gemacht hat, was er heute tun wird und was morgen. Kommentare werden von den anderen erbeten. Dadurch wird klar, was alle tun und wie sie zusammenarbeiten, was für die Teamkommunikation von Vorteil ist.

Eine weitere Grundidee im Produktentwicklungssystem von Toyota[3] das im Lean Thinking übernommen wurde und dann in der schlanken Softwareentwicklung ist es "Set-basiertes Design„Wenn zum Beispiel ein neues Bremssystem für ein Auto benötigt wird, können drei verschiedene Teams an einer Lösung dafür arbeiten. Jedes Team hört die Anforderungen und Wünsche inklusive der Einschränkungen und beginnt mit der Entwicklung einer möglichen Lösung Lösung erscheint unmöglich, sie wird eingestellt Am Ende der Entwicklungszeit werden die verbleibenden Designs verglichen und eines ausgewählt, möglicherweise mit einigen Anpassungen basierend auf den Erkenntnissen aus den anderen Designs. Beispiel für die Verschiebung einer Entscheidung bis zum letzten Möglicher Moment Softwareentwicklung kann diesen Ansatz auch verwenden, um das Risiko zu reduzieren, das durch die Erstellung großer Systemdesigns vor dem Bauprozess entsteht.

Geben Sie dem Team Verantwortung

Es gibt die traditionelle Sichtweise der organisatorischen Entscheidungsfindung, dass Manager den Mitarbeitern genau sagen, wie sie die Arbeit machen sollen. Das funktioniert gut, solange Manager genau wissen, was zu tun ist, was in gut berechenbaren Umgebungen der Fall ist, aber oft schon Lösungen / Standardprogramme dafür entwickelt wurden. In einer sogenannten „Work-Out“-Technik werden die Rollen vertauscht und Führungskräften beigebracht, den Entwicklern zuzuhören, damit diese besser erklären können, welche Maßnahmen zu ergreifen sind, sowie Verbesserungsvorschläge machen. Innerhalb des Lean-Ansatzes gibt es einen Befürworter des Sprichworts: "Gute Leute finden und die Arbeit machen lassen", diese Leute sollten auch gefördert, Fehler erkannt und Hindernisse beseitigt werden, aber es sollte nicht genau vorgeschrieben werden, was zu tun ist muss jede Sekunde getan werden, weil dies eine Verschwendung der kreativen Fähigkeiten des Entwicklers ist, Probleme zu lösen.[4]

Ein weiterer Fehler besteht darin, Menschen als "Marionetten" zu sehen. Der Mensch mag aus statistischer Sicht eine "Puppenfigur" sein, aber in Software-EntwicklungWie anderswo wollen Menschen nicht als "Marionetten" gesehen werden, daher brauchen Menschen mehr als nur eine Liste von Aufgaben und die Gewissheit, dass sie bei der Ausführung ihrer Arbeit nicht gestört werden. Die Leute brauchen oft so etwas wie Motivation und einen höheren Zweck zu arbeiten. Ein erreichbares Ziel, bei dem das Team angeben kann, wie es sich diesem nähert. Die Entwickler müssen daher auch mit den Kunden/Anwendern sprechen können; der Teamleiter muss sie in schwierigen Situationen erleichtern und unterstützen und muss verhindern Skepsis den guten Gruppenprozess gestört.[5] .

Qualität

Der Kunde soll einen guten Gesamteindruck vom Gesamtsystem haben: wie es in der Werbung verkauft wird, wie es geliefert, verwendet, zugänglich ist, wie benutzerfreundlich es ist, ob es preiswert ist und wie gut es Probleme löst. Diese müssen zusammenpassen und das ist die integrale Qualität, die der Kunde erlebt.

Bei der konzeptionellen Qualität geht es darum, ob die einzelnen Teile des Systems gut zusammenarbeiten, ob Flexibilität, Wartbarkeit, Effizienz in einem ausgewogenen Verhältnis stehen und das Ziel erreicht wird. Dies kann erreicht werden, indem man den Problembereich richtig versteht und gleichzeitig löst, nicht zuerst versteht und später löst. Die dafür notwendigen Informationen werden in kleinen Teilen, nicht im großen Ganzen wie bei den traditionellen Methoden, und am besten in Face-to-Face-Kommunikation, ohne (viel) schriftliche Dokumentation erhalten. Der Informationsfluss muss in beide Richtungen, vom Kunden zum Entwickler und zurück, konstant sein. Auf diese Weise wird vermieden, dass nach einer langen Zeit der isolierten Entwicklung etwas geliefert wird, das den Kunden unangenehm überrascht oder sogar verblüfft.

Ein guter Weg zu einer guten integrierten Architektur ist architecture Refactoring. Je mehr Schnickschnack dem Ganzen hinzugefügt wird, desto schwieriger wird es, es weiter zu verbessern. Beim Refactoring geht es darum, es einfach und klar zu halten. Wiederholungen im Code sind Anzeichen für schlechtes Design und sollten vermieden werden. Der gesamte automatisierte Build-Prozess muss von einem vollständigen, vorzugsweise automatisierten Satz von Tests begleitet werden, mit den gleichen Versionen und der gleichen Benennung wie das System, für das es entwickelt wurde. Am Ende jeder Iteration sollte die Qualität durch gründliche und vorzugsweise automatisierte Tests bestätigt werden, um sicherzustellen, dass das System das tut, was der Kunde vom System wünscht. Automatisierte Tests sind Teil des Produktionsprozesses. Wenn sie also keinen Mehrwert schaffen, werden sie auch verschwendet. Automatisiertes Testen sollte kein Selbstzweck sein, sondern ein Mittel zum Zweck, nämlich der Reduzierung von Verschwendung.

Sehen Sie das Ganze

Heutzutage sind Softwaresysteme mehr als eine Ansammlung von Teilen, es ist auch wichtig, wie diese Teile zusammenarbeiten. Fehler in der Software neigen dazu, sich während der Entwicklung anzuhäufen. Durch das Schneiden größerer Teile in kleinere Stücke wird alles überschaubarer. Auch die Standardisierung trägt dazu bei, Fehler zu reduzieren und die Software transparent zu machen, so dass weniger Fehler gemacht werden und, wenn sie gemacht werden, diese früher gefunden werden können. Es wird auch möglich, die zugrunde liegenden Fehlerursachen zu finden, um diese Ursachen zu beseitigen und Fehler zu vermeiden. Je größer das endgültige System, je mehr Organisationen an der Entwicklung beteiligt sind und je mehr Teile von verschiedenen Teams erstellt werden, desto wichtiger ist es, klar zu machen, wer was macht und wer wofür verantwortlich ist. Sonst wird es schwierig, ein System zu schaffen, in dem alles gut zusammenarbeitet. Bei einer längeren Entwicklungszeit ist es wichtiger, ein stärkeres Netzwerk mit Subunternehmern zu haben, als kurzfristige Gewinne zu erzielen, denn dies geht zu Lasten langfristiger Win-Win-Beziehungen.

Das „Lean“-Denken muss von jedem in einem Projekt verstanden werden, bevor es angewendet wird. „Das große Ganze sehen, kleine Schritte machen, sofort testen und schnell lernen“ (Think big, act small, fail fast; learn rapid) – diese Worte fassen gut zusammen, was in einem Lean-Projekt passiert und wie es sich auf den Softwareentwicklungsprozess auswirkt . Nur wenn alle Lean-Prinzipien gemeinsam angewendet werden, verbunden mit viel „gesundem Menschenverstand“ in Bezug auf das Arbeitsumfeld, nur dann ist die Grundlage für den Erfolg in success Software-Entwicklung.