Jak poprawnie estymować taski?

No właśnie, pytanie w tytule, ma ktoś jakiś sprawdzony sposób na estymowanie tasków z funkcjonalnościami których wcześniej się nie robiło?

Chyba najlepszy sposób to zadać sobie pytanie: do czego, co robiłem wcześniej, ten task jest najbardziej podobny wtedy wiesz że pi razy drzwi zajmie Ci to tyle co wtedy czyli np. 3 dni ale jesteś mądrym programistą więc tą wartość mnożysz jeszcze przez 3 albo 4. W większości przypadków taka metodyka mi się sprawdzała.

Ważne jest też podać przedział ufności. Ja na przykład mówię, że o ile nie będą mi przeszkadzali, to wtedy jest szansa, że skończę to w X na Y procent. Jak szefostwo pyta, czy da się w X/2, to oczywiście też, ale wtedy Y spada znacząco.

1. Myślisz ile wydaje ci się że to zajmie
2. Mnożysz razy 2
3. Podnosisz jednostkę o 1

Czyli myślisz ze zajmie godzinkę to estymujesz na 2 dni.

No właśnie, pytanie w tytule, ma ktoś jakiś sprawdzony sposób na estymowanie tasków z funkcjonalnościami których wcześniej się nie robiło?

Nie da się. Estymować można rzeczy podobnych do tych, które się robiło, a reszta to jest zgadywanka obarczona dużym ryzykiem.

Najprostszy sposób na polepszenie estymacji to zwiększenie praktycznych doświadczeń i redukcja niewiadomych.

Czyli masz taski z funkcjonalnościami, których wcześniej nie robiłeś - no to zrób najpierw na szybko Proof of Concept i sprawdź pewne hipotezy, a potem dopiero estymuj, proste. Ew. też czasem trzeba doprecyzować sam task, bo jeśli task ma niejasne wymagania, jest napisany zawiłym językiem, to odbije się to na estymacji.

Jeśli natomiast masz zbyt często problem z estymacjami, może to oznaczać, że masz za mało ogólnego doświadczenia. Wtedy rób swoje, a po iluś projektach (i pewnie po iluś miesiącach czy latach) jest szansa na to, że będziesz już w tym nieco lepszy, bo wtedy jest szansa, że każdy kolejny task będzie w jakimś stopniu podobny do tego, co już wcześniej robiłeś.

Jest mnóstwo sposobów na zrobienie trafnej estymacji.

1. Najważniejsza w tym wszystkim może się okazać dekompozycja. Im bardziej rozbite taski tym łatwiej oszacować czas na zrobienie.
2. Dane historyczne. Jeżeli prowadzisz dane historyczne wycen i realnego czasu wykonania jesteś w stanie na ich podstawie szacować podobieństwo i tym samym wycenę. To jest o tyle dobre, że np. da się oszacować czas wykonania zadania dla zespołu w którym nawet cię nie ma.. lub nawet w innej technologii...
3. Doświadczenie. Jeżeli jesteś doświadczony to wiesz z autopsji ile coś zajmie + przyrost skilla + czas za bycie optymista/pesymistą. Tyle że to metoda strzelania z d*** a nie wycenianie. Raz trafisz, a raz nie. W wycenie nie chodzi o to żeby się zmieścić w sensie ogólnym, tylko żeby estymacja była możliwie jak najbardziej zbliżona do realnego czasu potrzebnego na zrobienie.

Pomijam punkty funkcyjne czy od linijki kodu bo to wyceny kompletnie oderwane od rzeczywistości...

Kolejność taka: implementujesz, testujesz, wdrażasz, estymujesz. Wtedy jest 100% pewności i dokładności.

poczytaj o #noestimate

somekind napisał(a):

Kolejność taka: implementujesz, testujesz, wdrażasz, estymujesz. Wtedy jest 100% pewności i dokładności.

Słuszne podejście. Trzeba po prostu najpierw taska zrealizować, a potem cofnąć się w przeszłość do czasu, zanim zacząłeś nad nim pracować i estymować tyle, o ile się cofnąłeś. Daje to 100% dokładności. Umiem już prawie to zrobić, pracuję tylko jeszcze nad sposobem na przeniesienie się w czasie, ale reszta już działa

Meini napisał(a):

Słuszne podejście. Trzeba po prostu najpierw taska zrealizować, a potem cofnąć się w przeszłość do czasu, zanim zacząłeś nad nim pracować i estymować tyle, o ile się cofnąłeś. Daje to 100% dokładności. Umiem już prawie to zrobić, pracuję tylko jeszcze nad sposobem na przeniesienie się w czasie, ale reszta już działa

Podróżowanie w przeszłość nie jest potrzebne. Musisz po prostu tak szybko zakręcić wokół siebie osobę pytająca że wykonasz te 3 potrzebne elementy (implementacja, testy, wdrożenie) a ona nawet nie zorientuje się że zdążyłeś to zrobić. I wtedy dajesz jej estymatę.

Rozumiem. Czyli trzeba ściemniać i w międzyczasie zrobić. A potem już nie robić, tylko estymować i udawać, że się robi, podczas gdy wszystko mam już zrobione.

Estymujesz jakąś kosmiczną wartości i jeżeli ktoś ma problem to robisz burdę niczym BLM.

Najlepiej jeżeli masz po swojej stronie scrum mastera - on jest zajęty mową nienawiści, a ty możesz sobie w spokoju klepać task.
Słuchaj, nie jestem z tego dumny, ale trudno znaleźć lepszą metodę, która pozwalałby wyeliminować sm-a i pm-a jednocześnie.

Wystarczy użyć tej skali:

Proste,
Średnie,
Trudne,
Za duże

I jeszcze wersja specjalna: Nie wiem

Przez pierwsze 2-3miesiace random generator. Potem juz wiesz pi razy drzwi ile wam to zajmie. Jeśli zmieni się ktoś w zespole wracasz do kroku 1.

Metoda Monte Carlo sprawdza się najlepiej tam gdzie ludzki rozum jest za słaby by ogarnąć wszystkie zmienne.

Sprawa prosta:

• mówisz, że task zajmie Ci cały sprint
  a) Udało Ci się zrobić w sprincie to siedzisz i czekasz do końca, wyrzucając na produkcje pod koniec
  b) Nie udało Ci się to mówisz na planningu, że zaraz dokończysz i faktycznie kończysz jak się następny sprint skończy.

Tyle estymacji.

Lukxxx napisał(a):

Wystarczy użyć tej skali:

Proste,
Średnie,
Trudne,
Za duże

I jeszcze wersja specjalna: Nie wiem

To jest jedyna słuszna skala, która nadaje się do tego raka jakim jest estymacja. Problem zaczyna się wtedy kiedy szacujemy złożoność w jakiejś bardziej rozbudowanej skali, która ma przełożenie na czas. Wtedy scum masterzy, PO, PM i inni dewianci mogą sobie mierzyć wydajność zespołu oraz zajmować się najważniejszą rzeczą w pracy programisty - pracą nad trafnością estymacji.

Jeśli już musisz jednak to robić nie wiedząc kompletnie jak coś wykonać to zamiast rzucać się na zadanie zaproponuj utworzenie zadania na wykonanie analizy tematu i ewentualny prototyp. Jeśli to zrobisz to z grubsza będziesz wiedział ile ci może zająć zadanie. Jeśli się na to nie zgodzą to użyj algorytmu Shaloma

Policz sobie ile średnio robisz taski w danym projekcie, zawsze podawaj średnią wartość z jakąś dewiacją.
66% Czasu będzie wcześniej albo "na czas", 33% to spóźnienia mniejsze lub większe.
:D