Przewodnik po Scrumie | 32. Zalety i wady wykresu wypalania

Wykres spalania ma wiele zalet. Jest to jedno z głównych narzędzi pomiarowych w Scrumie z kilku powodów. Jest łatwy do tworzenia, skalowania i odczytywania. Ma jednak również wady, które sprawiają, że nie jest narzędziem uniwersalnym. W dzisiejszym artykule poruszymy temat wad i zalet wykresu spalania.

Zalety i wady wykresu spalania – spis treści:

1. Wstęp
2. Zalety wykresu wypalenia
3. Wady wykresu wypalenia
4. Streszczenie

Wstęp

O tym, co to jest, jak stworzyć i zinterpretować wykres spalania pisaliśmy w poprzednich artykułach. Dzisiaj skupimy się na zaletach i wadach wykresu wypalania. Jednak większość z nich nie jest ukryta w samym prostym wykresie. Są one raczej związane ze sposobami wykorzystania wykresu wypalenia do motywowania Zespołu Deweloperskiego, ponieważ opisują wyniki swojej pracy i wzmacniają samoorganizację.

Zalety wykresu wypalenia

Wykres wypalania umożliwia wizualizację postępu projektu. Jego czytelność i prostota sprawiają, że jest tak popularny. Dlatego dobrym pomysłem jest, aby Burn Chart był nie tylko stale aktualizowaną metryką ukrytą w cyfrowym narzędziu do zarządzania projektami. Jeśli to w ogóle możliwe, warto uczynić z niego punkt odniesienia dla Zespołu Deweloperskiego widoczny w fizycznym miejscu pracy. Czy to w formie wizualizacji na ekranie, czy odręcznego szkicu.

Motywuje Zespół Deweloperski

Przejrzystość wykresu spalania może sprawić, że będzie on narzędziem motywującym Zespół Deweloperski do efektywnej pracy. Osiągnięcie punktu „zerowego” w każdym Sprincie może stać się ambitnym celem Zespołu, za który przyznawane są nagrody – zgodnie z zasadami grywalizacji biznesowej.

Widoczność aktualnego i ciekawie prowadzonego wykresu spalania może również wzmocnić ducha współpracy i samoorganizacji. W końcu metryka jest miarą pracy zespołowej. Nie pokazuje dokładnie, kto wykonał – lub nie – zrealizował zaplanowanych zadań, a jedynie osiągnięte wyniki.

Mierzy faktycznie wykonaną pracę

Deweloperzy decydują, ile zadań wykonają w danym Sprincie. Im bardziej doświadczony Zespół, tym trafniej powinien przewidywać swoje działania. A wykres bur-down odzwierciedla prawdziwy postęp sprintu.

Zaletą wykresu spalania jest zatem nie tyle pomiar obiektywnej ilości wykonanej pracy, ile stosunek zaplanowanych do wykonanych zadań. Dzięki temu Deweloperzy stopniowo uczą się jak je planować i mogą coraz dokładniej szacować swoje możliwości oraz eliminować powtarzające się błędy.

Łączy się z innymi narzędziami

Jedną z istotnych zalet wykresu spalania jest jego wszechstronność w łączeniu z innymi narzędziami. Następujące narzędzia mogą mieć zastosowanie do:

• analiza pracy Zespołu Deweloperskiego
• wizualizacja postępu prac nad Produktem
• szacowanie budżetu projektu

Np. w tym drugim przypadku zastosowanie wykresu wypalania skali projektu pozwala na porównanie planowanego i rzeczywistego budżetu całego projektu.

Wady wykresu wypalenia

Pomimo wszystkich przedstawionych powyżej zalet wykresu Burndown, może on stać się źródłem zamieszania dla Zespołu Deweloperskiego. Jednak to, co często nazywamy „wadami” wykresu spalania, nie wynika z niedoskonałości samego narzędzia. Przedstawione poniżej problemy dotyczą sposobu realizacji wykresu spalania, a nie jego konstrukcji. Poniżej znajdują się wady, które mogą przeszkadzać w takim przedstawieniu postępów Zespołu Deweloperskiego.

„Czynnik ludzki”

Wykresy nie mogą być bezwzględną miarą postępów zespołu. Są tylko narzędziami do zastosowania na różne, mniej lub bardziej umiejętne sposoby. Możemy uznać to za wadę (lub zaletę) nie tylko wykresu spalania, ale także innych miar wydajności zespołu.

Aby utworzyć wykres spalania, potrzebujesz innych osób do wprowadzenia danych. Innymi słowy, Deweloperzy umieszczają czas wykonania zadania na wykresie. Mogli go nieco wydłużyć lub skrócić – albo przez nieuwagę, albo przez chęć poprawienia sytuacji dla zespołu. Deweloperzy czasami zapominają też o logowaniu swojego czasu. Lub zostaw włączony minutnik. Powoduje to wydłużenie czasu pracy do kilku godzin. A po odkryciu błędu trudno odtworzyć jego prawdziwy przebieg.

Zmiany w Backlogu Sprintu

Backlog Sprintu nie powinien być modyfikowany po rozpoczęciu Sprintu. Jednak w praktyce takie zmiany zdarzają się dość często. Wynikają one ze zmieniających się wymagań Interesariuszy. Lub nieprzewidziane problemy, które napotykają programiści.

Powoduje to skalowanie wykresu wypalania. Dzieje się tak, ponieważ czas potrzebny na wykonanie zadań pozostaje taki sam. Zwiększa się jednak skala pozostałych zadań. Może to sprawiać mylne wrażenie, że Zespół Deweloperski błędnie zaplanował pracę do wykonania w danym Sprincie. Albo że działa zbyt wolno.

Zmiany w Backlogu Sprintu mogą również wynikać z zadań, które zostały zaplanowane do wykonania zbyt szybko. W takiej sytuacji Zespół Deweloperski zazwyczaj decyduje się na zwiększenie liczby zadań. To z kolei może skutkować nieukończeniem ich na czas. Konflikty mogą również wynikać z nakładania się pozostałych zadań z poprzedniego Sprintu z nowymi zadaniami zaplanowanymi do wykonania przez Interesariuszy i Właścicieli Produktu.

Zmiany w Rejestrze Produktu

Duże zmiany w Rejestrze Produktu mogą zakłócić kształt wykresu spalania. I tym samym mocno zafałszować obraz postępów prac i efektywności Zespołu. Dzieje się tak, gdy pojawiają się nowe historie użytkowników . A te, które zbliżają się do fazy realizacji, często rozbijane są na mniejsze części. Zdarza się również, że Klient rezygnuje z niektórych funkcjonalności Produktu.

Dlatego przy interpretacji wykresu wypalenia należy kierować się wiedzą i doświadczeniem w ocenie pracy Zespołu. Weź również pod uwagę zmienność Backlogu. Jeśli wykres nie jest jedynym miernikiem używanym do oceny wydajności, inne wykresy pozwolą Ci zobaczyć pełniejszy obraz postępu pracy.

Streszczenie

Wykres wypalania może znacząco przyczynić się do motywacji Zespołu Deweloperskiego. Dzieje się tak, ponieważ zapewnia miarę rzeczywistej pracy wykonanej nad planem. Co więcej, jego połączenie z innymi narzędziami metrycznymi może być źródłem cennej wiedzy na temat pracy Zespołu i planowania Produktu.

Uważnie stosując zasady Scrum, możesz uniknąć potencjalnych problemów z wypalaniem. Najważniejsze jest dostosowanie narzędzi prowadzenia wykresu do rzeczywistej pracy Zespołu Scrumowego, a także minimalizacja zmian w Sprintu i Backlogu Produktu, o czym szerzej piszemy w tym artykule.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

1. Słowniczek podstawowych pojęć, ról i pojęć
2. Co to jest Scrum?
3. Wartości Scrum
4. Jak wdrożyć Scrum w swojej firmie?
5. Zespół Scrumowy - co to jest i jak działa?
6. Kim jest Product Owner?
7. Najczęstsze błędy Product Ownera
8. Kim jest Scrum Master?
9. Charakterystyka dobrego Scrum Mastera
10. Najczęstsze błędy Scrum Mastera
11. Jakie statystyki i metryki powinien śledzić Scrum Master?
12. Współpraca Product Ownera ze Scrum Masterem
13. Zespół Deweloperski w Scrum
14. Najczęstsze błędy programistów
15. Artefakty Scrum
16. Skalowanie Scrum
17. Backlog Sprintu
18. Czym jest Backlog Produktu?
19. Czym są historie użytkowników?
20. Tworzenie najlepszej historii użytkownika z INVEST
21. Najczęstsze błędy User Story
22. Kryteria akceptacji historii użytkownika
23. Szacowanie i punkty fabularne w Scrumie
24. Poker Planowania
25. Drużynowa gra szacowania
26. Definiowanie przyrostu
27. Wydarzenia scrumowe
28. Czym jest Sprint w Scrumie?
29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
30. Co to jest wykres spalania?
31. Jak stworzyć i zinterpretować wykres spalania?
32. Zalety i wady wykresu spalania
33. Tablice Kanban w Scrum i Scrumban
34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
35. Codzienny Scrum
36. Planowanie sprintu
37. Przegląd sprintu
38. Czym jest retrospektywa sprintu?
39. Typowe błędy podczas Retrospektywy Sprintu
40. Pielęgnacja Backlogu Produktu