Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Editorials

Von Scrum zu Lean

by
Read Time:20 minsLanguages:

German (Deutsch) translation by Tatsiana Bochkareva (you can also view the original English article)

Während das Hauptziel von Scrum das Organisations- und Projektmanagement ist, geht es bei Lean mehr um die Optimierung von Prozessen, um schnell Qualitätsprodukte zu produzieren. Dies kann Ihr erster Schritt zur Übernahme agiler Prinzipien sein, oder es kann etwas sein, zu dem sich Ihr Team entwickelt, wenn Scrum nicht ausreicht. Ich lade Sie ein, die Geschichte meines Teams zu lesen und zu erfahren, wie wir uns von Scrum zu einem schlankeren Entwicklungsprozess entwickelt haben.


Eine kleine Geschichte

Lean ist eine Reihe von Prinzipien, die in den 1980er Jahren von der japanischen Automobilindustrie definiert wurden. Der Toyota-Qualitätsingenieur John Krafcik prägte den Begriff und beobachtete dabei die Prozesse und Werkzeuge, mit denen Abfälle in der Massenproduktion von Automobilen beseitigt werden. Erst 2003 stellten Mary und Tom Poppendieck Lean als Softwareentwicklungsprozess in ihrem Buch Lean Software Development: An Agile Toolkit vor.

Während Scrum eine Reihe von Regeln und Rollen ist, ist Lean eine Reihe von Prinzipien und Konzepten mit einer Handvoll Werkzeugs. Beide gelten als agile Techniken und teilen die gleiche Ideologie, schnell zu liefern und gleichzeitig Fehler und Irrtümer zu reduzieren. Ich betone immer die Anpassungsfähigkeit von Agile, kann aber die Tatsache nicht ignorieren, dass sich Scrum als obligatorisches Regelwerk darstellt. Tatsächlich würden Scrums religiöse Fans Blasphemie schreien, weil sie Scrums Regeln nicht genau befolgt hatten.

Lean hingegen ist offener; Seine Anhänger präsentieren den Prozess als eine Reihe von sehr anpassungsfähigen Empfehlungen.

Es ermutigt das Team oder Unternehmen, Entscheidungen zu treffen, und passt sich den Entscheidungen und alltäglichen Überraschungen an, mit denen Ihr Team und Ihr Unternehmen konfrontiert sind.

Als mein Team reifte und Scrum ausnutzte, hatten wir das Gefühl, dass einige Aspekte uns zurückhielten. Wir wurden ein ziemlich diszipliniertes und homogenes Team. Einige Besprechungen waren für uns nicht mehr angemessen, und wir stellten fest, dass die täglichen Besprechungen nicht effizient waren. Wir haben gelernt, dass Probleme schneller gelöst werden sollten, und wir hatten das Bedürfnis, diese Verfahren zu vermeiden, die uns zurückhielten.

Wir gehen weiter.


Zwei Hauptkonzepte von Lean

Lean stellt zwei Hauptkonzepte vor, aber die Kernideen sind: Abfallbeseitigung und Verbesserung des Arbeitsablaufs.

Abfall beseitigen

Wenn etwas kaputt geht, wird es am Freitag kaputt gehen.

Alles, was der Produktion im Wege steht, ist Abfall. Dies schließt verlorene Zeit, Materialreste und nicht genutzte Arbeitskräfte ein. Fehler im Endprodukt sind Verschwendung, Zeitverschwendung, um sie zu reparieren, Geldverschwendung, um sie zu ersetzen, und Verschwendung von Ressourcen, um andere Lösungen zu finden.

Das Konzept der Verschwendung lässt sich gut auf die Welt der Softwareentwicklung übertragen. Verschwendung kann durch verspätete Lieferungen, Fehler und Programmierer beschrieben werden, die nichts zu tun haben (verwechseln Sie dies nicht mit "Programmierer sollten acht Stunden am Tag ohne Pause und YouTube programmieren").

Durchfluss verbessern

Toyotas Lean-Konzept konzentriert sich auf den Produktionsfluss. In einer Produktionsanlage ist der Fluss eine Kette von Verfahren, die die Rohstoffe in ihre Endprodukte umwandeln. Diese Verfahren können sehr unterschiedlich sein und unterschiedliche Zeit in Anspruch nehmen. Sie können jedoch jeweils verbessert werden, um sie effizienter zu gestalten. Es ist ein ständiger Kampf, Engpässe zu finden und zu verbessern.

Ein idealer Ablauf ist ein Ablauf, bei dem jeder Schritt dieselbe Zeit und Mühe benötigt, um dieselbe Menge an Produkten herzustellen.

Dies bedeutet nicht, dass jeder Prozess den gleichen Geldbetrag kosten sollte, sondern, dass jeder Prozess mit der gleichen Leichtigkeit durchgeführt werden sollte.

Ironischerweise war Scrum das Werkzeug, das uns schließlich dazu brachte, die Verschwendung in unserem Projekt zu realisieren. Während wir uns in einigen Bereichen unserer Produktion an reines Scrum hielten, begannen wir, Fehler und/oder Verzögerungen zu identifizieren, die wir durch einen anderen Ansatz leicht vermeiden konnten.

Zu diesem Zeitpunkt wussten wir wenig über Lean. Wir haben einige Artikel zu diesem Theme gelesen, aber wir haben das Falsche getan und sie ignoriert, weil wir uns so auf unseren Scrum-Prozess konzentriert haben. Wir waren fast davon überzeugt, dass Scrum der Heilige Gral war, aber unser "Scrum-Maschinengewehr" fing an, Fehlzündungen zu verursachen. Wir mussten unseren Geist öffnen.


Die Prinzipien von Lean

Für die Softwareentwicklung wurden die Prinzipien von Lean in die folgenden sieben angepasst.

1 - Abfall beseitigen

Der Wechsel von Scrum zu Lean war tatsächlich befreiend.

In der Softwareentwicklung können Sie Verschwendung finden und beseitigen, indem Sie die Dinge erkennen, die verbessert werden müssen. In einem pragmatischen Sinne ist alles, was für den Kunden kein direkter Wert ist, Verschwendung. Um nur einige Beispiele zu nennen: Verschwendung ist ein Fehler, ein Kommentar im Code, eine nicht verwendete (oder selten verwendete) Funktion, Teams, die auf andere Teams warten, einen persönlichen Anruf entgegennehmen... Sie haben die Idee. Alles, was Sie, Ihr Team oder Ihr Produkt zurückhält, ist eine Verschwendung, und Sie sollten die entsprechenden Maßnahmen ergreifen, um es zu entfernen.

Ich erinnere mich, dass eines unserer Probleme die häufige Notwendigkeit war, schneller als zwei Sprints zu reagieren. Wenn Sie sich in Sprints entwickeln und die Scrum-Regeln einhalten, können Sie die dem aktuellen Sprint zugewiesenen Storys nicht ändern. Ein Team muss sich anpassen, wenn ein Benutzer einen Fehler findet und eine Lösung benötigt oder wenn der wichtigste Kunde eine Funktion wünscht, die in zwei Tagen problemlos abgeschlossen werden kann. Scrum ist in diesen Fällen einfach nicht flexibel genug.

2 - Lernen verstärken

Legen Sie großen Wert auf Bildung.

Sie haben Abfall und möchten in Zukunft natürlich weniger Abfall. Aber warum gibt es Abfall? Es kommt höchstwahrscheinlich von einem Teammitglied, das nicht genau weiß, wie man ein bestimmtes Problem angeht. Ist schon okay; niemand weiß alles. Legen Sie großen Wert auf Bildung.

Identifizieren Sie die Bereiche, die am meisten verbessert werden müssen (wissensbasiert), und beginnen Sie mit dem Training. Je mehr Sie und Ihr Team wissen, desto einfacher ist es, Abfall zu reduzieren.

Durch das Erlernen von Test Driven Development (TDD) kann beispielsweise die Anzahl der Fehler in Ihrem Code verringert werden. Wenn Sie Probleme bei der Integration der Module verschiedener Teams haben, möchten Sie möglicherweise wissen, was kontinuierliche Integration bedeutet, und eine geeignete Lösung implementieren.

Sie können auch aus dem Feedback der Benutzer lernen. Auf diese Weise erfahren Sie, wie Benutzer Ihr Produkt verwenden. Auf eine häufig verwendete Funktion kann möglicherweise nur zugegriffen werden, indem Sie durch fünf Menüs navigieren. Das ist ein Zeichen von Verschwendung! Möglicherweise geben Sie Programmierern und Designern zunächst die Schuld an dieser Verschwendung (und Sie haben möglicherweise Recht), aber Benutzer verwenden Ihre Software in der Regel auf eine Weise, die Sie nie beabsichtigt haben. Wenn Sie von Ihren Benutzern lernen, können Sie diese Art von Verschwendung vermeiden. Es hilft Ihnen auch, falsche oder unvollständige Anforderungen zu beseitigen. Benutzerfeedback kann ein Produkt auf Pfaden steuern, die Sie sonst nie in Betracht gezogen hätten.

Irgendwann stellte mein Team fest, dass bestimmte Module besser hätten geschrieben werden können, wenn wir am Anfang mehr über die Domain gewusst hätten. Natürlich gibt es keine Möglichkeit, die Zeit zurückzudrehen, und das Umschreiben eines großen Codeabschnitts ist nicht praktikabel. Wir haben uns entschlossen, Zeit zu investieren, um mehr über die Domain zu erfahren, wenn wir mit einer komplexeren Funktion beauftragt werden. Dies kann je nach Komplexität des Problems einige Stunden oder sogar Wochen dauern.

3 - Treffen Sie eine Entscheidung so spät wie möglich

Jede Entscheidung hat Kosten. Es mag nicht unmittelbar und materiell sein, aber die Kosten sind da. Wenn Sie Entscheidungen verschieben, können Sie sich umfassend auf die Probleme vorbereiten, mit denen Sie konfrontiert werden müssen. Das wahrscheinlich häufigste Beispiel für eine verzögerte Entscheidung ist das Datenbankdesign.

Entscheidungen müssen nicht technischer Natur sein. Durch die Kommunikation mit Kunden können Sie Entscheidungen treffen, die sich auf Ihre Herangehensweise an die Funktionen Ihrer Produkte auswirken.

Benutzer wissen jedoch nicht immer, was sie wollen. Wenn Sie Funktionsentscheidungen verschieben, bis die Benutzer die Funktion tatsächlich benötigen, erhalten Sie weitere Informationen zum Problem und können die erforderlichen Funktionen bereitstellen.

Wählen Sie die agile Methode, die für Sie und Ihr Team am besten geeignet ist.

Vor vierzehn Jahren traf das Team die Entscheidung, die Konfiguration der Anwendung in einer MySQL-Datenbank zu speichern. Sie haben diese Entscheidung zu Beginn des Projekts getroffen, und jetzt hat das aktuelle Team (mein Team) eine schwierige Belastung zu tragen. Glücklicherweise befindet sich dieses Produkt nicht mehr in der aktiven Entwicklung, aber wir müssen von Zeit zu Zeit darauf warten. Was eine einfache Aufgabe sein sollte, wird monumental riesig.

Auf der positiven Seite haben wir aus den Fehlern unserer Vorgänger gelernt. Wir treffen Programmier-, Architektur- und Projektentscheidungen so spät wie möglich. Tatsächlich haben wir diese harte Lektion gelernt, bevor wir Lean eingeführt haben. Schreiben Sie offenen und entkoppelten Code und schreiben Sie ein Design, das beständig und konfigurationsunabhängig ist. Das ist sicherlich schwieriger, spart Ihnen aber letztendlich in Zukunft viel Zeit.

Vor einiger Zeit haben wir unserem Produkt eine Funktion hinzugefügt, mit der Daten auf der Festplatte komprimiert werden. Wir wussten, dass es nützlich sein würde und wollten es so schnell wie möglich zu unserem Produkt hinzufügen. Wir haben mit einfachen Funktionen begonnen und Entscheidungen über Optionen und Konfiguration bis zu einem späteren Zeitpunkt vermieden. Nach einigen Monaten gaben die Benutzer Feedback, und wir haben diese Informationen verwendet, um unsere Entscheidungen über die Optionen und die Konfiguration der Funktion zu treffen. Wir haben die Funktion in weniger als einem Tag geändert, und kein einziger Benutzer hat sich beschwert oder mehr Funktionen angefordert. Es war eine einfache Modifikation; Wir haben den Code in dem Wissen geschrieben, dass wir in Zukunft eine Änderung vornehmen werden.

4 - Liefern Sie so schnell wie möglich

Wir leben in einer sich ständig verändernden Welt. Die Programme, die wir heute schreiben, sind für Computer gedacht, die in zwei Jahren veraltet sein werden. Moores Gesetz ist immer noch gültig und wird es auch weiterhin sein.

Die Liefergeschwindigkeit ist alles in dieser schnelllebigen Welt.

Wenn Sie ein Produkt in drei Jahren liefern, stehen Sie hinter dem Rudel. Daher ist es sehr wichtig, Ihren Kunden so schnell wie möglich einen Mehrwert zu bieten. Die Geschichte hat gezeigt, dass ein unvollständiges Produkt mit einer akzeptablen Anzahl von Fehlern besser ist als nichts. Außerdem haben Sie wertvolles Benutzer-Feedback.

Unsere Firma hatte einen Traum: Nach jedem Sprint liefern. Das ist natürlich in den meisten Fällen unpraktisch. Unsere Benutzer wollten nicht jede Woche oder jeden Monat ein aktualisiertes Produkt. Während wir uns bemühen, jede Version unseres Codes freizugeben, tun wir dies nicht. Wir haben gelernt, dass "schnell" das ist, was der Benutzer wahrnimmt - nicht das, was wir physisch können. In der Branche unseres Produkts bedeutet schnell regelmäßige Updates alle paar Monate und kritische Fehlerbehebungen innerhalb weniger Tage. So nehmen unsere Benutzer "schnell" wahr; Andere Arten von Produkten und Branchen haben andere Definitionen von "schnell".

5 - Stärken Sie das Team

Zuvor waren Programmierer in Büros eingesperrt und erledigten leise ihre Arbeit für ihr Unternehmen. Dies war das übliche Bild eines Programmierers Ende der neunziger Jahre, aber jetzt ist es nicht so.

Die Geschichte hat gezeigt, dass dieser Ansatz und das traditionelle Management von Wasserfallprojekten nicht für Software geeignet sind.

Zu einem bestimmten Zeitpunkt war es so schlimm, dass nur rund 5% aller Softwareprojekte tatsächlich ausgeliefert wurden. Millionen-Dollar-Unternehmen und -Produkte scheiterten in 95% der Fälle und führten zu enormen Verlusten.

Lean stellte fest, dass nicht motivierte Programmierer diese Verschwendung verursachten. Aber warum die mangelnde Motivation? Nun, Programmierer und Entwicklungsteams wurden nicht angehört. Das Unternehmen stellte Aufgaben und verwaltete die Mitarbeiter, die nur als Ressourcen für die Erstellung von Quellcode angesehen wurden, im Mikromanagement.

Lean ermutigt Manager, Programmierern zuzuhören, und es ermutigt Programmierer, ihren Managern den Prozess der Softwareproduktion beizubringen. Es ermutigt Programmierer auch, direkt mit Kunden und Benutzern zu arbeiten. Dies bedeutet nicht, dass die Entwickler alles tun, aber es gibt ihnen die Möglichkeit, die Entwicklung der Produktion zu beeinflussen. Überraschenderweise hatte ich das Gefühl: "Sie kennen das großartige Feature, das die Benutzer lieben? Es war meine Idee!" ist ein großer Motivationsfaktor.

Aber denken Sie nicht, dass dies nur für große Teams funktioniert. Unser Team ist klein. Unser Unternehmen hat nur eine Handvoll Entwickler, daher waren wir unseren Benutzern immer nahe. Diese Beziehung hat es uns ermöglicht, unser Produkt über das hinaus zu beeinflussen, was sich unsere Manager ursprünglich vorgestellt hatten.

6 - Integrität aufbauen

Alles, was der Produktion im Wege steht, ist Abfall.

Bei Integrität geht es um die Robustheit Ihres Produkts und darum, wie Kunden Ihr Produkt als Ganzes sehen. Bei Integrität geht es um Einheitlichkeit, Zuverlässigkeit und Sicherheit der Benutzeroberfläche und darum, dass sich der Benutzer bei der Verwendung Ihres Produkts sicher fühlt. Integrität ist das vollständige Image, das der Benutzer für Ihr Produkt erstellt. Die Integrität der Benutzeroberfläche umfasst beispielsweise das Erscheinungsbild zwischen Seiten, Bildschirmen, Modulen oder sogar zwischen der Benutzeroberfläche Ihres Systems und der Website des Unternehmens.

Integrität kann aber auch auf Quellcode-Ebene beobachtet und geübt werden. Integrität kann bedeuten, dass Ihre Module, Klassen und andere Teile auf ähnliche Weise geschrieben sind. Sie verwenden in Ihrer gesamten Codebasis dieselben Prinzipien, Muster und Techniken - auch zwischen verschiedenen Teams. Integrität bedeutet, dass Sie Ihren Code häufig umgestalten müssen. Es ist kontinuierliche und endlose Arbeit, und Sie sollten danach streben, sie aber niemals erreichen.

Die Aufrechterhaltung der Integrität in unserem Quellcode ist eine schwierige Aufgabe. Wir haben erkannt, dass es am schwierigsten ist, doppelten Code zu finden, und mit Duplizieren meine ich nicht ein paar Zeilen doppelten Codes in derselben Methode oder Klasse.

Es geht nicht einmal darum, in verschiedenen Modulen nach genau demselben Code zu suchen. Es geht darum, diese Teile der gemeinsamen Logik zu finden, sie in ihre eigenen Klassen zu extrahieren und sie an mehreren Stellen zu verwenden.

Das Auffinden logischer Duplikate ist sehr schwierig und erfordert genaue Kenntnisse des Quellcodes.

Ich bin seit mehr als einem Jahr im selben Projekt und bin immer noch überrascht, wenn ich doppelten Code finde. Aber das ist gut so; Wir haben einen Punkt erreicht, an dem wir diese Dinge tatsächlich sehen und Maßnahmen ergreifen. Seit wir begonnen haben, doppelte Logik auf hoher Ebene aktiv zu entfernen, hat sich unsere Codequalität erhöht. Wir sind der Erreichung der Integrität einen Schritt näher gekommen.

7 - Das Ganze sehen

Benutzer wissen nicht immer, was sie wollen.

Wenn Sie Ihre Anwendung erstellen, müssen Sie über die Komponenten von Drittanbietern nachdenken, auf die Sie sich verlassen, um Ihr Produkt zu entwickeln, sowie über die anderen Drittanbieter, mit denen Ihr Produkt kommuniziert. Ihre Anwendung muss in das Design eines Geräts oder des Betriebssystems auf einem Desktop-PC integriert werden. Ist es nicht einfacher, eine App zu verwenden, die in das Benachrichtigungssystem Ihres Smartphones integriert ist und deren Benutzeroberfläche die Benutzeroberfläche des Betriebssystems widerspiegelt?

Ja, das Ganze zu sehen ist nicht so einfach. Sie müssen sich von den winzigen Details lösen und Ihr Produkt aus der Ferne betrachten. Einer der denkwürdigen Momente in der Entwicklung unseres Produkts war, als wir erkannten, dass wir uns darauf verlassen müssen, was andere Programmierer in anderen Projekten produzieren. Wir haben festgestellt, dass der von anderen programmierte Kernel des Systems eine dieser Komponenten von Drittanbietern ist, auf die wir uns verlassen.

Zu einem bestimmten Zeitpunkt wurde diese Komponente eines Drittanbieters geändert. Wir hätten einfach Band-Aids auf unsere Anwendung anwenden können, oder wir hätten den einfachen Weg gehen und den Programmierern die Schuld geben können, die diese Komponente geschrieben haben. Stattdessen haben wir das Problem bei den Hörnern gepackt und das Problem im Kernel eines Drittanbieters behoben. Das Ganze zu sehen und damit zu arbeiten kann chaotisch sein, aber es kann den Unterschied zwischen einem Produkt und einem großartigen Produkt ausmachen.


Kanban - Ein großartiges Werkzeug

Es gibt verschiedene Werkzeugs und Techniken, mit denen Lean funktioniert. Ich bevorzuge Kanban, ein Board-basiertes Werkzeug, das Scrums Plantafel ähnelt. Stellen Sie sich ein Kanban-Brett als Doppeltrichter vor.

Links ist die unendliche Liste der Geschichten, die wir ansprechen müssen. Alle fertigen Storys stapeln sich rechts und der Manager oder Product Owner bestimmt anhand dieser Liste, wann eine neue Version veröffentlicht werden soll.

In der Mitte steht unser effektiver Kanban-Prozess. Das Produkt sollte sich in einem stabilen und Release-fähigen Zustand befinden, wenn wir eine Story fertigstellen. Dies bedeutet nicht unbedingt, dass eine Funktion ausgeführt wird. Das Produkt verfügt möglicherweise über einige teilweise implementierte Funktionen. Die Stabilität, Sicherheit und Robustheit des Produkts sollte jedoch die Produktionsqualität sein.

Mehr Flexibilität mit Releases

Mit unserem aktuellen Sprint haben wir uns ganz gut geschlagen. Es war ein gewöhnlicher Montag, ein ruhiger Tag mit wenig Aufregung, aber am Mittwoch stellten wir einige Probleme fest. Das ist in Ordnung, es passiert die ganze Zeit. Die Überwindung dieser Schwierigkeiten erforderte jedoch einige zusätzliche Zeit. Unser Product Owner hat mit uns vereinbart, weiter an der aktuellen Funktion zu arbeiten und den aktuellen Sprint um drei oder vier zusätzliche Tage zu verlängern.

Der Freitag kam mit einer Überraschung. Sie kennen die Regel: Wenn etwas kaputt geht, bricht es am Freitag. Ein wichtiger und potenzieller Kunde benötigte eine bestimmte Funktion, bevor er einen Vertrag mit dem Unternehmen unterzeichnete. Wir mussten reagieren (und zwar schnell!). Eine neue Version war obligatorisch... Aber warten Sie! Wir sind mitten im Sprint. Das Produkt sollte bis zum Ende des Sprints einsatzbereit sein. Was machen wir? Scrum würde sagen, dass wir das neue Feature im nächsten Sprint machen sollen, aber wir sind bereits zu spät mit dem aktuellen Sprint! Damals wurde uns klar, dass wir in weniger als einem Sprint denken mussten. Wir müssen in der Lage sein, uns schneller anzupassen, und wir müssen bei Bedarf schneller veröffentlichen.


Das Kanban Board

Ein Kanban-Board sieht einem Scrum-Planungsboard ziemlich ähnlich, jedoch mit einigen Ergänzungen, um den Lean-Prozess besser zu unterstützen.

Die erste Spalte links ist der vollständige Rückstand: alles, was wir irgendwann tun müssen. Ganz rechts haben Sie den anderen Trichter, der alle abgeschlossenen (aber nicht veröffentlichten) Geschichten enthält.

In der Mitte ist unser Prozess. Diese Spalten können je nach Team und Prozess unterschiedlich sein. Es wird allgemein empfohlen, mindestens eine Spalte für die folgenden Aufgaben und eine weitere Spalte für Geschichten zu haben, die derzeit entwickelt werden. Das obige Bild zeigt mehrere weitere Spalten, um den Entwicklungsprozess besser darzustellen.

In der Spalte Aufgaben werden die Aufgaben aufgelistet, die wir ausführen müssen. Dann haben wir Design, wo Entwickler an der Gestaltung der aktuellen Geschichten arbeiten. Die vierte Spalte ist Entwicklung, die eigentliche Codierung. Schließlich werden in der Spalte Testen die Aufgaben aufgelistet, die auf die Überprüfung durch einen anderen Teamkollegen warten.

Begrenzen Sie die laufenden Arbeiten

Niemand weiss alles.

Wenn Sie dieses Kanban-Board mit einem Scrum-Planungsboard vergleichen, werden Sie sofort die offensichtlichen Unterschiede bemerken. Erstens hat jede Spalte eine Nummer, die die maximale Anzahl von Storys darstellt, die sich in dieser Spalte befinden dürfen. Wir haben vier Aufgaben, vier im Design, drei in der Entwicklung und zwei im Testen. Der Rückstand und die erledigten Aufgaben haben keine solche Begrenzung.

Der Wert jeder Spalte muss vom Team definiert werden. Im obigen Bild habe ich den Spalten beliebige Zahlen zugewiesen. Ihre Zahlen können sich erheblich unterscheiden. Auch die Zahlen sind nicht endgültig. Passen Sie die Zahlen an, wenn Sie Engpässe identifizieren und beseitigen.

Ressourcen dynamisch zuweisen

Eine der erstaunlichsten Eigenschaften von Kanban und Lean ist die Bedeutung der Zusammenarbeit und der Neuzuweisung von Anstrengungen. Wie Sie an der Tafel sehen können, enthält jede Spalte unseres Prozesses Karten mit Personen darauf. Auf dem Beispielboard befinden sich acht Entwickler - ein ziemlich großes Team! Das Board zeigt immer den aktuellen Status an, wer was zu einem bestimmten Zeitpunkt tut.

Laut unserem Board arbeiten drei Personen am Design, zwei Paare an der Entwicklung und ein Entwicklertest. Geschichten werden in die nächste Spalte verschoben, sobald die Arbeit in der aktuellen Spalte abgeschlossen ist. Abhängig von der Art der Entwicklung und Organisation des Teams kann derselbe Entwickler weiterhin an derselben Geschichte arbeiten, während er sich durch den Prozess bewegt.

Nehmen wir an, wir haben spezialisierte Leute. Die Hauptfunktion der drei Designer ist also das Design, die vier Entwickler schreiben Code und der einsame Tester testet hauptsächlich das Produkt/die Funktion. Wenn ein Designer eine Geschichte beendet, wird die Geschichte weiterentwickelt und eine andere Geschichte aus der To-Do-Liste wird in das Design übernommen.

Dies ist ein normaler Prozess. Eine Geschichte wurde vom Design zur Entwicklung verschoben, und jetzt ist die Entwicklung am höchsten. Aber was ist, wenn ein anderer Designer eine andere Geschichte beendet? Das gibt dem Entwicklerteam vier Geschichten - eine unerwünschte Situation.

Lean möchte Staus vermeiden. Es ist verboten, eine Story in die nächste Spalte zu verschieben, wenn sie das Maximum der Spalte überschreitet. In diesem Fall müssen die Ressourcen neu zugewiesen werden. Der Designer, der seine Aufgabe erledigt hat, muss entscheiden, was als nächstes zu tun ist. Seine erste Option besteht darin, eine andere Aufgabe aus der To-Do-Spalte zu ziehen. Dies kann er jedoch nicht, da er seine neu abgeschlossene Aufgabe an das Entwicklungsteam übergeben muss (was er nicht tun kann). Seine einzige andere Möglichkeit ist, an einer Entwicklungsgeschichte zu arbeiten. Er ist vielleicht nicht der beste Entwickler, aber seine Bemühungen werden dazu beitragen, den Prozessfluss aufrechtzuerhalten.

Wenn der Tester die letzte Geschichte in seiner Kolumne beendet, kann er dem Designer bei seiner Entwicklungsaufgabe helfen.

Das ist toll! Das Team kann sich schnell neu organisieren! Sehen Sie eine Verschwendung? Sehen Sie einen Engpass im Fluss? Sofort handeln!

Sobald eine Story in der Entwicklungsspalte abgeschlossen ist, kehrt der Tester zum Testen zurück, der Designer zum Entwerfen, und die Entwickler greifen die Story auf, an der der Designer und der Tester gearbeitet haben. Denken Sie jedoch daran, dass Sie dieses genaue Rezept nicht befolgen müssen. Der Entwickler konnte mit dem Entwerfen beginnen, als der Designer und der Tester die Entwicklung ihrer Geschichte beendet hatten. Es liegt an dir!

Unser Board ist jetzt wieder normal.

Willkommen Scrum-Ban

Es ist verboten, eine Story in die nächste Spalte zu verschieben, wenn sie das Maximum der Spalte überschreitet.

Ich sah mit Nostalgie zu, wie unser Scrum Master unser Board zerlegte. Stück für Stück riss er unser geliebtes Brett ab, das dann zu einem Berg zerknitterten Papiers wurde.

Ein anderer Kollege betrat den Raum, ein paar riesige Blätter frisches weißes Papier in den Händen. Unser Board sollte in etwas anderes wiedergeboren werden, etwas, das besser zu unseren Bedürfnissen passt. Nachdem die Papierblätter an der Wand waren, starteten wir ein Ad-hoc-Meeting, um die Spalten zu definieren, die wir zur Definition unseres Prozesses benötigten. Wir haben dann die Anzahl der Geschichten diskutiert, die in jeder Spalte enthalten sein sollten. Nachdem alles sorgfältig an die Wand gemalt und angeordnet worden war, erlebten wir dieses seltsame Gefühl... Traurigkeit für das Alte, aber Glück für das Neue.

Wir haben etwas gemacht, das viele Leute nennen, Scrum-Ban. Wir haben einige Scrum-Konzepte beibehalten, z. B. die Scrum-Master- und Product-Owner-Rollen, und wir schätzen und bewerten die Storys weiterhin. Jetzt konzentrieren wir uns auf Lean und Kanban, die Erhaltung des Flusses sowie die Entdeckung und Behebung von Abfällen und Engpässen.

Der Wechsel von Scrum zu Lean war tatsächlich befreiend. Die Teammitglieder wurden viel freundlicher miteinander und wir haben verstanden, dass wir Hilfe anbieten sollten, sobald nichts in unserer Kolumne ist. Dieses Gefühl, dass Entwickler wichtig sind, ließ uns über das gesamte Projekt nachdenken. Wir kümmern uns mehr um das Projekt als jemals zuvor.


Schlussfolgerung

Lean galt nicht immer als agil. Noch heute weigern sich einige Agilisten, es als agile Methode anzuerkennen. Aber immer mehr Programmierer akzeptieren Lean als eine der ultimativen agilen Methoden.

Wie einer meiner weisen Kollegen betonte, können Sie mit Lean und Kanban diese Methode selbst anwenden. Wenn Sie ein Einzelentwickler sind und Werkzeugs benötigen, die Ihnen das Leben erleichtern, probieren Sie einige kostenlose Kanban-Werkzeugs aus.

Die AgileZen-Website bietet ein kostenloses Konto, mit dem Sie ein einzelnes Projekt verfolgen können.

Ich fand es eines der besten kostenlosen Online-Kanban-Werkzeugs. Ich benutze es sogar jeden Tag, um den Fortschritt der Artikel und Kurse, die ich für Tuts+ anbiete, zu verfolgen und zu planen. Natürlich können Sie Ihr AgileZen-Konto jederzeit aktualisieren, wenn Sie weitere Projekte verfolgen müssen.

In diesem Artikel haben wir Lean und Kanban als eine Weiterentwicklung von Scrum betrachtet. Bedeutet das, dass Lean besser ist als Scrum? Absolut nicht! Dies hängt von den Projekten und Personen ab, mit denen Sie arbeiten. Wählen Sie wie immer die agile Methode, die für Sie und Ihr Team am besten geeignet ist.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.