Korzystanie z wykresu wypalania do oszacowania daty zakończenia projektu Scrum
Czasami czytam o używaniu wykresu wypalania do oszacowania daty zakończenia projektu Scrum. Często jest opisywany w ten sposób:
- oszacuj wszystkie cechy produktu i podsumuj je (TOTAL_STORY_POINTS)
- wykonaj kilka sprintów, aby uzyskać prędkość zespołu
- podziel TOTAL_STORY_POINTS przez prędkość
Jeśli tak to ma działać, to pierwsze pytanie, które się pojawia, brzmi: jak szacujemy całe cechy? Możemy oszacować małe Historie użytkowników, ponieważ mniej lub bardziej rozumiemy ilość pracy wymaganej do ich wykonania i dlatego możemy z grubsza porównać te kwoty. Ale na początku projektu mamy tylko ogólne zrozumienie funkcji, z których składa się nasz produkt. Zamierzamy również zmienić te funkcje w miarę rozwoju klienta. Jak więc oszacować początkowy zakres projektu w Story Points?
Odpowiedzi
Teoretycznie tak, możesz użyć wykresu wypalenia, aby oszacować, kiedy wszystkie prace w Backlogu Produktu zostaną zakończone. Jednak w praktyce i jak widać, nie zawsze się to udaje.
Korzystanie z wykresu wypalania do oszacowania stopnia ukończenia opiera się na kilku założeniach, takich jak fakt, że Backlog Produktu jest dobrze zrozumiały i generalnie jest statyczny. Jednak zwykle nie są to prawdziwe stwierdzenia.
Zespół zwykle koncentruje swoje wysiłki na zrozumieniu pracy o najwyższym priorytecie na szczycie zaległości i tylko minimalnym wysiłku, jeśli w ogóle, na zrozumieniu mniej ważnych prac. W miarę zmniejszania się zaległości praca jest zwykle większa i słabiej zdefiniowana.
Rejestr Produktu również często się zmienia. Pomiędzy regularną pracą Właściciela Produktu mającą na celu zrozumienie potrzeb interesariuszy, opiniami uzyskanymi w Przeglądzie Sprintu oraz opiniami z innych źródeł w miarę używania produktu, zawartość Backlogu Produktu może ulec zmianie.
W praktyce pomysł, że można przewidzieć zakończenie wysiłku, nie jest z natury Agile. W Agile zakres nie jest zobowiązany. Kończy się wysiłek, gdy koszt dostarczenia następnej jednostki przekracza wartość, którą by ona oferowała. Nie poświęcając wysiłku na zdefiniowanie i zobowiązanie się do określenia zakresu, umożliwia zespołowi reagowanie na informacje zwrotne i uwzględnienie tego, czego dowiaduje się o przestrzeni operacyjnej produktu. Sugerowałbym, że nie ma dużej różnicy między próbą użycia wykresu wypalenia do oszacowania ukończenia a dużym planowaniem z góry, które nie działa w domenach, w których występuje duża ilość niepewności.
Jeśli masz już trzy wspomniane powyżej punkty, nie potrzebujesz wykresu wypalania, aby oszacować datę zakończenia projektu. Kiedy dzielisz całkowitą liczbę punktów historii przez prędkość, otrzymujesz liczbę sprintów, które są (zwykle) ograniczone czasowo do tygodni, które możesz następnie rozłożyć na kalendarzu i uzyskać datę zakończenia projektu. Narysowanie wykresu postępu po prostu pokaże idealną linię między rozpoczęciem projektu a tą samą datą zakończenia, którą obliczyłeś. Niezbyt przydatne.
Wykres wypalania jest przydatny, aby nie prognozować daty zakończenia, ale aby pokazać, czy rzeczywisty postęp jest taki, jak przewidywany . Masz idealną linię na wypaleniu i rzeczywistą linię, która pokazuje, czy jesteś w tyle (powyżej), czy przed (poniżej) tego, co idealnie przewidziałeś. Widząc to, możesz podjąć działania i skorygować trajektorię, jeśli nadal chcesz dostarczyć w pożądanym terminie.
Oczywiście to wszystko to tylko kilka idealnych rzeczy, które według Ciebie się wydarzy. To prognoza, a nie prognoza . Wiele rzeczy ma się inaczej, gdy projekt jest w toku.
Wypalanie nie pokazuje na przykład, czy zaległości uległy zmianie; po prostu przepalasz punkty historii. Wypalenie nie pokazuje, czy zmieniły się priorytety, ani czy teraz pracujesz nad tym, nad czym myślałeś, że będziesz pracować, czy nad czymś innym; pokazuje tylko, ile punktów historii spaliłeś i ile pozostało. Zakładasz również, że po narysowaniu idealnej linii wypalenia wszystko pozostaje takie samo.
Ale oczywiście wszystko się zmienia . Jeśli ludzie skupią się na tworzeniu odpowiedniego produktu , sytuacja ulegnie zmianie po wykonaniu wstępnej prognozy. Jeśli źle korzystasz z wykresu wypalania, niektórzy mogą zmusić zespół do podjęcia wysiłków i podążania za idealną linią wypalania i po prostu przepalić kilka historii lub funkcji, które powinny zostać ukończone przed szacowaną datą zakończenia. Teraz w zasadzie otrzymujesz Waterfall z dużym planowaniem z góry i założeniem, że prognozowane rzeczy są poprawne, a wszelkie odchylenia od nich są złe, co w rzeczywistości jest odwrotnie.
Jeśli chcesz dowiedzieć się więcej o prognozowaniu dostaw w Agile , możesz zacząć od tych postów:
- Jak planujesz terminy dostaw w Scrumie?
- Jak oceniasz eposy?