Close

Kanban

So lässt sich die Kanban-Methode in der Softwareentwicklung anwenden

Themen durchsuchen

Was ist Kanban?

Kanban ist ein beliebtes Framework zum Implementieren agiler Softwareentwicklung. Dazu müssen Kapazitäten in Echtzeit kommuniziert werden und alle Aufgaben völlig transparent sein. Die einzelnen Aufgabenelemente werden auf einem Kanban Board visuell dargestellt, sodass sich die Teammitglieder jederzeit einen Überblick über den Status der Arbeitsschritte verschaffen können.

Artikel zu Kanban

[FORTSETZUNG]

Die Kanban-Methode ist bei heutigen Agile-Softwareteams sehr verbreitet, existiert jedoch bereits seit über 50 Jahren. Ende der 1940er-Jahre begann Toyota mit der Optimierung seiner Fertigungsprozesse auf Basis eines Modells, das Supermärkte zum Auffüllen der Regale verwendeten. Supermärkte lagern gerade genug Produkte, um die Nachfrage der Konsumenten zu befriedigen. Diese Praktik optimiert den Prozessfluss zwischen Supermarkt und Konsument. Da die Lagerbestände mit den Verbrauchergewohnheiten übereinstimmen, gewinnt der Supermarkt erheblich an Effizienz bei der Lagerverwaltung und Optimierung für den Kunden. Unterdessen kann der Supermarkt trotzdem sicherstellen, dass die von den Kunden benötigten Produkte stets vorrätig sind.

Als Toyota dieses System in seinen Fertigungshallen einführte, war das Ziel, die enormen Lagerbestände besser am tatsächlichen Materialverbrauch auszurichten. Zur Mitteilung von Kapazitäten in Echtzeit innerhalb der Fertigungshalle (und an Zulieferer) reichten die Arbeiter Karten, die sogenannten "Kanban", zwischen den Teams weiter. Wenn die Materialien an einer Produktionslinie zu Ende gingen, wurde eine Kanban an das Lager weitergereicht, auf der u. a. vermerkt war, welche Materialien in welcher Menge benötigt wurden. Die im Lager bereitgehaltenen Materialien wurden nach Erhalt der Kanban an die Fertigungshalle geliefert. Daraufhin übermittelte das Lager eine Kanban an den Zulieferer. Der Zulieferer hielt ebenfalls eine gewisse Menge dieser Materialien bereit und lieferte die angeforderte Menge an das Lager aus. Auch wenn sich die bei diesem Prozess genutzte Technologie seit den 1940er-Jahren weiterentwickelt hat, ist dieses System immer noch der Kern der heutigen "Just in Time"-Fertigung (JIT).

Kanban für Softwareteams

Agile Softwareentwicklungsteams nutzen heute dieselben JIT-Grundsätze, wenn sie die Anzahl der Work-in-Progress-Aufgaben (WIP) der Kapazität des Teams zuordnen. So kann das Team flexibler planen, Aufgaben schneller erledigen, eine klare Fokussierung erreichen und für Transparenz im gesamten Entwicklungszyklus sorgen.

Kanban Board | Atlassian Agile Coach

Während die Kernprinzipien des Framework zeitlos sind und in nahezu jeder Branche angewandt werden können, verzeichnen insbesondere Softwareentwicklungsteams großen Erfolg mit der agilen Methode. Dies liegt zum Teil daran, dass Softwareteams sie ohne großen Aufwand umsetzen können, sobald sie die grundsätzlichen Prinzipien verstanden haben. Im Gegensatz zu der Einführung von Kanban in einer Fertigungshalle, wo dies zu Veränderungen physischer Prozesse und zu einer beträchtlichen Menge an zusätzlichen Materialien führen würde, benötigen Softwareteams als einziges physisches Material ein Board und Karten – und selbst diese können virtuell sein.

Kanbanboards

Bei der Arbeit aller Kanban-Teams steht das Kanban Board im Mittelpunkt, ein Tool zur Visualisierung von Aufgaben und der Optimierung des Workflows im Team. Manche Teams arbeiten gerne mit physischen Boards, doch virtuelle Boards sind wegen der besseren Nachverfolgbarkeit, der einfacheren Zusammenarbeit und der Zugänglichkeit von verschiedenen Standorten aus ein entscheidender Bestandteil jedes agilen Softwareentwicklungstools .

Unabhängig davon, ob das Board eines Teams physisch oder digital ist, besteht seine Funktion in der Visualisierung der Aufgaben, der Standardisierung des Workflows und der unmittelbaren Ermittlung und Beseitigung aller Hindernisse und Probleme durch Abhängigkeiten. Ein einfaches Kanban Board ist in einen Workflow mit drei Schritten unterteilt: Zu erledigen, in Bearbeitung, erledigt. Je nach Größe, Struktur und Zielen eines Teams kann der Workflow jedoch an die spezifischen Prozesse jedes beliebigen Teams angepasst werden.

Die Kanban-Methode basiert auf völliger Transparenz der Aufgaben und Mitteilung der Kapazitäten in Echtzeit. Deshalb sollte das Kanban Board die Stellung einer zentralen Informationsquelle zu den Aufgaben des Teams einnehmen.

Agiles Kanban Board | Atlassian Agile Coach

Kanban-Karten

Die wörtliche Übersetzung von Kanban aus dem Japanischen ist "visuelles Signal". In Kanban-Teams wird jedes Aufgabenelement als eine separate Karte auf dem Board dargestellt.

Die Repräsentation von Aufgaben als Karten auf dem Kanban Board soll zuallererst die Verfolgung des Arbeitsfortschritts entlang des Workflows durch eine klare visuelle Darstellung ermöglichen. Kanban-Karten stellen kritische Informationen zu dem jeweiligen Aufgabenelement in den Vordergrund, sodass das gesamte Team völlige Transparenz darüber erhält, wer für das Aufgabenelement zuständig ist, worum es sich bei der Aufgabe handelt, wie lange die Bearbeitung schätzungsweise dauern wird usw. Karten auf virtuellen Kanban Boards sind zudem häufig mit Screenshots und anderen technischen Details versehen, die für die zugeordnete Person hilfreich sind. Dadurch, dass die Teammitglieder den Status jedes Aufgabenelements sowie die zugehörigen Details zu jeder Zeit einsehen können, wird eine stärkere Fokussierung, eine völlige Nachverfolgbarkeit und eine schnelle Ermittlung von Hindernissen und Abhängigkeiten sichergestellt.

Die Vorteile von Kanban

Kanban wird von agilen Teams heute als eine der beliebtesten Methoden der Softwareentwicklung übernommen. Es bietet verschiedene zusätzliche Vorteile bezüglich Aufgabenplanung und Durchsatz bei Teams jeder Größe.

Flexibilität bei der Planung

Ein Kanban-Team konzentriert sich nur auf die Arbeit, die aktiv ausgeführt wird. Sobald das Team ein Aufgabenelement abgeschlossen hat, wird das nächste Aufgabenelement aus dem obersten Bereich des Backlogs entnommen. Der Produktinhaber kann Prioritäten für Aufgaben im Backlog beliebig neu festlegen, ohne das Team zu unterbrechen, da sich alle Änderungen, die das aktuelle Aufgabenelement nicht betreffen, nicht auf das Team auswirken. Solange der Produktinhaber dafür sorgt, dass die wichtigsten Aufgabenelemente oben im Backlog stehen, kann das Entwicklerteam dem Unternehmen den größtmöglichen Wert bereitstellen. Die für Scrum typischen Iterationen mit fester Länge sind hier also nicht erforderlich.

Profitipp:

Erfahrene Produktinhaber beziehen das Entwicklerteam immer mit ein, wenn sie Änderungen am Backlog in Betracht ziehen. Wenn sich beispielsweise die User Storys 1 bis 6 im Backlog befinden, basiert die Schätzung für User Story 6 möglicherweise auf dem geplanten Abschluss der User Storys 1 bis 5. Änderungen sollten immer mit dem Entwicklerteam besprochen werden, damit es keine Überraschungen gibt. 

Kürzere Durchlaufzeit

Die Durchlaufzeit ist für Kanban-Teams eine wichtige Metrik. Die Durchlaufzeit ist die Zeit, die eine Arbeitseinheit benötigt, um den Workflow des Teams zu durchlaufen – von dem Moment, an dem die Aufgabe gestartet wird, bis zu dem Moment, an dem sie ausgeliefert wird. Durch eine Optimierung der Durchlaufzeit kann das Team die Bereitstellung geplanter Aufgaben zuverlässig prognostizieren.

Die Überschneidung von Kompetenzen sorgt für kürzere Durchlaufzeiten. Wenn nur eine Person über eine bestimmte Kompetenz verfügt, kann diese Person einen Engpass im Workflow darstellen. Deshalb nutzen Teams grundlegende Best Practices wie Code-Reviews und Mentoring, um ihr Wissen zu verteilen. Geteilte Kompetenzen bedeuten, dass Teammitglieder heterogene Aufgaben übernehmen und damit die Durchlaufzeit weiter verbessern können. Das bedeutet auch, dass bei einem Aufgabenstau das gesamte Team einspringen kann, um den Prozess wieder reibungslos laufen zu lassen. So wird beispielsweise das Testen nicht nur von QA-Technikern ausgeführt, sondern auch Entwickler können einspringen.

In einem Kanban-Framework ist das gesamte Team für einen reibungslosen Ablauf der Arbeit im gesamten Prozess verantwortlich.

Weniger Engpässe

Multitasking erstickt die Effizienz. Je mehr Aufgabenelemente zu einem bestimmten Zeitpunkt bearbeitet werden, umso mehr Kontextwechsel finden statt. Und diese behindern den Abschluss der Aufgaben. Darum besteht einer der Grundsätze von Kanban-Verfahren darin, die Menge der Work-in-Progress (WIP) einzugrenzen. Work-in-Progress-Grenzen heben Engpässe und Staus im Teamprozess durch fehlende Fokussierung sowie fehlende Mitarbeiter oder Kompetenzen hervor.

Ein typisches Softwareteam hat möglicherweise vier Workflow-Status festgelegt: Zu erledigen, in Bearbeitung, Code-Review und erledigt. Das Team kann die WIP-Grenze für den Code-Review-Status auf 2 festlegen. Das mag niedrig erscheinen, hat aber einen guten Grund: Entwickler schreiben oft lieber neuen Code, als dass sie die Arbeit eines Kollegen reviewen. Eine niedrige Grenze ermuntert die Teammitglieder, besonders auf Vorgänge im Review-Status zu achten und die Arbeit anderer zu reviewen, bevor sie Reviews ihres eigenen Codes anfordern. Dies minimiert letztendlich die gesamte Durchlaufzeit.

Visuelle Darstellung von Metriken

Zu den zentralen Werten zählt ein starker Fokus auf eine stetige Verbesserung der Teameffizienz und -effektivität bei jeder Iteration. Diagramme können Teams als visuelle Mechanismen dienen, um sicherzustellen, dass sie sich weiter verbessern. Wenn das Team Daten sehen kann, können Engpässe im Prozess einfacher erkannt (und aus diesem entfernt) werden. Kanban-Teams nutzen dafür hauptsächlich Kontrollcharts und kumulative Flussdiagramme.

In einem Kontrollchart werden die Durchlaufzeit für jeden Vorgang und ein fortlaufender Durchschnitt für das Team dargestellt.

Profitipp:

Das Team verfolgt das Ziel, die erforderliche Zeit zu verkürzen, in der ein Vorgang den gesamten Prozess durchläuft. Eine erfolgreiche Durchführung lässt sich daran ablesen, dass die durchschnittliche Durchlaufzeit im Kontrollchart fällt. 

Agiles Kontrollchart | Atlassian Agile Coach

In einem kumulativen Flussdiagramm wird die Anzahl der Vorgänge dargestellt, die sich in einem bestimmten Status befinden. Das Team kann schnell Blockaden erkennen, indem es die Anzahl der Vorgänge in einem bestimmten Status beobachtet. Vorgänge in Zwischenstadien, wie z. B. "In Progress" (in Bearbeitung) oder "In Review" (in der Review-Phase) werden noch nicht an Kunden ausgeliefert und eine Blockade in diesen Stadien erhöht die Wahrscheinlichkeit enormer Integrationskonflikte, wenn ein Upstream-Merging der Aufgaben erfolgt. 

Kumulatives Flussdiagramm

Continuous Delivery

Wir wissen, dass Continuous Integration – das Verfahren, mit dem im Verlauf eines Tages automatisch inkrementell Builds erstellt und Tests durchlaufen werden – ein entscheidender Faktor für die Qualität des Codes ist. Sehen wir uns jetzt Continuous Delivery (CD) an. Bei CD geht es darum, Kunden häufige Releases bereitzustellen – oft täglich oder sogar stündlich. Kanban und CD ergänzen einander auf nahezu perfekte Weise, da bei beiden der Schwerpunkt auf der Just-in-time-Wertbereitstellung (mit jeweils einem Wert) liegt.

Je schneller ein Team dem Markt Innovationen liefern kann, umso wettbewerbsfähiger ist das Produkt. Und Kanban-Teams konzentrieren sich genau auf die Optimierung von Aufgaben, die an Kunden übergeben werden.

Scrum im Vergleich zu Kanban

Kanban und Scrum basieren teilweise auf gemeinsamen Konzepten, der Ansatz ist jedoch jeweils unterschiedlich. Die Verfahren sollten nicht miteinander verwechselt werden. 

 

SCRUM

KANBAN
Rhythmus

Regelmäßige Sprints mit fester Länge (d. h. 2 Wochen)

 Kontinuierlicher Fluss
Release-Methode Am Ende jedes Sprints, wenn vom Produktinhaber genehmigt Continuous Delivery oder nach Ermessen des Teams
Rollen Produktinhaber, Scrum Master, Entwicklerteam Keine vorhandenen Rollen. Einige Teams nehmen die Hilfe eines Agile Coach in Anspruch.
Zentrale Metriken Velocity Durchlaufzeit
Änderungsphilosophie Teams sollten während des Sprints keine Änderungen an der Sprintprognose vornehmen, da dies die Lernlektionen aus der Schätzung beeinträchtigt. Es kann jederzeit zu Änderungen kommen.

 

Einige Teams vereinen die Ideale von Kanban und Scrum zu "Scrumban". Sie kombinieren Sprints mit fester Länge und Rollen aus Scrum-Verfahren mit der Fokussierung auf Work-in-Progress-Grenzen und Durchlaufzeiten der Kanban-Methoden. Teams, die agile Methoden gerade erst einführen, sollten sich jedoch unbedingt für eine Methode entscheiden und diese eine Weile beibehalten. Sie können später immer noch auf ausgefallenere Methoden umsteigen. 

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. 

Weiter geht's
Boards