Close

Kanban

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

Themen durchsuchen
Jira-Board

Teste kostenlos die Kanban-Vorlage von Jira

Maximale Effizienz dank eines guten Überblicks über die wichtigsten Aufgaben

Vorlage verwenden

Was ist Kanban?

Kanban ist ein beliebtes Framework zum Implementieren von Agile und DevOps in der Softwareentwicklung. Dazu müssen Kapazitäten in Echtzeit kommuniziert werden und alle Aufgaben müssen 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- und DevOps-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 Verbrauchern. 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, indem sie die Anzahl der Work-in-Progress-Aufgaben 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.

Kanban Boards

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

Unabhängig davon, ob das Board eines Teams physisch oder digital ist – seine Funktion ist die Visualisierung der Aufgaben, die Standardisierung des Workflows und die Ermittlung und Beseitigung aller Hindernisse und Probleme durch Abhängigkeiten. Ein einfaches Kanban Board ist in einen Workflow in drei Schritten unterteilt: ToDo, 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 eine Stellung als die zentrale 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, völlige Nachverfolgbarkeit und eine schnelle Ermittlung von Hindernissen und Abhängigkeiten sichergestellt.

Die Vorteile von Kanban

Kanban ist eine der beliebtesten Methoden bei der Softwareentwicklung, die heute von agilen Teams übernommen wird. Kanban 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 Arbeit", "Code-Review" und "Fertig". 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, statt die Arbeit eines Kollegen zu prüfen. Eine niedrige Grenze motiviert die Teammitglieder, besonders auf Vorgänge im Review-Status zu achten und die Arbeit anderer zu prüfen, bevor sie Reviews ihres eigenen Codes anfordern. Dies minimiert letztendlich die Durchlaufzeit insgesamt.

Visuelle Darstellung von Metriken

Zu den zentralen Werten zählt ein starker Fokus auf eine stetige Verbesserung der Teameffizienz und -effektivität bei jeder Wiederholung einer Aufgabe. 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

Bei Continuous Delivery (CD) geht es darum, Kunden häufige Releases bereitzustellen. Bei Continuous Integration (CI) werden im Verlauf eines Tages automatisch inkrementell Builds erstellt und Code-Tests durchlaufen. Zusammen bilden sie eine CI/CD-Pipeline, die für Entwicklerteams (insbesondere für DevOps-Teams) unerlässlich ist, um Software schneller und in hoher Qualität ausliefern zu können.

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-Methoden Am Ende jedes Sprints, wenn vom Product Owner genehmigt Continuous Delivery oder nach Ermessen des Teams
Rollen Product Owner, Scrum Master, Entwicklerteam Keine vorhandenen Rollen. Einige Teams nehmen die Hilfe eines Agile Coach in Anspruch.
Zentrale Messgrößen 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.

Jira-Board

Mit der Jira Kanban-Vorlage kostenlos loslegen

Maximale Effizienz dank eines guten Überblicks über die wichtigsten Aufgaben

Dan Radigan
Dan Radigan

Agile Methoden haben mich sowohl beruflich als auch persönlich stark beeinflusst, da ich gelernt habe, dass durch Agilität die besten Erfahrungen entstehen, sowohl beim Code als auch im Leben allgemein. Meine Leidenschaft sind Technologie, Fotografie und Motorradfahren – gerne in Kombination.

Weiter geht's
Boards