Planning Poker

Prezentacja Slajd01

Slajd02 Slajd03 Slajd04 Slajd05 Slajd06 Slajd07 Slajd08 Slajd09 Slajd10 Slajd11 Slajd12 Slajd13 Slajd14 Slajd15 Slajd16 Slajd17 Slajd18 Slajd19

Metodyki zwinne określane mianem Agile w ostatnich czasach zyskują na popularności. Wynika to z faktu dużej ich skuteczności przy minimalnych nakładach czasowych związanych z realizacją procesów zarządczych w projektach. Nie wszystkie projekty są idealne dla tej metody monitorowania przebiegu. W przypadku wielki projektów, gdzie dokładnie musimy znać czasy przestojów linii, dostarczenia komponentów, wyłączenia z użytkowania obiektów, ważne jest ustalenie terminów z dużym wyprzedzeniem. Bardzo często stosuje dla takich projektów mieszane techniki nadzorowania realizacji, podstawowy klasyczny harmonogram, w których pewne produkty cząstkowe monitoruje się poprzez technikę zwaną Burndown Charter. Autor w chwili obecnej przygotowuje dwa moduły do dotProject pozwalające na wykorzystanie techniki Planning Poker / Burndown Charter do estymacji czasu trwania poszczególnych funkcjonalności produktu końcowego (ang. items) oraz zadań (ang. tasks). Dla czytelności opisu będą używane słowa angielskie, gdyż brak odpowiedników w języku polskim oddających w pełni podane znaczenie. Należy podkreślić, że opisane techniki są wykorzystywane w metodyce SCRUM, jednak można je wykorzystać jako samowystarczającą technikę monitorowania przebiegu projektu.

 

Planning Poker wykorzystuje:

 

  • Opinie eksperckie - każdy z członków zespołu posiada bagaż doświadczeń;
  • Podział na mniejsze elementy - dostarczany produkt dekomponujemy na items, a items na tasks;
  • Analogię - porównujemy podobne task oraz item, również z innych projektów.

 

Technika niezwykle usprawnia komunikacje w zespole, wymusza podejmowanie opinii przez każdego członka zespołu. Planning Poker cechuje wyjątkowo krótki czas poświęcanych na sam proces estymacji, przy trafnych ocenach.

Krok 1

Określenie cech produktu dostarczanego przez projekt, jego rezultat. To zadanie należy do Kluczowego użytkownika (Product Owner w metodyce SCRUM). Bez względu na to czy dostarczamy w ramach projektu namacalny produkt czy usługę - rezultat będziemy nazywać produktem. Produkt zostanie zdekomponowany na items (funkcjonalności, cechy, produkty cząstkowe), a items zdekomponujemy na zadania do wykonania (tasks). W pierwszym kroku tylko określamy items składające się na produkt. Wszystkie cechy produktu (items) należy uporządkować według priorytetów. Najlepiej posłużyć się notacją Moscow:

  • M - Must have - tę funkcjonalność produkt posiadać musi, często jest konieczna do realizacji innych wymagań
  • o
  • S - Should have - tę funkcjonalność produkt posiadać powinien
  • C - Could have - tę funkcjonalność produkt mógłby posiadać, jest pożądana
  • o
  • W - Will not have (won't have) - tęj funkcjonalności w bieżącej realizacji nie uwzględnimy

Litery "o" zostały dodane, aby łatwo było zapamiętać nazwę metody i nic nie znaczą. W metodyce SCRUM lista uporządkowanych items (u góry najbardziej pożądane) stanowi tzw. backlog produktu.

Krok 2

W następnym kroku dokonujemy oceny złożoności / skomplikowania realizacji items. Należy pamiętać o ich wzajemnych powiązaniach np. aby kupić mieszkanie na kredyt, najpierw należy zawrzeć umowę kredytową z bankiem. Jeden item - mieszkanie zależy od drugiego - kredyt. Estymację przeprowadzamy między innymi przy użyciu techniki Planning Poker.

Estymacja items ma charakter pomocniczy, pozwala zorientować się w złożoności poszczególnych cech, funkcjonalności, produktów cząstkowych oraz ich zależności między sobą. Pozwala także opisać stopień złożoności wykonania produktu końcowego.

W drugim kroku również dokonujemy dekompozycji items na tasks. Na każdą funkcjonalność, cechę lub produkt cząstkowyy składa sie szereg czynności, aby ją uzyskać w finalnym produkcie. Np. w celu uzyskania kredytu trzeba między innymi pobrać wnioski z banku, uzyskać zaświadczenia o dochodzie, złożyć niezbędne formularze w banku, podpisać umowę kredytową.

Krok 3

W przypadku metodyki SCRUM wytwarzanie produktu będzie następowało iteracyjnie, w cyklach o stałym okresie (od 2 do 4 tygodni). Dlatego do pojedynczego przebiegu wybieramy odpowiednią ilość items, którą będziemy w stanie zrealizować w tym stałym czasie. Estymujemy wyłącznie zadania (tasks) składające się na wybrane items w danym przebiegu (ang. sprint). 

W przypadku korzystania tylko z Burndown charter do zarządzania projektem estymujemy wartości dla wszystkich zadań należących do projektu. W tym celu dokonujemy dekompozycji items na tasks (jeśli tego nie zrobiliśmy w kroku 2). Następnie estymujemy wszystkie tasks.

 

Krok 4

Wpisujemy uzyskane wartości do Burndown charter-a. Arkusz Excela można pobrać tu. Następna czynnością jest przypisanie tasks osobom je realizującym. Nie wszystkie zadania zostaną przypisane od razu, gdyż nie wiemy kto je będzie wykonywał. Jednak znaczna ich część jest na tyle charakterystyczna, że możemy od razu je przyporządkować do właścicieli. W innym artykule znajdziesz opis jak zarządzać przebiegiem projektu przy pomocy Burndown charter-a. (link wkrótce)

 

Planning Poker

[1] Agile Estimating and Planning, Mike Cohn

Autorem tej techniki szacowania jest Mike Cohn, który między innymi stworzył metodykę SCRUM (czyt. skram). Opis został zaczerpnięty z literatury [1] - widok okładki znajduje się obok. Technika opiera się na wskazywaniu względnych wartości odpowiadających czasom realizacji/ stopniu skomplikowania/ złożoności zadań (tasks) i funkcjonalności (items). Szacowanie polega na wytypowaniu karty z proponowaną wartością przez każdego członka zespołu po odczytaniu historyjki opisującej czego dany item albo task dotyczy. Zestaw kart u każdego uczestnika zawiera wartości 1/2, 1, 2, 3, 5, 8, 13, 20. Można spotkać talie rozszerzone o: 0, 40, 100, ?, break. Znaczenie wartości jest względne, tzn. nie jest reprezentowane przez konkretne wartości np. dni czy godziny. Jeśli jakieś zadanie (task) zostało oszacowane na 1, a inne na 3 to oznacza, że jest trzykrotnie bardziej złożone lub zabiera trzy razy więcej czasu niż to pierwsze. Takie jest znaczenie wartości względnych. Ilość kart z pełnego przedziału (np. 0 -100)  została ograniczona do kilku wartości. Wynika to z faktu niewielkiej różnicy pomiędzy np. 12, 13 i 14. Czas poświęcany na zastanawianie się która z nich jest "lepsza", by się wydłużał, a nie byłoby przełożenia na zwiększenie trafności estymacji. Ciąg jest tak dobrany, aby następna karta była mniej-więcej sumą wartości dwóch poprzednich.

Proces estymacji polega na wytypowaniu wartości dla poszczególnych tasks (lub items). Do estymacji potrzebujemy: zestaw kart dla każdego uczestnika (pobierz i wydrukuj), listy z opisanymi funkcjonalnościami i/lub zadaniami (items oraz tasks), czasomierza odliczającego 2 lub 3 minuty (najczęściej stosuje się sprężynowe minutniki).

W pierwszej kolejności członkowie zespołu zadają szereg pytań Kluczowemu Użytkownikowi (w SCRUM rola nazywa się Product Owner), który określa jakie cechy zawiera produkt, jak należy rozumieć opisane funkcjonalności i zadania. Po wyczerpaniu wszystkich pytań zaczyna się właściwa estymacja. Osoba kierująca procesem oceny (w SCRUM może to być Scrum Master lub członek zespołu) odczytuje pierwszą historyjkę zawierającą opis pierwszego zadania. Wszyscy uczestnicy wybierają kartę i wyciągają ją z tali, przytrzymując w dłoni w taki sposób, aby była niewidoczna dla pozostałych. Chodzi o niesugerowanie wyboru innym. Jeśli wszyscy trzymają w dłoni kartę można je położyć na stole tak, aby inni mogli poznać oceny. Jeśli zdecydowana większość wytypowała tę samą wartość to mamy gotowy wynik, który wpisujemy do arkusza. Jeśli nie to nakręcamy czasomierz na 3 minuty i rozpoczynamy dyskusję. Najczęściej zabierają głos osoby, które wytypowały najbardziej skrajne oceny. Dyskutować można wyłącznie do dzwonka. Po dzwonku należy ponownie przeprowadzić głosowanie. W dyskusji staramy sie osiągnąć konsensus. jeśli nie uda się doprowadzić do wspólnego werdyktu należy w czwartym głosowaniu wpisać średnią. Po pewnym czasie zespół nabierze wprawy,  co pozwoli skrócić czas dyskusji do 2 minut.

Uwaga dotycząca minutników: przekręcić pokrętło do 20 i powrócić na 2 lub 3 minuty. Jeśli będziesz nakręcać sprężynę mocniej dzwonek będzie długo dzwonił, jeśli od razu ustawisz 2 zapewne nie zadzwoni wcale.

Po wykonaniu estymacji wszystkich zadań należy wpisać je do burndown charter-a. Proces monitorowania polega na modyfikacji wartości przypisanej zadaniom każdego dnia w zależnosci od wykonanych prac. Liczba reprezentująca czas dla zadania może sie zwiększać - okazało się trudniejesze niż oczekiwano. Bardzo często zadaniu które zrealizowaliśmy całkowicie i jest ocenione jako 0 po jakimś czasie otrzymuje wartość niezerową.

Suma wszystkich wartości jest miarą pozostałej pracy do wykonania. Do listy można również dopisywać zadania w dowolnym momencie np. zapomnieliśmy o jakiś czynnościach lub nowe zadania wynikają z reagowania na zmieniające się otoczenie projektu, zmiany wymagań interesariuszy itp.

Przykładowy przebieg projektu

 

ZałącznikWielkość
Karty do Planning Poker.pdf315.3 KB
Monitorowanie przebiegu projektu.xls109.5 KB
Tabela estymacji do Planning Poker.pdf336.08 KB