Was ist Kanban?

  • Artikel

Kanban ist ein japanischer Begriff, der Schild oder Werbetafel bedeutet. Ein Industrieingenieur namens Taiichi Ohno entwickelte Kanban bei Toyota Motor Corporation, um die Fertigungseffizienz zu verbessern.

Obwohl Kanban für die Fertigung entwickelt wurde, verfolgt die Softwareentwicklung viele derselben Ziele, beispielsweise die Steigerung von Durchfluss und Durchsatz. Softwareentwicklungsteams können ihre Effizienz verbessern und den Benutzern schneller einen Mehrwert bieten, indem sie Kanban-Leitprinzipien und -Methoden anwenden.

Image that shows people using Kanban boards.

Kanban-Prinzipien

Die Einführung von Kanban erfordert die Einhaltung einiger grundlegender Praktiken, die von den vorherigen Methoden des Teams abweichen können.

Arbeit visualisieren

Es kann eine Herausforderung darstellen, den Status und den Arbeitsfortschritt des Entwicklungsteams zu verstehen. Der Arbeitsfortschritt und der aktuelle Status sind leichter zu verstehen, wenn sie visuell dargestellt werden, statt als Liste von Arbeitselementen oder als Dokument.

Die Visualisierung der Arbeit ist ein Schlüsselprinzip, das Kanban hauptsächlich über Kanban-Boards adressiert. Diese Boards verwenden Karten, die nach Fortschritt organisiert sind, um den Gesamtstatus zu kommunizieren. Durch die Visualisierung der Arbeit als Karten in unterschiedlichen Stadien auf einem Board können Sie sich einen Überblick über den aktuellen Stand eines Projekts verschaffen und potenzielle Engpässe erkennen, die sich auf die Produktivität auswirken könnten.

Diagram showing a Kanban board.

Pull-Modell verwenden

In der Vergangenheit haben Stakeholder Funktionalitäten angefordert, indem sie die Arbeit den Entwicklungsteams übertrugen, oft mit knappen Fristen. Darunter litt die Qualität, wenn Teams Vorgänge auslassen mussten, um die Funktionalität innerhalb des Zeitrahmens bereitzustellen.

Kanban konzentriert sich auf die Aufrechterhaltung eines vereinbarten Qualitätsniveaus, das erfüllt werden muss, bevor die Arbeit als erledigt gilt. Um dieses Modell zu unterstützen, drängen Stakeholder Teams, die bereits voll ausgelastet sind, keine Arbeiten auf. Stattdessen fügen Stakeholder Anfragen zu einem Backlog hinzu, die ein Team in seinen Workflow einfügt, sobald Kapazität verfügbar wird.

Ein WIP-Limit erzwingen

Teams, die versuchen, gleichzeitig an zu vielen Dingen zu arbeiten, können aufgrund eines häufigen und kostspieligen Kontextwechsels unter einer reduzierten Produktivität leiden. Das Team ist beschäftigt, aber die Arbeit wird nicht erledigt, was zu unannehmbar hohen Vorlaufzeiten führt. Die Begrenzung der Anzahl der Backlog-Elemente, an denen ein Team gleichzeitig arbeiten kann, trägt dazu bei, den Fokus zu erhöhen und gleichzeitig den Kontextwechsel zu reduzieren. Die Elemente, an denen das Team gerade arbeitet, werden als Work In Progress (WIP) bezeichnet.

Teams entscheiden sich für einen WIP-Grenzwert oder die maximale Anzahl von Elementen, an denen sie gleichzeitig arbeiten können. Ein gut diszipliniertes Team stellt sicher, dass der WIP-Grenzwert nicht überschritten wird. Wenn Teams ihre WIP-Grenzwerte überschreiten, untersuchen sie den Grund und die Arbeit, um die Ursache zu beheben.

Kontinuierliche Verbesserung messen

Um eine kontinuierliche Verbesserung zu üben, benötigen Entwicklungsteams eine Möglichkeit zur Messung der Effektivität und des Durchsatzes. Kanban-Boards bieten eine dynamische Ansicht der Arbeitszustände in einem Workflow, sodass Teams mit Prozessen experimentieren und die Auswirkungen auf Workflows einfacher bewerten können. Teams, die Kanban für eine kontinuierliche Verbesserung nutzen, verwenden Messungen wie Vorlaufzeit und Zykluszeit.

Kanban-Boards

Das Kanban-Board ist eines der Tools, die Teams verwenden, um Kanban-Praktiken zu implementieren. Ein Kanban-Board kann ein physisches Board oder eine Softwareanwendung sein, in der Karten in Spalten angeordnet sind. Typische Spaltennamen sind Aufgaben, In Bearbeitung und Erledigt, aber Teams können die Namen anpassen, damit sie ihren Workflow-Status entsprechen. Beispielsweise könnte ein Team die Verwendung von Neu, Entwicklung, Test, UAT und Erledigt bevorzugen.

Softwareentwicklungsbasierte Kanban-Boards zeigen Karten an, die Produkt-Backlog-Elementen entsprechen. Die Karten enthalten Links zu anderen Elementen, z. B. Aufgaben und Testfälle. Teams können die Karten so anpassen, dass sie Informationen enthalten, die für ihren Prozess relevant sind.

Screenshot of a software development Kanban board.

Auf einem Kanban-Board gilt der WIP-Grenzwert für alle in Bearbeitung befindlichen Spalten. WIP-Grenzwerte gelten nicht für die ersten und letzten Spalten, da diese Spalten Arbeit darstellen, die nicht gestartet oder abgeschlossen wurde. Kanban-Boards helfen Teams dabei, innerhalb der WIP-Grenzwerte zu bleiben, indem sie die Aufmerksamkeit auf Spalten lenken, die die Grenzwerte überschreiten. Teams können dann einen Handlungsverlauf bestimmen, um den Engpass zu beseitigen.

Kumulative Flussdiagramme

Eine häufige Ergänzung zu softwareentwicklungsbasierten Kanban-Boards ist ein Diagramm, das als kumuliertes Flussdiagramm (CFD) bezeichnet wird. Der CFD veranschaulicht die Anzahl der Elemente in jedem Zustand im Laufe der Zeit, in der Regel über mehrere Wochen. Die horizontale Achse zeigt die Zeitachse an, während die vertikale Achse die Anzahl der Produkt-Backlog-Elemente anzeigt. Farbige Bereiche geben die Zustände oder Spalten an, in denen sich die Karten derzeit befinden.

Das CFD ist besonders nützlich, um Trends im Laufe der Zeit zu identifizieren, einschließlich Engpässen und anderen Unterbrechungen der Fortschrittsgeschwindigkeit. Ein gutes CFD zeigt einen konsistenten Aufwärtstrend, während ein Team an einem Projekt arbeitet. Die farbigen Bereiche im Diagramm sollten ungefähr parallel sein, wenn das Team innerhalb seiner WIP-Grenzwerte arbeitet.

Image showing a cumulative flow diagram.

Eine Ausbuchtung in einem oder mehreren der farbigen Bereiche weist normalerweise auf einen Engpass oder ein Hindernis im Teamfluss hin. Im folgenden CFD ist die abgeschlossene Arbeit in Grün flach, während der Testzustand in Blau zunimmt, wahrscheinlich aufgrund eines Engpasses.

Image showing a bottleneck in a cumulative flow diagram.

Kanban und Scrum in der Agile-Entwicklung

Auch wenn sich Scrum und Kanban allgemein unter dem Dach der Agile-Entwicklung befinden, sind Scrum und Kanban äußerst unterschiedlich.

  • Scrum konzentriert sich auf Sprints mit fester Länge, während Kanban ein fortlaufendes Flussmodell ist.
  • Scrum hat definierte Rollen, während Kanban keine Teamrollen definiert.
  • Scrum verwendet Geschwindigkeit als Schlüsselmetrik, während Kanban Zykluszeit verwendet.

Teams übernehmen in der Regel Aspekte von Scrum und Kanban, um ihnen dabei zu helfen, am effektivsten zu arbeiten. Ganz gleich, für welche Merkmale sie sich entscheiden, die Teams können jederzeit überprüfen und anpassen, bis sie die beste Lösung gefunden haben. Teams sollten einfach beginnen und nicht aus den Augen verlieren, wie wichtig es ist, den Benutzern regelmäßig einen Mehrwert zu bieten.

Kanban mit GitHub

GitHub bietet eine Kanban-Erfahrung über Projekt-Boards (klassisch). Diese Boards helfen Ihnen bei der Organisation und Priorisierung der Arbeit für bestimmte Featureentwicklungen, umfassende Roadmaps oder Release-Checklisten. Sie können Projekt-Boards (klassisch) automatisieren, um den Kartenstatus mit zugehörigen Problemen und Pullanforderungen zu synchronisieren.

Kanban mit Azure Boards

Azure Boards bietet eine umfassende Kanban-Lösung für die DevOps-Planung. Azure Boards verfügt über eine umfassende Integration in Azure DevOps und kann auch Teil der Azure Boards-GitHub-Integration sein.