PHP Magazin

Das Magazin für PHP Entwicklung

Warenkorb (0) |

Registrieren

Das Beste aus Kanban und Scrum in 11 Schritten

19.07.2012 - 13:49

Beispiel: "Scrumban" in der Anwendung

Das Beste aus Kanban und Scrum in 11 Schritten

Torsten Zimmermann

Im ersten Artikel der zweiteiligen Reihe wurde der Methodenhybrid, bestehend aus Kanban und Scrum, vorgestellt. Anhand eines fiktiven Beispiels - in Form eines Comics - soll im zweiten Teil nun das Arbeiten mit Arbeitspaketen nach Scrumban über verschiedene Teams hinweg illustriert werden.

Artikelserie

Software-Kanban - Grundlagen und Methodenhybride
Scrum trifft Kanban - Beispiele aus der Praxis

Ausgangssituation

Abb. 1: Ausgangssituation

Entwickler Magazin

Der Artikel "Das Beste aus Kanban und Scrum" von Torsten Zimmermann ist erstmalig erschienen im

Entwickler Magazin 1.2012

Abbildung 1 zeigt die Ausgangssituation. Es gibt eine Reihe priorisierter Aufgaben in dem Product Backlog. Der Product Owner, das Entwicklungsteam, bestehend aus vier Entwicklern, und das Qualitätssicherungsteam mit zwei Kollegen bilden eine Abteilung, die Funktionen für verschiedene Softwareprodukte realisieren soll. Die WIP-Limitierungen auf dem stilisierten Kanban-Board der einzelnen Bereiche sind am Anfang auf 3 ("Ausgewählt"), 2 ("Entwicklung") bzw. 1 ("QS") festgelegt. Zu jeder Zeit kann der Product Owner das Product Backlog und die Arbeitspakete der Spalte "Ausgewählt" ändern bzw. austauschen. Die anderen Spalten sind jedoch für den Product Owner tabu. Die Spalten "Entwicklung" und "Qualitätssicherung" sind jeweils in "in Arbeit" und "erledigt" unterteilt.

Mehrere verschiedene Produkte in einem Team bearbeiten?

Wie in Abbildung 1 zu erkennen ist, können Arbeitspakete für verschiedene Produkte von den gleichen Teams bearbeitet werden. In Scrum ist das normalerweise so nicht vorgesehen; in Kanban beziehungsweise dem Methodenhybrid "Scrumban" hingegen schon.

Schritt 1

Der Product Owner schiebt die ersten drei Arbeitspakete, die als Nächstes erledigt werden sollen, in die Spalte "Ausgewählt". In einem bereits priorisierten Product Backlog sind das die drei obersten Stories. Eine vierte Story kann der Product Owner nicht in die besagte Spalte verschieben, da das WIP-Limit bereits erreicht ist. Ist das Product Backlog nicht priorisiert - eine Priorisierung der Backlog-Einträge ist in Kanban nicht zwingend - so erfolgt die Priorisierung der Stories indirekt durch das Verschieben der jeweils nächsten Stories in die Spalte "Ausgewählt". Egal, welche Methode letztlich gewählt wird: Eine auf den Kundenbedarf gut abgestimmte Priorisierung ist in jedem Fall ein Erfolgsfaktor.

Abb. 2: Schritt 1

Schritt 2

Abb. 3: Schritt 2

Das Entwicklungsteam wird in zwei Gruppen unterteilt. Jede übernehmen jeweils ein Arbeitspaket aus der Spalte "Ausgewählt" in die "in Arbeit"-Spalte des Entwicklungsbereiches und führen die notwendigen Arbeiten aus.

Schritt 3

Dies erlaubt es dem Product Owner, die beiden frei gewordenen Plätze mit neuen Aufgaben aus dem Product Backlog zu belegen.

Abb. 4: Schritt 3

Schritt 4

Abb. 5: Schritt 4

Eine der beiden Entwicklungsaufgaben ist erledigt und wird damit in die "Erledigt"-Spalte verschoben. Jetzt kommt das QS-Team zum Zuge: Es kann nun diese Aufgabe zwecks Prüfung der Umsetzungsarbeit übernehmen.