Znasz zakres, chcesz oszacować budżet i czas. Chcesz wiedzieć ile “man-days’ów” (ang. osobodni) zajmie realizacja poszczególnych zadań z WBS, a także kiedy wypadną kolejne kamienie milowe. Nie lubisz wróżyć z fusów, zaczynasz planować. Albo przynajmniej zaczynasz myśleć o planowaniu.
Pieniądze już mamy. Plan też. Plan brzmi: planujemy! A może jednak w coś zagramy? Kości? Bierki? Scrabble? Zagrajmy w pokera.
Czym jest poker planning?
Jest to technika relatywnego szacowania, która wywodzi się z metodyk zwinnych, głównie ze Scruma oraz programowania ekstremalnego. Polega na szacowaniu wysiłku / złożoności / rozmiaru zadań za pomocą kart.
Jest ich 14. Typowa talia ma wartości będące liczbami z ciągu Fibonacciego: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Jest to ciąg liczb określony rekurencyjnie (za pomocą wartości uprzednio znanych) według wzoru: F0 = 0. F1 = 1. Fn = Fn-1 + Fn-2, dla n ≥ 2.
W komercyjnym zastosowaniu używa się kart, które przyjmują następujące wartości: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 i 100, kawa, znak zapytania, znak nieskończoności.
Zasadę relatywności przedstawia poniższy rysunek (rys. 1), na którym widać wyraźnie, że koła nr 1, 2 i 3 różnią się względem siebie, przy czym koła nr 2 i 3 są znacznie większe od koła nr 1. Można intuicyjnie stwierdzić, że koło nr 2 jest dwukrotnie większe od koła nr 1, które jest trzykrotnie mniejsze od koła nr 3.
Łatwo to oszacować, ponieważ:
- wielkość kół nr 2 i 3 szacujemy względem koła nr 1 – mamy punkt odniesienia,
- koła nr 2 i 3 są wyraźnie większe od koła nr 1.
Zdecydowanie trudniej ocenić wielkość koła nr 4 z poniższego rysunku (rys. 2). Jeśli przyjmiemy, że koło nr 3 jest trzykrotnie większe od koła nr 1, to jaką wielkość względem koła nr 1 ma koło nr 4?
No właśnie. Mam nadzieję, że w tym miejscu już nie masz wątpliwości, że skala Fibonacciego lub jej komercyjna wersja, są słuszne. Przyjęta sekwencja liczb i rozpiętość pomiędzy nimi pomagają rozgraniczyć stopień trudności zadania, bowiem trudna do uchwycenia byłaby różnica pomiędzy zadaniami o wartościach np. 20 i 21 (podobnie jak w przypadku kół trudno rozgraniczyć wielkość pomiędzy kołami nr 3 i 4).
Pamiętaj, że jak każda technika szacowania i ta obarczona jest błędem wynikającym np. z niepewności, które pojawiają się podczas estymowania. Jednak sam etap planowania z wykorzystaniem tej metody pozwala je wcześniej zidentyfikować i wziąć pod uwagę. Stwarza Ci szansę do usunięcia przeszkód zanim spotka się z nimi zespół lub ostatecznie przygotowuje Cię na to, że przeszkody wystąpią.
Jak to zrobić w waterfall?
Choć metoda ta swoje założenia wywodzi z metodyk zwinnych, dostosowałam ją do swoich potrzeb i procesów waterfall. Jedyna modyfikacja polega na tym, że postanowiłam traktować wymaganie (pojedyncze zadanie) tak, jak Scrum traktuje user story. Wartości z kart (story point w przypadku Scruma) nie zamieniam na roboczodni, nazywam je jedynie “task pointami”, czyli nadal pozostają punktami.
User Story (Scrum) = 1 zadanie z WBS (waterfall)
1 story point = 1 task point
Dlaczego task point nie jest man-days’em?
Story point czy task point określają rozmiar zadania, natomiast roboczodzień jest jednostką określającą czas. Inaczej mówiąc, punkty nie odzwierciedlają czasu, roboczodzień czy godzina – tak. I właśnie próba “przełożenia” story pointów na jednostkę czasu (np. 1 story pint = 3 h) jest najczęściej spotykanym błędem w zespołach projektowych.
Aby rzetelnie przełożyć punkty na czas, musiałabyś uwzględnić nie tylko rozmiar zadania, ale również wydajność, doświadczenie i wiedzę pracowników. Pamiętaj, że zadanie oszacowane np. na 3 punkty, jednemu programiście zajmie x godzin, a drugiemu x+2. Idąc tą drogą, lepiej od razu zarzuć szacowanie złożoności w punktach i przestawić się na estymacje w roboczodniach lub godzinach; punkty nie mają wówczas żadnego sensu.
Czas ma również to do siebie, że np. nieoszacowane zadania stają się opóźnione. W Scrumie sprinty trwają określoną długość, niedokończone zadania z zasady nie stają się opóźnione, a wracają do backlogu i to właśnie dzięki story pointom jesteś w stanie określić velocity (prędkość) zespołu i przewidzieć ile ich zespół zdoła wykonać w trakcie jednej iteracji.
Do dzieła! Zasady gry
- Każdy członek zespołu projektowego otrzymuje zestaw kart z wartościami: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 i 100, które będą służyły do określenia wartości wymagania. Czasem talie uzupełnione są jeszcze o trzy karty – z kawą (“czas na przerwę”), ze znakiem zapytania (“nie mam pojęcia”) oraz znakiem nieskończoności (“wymaganie zbyt duże do oszacowania”).
- Scrum Master ustala zadania bazowe, które stanowić będzie punkt odniesienia dla pozostałych wymagań, najczęściej jest to 1 – zadanie, które będzie punktem odniesienia do pozostałych user story / wymagań.
- Product Owner omawia user story / wymaganie i odpowiada na ewentualne pytania członków zespołu.
- Na podane hasło wszyscy pokazują kartę z wartością określającą stopień złożoności user story / wymagania (relatywnie w odniesieniu do wyjściowego user story / wymagania).
- Osoby, które przedstawiły najniższą i najwyższą wartość tłumaczą dlaczego zaproponowały właśnie taką. Następuje przedstawienie argumentów stojących za daną estymacją.
- Następuje ponowne głosowanie.
- Kiedy udaje się dojść do porozumienia, przechodzimy do kolejnego user story / wymagania.
Kiedy gramy, musimy przede wszystkim zdawać sobie sprawę z tego, że naszym celem jest zarobienie pieniędzy.
/David Sklansky – zawodowy pokerzysta, wybitny gracz, jeden z najbardziej poważanych na świecie autorów książek poświęconych tej tematyce/
Kiedy planujemy, musimy zdawać sobie sprawę z tego, że naszym celem jest właściwe wydanie pieniędzy.
Pamiętaj:
- Product Owner nie uczestniczy w estymowaniu
- Jeśli po 3-4 rundach uczestnicy nie będą w stanie dojść do porozumienia, oznacza to, że user story / wymaganie wymaga doprecyzowania
- Jeśli wynikiem szacowania jest nieskończoność, oznacza to, że user story / wymaganie jest za duże do oszacowania i należy je podzielić na mniejsze, łatwiejsze do oszacowania
- Jeśli któryś z członków zespołu pokaże kartę ze znakiem “?”, oznacza to, że user story / wymaganie wymaga dalszego wyjaśnienia
- Jeśli któryś z członków zespołu pokaże kartę symbolizującą kawę, znaczy, że czas na przerwę
- Alternatywne do liczenia do 3 jest również wykładanie kart na stół (wartością do blatu) i odkrywanie kart, kiedy już wszyscy uczestnicy wyłożą swoje karty
Korzyści, jakie przynosi szacowanie tą metodą, są wielowymiarowe. Osiąga je zarówno zespół poprzez zrozumienie zadań do realizacji i walor integracyjny, jak i sam projekt – można go określić w czasie.
Aspekt twardy – “rozumiem co i wiem jak”
- Zrozumienie zakresu prac, które podlegają estymacji
- Wychwycenie ewentualnych braków w ustaleniach lub przewidywanie “co jeśli?”
- Rozstrzygnięcie niejasnych kwestii już na poziomie estymowania
- Zwiększenie precyzji ustaleń w toku dyskusji
- Wykorzystanie wiedzy całego zespołu, w tym wiedzy osób kompetentnych, odpowiedzialnych za realizację
- Zrozumienie sposobu realizacji zadań
- Urealnienie czasu realizacji zadań
Aspekt miękki – “dzielę się wiedzą, komunikuję się, integruję, czuję się odpowiedzialny”
- Wymiana doświadczeń pomiędzy członkami zespołu
- Za wspólnie wypracowane wartości odpowiada cały zespół, a nie tylko Product Owner / PM
- Utożsamianie się z estymacją (poczucie odpowiedzialności za ustaloną wartość)
- Element integrujący, odskocznia od formalnych spotkań
Korzyści dla projektu
- Wiarygodność estymacji – członkowie zespołu pokazują swoje karty jednocześnie, nie mogą sugerować się opinią innych
- Relatywne szacowanie user story / wymagań w stosunku do pozostałych
- Określenie czasu trwania projektu
Włączając poker planning do etapu planowania, nie tylko angażujesz do współpracy zespól już na wczesnym etapie projektu, ale także zyskujesz realne spojrzenie na czas, który dla Ciebie przekłada się na budżet, a w końcu Ty odpowiadasz za to, żeby był dobrze wykorzystany.
Pobierz:
