2010-09-01 24 views
6

Myślimy o przejściu od Scrum do bardziej kanbanowego stylu rozwoju, jednak jedną rzecz, która nie jest dla mnie jasna, jest to, jak monitorować postępy w Kanban.Jak śledzić postępy podczas korzystania z Kanban?

Czytałem, że postęp można zmierzyć poprzez monitorowanie czasu cyklu każdej opowieści, a następnie przypuszczalnie zastosowanie tego czasu do liczby zaległych historii. Ale wydaje mi się, że zależy to od wielkości i złożoności historii, które mogą być różne.

Widziałem również używane tabele wypalania, więc czy istnieje wykres dla całego wydania? Ponieważ zaległości nie są stałe (w przeciwieństwie do sprintu), czy pozwolisz, aby spalił się w górę/w dół, gdy oczekujący backlog jest zmieniany przez OP? Wydaje mi się, że w miarę jak zbliżasz się do uwolnienia, zaległości powinny być mniej zmienne, abyś mógł zakończyć się pożarem.

Po głębszym zastanowieniu myślę, że moim problemem jest to, że nasi menadżerowie lubią "iluzję" kontroli, którą przynosi wykres pożegnalny. Mają tendencję do postrzegania tego (niesłusznie moim zdaniem) jako harmonogramu i dlatego są w stanie wydawać osądy, takie jak projekt "na czas" lub "z opóźnieniem", czy cokolwiek innego. Nie mogę dokładnie zobaczyć, jak to jest powielane w Kanban. Może to dobra rzecz.

+0

Pytanie do programowania? – Select0r

+0

W związku z zarządzaniem projektem programistycznym uważam, że jest ono zgodne z rodzajem pytań zadawanych na tej stronie. –

Odpowiedz

3

Dla całego projektu najlepszym sposobem śledzenia postępów jest Cumulative Flow Diagram. Dowiedz się więcej o CFD od this presentation. Możesz także uczyć się od CFD o rzeczach takich jak wąskie gardła itp.

Dla konkretnych zadań to naprawdę zależy od twojego podejścia. Jeśli masz małe funkcje (np. 1-2 dni rozwoju) na tablicy Kanban, możesz zobaczyć status bezpośrednio na planszy, ponieważ funkcje poruszają się szybko w przepływie pracy.

Jeśli używasz większych funkcji, możesz podzielić je na mniejsze zadania. Zasadniczo pracujemy z naszymi funkcjami: w przypadku większych funkcji (np. 5-10 dni) dzielimy je na zadania rozwojowe (nie umieszczamy jednak zadania programistycznego na planszy). Następnie mogę powiedzieć, że zadanie A zawiera 3 z 4 zadań programistycznych, więc dobrze nam idzie. Dodatkowo szacujemy długość zadań rozwojowych, aby móc rozróżnić zadania trwające od 1 godziny do 8 godzin. W przypadku małych funkcji mamy tylko pojedyncze zadania programistyczne, które rozwijają tę funkcję.

+0

Uważam, że moim problemem jest to, że nasi menadżerowie lubią "iluzję" kontroli, którą przynosi wykres pożegnalny. Mają tendencję do postrzegania tego (niesłusznie moim zdaniem) jako harmonogramu i dlatego są w stanie wydawać osądy, takie jak projekt "na czas" lub "z opóźnieniem", czy cokolwiek innego. Nie mogę dokładnie zobaczyć, jak to jest powielane w Kanban. Może to dobra rzecz. –

+0

CFD to rodzaj wykresu wypalania. Pokazuje, ile pracy już wykonałeś. Teraz, jeśli chcesz go zweryfikować w oparciu o jakiś harmonogram, po prostu narysuj linię odniesienia rosnąco na wykresie (który reprezentuje spodziewane tempo wypełniania funkcji), aby sprawdzić, czy robisz lepiej lub gorzej niż planowałeś. – pawelbrodzinski

+1

@Si Keep: To jest punkt z wykresami spalenia - aby sprawdzić, czy zespół może rozsądnie zakończyć swoje zadania podczas bieżącego sprintu. W przypadku sprintu krzyżowego polecam [tablice wypalania] (http://blog.workingsoftware.se/2010/09/burn-up-or-burn-down.html) –

Powiązane problemy