2010-09-01 11 views
6

Wir denken über den Wechsel von Scrum zu einem Kanban-Entwicklungsstil nach, aber eine Sache, die mir nicht klar ist, ist, wie man den Fortschritt unter Kanban überwachen kann.Wie verfolge ich den Fortschritt bei der Verwendung von Kanban?

Ich habe gelesen, dass der Fortschritt gemessen werden kann, indem man die Zykluszeit jeder Geschichte überwacht und dann diese Zeit vermutlich auf die Anzahl der ausstehenden Geschichten anwendet. Aber das scheint mir von der Größe und Komplexität der Geschichten abhängig zu sein, die alle unterschiedlich sein könnten.

Ich habe auch Burndown Charts verwendet, also würde es eine Tabelle für die gesamte Veröffentlichung geben? Da der Rückstand nicht behoben ist (im Gegensatz zu einem Sprint), würden Sie nur zulassen, dass er aufbricht, wenn der ausstehende Rückstand von der Bestellung geändert wird? Ich schätze, wenn Sie sich dem Release nähern, sollte der Backlog weniger volatil sein, was es Ihnen ermöglicht, bis zum Abschluss zu burdown.

Nach weiterem Nachdenken denke ich, mein Problem ist, dass unsere Manager die "Illusion" der Kontrolle mögen, die ein Burndown-Chart bringt. Sie neigen dazu, dies (zu Unrecht meiner Meinung nach) als einen Zeitplan zu sehen und sind daher in der Lage, zu beurteilen, ob das Projekt "planmäßig" oder "hinter dem Zeitplan" ist oder was auch immer. Ich kann nicht genau sehen, wie dies in Kanban repliziert wird. Vielleicht ist das eine gute Sache.

+0

Programmierfrage? – Select0r

+0

In Bezug auf die Verwaltung eines Programmierprojekts glaube ich, dass es den Fragen entspricht, die auf dieser Seite gestellt werden. –

Antwort

3

Für ein ganzes Projekt ist der kumulative Ablaufplan der beste Weg, den Fortschritt zu verfolgen. Erfahren Sie mehr über CFD von this presentation. Sie können auch von CFD über Dinge wie Engpässe usw. lernen.

Für eine bestimmte Aufgaben hängt es wirklich von Ihrem Ansatz. Wenn Sie kleine Features (zB 1-2 Tage Entwicklung) auf der Kanban-Platine haben, können Sie den Status direkt auf der Platine sehen, da sich die Features schnell durch den Workflow bewegen.

Wenn Sie größere Funktionen verwenden, können Sie sie in kleinere Aufgaben aufteilen. So arbeiten wir grundsätzlich mit unseren Features: Für größere Features (zB 5-10 Tage) teilen wir sie in Entwicklungsaufgaben auf (wir stellen die Entwicklungsaufgabe jedoch nicht an die Tafel). Dann kann ich sagen, dass Aufgabe A 3 von 4 Entwicklungsaufgaben erledigt hat, also geht es uns gut. Außerdem schätzen wir die Länge der Entwicklungsaufgaben, so dass ich zwischen einstündigen und acht Stunden langen Aufgaben unterscheiden kann. Für kleine Features haben wir nur eine einzige Entwicklungsaufgabe, die das Feature entwickelt.

+0

Ich denke, mein Problem ist, dass unsere Manager die "Illusion" der Kontrolle mögen, die ein Burndown-Chart bringt. Sie neigen dazu, dies (zu Unrecht meiner Meinung nach) als einen Zeitplan zu sehen und sind daher in der Lage, zu beurteilen, ob das Projekt "planmäßig" oder "hinter dem Zeitplan" ist oder was auch immer. Ich kann nicht genau sehen, wie dies in Kanban repliziert wird. Vielleicht ist das eine gute Sache. –

+0

CFD ist eine Art Burn-up-Diagramm. Es zeigt, wie viel Arbeit Sie bereits geleistet haben. Jetzt, wenn Sie es gegen irgendeine Art von Zeitplan verifizieren müssen, zeichnen Sie einfach eine aufsteigende Linie durch das Diagramm (die das erwartete Tempo der Komplettierungsfunktionen darstellt), um zu sehen, ob es Ihnen besser oder schlechter geht als geplant. – pawelbrodzinski

+1

@Si Keep: Das ist der Punkt bei Burn-Down-Charts - um zu sehen, ob das Team seine Aufgaben während des aktuellen Sprints vernünftig beenden kann. Für das Cross-Sprint-Charting empfehle ich [Burn-up-Diagramme] (http://blog.workingsoftware.se/2010/09/burn-up-or-burn-down.html) –

Verwandte Themen