Kanban (Entwicklung) - Kanban (development)
| Software-Entwicklung |
|---|
Kanban ( japanisch :看板, was Schild oder Billboard bedeutet ) ist eine schlanke Methode zur Verwaltung und Verbesserung der Arbeit über menschliche Systeme hinweg . Dieser Ansatz zielt darauf ab, die Arbeit zu verwalten, indem Bedarf mit verfügbarer Kapazität in Einklang gebracht und der Umgang mit Engpässen auf Systemebene verbessert wird .
Arbeitselemente werden visualisiert, um den Teilnehmern einen Überblick über den Fortschritt und den Prozess von Anfang bis Ende zu geben – normalerweise über ein Kanban-Board . Arbeit wird nach Maßgabe der Kapazitäten gezogen und nicht auf Anforderung in den Prozess geschoben.
In der Wissensarbeit und in der Softwareentwicklung geht es darum, ein visuelles Prozessmanagementsystem bereitzustellen , das bei der Entscheidungsfindung darüber hilft, was, wann und wie viel produziert werden soll. Die zugrunde liegende Kanban- Methode stammt aus dem Lean Manufacturing , das vom Toyota Production System inspiriert wurde . Es hat seinen Ursprung in den späten 1940er Jahren, als der Automobilkonzern Toyota ein Produktionssystem namens Just-in-Time einführte; mit dem Ziel, nach Kundenwunsch zu produzieren und mögliche Materialengpässe innerhalb der Produktionslinie zu erkennen. Aber es war Microsoft-Ingenieur David J. Anderson, der erkannte, wie diese von Toyota entwickelte Methode zu einem Prozess werden könnte, der auf jede Art von Unternehmen anwendbar ist, das Organisation benötigt. Kanban wird in der Softwareentwicklung häufig in Kombination mit anderen Methoden und Frameworks wie Scrum verwendet .
Entwicklung und Dokumentation der Methode
David Andersons Buch Kanban aus dem Jahr 2010 beschreibt eine Entwicklung des Ansatzes von einem 2004-Projekt bei Microsoft, das einen Theorie-of-Constraint- Ansatz verwendet und ein Trommelpuffer-Seil (vergleichbar mit dem Kanban-Pull-System ) verwendet, zu einem Projekt von 2006–2007 bei Corbis, in dem die Kanban-Methode identifiziert wurde. 2009 veröffentlichte Don Reinertsen ein Buch über die schlanke Produktentwicklung der zweiten Generation, das die Einführung des Kanban-Systems und die Verwendung von Datenerfassung und ein wirtschaftliches Modell für Managemententscheidungen beschreibt. Ein weiterer früher Beitrag kam von Corey Ladas, dessen Buch Scrumban aus dem Jahr 2008 vorschlug, dass Kanban Scrum für die Softwareentwicklung verbessern könnte . Ladas sah Scrumban als Übergang von Scrum zu Kanban. Jim Benson und Tonianne DeMaria Barry veröffentlichten 2011 Personal Kanban , das Kanban auf Einzelpersonen und kleine Teams anwendet. In Kanban from the Inside (2014) erläuterte Mike Burrows die Prinzipien, Praktiken und zugrunde liegenden Werte von Kanban und verknüpfte sie mit früheren Theorien und Modellen. In Agile Project Management with Kanban (2015) gibt Eric Brechner einen Überblick über Kanban in der Praxis bei Microsoft und Xbox . Kanban Change Leadership (2015) von Klaus Leopold und Siegfried Kaltenecker erläuterte die Methode aus der Perspektive des Change Managements und gab Orientierung für Change-Initiativen. Im Jahr 2016 veröffentlichte Lean Kanban University Press einen komprimierten Leitfaden zur Methode, der Verbesserungen und Erweiterungen aus den frühen Kanban-Projekten enthält.
Kanban-Boards
Das Diagramm hier zeigt einen Softwareentwicklungsworkflow auf einem Kanban-Board. Kanban-Boards, die für den Kontext, in dem sie verwendet werden, entwickelt wurden, unterscheiden sich erheblich und können Arbeitsaufgabentypen (hier "Features" und "User Stories") zeigen, Spalten mit Workflow-Aktivitäten, explizite Richtlinien und Swimlanes (Zeilen, die mehrere Spalten überqueren, verwendet) um hier User Stories nach Funktion zu gruppieren). Ziel ist es, den Teilnehmern und Stakeholdern den generellen Arbeitsablauf und den Fortschritt einzelner Items zu verdeutlichen.
Wie in Büchern über Kanban für die Softwareentwicklung beschrieben, bestehen die beiden Hauptpraktiken von Kanban darin, Ihre Arbeit zu visualisieren und die laufende Arbeit (WIP) zu begrenzen. Vier weitere allgemeine Kanban-Praktiken, die in Essential Kanban Condensed aufgeführt sind , bestehen darin, Richtlinien explizit zu machen, den Fluss zu verwalten, Feedbackschleifen zu implementieren und gemeinsam zu verbessern.
Das Kanban-Board im obigen Diagramm hebt die ersten drei allgemeinen Praktiken von Kanban hervor.
- Es visualisiert die Arbeit des Entwicklungsteams (die Features und User Stories).
- Es erfasst WIP-Limits für Entwicklungsschritte: die eingekreisten Werte unter den Spaltenüberschriften, die die Anzahl der Arbeitselemente unter diesem Schritt begrenzen.
- Es dokumentiert Richtlinien, auch als Fertigregeln bekannt, in blauen Rechtecken unter einigen der Entwicklungsschritte.
- Es zeigt auch einige Kanban-Flow-Management für die Schritte "Vorbereitung der User Story", "Entwicklung der User Story" und "Feature Acceptance", die die Unterspalten "In Bearbeitung" und "Bereit" haben. Das WIP-Limit jedes Schritts gilt für beide Unterspalten, wodurch verhindert wird, dass Arbeitsaufgaben den Fluss in oder aus diesen Schritten überfordern.
Workflow verwalten
Kanban verwaltet den Workflow direkt auf dem Kanban-Board. Die WIP-Limits für Entwicklungsschritte geben Entwicklungsteams sofortiges Feedback zu häufigen Workflow-Problemen.
Auf dem oben gezeigten Kanban-Board hat der Schritt "Bereitstellung" beispielsweise ein WIP-Limit von fünf und es werden derzeit fünf Epics in diesem Schritt angezeigt. Es können keine weiteren Arbeitselemente in die Bereitstellung verschoben werden, bis ein oder mehrere Epics diesen Schritt abgeschlossen haben (Wechsel zu "Zugestellt"). Dadurch wird verhindert, dass der Schritt "Deployment" überfordert wird. Teammitglieder, die an "Feature Acceptance" (dem vorherigen Schritt) arbeiten, können stecken bleiben, weil sie keine neuen Epics bereitstellen können. Sie können sofort an der Tafel sehen, warum und bei den aktuellen epischen Bereitstellungen helfen.
Sobald die fünf Epics im Schritt "Deployment" geliefert wurden, können die beiden Epics aus der Unterspalte "Ready" von "Feature Acceptance" (dem vorherigen Schritt) in die Spalte "Deployment" verschoben werden. Wenn diese beiden Epics geliefert werden, können keine anderen Epics bereitgestellt werden (vorausgesetzt, es sind keine neuen Epics bereit). Jetzt stecken Teammitglieder, die an der Bereitstellung arbeiten, fest. Sie sehen sofort, warum und helfen bei der Feature-Akzeptanz.
Diese Workflow-Steuerung funktioniert für jeden Schritt ähnlich. Probleme sind sofort sichtbar und sichtbar, und eine Neuplanung kann kontinuierlich durchgeführt werden. Die Arbeitsverwaltung wird ermöglicht, indem die laufende Arbeit so begrenzt wird, dass die Teammitglieder jederzeit sehen und verfolgen können.
Kanban-Metriken
Kanban verwendet spezifische Metriken, um die Teamkapazität zu messen und die Projektdauer abzuschätzen.
Team Velocity definiert, wie viele Aufgaben ein Team in einem bestimmten Zeitraum, beispielsweise einer Woche oder einer Iteration, erledigen kann. Die Geschwindigkeit wird regelmäßig berechnet und um die Genauigkeit der berechneten Geschwindigkeit zu verbessern, versuchen Teams, Aufgaben mit ähnlicher Größe zu erstellen. Die Kenntnis der Teamgeschwindigkeit hilft, das Ende eines Projekts besser vorherzusagen.
Die Lead- und Cycle-Zeit definiert die durchschnittliche Zeit, die zum Erledigen einer Aufgabe benötigt wird. Die Durchlaufzeit wird berechnet, da das Team eine Anfrage vom Kunden erhält, und die Zykluszeit wird berechnet, seit das Team mit der Arbeit an einer Aufgabe beginnt. Die Vorlaufzeit wird verwendet, um zu verstehen, wie lange ein Kunde auf sein Produkt warten muss, und die Zykluszeit wird verwendet, um zu verstehen, wie schnell das Team ein Produkt produziert.
Umsetzbare Agile-Metriken verwenden die Zykluszeit, um besser vorherzusagen, wann jedes Projektelement abgeschlossen sein wird. Von Daniel S. Vacanti im Jahr 2015 erstellt, messen umsetzbare Agile-Metriken, wie lange es dauerte, 50 %, 85 % und 95 % der Aufgaben zu erledigen. Und verwenden Sie diese Informationen, um dem Team dabei zu helfen, Liefertermine für Aufgaben besser vorherzusagen und zu kontrollieren.
Siehe auch
Verweise
Weiterlesen
- Kanban: Erfolgreicher evolutionärer Wandel für Ihr Technologiegeschäft, David J. Anderson. (USA, Blue Hole Press, 2010. ISBN 978-0984521401
- Scrumban: Essays über Kanban-Systeme für die schlanke Softwareentwicklung, Corey Ladas. (USA, Modus Cooperandi Press, 2009. ISBN 9780578002149
- Agiles Projektmanagement mit Kanban (Developer Best Practices) , Eric Brechner. (USA: Microsoft Press, 2015). ISBN 978-0735698956 .
- Kanban in Aktion , Marcus Hammarberg und Joakim Sunden. (Shelter Island, NY: Manning Publications, 2014). ISBN 978-1-617291-05-0 .
- Lean from the Gräben: Großprojekte managen mit Kanban, Henrik Kniberg. (Dallas, TX: The Pragmatic Programmers, 2012). ISBN 978-1-93435-685-2 .
- Hör auf zu beginnen, fang an zu beenden! Arne Roock und Claudia Leschik. (USA: Lean-Kanban-Universität, 2012). ISBN 978-0985305161 .
- Kanban in der Praxis: Weniger tun, mehr erreichen mit Lean Thinking , Mattias Skarin. (USA: Pragmatic Bookshelf, 2015). ISBN 978-1680500776 .