A gdyby tak zagrać w pracy w pokera?

Blog / Dobre praktyki / A gdyby tak zagrać w pracy w pokera?

Jak często zdarza się Wam szacować czas pracy, jaki Wasze zespoły będą musiały poświęcić na zadania, które będą musiały zostać zrealizowane w sprincie czy timebox’ie?

Czy wam lub waszym managerom lub kierownikom projektu zdarza się stosować magiczny mnożnik, aby urealnić czas zadań, który jest Waszym zdaniem błędnie określony przez zespół Developerski?

Jak to zmienić? Jak doprowadzić do tego aby szacowanie nie do końca było zabawą w zgadywanie a coraz częściej dostarczało przewidywalne i sprawdzające się estymacje?

Tutaj z pomocą przychodzi sympatyczna technika zwana Planning Poker.

Metoda ta została po raz pierwszy opisana w 2002 roku w krótkim artykule autorstwa James’a Grenning’a. Następnie została dokładniej omówiona Przez Mike’a Cohn’a w książce „Agile Estimating and Planning”. Firma Cohn’a, Mountain Goat Software jest właścicielem znaku towarowego Planning Poker, oraz posiada patent na sekwencje wartości.

Nazwa tej metody wzięła się stąd, że w szacowaniu używamy kart oraz tego jak one są odkrywane.

Jak działa planning poker?

W metodzie nie używamy czasu pracy jaki potrzebny jest na zrealizowanie założonego User Stories a tak zwanych Story Points, które pokazują złożoność historyjek względem siebie.

W grze biorą udział wszyscy członkowie zespołu włącznie z Produkt Ownerem lub Kierownikiem Projektu, każdy z nich musi posiadać komplet kart, z różnymi wartościami (głównie wykorzystywany jest model z wartościami liczbowymi ale zdarzają się również modele z np. wartościami znanymi z rozmiarów koszulek). Ważne jest wartości nie były liniowe więc często wykorzystuje się wartości zawierające skalę wykładniczą, ciąg Fibonacciego lub co jest wykorzystywane w oryginalnym Planning Poker, zmodyfikowany ciąg Fibonacciego czyli liczby 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 i 100. Czasem dokłada się jeszcze dwie dodatkowe karty – np. ?, który określa, że dany członek zespołu nie potrafi określić czasu produkcji danej historyjki.

Sesję zaczyna się od wybrania teoretycznie najprostszej lub najłatwiejszej w oszacowaniu Historyjki takiej, którą będziemy mogli oszacować np. na 1SP lub np. na 5SP. Aby ułatwić to zadania dobrze jest zapisać na tablicy szacowania SP dla kilku typowych User Stories .

Moderator czyta po kolei User Stories, a po każdej z nich członkowie zespołu wyciągają karty z taką ilością SP, które ich zdaniem powinna mieć dana historyjka.

Jeżeli wartości znacząco się różnią, to właściciele największej i najmniejszej ilości wskazanych SP opowiadają, dlaczego wybrali właśnie takie karty po czym ponawiane jest głosowanie. W tym procesie nie chodzi obronę własnej tezy a jedynie wskazanie czynników, które były przez nich brane pod uwagę tak aby ponownie rozpatrzył je cały zespół (może to być kwestia związana z tym, że w firmie pojawia się nowa nieznana technologia, mamy nowego członka w zespole i testowanie może się wydłużyć lub np. faktu, że podobne rozwiązanie kiedyś było już napisane i nie trzeba wymyślać koła od nowa).

Po 2-3 głosowaniach, zespół zazwyczaj jest zgodny lub różnice są niewielkie i można przyjąć jakąś metodę oceny np. wybór większością głosów lub ostatecznie decyduje Lider.

Jakie są zalety wykorzystania pokera?

  • Każdy z członków pracuje indywidualnie i nie opiera się tylko na wiedzy lidera z danej dziedziny
  • Porównywanie Historyjek na zasadzie „ta będzie większa od 8 ale mniejsza od 20 więc zróbmy z niej 13”
  • Szybkość – na godzinnym spotkaniu można ocenić naprawdę sporo Historyjek
  • Historyjki są przedyskutowane w gronie expertów mających wiedzę porównawczą z poprzednich szacowań

Co zrobić jak nie mamy kart?

  • Można wykorzystać karteczki z wypisanymi liczbami
  • Można użyć kilku dostępnych na telefony aplikacji
  • Można skorzystać z darmowej wersji aplikacji webowej http://planningpoker.com/

Jak szacowanie przełożyć na realny czas projektu?

Tutaj mamy dwie możliwości:

  1. Na początku wybraliśmy najłatwiejszą w szacowaniu Historyjkę – pewnie w pewnym przybliżeniu możemy określić więc czas jej trwania w godzinach a następnie porównać to z pozostałymi Historyjkami. Uda nam się określić ile czasu potrzebujemy na realizację wszystkich User Stories.
  2. Częściej stosowaną metodą jest określenie Prędkości (ang. Velocity) Zespołu, np. na 40 SP/sprint. Zapewne to podejście na początku będzie obarczone pewnymi błędami ale w kolejnych iteracjach nasze estymaty będą zdecydowanie bardziej precyzyjne niż w tradycyjnej metodzie planowania.

Po więcej informacji odsyłam do: „Agile Estimation Practise – Demystifying Story Points” – John Donovan.

Paweł Cichoń

Manager z 12 letnim doświadczeniem w branży IT. Doświadczenie w zarządzaniu zdobywał w firmach z sektora logistycznego, finansowego, e-commerce i automotive. Brał udział w wielu innowacyjnych projektach gdzie wsparcie IT umożliwiało dostarczanie wydajnych i wysokodostępnych usług biznesowych. Do dostarczania usług szytych na miarę potrzeb biznesu podchodzi z pasją podobnie jak do otaczających go ludzi, co umożliwia mu tworzenie zespołów rozumiejących potrzeby biznesu jak i budować dopasowanie Biznes-IT. Motywuje go rozwój swój jak i współpracowników. W czasie prywatnym spędza czas z rodziną, pożera książki i gra w squash.

Dodaj komentarz

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