W pierwszej części rozprawiałyśmy o teoretycznych podstawach estymowania, czas na zajęcie się przykładami technik estymacji wspierających zespół w szacowaniu. Tutaj podkreślamy słowo wspierających – nie są to techniki wiodące, jedyne słuszne, czy najbardziej efektywne.
Podstawą każdej estymacji jest dyskusja i zrozumienie wymagań,
a nie to, w jaki sposób nadamy wartość zadaniu.
Dajcie znać w komentarzach, jakie techniki poza tymi wymienionymi są wam znane i sprawdzają się w waszej codzienności produkowo-projektowej!
Planning Poker
Planning Poker to technika estymacji, która wykorzystuje ciąg liczb np. 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 jako określników złożoności. Te liczby mogą być story pointami, dniami, manday’ami, godzinami itd. Można im przypisać dowolną miarę.
Jak grać? Każdy estymujący posiada swoją talię kart do PP. Przed estymacją, omawia się funkcjonalność. Gdy wszystkie wątpliwości zostaną wyjaśnione, estymujący wybierają indywidualnie, w tajemnicy przed innymi kartę reprezentującą estymację.
Następnie każdy pokazuje swój wybór. Jeśli wszyscy wybrali tę samą wartość, staje się ona estymacją dla omawianego zadania. Jeśli nie ma zgodności, Ci, którzy wybrali najmniejszą i największą wartość dzielą się swoimi wątpliwościami. Gra ponawiana jest po zakończeniu dyskusji aż do uzyskania jedności co do estymacji.
Poniżej zmieściłyśmy film wideo autorstwa Mika Cohna i Mountain Goat Software, który wizualizuje przebieg gry i wyjaśnia ją jeszcze bardziej szczegółowo.
Zalety:
- stosunkowo prosta technika w zrozumieniu;
- motywuje do dyskusji nad estymacją zadania;
- wywołuje dyskusje i pozwala każdemu wyrazić swoje zdanie.
Jedyna z wad jaką widzimy może wynikać z osobowości i charakteru: deweloperzy bardziej podatni na wpływy mogą zgadzać się z kolegami i zmieniać swoje zdanie bez większej dyskusji.
Na strzelca
Ta metoda nie ma swojej oficjalnej nazwy, nadałyśmy ją samodzielnie, bo kojarzy się ze strzelaniem w ciemno. W przebiegu szacowania z wykorzystaniem techniki “Na strzelca” estymację prowadzi się bez użycia materiałów dodatkowych, a przebieg jest bardzo prosty. Zespół po poznaniu zadania rozpoczyna estymację, ktoś mówi swoją propozycję, reszta się zgadza lub nie.
Zalety:
- nie są potrzebne dodatkowe materiały;
- estymacja odbywa się szybko, technika prosta w zrozumieniu.
Wady:
- brak stymulacji dyskusji;
- ryzyko dominacji senior developerów i ekstrawertyków nad resztą zespołu;
- ryzyko estymowania w pojedynkę i brak zaangażowania zespołu w dyskusję nad funkcjonalnościami.
PERT
PERT – od Program/Project Evaluation and Review Technique, została stworzona przez Departament Obrony Stanów Zjednoczonych. Używana była przez marynarkę wojenną przy budowie rakiet balistycznych POLARIS. Podejście to zakłada wzór na estymatę czasową. Oczekiwany czas realizacji danego zadania polega na wyliczeniu estymacji, bazując głównie na największym prawdopodobieństwie, zgodnie ze wzorem:
te = (o + 4m + p) ÷ 6
- o – optimistic time, minimum potrzebnego czasu na realizację zadania
- m – most likely time, najprawdopodobniejszy czas na realizację zadania
- p – pessimistic time, maksimum potrzebnego czasu na realizację zadania
- te – time expected, czas potrzebny na realizację zadania (ostateczna estymata)
Jest to średnia ważona. Największą wagę kładzie się się na wartość najbardziej prawdopodobną, stąd 4a w równaniu. Nazywana jest inaczej trzy punktową estymacją i dla projektów nowych, bez odpowiedniej ilości danych historycznych może przybrać postać wyliczania średniej arytmetycznej z trzech wartości. To jaką wersję techniki estymacji wybierzecie zależy od tego co macie na początku.
Zalety:
- wspieranie zarządzania dużymi i złożonymi projektami;
- nieskomplikowane obliczenia;
- możliwość oceny ryzyka czasowego ukończenia zadań i projektu;
- możliwość szacowania prawdopodobieństwa ukończenia zadań jak i całego projektu w zadanym terminie.
Wady:
- mała elastyczność metody w trakcie realizacji projektu ze względu na deterministyczny charakter;
- duża subiektywność przy ocenie czasów realizacji zadań;
- czasochłonność w porównaniu z pozostałymi technikami;
- sprawdza się gdy mamy dużo danych historycznych i realizujemy podobne projekty.
#NoEstimates
Wszystko zaczęło się od chwytliwego hashtagu #noestimates kilka lat temu, którego użył Woody Zuill na swoim twitterze podczas rozważań po co tak naprawdę estymujemy. Jednym z późniejszych etapów rozwoju nurtu była książką Vasco Durante o chwytliwym tytule “No estimates How to measure project progress without estimating”. Na pierwszy rzut oko można by się pokusić o założenie, że faktycznie w tej technice nie ma estymacji. Przyjrzyjmy się temu jednak trochę bliżej.
W książce Durante opiera się na pracy z User Stories jako elementach Product Backlogu, maksymalnie skupiając się na możliwości dostarczenia wartości biznesowi grupując historyjki w features. Cała idea polega na tym by dzielić poszczególne elementy nad którymi będziemy pracować zgodnie z techniką INVEST (niezależne, wartościowe, negocjowane, esencjonalne, małe i testowalne). Małe w tym wypadku oznacza tyle, że praca nad nimi powinna mieścić się w przedziale 0,5 -1 dnia. Następnie określamy przepustowość zespołu i pracujemy nad elementami PB, które mogą przynieść biznesowi największą wartość. Można pokusić się więc o stwierdzenie, że tak naprawdę odgórnie estymujemy każde z zadań na określoną wartość i na tej podstawie określamy co i na kiedy możemy zrealizować. Oczywiście w całym procesie opieramy się również na innych miarach m.in. na cycle time. Na podstawie których określamy pewien histogram i dzięki temu wizualizujemy przepustowość zespołu.
Naszym celem nie jest tutaj określenie dokładnie jak korzystać z techniki a jedynie pokazanie innej możliwości podejścia do estymacji oraz wskazanie źródła (książka Durante) do zgłębienia tematu. Warto wspomnieć, że nurt #noestimates jest coraz bardziej popularny i przybiera coraz inne formy, ta o której wspominamy jest tylko jedną z możliwości.
Zalety:
- m.in. zmusza zespół do zastanowienia się jak faktycznie podzielić wymagania na tak małe żeby mieściły się w jednym dniu pracy;
- działamy tylko na najważniejszych elementach PB, przynoszących wartości na tyle małe, że feedback od klienta powinien trafiać do nas możliwie szybko i kształtować kolejne działania.
Wady:
- dzieląc zadania musimy dokonywać szacowania;
- brak sposobu na zadania, które są mniejsze lub niepodzielne i wynoszą więcej niż wskazany 1 dzień pracy.
Którą technikę estymacji wybrać?
Spośród wymienionych technik, żadna nie jest naszą ulubioną – stosowałyśmy je wielokrotnie zamiennie (z wyjątkiem #noestimate, ale pewnie spróbujemy!) i każda ma swój unikalny wpływ na zespół. Stosując różne podejścia, zespół uczy się dyskusji w innym wymiarze, a każda zmiana ożywia – zatem zachęcamy do eksperymentowania!
Koniecznie podzielcie się w komentarzach jakimi techniki estymacji wy wspieracie swoje zespoły 🙂
Zobacz pierwszy wpis z serii o teorii estymacji >>
Zobacz trzeci wpis z serii o Team Estimation Game >>
Sprawdź nasze ostatnie wpisy:
