Estymowanie jest to proces znalezienia wyceny lub jej ekstrapolacji, czasami bazujący na danych niekompletnych, nieprzewidywalnych, niestabilnych. Estymowanie mówi nam, jak wiele pieniędzy, wysiłku, zasobów i czasu poświęcimy na zbudowanie określonego systemu lub produktu przy określonych ryzykach.
Wstęp może być zawiły i niezrozumiały, jednakże podałem Wam definicje estymowania pojawiającą się w wielu publikacjach. Samo estymowanie bazuje na:
- doświadczeniach,
- danych,
- dostępnej dokumentacji,
- dostępnej wiedzy,
- założeniach,
- zidentyfikowanych ryzykach,
- podobieństwie do wcześniej realizowanych zadań.
Najważniejsze jest zrozumienie wymagań. Tak jak pokazuje poniższy rysunek, żart, taka rzeczywistość bardzo często nas otacza.
Aby uniknąć niezrozumienia się, musimy jak najczęściej ze sobą rozmawiać. Jeżeli mamy kilka małych wymagań, zaprośmy ich inicjatora, aby o nich porozmawiać. Niech wyjaśni nam, co miał na myśli, jaki cel chce osiągnąć. 
Co te wymagania oznaczają dla użytkowników produktu, jaką wartość przyniosą. Z tym wiąże się jeszcze jeden punkt. Znając ważność danych wymagań, można bardziej szczegółowo określić ich priorytet. W podlinkowanym artykule znajdziecie więcej o piorytetyzacji i robieniu porządku w wymaganiach. Jeżeli natomiast mamy do realizacji duży projekt. zdekomponujmy wymagania, czyli poznajmy całość wymagań, podzielmy je na bloki, opiszmy w ramach każdego bloku, czego inicjator od nas oczekuje. I powtórzmy to, co napisałem wcześniej. Porozmawiajmy o nich z inicjatorem oraz z zespołem odpowiedzialnym za ich realizację. Jednym z największych problemów w organizacjach jest komunikacja. Możemy temu problemowi przeciwdziałać właśnie poprzez rozmowę, jak najczęstszą. Z tą kwestią oczywiście łączy się inne zagadnienie – zniekształcenie wymagań. Jeżeli ktoś inny wymyślił wymagania, przekazał je kolejnej osobie, która np. swojego podwładnego poprosiła o ich spisanie, a wersję finalną zrobili analitycy, bądźmy pewni, że mamy do czynienia z “głuchym telefonem”, zniekształceniem wymagań i ich “przekręceniem”.
Estymowanie klasyczne (ang. absolute estimation)
Estymowanie klasyczne to wycena zadań w procesie kaskadowym, inaczej zwanym waterfall. Polega ono na wycenie prac:
- zaangażowanych pracowników, liczonych w osobomiesiącach lub osobodniach,
- wyznaczeniu czasu trwania zmiany / projektu w miesiącach,
- oszacowaniu kosztu zmiany / projektu.
Estymowanie klasyczne jest procesem długotrwałym, a przez to kosztownym. Wyobraźcie sobie projekt (ponieważ w 90% przypadków szacujemy klasycznie właśnie projekty), którego wymagania “biznes” spisał na kilkuset stronach. Ile będzie trwała wycena? Tygodnie. I wiele osób będzie w ten proces zaangażowanych.
Przykłady używanych metod w estymowaniu klasycznym znajdziecie tu
Główna zaletą takiego szacowania zadań jest dość łatwe zobrazowanie sobie końcowej wartości. Chodzi o to, że jeżeli otrzymujemy od developmentu wartość np. 100 roboczodni (ang. mandays- md), dość łatwo możemy sobie to przełożyć na czas potrzebny do wytworzenia zmiany.
Natomiast główną wadą takiego podejścia jest bardzo częste rozmijanie się z wyceną w stosunku do faktycznego czasu trwania zmiany. Pewnie często słyszeliście o przekroczonych budżetach, terminach projektów. Poniższa grafika prezentuje tylko dwa badania przeprowadzone przez McKinsey oraz Gartner.
Jak wynika z prezentowanych wyników, aż 33% projektów przekracza szacowany czas trwania. Innymi słowy, w takim procencie oszacowane wyceny zmian rozminęły się z rzeczywistością.
Estymowanie relatywne
Innym sposobem szacowania zadań jest estymacja relatywna. W uproszczeniu polega ona na porównywaniu zadań między sobą celem ustalenia ich wielkości. Jednak nie tylko o wielkość chodzi. Tak jak w estymowaniu klasycznym przede wszystkim skupiamy się na czasie trwania, tak w estymowaniu relatywnym bierzemy pod uwagę trzy elementy:
- złożoność / trudność,
- czasochłonność,
- ryzyko.
Innymi słowy nie skupiamy się tylko na określeniu czasu trwania zadania, ale także rozważamy nasze dotychczasowe doświadczenia, znajomość produktu, znajomość technologii, zależności zewnętrzne.
W estymowaniu klasycznym uzyskaną wartość określamy zdaniem “Zadanie X zajmie nam 5 dni”, natomiast w estymowaniu relatywnym wynik określimy bardziej jako “Zadanie X jest podobnej wielkości co zadanie Y”.
Taka estymacja jest:
- tania – czas potrzebny do określenia wyceny jest dużo szybszy niż w estymowaniu klasycznym,
- intuicyjna – porównujemy ze sobą dwa zadania i określamy to drugie jako większe, mniejsze, podobne bazując na swojej wiedzy, uszczegółowieniu zadania i swojej intuicji,
- szybka – wycena nawet dużego zadania, projektu trwa dużo mniej czasu,
Najbardziej popularną skalą jest ciąg Fibonacciego. Zadania są porównywane między sobą i przypisywane są im wartości ze skali. Niektóre zespoły używają nienumerycznej skali wyceny. Czasami taka skala jest używana, aby odzwyczaić się od skali numerycznej, gdzie istnieje ryzyko “schodzenia” do wyceny dotyczącej czasu trwania.
Najpopularniejszą nienumeryczną skalą jest “T-shirt sizing”. Przypisuje w niej danym zadaniom rozmiary koszulek, zamiast wartości liczbowych.
Aby bardziej zaznajomić się z kwestią wycen, polecam przeczytać książkę Mike Cohna “Agile Estimating and Planning”.
Planning Poker
Jest to najpopularniejsza metoda szacowania zadań w technice relatywnej. Polega ona na omówieniu danego zadania, potwierdzeniu, że każdy je zrozumiał oraz estymacji zadania. Sama estymacja przebiega w następujący sposób:
- każdy z uczestników estymacji (a powinien to robić cały zespół developerski) posiada karty (lub coś innego, np. aplikację)
- uczestnicy samodzielnie, bez konsultacji postanawiają, jaką wartość pokażą, czyli na ile szacują dane zadanie,
- uczestnicy jednocześnie pokazują wartości wyceny.
Te same wyceny oznaczają, że mamy jako zespół zgodność. Jednak jeżeli wyceny się różnią (zazwyczaj), następuje najciekawszy i, moim zdaniem, najbardziej wartościowy moment całego szacowania. Otwieramy panel dyskusyjny, na którym zespół ze sobą rozmawia o danej funkcjonalności. Dlaczego przez jednych jest traktowana jak prosta, nieskomplikowana, a przez resztę zespołu jak zadanie trudniejsze, wymagające większej ilości pracy.
W momencie kiedy zespół wyjaśni wszelkie pojawiające się wątpliwości, przystępuje do drugiej rundy wyceny. Odbywa się ona tak jak pierwsza – zastanówmy się ile, pokażmy wartość. Poniżej znajdziecie film, również stworzony przez m.in. Mike Cohna o samej technice Planning Poker.
Podsumowując
Wycena zadań zawsze niesie ze sobą emocje. I to po stronie zespołu (niezależnie jaką techniką / metodą ją robi), ale także po stronie inicjatorów wymagań. Wszyscy by chcieli, aby była ona dokładna, szybka. Jednak nie zawsze jest to możliwe.
Polecam Wam jak najszybsze przejście na estymowanie relatywne, ponieważ jest dużo szybsze i mniej skomplikowane od tradycyjnego. I nawet kiedy pojawią się jakieś niedociągnięcia, z upływem czasu się one wyrównają.
Posłuchaj też 19. odcinka Podcastu Porządny Agile – Estymowanie