Poker planning – granie w planowanie

Poker planning

Znasz zakres, chcesz oszacować budżet i czas. Chcesz wiedzieć ile “man-days’ów” (ang. osobodni) zajmie realizacja poszczególnych user stories lub 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.

Zasada relatywności

Ł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?

Zasada relatywności

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 metodyk 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.

Aby przełożyć punkty na czas, musisz uwzględnić nie tylko rozmiar zadania, ale również wydajność pracowników. Pamiętaj, że zadanie oszacowane np. na 3 punkty, jednemu programiście zajmie x godzin, a drugiemu x+2, uwzględnij więc przy planowaniu doświadczenie i wiedzę poszczególnych członków zespołu.

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”).
  • Project Manager / 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 / PM 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 / PM nie uczestniczą 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:

Więcej wpisów autora: Karolina Jarocka

Dziennik Projektu – zrewolucjonizuj raportowanie w projekcie!

Raportowanie w projekcie to nie lada wyzwanie, zwłaszcza dla tych, którzy nie...
Czytaj dalej

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *