W artykule przedstawiam sposoby na uzyskiwanie wiarygodnych informacji o skuteczności zespołu i jej przyczynach. Prezentuję metodę, którą stworzyłem opierając się na pomysłach praktyków i Guru SCRUM'a, znakomicie działającą podczas dłuższych projektów. Przypomina ona w dużej mierze Wykres Spalania (Burndown Chart), dlatego polecam przeczytanie najpierw artykułu na ten temat (link), a później powrót tutaj.
Kasia, jeden z PSPO (Professional Scrum Product Owner) firmy Mobitech, doprowadziła do podpisania kontraktu z dużą firmą szkoleniową na dostarczenie oprogramowania mobilnego służącego do prowadzenia interaktywnych warsztatów sprzedażowych. Podczas rozmów z klientem dobrze poznała założenia projektu i opracowała wstępny zarys Product Backlog'u (Rejestru Produktu). Po dyskusji z zespołem, który zajmie się realizacją projektu, ustaliła, że przewidywalny zakres projektu to 400 Story Points. Klient chce dostać oprogramowanie przed upływem dwudziestu tygodni.
Rafał, PSM (Professional Scrum Master) wyznaczony do czuwania nad projektem, obliczył, że w trakcie każdego z 10 dwutygodniowych Sprintów zespół będzie musiał realizować 40 Story Points. Biorąc pod uwagę, że przeciętny Focus Factor zespołów w Mobitech kształtuje się na poziomie około 70%, ustalił, że Sprinty będą wymagały zespołu dysponującego około 60 Man Days na 10 dni. Przy pełnej dyspozycyjności zasobów ludzkich Mobitech'u, daje to 6 osobowy zespół. Taką właśnie liczebność Rafał zaproponował zarządowi Mobitech'u.
Po 8 sprintach zespół ma do zrealizowania jeszcze 180 Story Points, czyli średnio 90 w każdym z dwóch pozostałych sprintów.
Stosując "tradycyjny" wykres spalania całego projektu, czyli Release Monitoring/Burndown Chart, Scrum Master otrzymuje następujący obraz projektu.
Stosując "tradycyjny" wykres spalania całego projektu, czyli Release Monitoring/Burndown Chart, Scrum Master otrzymuje następujący obraz projektu.
Bez sięgania po dodatkowe informacje, można wnioskować, że w 3 i 6 sprincie "coś" się stało. Jedna z możliwości to niedoszacowanie zadań, jakie wziął na siebie Development Team. Wskazuje na nią wznosząca się krzywa, która oznacza, że po Sprincie pozostało więcej Story Points niż przed nim. Druga opcja, to "sabotaż" Product Ownera, który dołożył w trakcie sprintu dodatkowe Story Points do Product Backlog'u. Nie da się podać prawdziwej przyczyny bez analizy dodatkowych informacji.
Dużo mogłaby wnieść analiza Burndown Charts z 3 i 6 Sprintu. Jeżeli nie wskazują one na złą samoorganizację Development Teamu'u, to prawdopodobnie wina leży po stronie Product Ownera, który rozszerza zakres projektu.
Pytania, na jakie musi odpowiedzieć Scrum Master to:
Dużo mogłaby wnieść analiza Burndown Charts z 3 i 6 Sprintu. Jeżeli nie wskazują one na złą samoorganizację Development Teamu'u, to prawdopodobnie wina leży po stronie Product Ownera, który rozszerza zakres projektu.
Pytania, na jakie musi odpowiedzieć Scrum Master to:
- Co jest przyczyną niekorzystnego przebiegu wykresu w sprintach 3 i 6? ( Złe szacowanie zespołu, a może dodatkowe zadania od PSPO? )
- Jeżeli to zespół źle szacuje, jakie podjąć działania zaradcze?
- Jeżeli za dodatkowe Story Points odpowiada Product Owner, to ile punktów zostało dodanych a ile spalonych? (Jeżeli PSPO dodał więcej punktów niż odległość wykresu spalania od idealnej ścieżki spalania, to zespół spisuje się rewelacyjnie. Jeżeli nie, to zespół sobie nie radzi)
- Czy do zespołu powinna dołączyć kolejna osoba, a może trzeba pracować nad wydajnością zespołu?
Wykres zamieszczony poniżej pozwala rozwiać wątpliwości Scrum Mastera i podjąć właściwe decyzje.
Wykres wprowadza dwie innowacje.
Pierwsza to dodatkowa oś pionowa, odzwierciedlająca Focus Factor Development Team'u. Jest to wskaźnik zaczerpnięty od Henrika Kniberga (Scrum and XP from the Trenches) pokazujący relację pomiędzy Available Man Days na dany Sprint, a Actual Velocity (spalone Story Points) z danego Sprintu. Im wyższa jego wartość tym wyższa wydajność zespołu. Np. jeżeli zespół dysponuje 10 Man Days a spalił 7 Story Points, to znaczy, że pracował z wydajnością 70%. Jeśli w kolejnych Sprintach wskaźnik utrzymuje się na podobnym poziomie to znaczy, że zespół pracuje równo. Systematyczny wzrost oznacza, że Development Team coraz lepiej się samoorganizuje. Spadający wskaźnik sygnalizuje występowanie problemów. Warto zauważyć, że wskaźnik jest niezależny od tego, jak zespół szacuje, czy Product Owner dokłada zadania, czy redukuje zakres. Focus Factor zawsze pokazuje relację pomiędzy potencjałem zespołu a tym co osiągnął!
Drugą innowacją jest krzywa idealnego spalania Story Points w projekcie. Wprowadzenie krzywej w miejsce odcinka umożliwia modyfikowanie idealnej ścieżki o zmiany zakresu projektu dokonywane przez Product Owner'a. Można dzięki niej śledzić prawdziwe, aktualne odchylenia pracy zespołu od ideału, zamiast analizować fikcyjne odchylenia od ścieżki wyznaczonej na początku projektu. Na krzywej nie są zaznaczane zmiany szacunków dokonanych przez Development Team w odniesieniu do początkowego Product Backlog'u. Dzięki temu można obserwować zmiany wynikające z jakości pracy zespołu niezależnie od modyfikacji zakresu wprowadzanych przez Product Owner'a.
Analiza wykresu odpowiada praktycznie na wszystkie pytania zadane przez Scrum Mastera.
Pierwsza to dodatkowa oś pionowa, odzwierciedlająca Focus Factor Development Team'u. Jest to wskaźnik zaczerpnięty od Henrika Kniberga (Scrum and XP from the Trenches) pokazujący relację pomiędzy Available Man Days na dany Sprint, a Actual Velocity (spalone Story Points) z danego Sprintu. Im wyższa jego wartość tym wyższa wydajność zespołu. Np. jeżeli zespół dysponuje 10 Man Days a spalił 7 Story Points, to znaczy, że pracował z wydajnością 70%. Jeśli w kolejnych Sprintach wskaźnik utrzymuje się na podobnym poziomie to znaczy, że zespół pracuje równo. Systematyczny wzrost oznacza, że Development Team coraz lepiej się samoorganizuje. Spadający wskaźnik sygnalizuje występowanie problemów. Warto zauważyć, że wskaźnik jest niezależny od tego, jak zespół szacuje, czy Product Owner dokłada zadania, czy redukuje zakres. Focus Factor zawsze pokazuje relację pomiędzy potencjałem zespołu a tym co osiągnął!
Drugą innowacją jest krzywa idealnego spalania Story Points w projekcie. Wprowadzenie krzywej w miejsce odcinka umożliwia modyfikowanie idealnej ścieżki o zmiany zakresu projektu dokonywane przez Product Owner'a. Można dzięki niej śledzić prawdziwe, aktualne odchylenia pracy zespołu od ideału, zamiast analizować fikcyjne odchylenia od ścieżki wyznaczonej na początku projektu. Na krzywej nie są zaznaczane zmiany szacunków dokonanych przez Development Team w odniesieniu do początkowego Product Backlog'u. Dzięki temu można obserwować zmiany wynikające z jakości pracy zespołu niezależnie od modyfikacji zakresu wprowadzanych przez Product Owner'a.
Analiza wykresu odpowiada praktycznie na wszystkie pytania zadane przez Scrum Mastera.
- Za odchylenie w Sprincie 3 odpowiedzialny jest na pewno Product Owner ponieważ podniosła się idealna ścieżka spalania. Wskazuje to na rozszerzenie zakresu projektu i zmianę tempa spalania (kąt nachylenia krzywej) prowadzącego do realizacji projektu w terminie. Niewykluczone, że również zespół nie doszacował części zadań. Warto przeanalizować dodatkowo Wskaźnik Dokładności Szacowania Zadań ( Task Estimation Accuracy Metric = Estimated Velocity / Actual Velocity + Remaining Story Points ). Wskaźnik dokładnie opisuje Ilan Goldstein na swoim blogu (link na końcu artykułu). W skrócie, wartości mniejsze od 1 sygnalizują, że zespół robi więcej niż zakładał na początku Sprintu. Większe od 1 oznaczają, że Development Team przeszacowuje swoje możliwości lub nie doszacowuje rzeczywistą czasochłonność zadań. Gdyby jednak niedoszacowanie zadań przez zespół było znaczące, to wykres spalania poszedłby w górę dużo bardziej niż ścieżka idealnego spalania.
- Co bardzo ważne, Focus Factor zespołu w 3 Sprincie się nie zmienił, co oznacza, że zespół dobrze wykonuje swoją pracę, a zaburzenie krzywej spalania to efekt działań Product Owner'a.
- Pomimo utrzymania stałej wydajności, krzywa spalania coraz bardziej oddala się od idealnej ścieżki. Widać to dzięki zmianie kąta jej nachylenia. Żeby zespół zdążył z terminową realizacją projektu niezbędne jest zwiększenie wydajności zespołu lub dodanie Available Man Days, przez rozszerzenie składu Development Team'u. W pierwszej kolejności Scrum Master powinien przeanalizować Impediment Backlog (Rejestr Przeszkód), żeby wyeliminować potencjalne bariery pracy zespołu, obniżające jego wydajność.
- Teoretycznie podobna zmiana po Sprincie 6, okazuje się mieć zupełnie inne przyczyny niż wcześniejsze odchylenie. Dzięki wykresowi można zauważyć, że Product Owner dodał stosunkowo niewiele Story Points (30) do projektu. Mimo to, krzywa spalania poszła bardzo w górę. Winę ponosi za to słaba wydajność zespołu, który zanotował bardzo niski poziom Focus Factor. Najprawdopodobniej wydarzyło się coś niekorzystnego wewnątrz Development Team'u. Sprawa wymaga bliższego przyjrzenia się.
- Bardzo ciekawe informacje pokazuje kształt wykresu po Sprincie 7. Wykres standardowy nie wskazywał na nic nadzwyczajnego. Tymczasem kolejne załamanie się idealnej ścieżki spalania pokazuje, że Product Owner znów dodał Story Points do zakresu projektu. Pomimo to, krzywa spalania nie zmieniła swojego kąta. Oznacza to, że Development Team wyrobił swoją normę 40 Story Points oraz dodatkowe 30, dodane przez PSPO. Potwierdza to bardzo wysoki poziom Focus Factor. Scrum Master musi nagrodzić zespół :-)
Dodatkowe wskazania wykresu, który nazwałem Improved Release Monitoring Chart pozwalają dużo dokładniej śledzić przebieg projektu i reagować w odpowiedni sposób na zachodzące w nim zdarzenia. Jego tworzenie jest bardzo proste i nie wymaga od Scrum Mastera praktycznie żadnych dodatkowych nakładów pracy. Wykres stanowi w rękach PSM'a dodatkowy atut np. podczas rozmów z zarządem, kiedy trzeba negocjować dodanie kolejnej osoby do zespołu lub nagrody dla Development Teamu (Sprint 7).
Poza Improved Release Monitoring Chart warto śledzić również proste wskaźniki liczbowe. Jedną z ważnych wartości jest przeciętna wartość spalania zespołu (Average Velocity). Jej obserwacja i porównywanie z zakresem projektu liczonym w Story Points pozwala na bieżąco określać prognozowane opóźnienie projektu. W omawianym przykładzie Average Velocity wynosiło po 4 Sprincie 40 Story Points. Przy zakresie wynoszącym 450 było jasne, że bez zmiany tej wartości projekt opóźni się o około 1 Sprint. Wyjściem była praca nad Focus Factor, albo dodanie nowego członka zespołu. Brak reakcji na odchylenia sprawił, że kolejne zmiany w projekcie zaowocowały zwiększeniem zakresu projektu do 510, przy niezmiennym niemal poziomie Average Velocity, który w tamtym momencie wynosił nieco ponad 41 (wyłącznie dzięki rewelacyjnemu 7 Sprintowi). W rezultacie spodziewane opóźnienie zbliżyło się do 3 Sprintów, czyli 6 tygodni!
Linki:
Inspiracją do stworzenia Improved Release Monitoring Chart była w dużej mierze lektura bloga Mike'a Cohn'a - http://www.mountaingoatsoftware.com/
Wiele zaczerpnąłem od Ilan'a Goldstein'a - http://www.scrumshortcuts.com/blog/
Focus Factor od Herika Kniberg'a - http://www.crisp.se/bocker-och-produkter/scrum-and-xp-from-the-trenches
Brak komentarzy:
Prześlij komentarz