Gdybym miał wytłumaczyć komuś, czym są estymacje — podszedłbym do tego w następujący sposób. 

Estymacja jest niczym innym, jak określeniem w jakim czasie, uda się osiągnąć określony efekt. Osoby chcące być przy tym dokładne, zazwyczaj rozbijają sobie dane zadanie na kilka części (składowych), których suma daje nam finalny efekt. Przykładowo: 

Dodanie na stronie formularza, do zapisu na newsletter, składa się z kilku czynności: 

• przełączenie się na najnowszy kod i ściągnięcie zmian – 10 min 
• dodanie formularza wraz z logiką – 1 h 
• wystylizowanie zgodnie z makietą – 30 min
• napisanie kilku przypadków testowych i ręczne testy – 1 h

Łącznie: 2 h 40 min 

Możemy wówczas usłyszeć:

Cześć Zenon — powinno mi się udać, zmieścić w 3 h.

Można również do tego tematu, podejść na wiele innych sposobów, zobaczmy inne podejście. 

W przypadku, gdzie jest więcej nieznanych i zależności, programista może podejść do estymacji, stosując metodę trzypunktową (lub PERT’a), którą w uproszczeniu można rozumieć następująco: 

a. (czas minimalny) – najkrótszy możliwy czas, czyli zakładamy, że zadanie pójdzie nam idealnie, wszystko zadzieje się zgodnie z tym, jak sobie planujemy, nie będzie żadnych komplikacji 

b. (czas uśredniony) – najbardziej prawdopodobny czas, czyli zakładamy, że mogą pojawić się jakieś komplikacje, ale nie powinny one być zbyt trudne

c. (czas maksymalny) – najdłuższy możliwy czas, czyli spełnią się wszystkie ryzyka i trzeba będzie rzeźbić koło od nowa

W takim podejściu nasza estymacja może wyglądać następująco:

Dodanie na stronie formularza, do zapisu na newsletter: 

• przełączenie się na najnowszy kod i ściągnięcie zmian – 10 min / 10 min / 10 min
• dodanie formularza wraz z logiką – 30 min /  2 h  /  3 h
• wystylizowanie zgodnie z makietą  –  30 min / 1.5 h  / 4 h
• napisanie kilku przypadków testowych i ręczne testy  –  1 h  /  2 h / 4 h

Łącznie wartości:

min: 2 h 10 min

avg: 5 h 40 min

max: 11 h 10 min

Tym razem usłyszymy:

Cześć Zenon, powinienem się zmieścić w 2,5 h, ale jak napotkam problemy, może mi zejść nawet 11 h. Zakładam jednak, że nie będzie to więcej niż 4 h. 

Jak widzicie na powyższych przykładach, ciężko jest określić dokładnie, ile zadanie może zająć czasu. Jest to również problematyczne dla programistów, bo finalny czas zależy od wielu składników i doświadczenia w przewidywaniu, jakie problemy mogą wystąpić po drodze. 

Dlatego tak często się zdarza, że estymacje są przestrzelone, tj. programista zakładał 5 h, a zajęło mu to 20 h. Zdarza się. Z perspektywy PM’a, o wiele lepiej jest, gdy informujemy o potencjalnym przekroczeniu na bieżąco, niż po fakcie. Na bieżąco, z taką informacją można jeszcze coś zdziałać, po fakcie jest już o wiele ciężej. 😉 

Dobrą wiadomością jest natomiast to, że umiejętność estymowania przychodzi z czasem. Im więcej programista próbuje określać ile czasu coś mu zajmie z rozbijaniem to na mniejsze zadania, tym szybciej się uczy na własnych błędach i staje się dokładniejszy w estymowaniu.

Ciekawi mnie wasze podejście — co byście doradzili swojemu koledze, w celu podszkolenia go z estymowania? Co sprawdzało się u Was, zanim doszliście do wprawy?