Prognoza oraz zobowiązanie w Scrumie

Nostradamus

Nostradamus

W połowie 2011 roku miała miejsce aktualizacja Scrum Guide’a. Jedną z większych zmian było zastąpienie słowa „zobowiązanie” na „prognoza” w kontekście zakresu sprintu, ustalanego przez zespół deweloperski.

Zmiana ta jest akceptacją faktu, że tworzenie oprogramowania to skomplikowany i mało przewidywalny proces. Trudno wobec tego wymagać od zespołu, aby zobowiązał się do wykonania konkretnej liczby zadań, wybranych podczas planowania sprintu. To, co zespół może wykonać, to prognoza zakresu, który planuje dostarczyć w kolejnym sprincie.

Pozornie wygląda to jak zwolnienie zespołu z odpowiedzialności. Nic bardziej mylnego – zespół nadal zobowiązuje się do wykonania pracy na poziomie celu sprintu.

Przykład

Załóżmy, że zespół scrumowy tworzy sklep interentowy.

Zespół wraz z Product Ownerem formułuje cel sprintu, który zobowiązuje się zrealizować: „Zwiększenie liczby sposobów dostawy przedmiotów”.

Zespół prognozuje, że będzie w stanie dodać możliwość:

  • odbióru osobistego
  • przesyłki Pocztą Polską
  • usługi kuriera
  • odbioru w Paczkomacie

Nawet jeśli zespół nie dostarczy na koniec sprintu możliwości odbioru w Paczkomacie, a wszystkie pozostałe sposoby odbioru zostaną ukończone, cel sprintu zostanie spełniony – liczba sposobów dostawy zostanie zwiększona.

Podsumowanie

Zgodnie z aktualną wersją Scrum Guide’a, zespół zobowiązuje się zrealizować cel sprintu i prognozuje zakres, który będzie realizował ten cel.

Wspomniana zmiana przekłada ciężar z zakresu sprintu na cel sprintu. Wymaga dobrze przygotowanego Product Backlogu oraz przemyślanych celów na kolejne sprinty.

Fotografia użyta na licencji Creative Commons od użytkownika dierk schaefer.

Scrum Master – Batman czy Joker?

Scrum Master - Joker czy Batman?

Scrum Master – Batman czy Joker?

Spotykam się z dwoma modelami pracy Scrum Mastera. Różnią się one od siebie zasadniczo stopniem zaangażowania czasowego.

Jedni widzą tę rolę jako praca typowo z doskoku – usuwanie problemów, które w jakiś sposób blokują zespół, prowadzenie ceremonii scrumowych, pilnowanie timeboxów. Kiedy Scrum Master wykona zadania względem zespołu, może wrócić do swojej macierzystej roli – programisty, kierownika czy też project managera.

Balansuje między dwoma rolami, niczym Bruce Wayne – na codzień jest zwykłym członkiem zespołu deweloperskiego, ale kiedy zachodzi potrzeba i zespół wzywa go, zakłada kostium super bohatera i pojawia się na posterunku, zupełnie jak Batman na ulicach Gotham City.

Dla innych to praca na pełen etat, w myśl zasady, że dobry Scrum Master potrafi poprowadzić dwa lub trzy zespoły, natomiast świetny Scrum Master – tylko jeden. Kiedy wykona pracę z zespołem, pracuje z Product Ownerem lub ewangelizuje organizację. Ma czas na edukację, rozmowy ze społecznością Scrum Masterów oraz złapanie odpowiedniego dystansu, aby pomóc zespołowi wejść na kolejny poziom rozwoju.

Jest niczym Joker, który w sposób ciągły oraz w pełni transparentny sposób realizuje swoje zadania. Jest cały czas sobą, zaangażowany na 100%.

A kim Ty jesteś?

Fotografia użyta na licencji Creative Commons od użytkownika Daniel Dobleu.