Kanban

Vorgehen

Nachdem heute praktisch alle Automobilhersteller nach KANBAN vorgehen, verbreitet sich diese Modell heute auch bei der Herstellung von Software. KANBAN (japanisch "Karte") wurde von Taichi Ohno (1912-1990) ab 1947 für Toyota entwickelt, das auf seinem Managementprinzip KAIZEN (jap. "Veränderung zum Besseren") basiert.

Die IT Anforderungen werden als User Stories auf Karten geschrieben. Bei Bedarf werden die User Stories in Tasks (oder Features) zerlegt. Auch jede Task wird auf eine Karte geschrieben. Die Aufgabe des Team ist, die User Stories/Tasks abzuarbeiten.<

KANBAN wird durch 5 Grundprinzipien beschrieben

Visualisierung auf KANBAN Board

Visualisierung auf KANBAN Board in den Spalten "User Stories und Tasks", "Entwicklung", "Test", "Produktion", "Fertig"

Arbeitsmengenbegrenzung

Die Menge der User Stories bzw. Tasks, die gleichzeitig bearbeitet werden, ist begrenzt.
Beispiel: Wenn jeder Entwickler nur an maximal 2 Tasks gleichzeitig arbeiten darf und 5 Entwickler das Team bilden, dürfen maximal 10 Tasks in der Spalte "Entwicklung" hängen.

Messen und Steuern

Die Teammitglieder messen Zustände und machen sie dem Team transparent. Dadurch werden Verlässlichkeit der Zusagen an Stakeholder und Durchsatz gesteigert.
- Länge der Warteschlangen,
- Zykluszeit
- Arbeitsdurchsatz wieviel Tickets pro Woche erledigt wurden
- Burndown Diagramme fürr die verschiedenen Zustände des KANBAN Boards verdeutlichen die Bottlenecks
- Fehlerrate wie sich die Menge der Bugs über die Zeit entwickeln

Diese Statistiken sollten allerdings nur für das Team sichtbar sein, da sonst bei Außenstehenden leicht falsche, gar geschäftsschädigende Eindrücke entstehen können.

User Stories / Tasks / Features können nach verschiedenen Metriken für das KANBAN Board priorisiert werden (optional).
- Wert für das Unternehmen
- Opportunitätskosten der entgangenen Gewinne aufgrund verzögerter Fertigstellung
- Strafen (Penality) aufgrund verzögerter Fertigstellung, z.B. bei SLAs, gesetzlichen Fristen

Erfolgt die Priorisierung allein durch das Management werden regelmäßig Tasks niedrig priorisiert, die für das Refactoring der Software wichtig sind.
Erfolg die Priorisierung allein durch die Entwickler werden häufig die Geschäftsnotwendigkeiten bestimmter Features vernachlässigt.
Idealerweise erfolgt eine Priorisierung in einem diskursiven Prozesse der Beteiligten.

Beziehung zwischen Scrum und KANBAN

Beziehung zwischen Scrum und KANBAN
Scrum ist mit den stets gleich langen Sprints time-boxed. Diese gleich langen Iterationen sieht KANBAN nicht vor. Bei KANBAN kann an einer User Story oder Task mehrere Tage und über einen längeren Zeitraum gearbeitet werden. Das ist etwa sinnvoll, wenn KANBAN zum Debugging eingesetzt wird. Morgens arbeitet das Team nach Scrum und entwickelt ein neues Release. Nachmittags wir das laufende Release mit KANBAN debugged. Jeder neue Bug wird auf eine Karte geschrieben. Am Sprintende berichtet das Scrum/KANBAN-Team auch seine Debugging Leistungen.

So ergänzt KANBAN symbiotisch Scrum.

Kanban

KANBAN Regeln KANBAN Zeremonien KANBAN Rollen KAIZEN

Einkaufen

Warenkorb anzeigen Zur Kasse gehen Mein Konto

In Ihrem Warenkorb: 0 Artikel, 0,00 EUR

Suchen nach

Allgemein