Процена за мобилне пројекте — шта је то, методе оцењивања задатака

Šta je procena?

Procena (od eng. estimate — procena) — predviđanje količine vremena ili truda potrebnog za izvršenje zadatka. U mobilnom razvoju, procene se izražavaju u satima, danima, story point-ovima ili novčanom ekvivalentu. Cilj procene nije tačno predviđanje, već smanjenje neizvesnosti radi donošenja odluka.

Čim se procena razlikuje od obaveze

Procena — predviđanje sa marginom greške. Obaveza (commitment) — obećanje da će se zadatak izvršiti do određenog datuma. Razlika je kritična: procena kaže „verovatno 5 dana„, obaveza — „uradićemo za 5 dana„. Menadžeri često mešaju ove pojmove, pretvarajući procenu u rok bez prava na grešku.

Procena kao komunikacioni alat

Proces procenjivanja nije manje važan od njegovog rezultata. Kada tim diskutuje o oceni zadatka, otkrivaju se skriveni zahtevi, zavisnosti i rizici. Čak i ako je konačna cifra netačna, diskusija daje svim učesnicima razumevanje zadatka. Zato su kolektivne metode procene (Planning Poker) efikasnije od individualnih.

Metode procene u razvoju

Postoji nekoliko metoda procene, svaka pogodna za različite faze projekta i nivoe detaljnosti. Izbor metode zavisi od dostupnih podataka i potrebne tačnosti.

Planning Poker

Planning Poker — najpopularnija metoda procene u Agile-u. Svaki programer dobija špil karata sa Fibonačijevim brojevima (1, 2, 3, 5, 8, 13, 21). Nakon diskusije o zadatku, svi istovremeno pokazuju kartu. Ako se procene razlikuju — programeri sa minimalnom i maksimalnom procenom objašnjavaju svoju logiku, zatim sledi ponovno glasanje. Metoda eliminiše uticaj autoriteta i daje tačniju procenu.

T-Shirt sizing

T-Shirt sizing — gruba procena po veličini majice: XS, S, M, L, XL, XXL. Metoda se koristi za brzu procenu velikih zadataka (epika) u ranim fazama, kada detalji nisu poznati. Kasnije se svaki takav zadatak dekomponuje i procenjuje u Planning Poker-u. T-Shirt sizing traje 5-10 minuta po zadatku, ali daje samo red veličine.

Three-point estimation (PERT)

PERT koristi tri procene: optimističnu (O), pesimističnu (P) i najverovatniju (M). Konačna procena se računa po formuli: (O + 4M + P) / 6. Metoda uzima u obzir neizvesnost i daje realističniji rezultat od pojedinačne procene. PERT je posebno koristan za zadatke sa visokim rizicima ili novim tehnologijama.

Tačnost procene: očekivanja vs realnost

Tačnost procene zavisi od faze projekta i količine poznatih informacija. Što se procena radi ranije, veća je margina greške — to je normalno i treba uzeti u obzir u planiranju.

Konus neizvesnosti

Konus neizvesnosti (Cone of Uncertainty) — model koji opisuje kako se margina greške procene smanjuje kako projekat napreduje. U fazi koncepta, margina greške iznosi 400% (zadatak može trajati od 1 do 4 meseca). U trenutku sprint-a — 20% (1-1.2 meseca). Svest o ovom modelu pomaže da se ne zahtevaju tačne procene u ranim fazama.

Faktori koji utiču na tačnost

• Složenost zadatka — nova tehnologija ili poznata? Nepoznato povećava grešku 2-3 puta.
• Veličina zadatka — mali zadaci (do 2 dana) procenjuju se tačnije od velikih. Dekompozicija poboljšava tačnost.
• Iskustvo tima — tim koji je radio zajedno 6+ meseci procenjuje 30-50% tačnije od novog.
• Istorijski podaci — postojanje metrika velocity i ciklometrije povećava tačnost predviđanja.

Relativna vs apsolutna procena

Relativna procena (u story point-ovima) tačnija je od apsolutne (u satima), jer ljudi bolje porede zadatke nego što procenjuju vreme. „Ovaj zadatak je dva puta složeniji od onog„ — pouzdaniji sud nego „ovaj zadatak će trajati 8 sati„. Relativne procene ne zavise od konkretnog programera i zadržavaju tačnost pri promeni izvršioca.

Kako poboljšati tačnost procene: najbolje prakse

Tačnost procene se može povećati sistematskim pristupom, kolektivnom diskusijom i analizom prošlih grešaka. Postoji nekoliko dokazanih praksi.

Dekompozicija na 1-2 dana

Svaki zadatak procenjen na više od 2 dana treba dekomponovati na podzadatke. Princip: ako se zadatak ne može proceniti sa tačnošću od 50%, znači da je prevelik. Podeli ga na korake koji su razumljivi i merljivi. Nakon dekompozicije, ukupna procena je često 1.5-2 puta veća od početne.

Istorijski podaci i metrike

Vodi istoriju procena i upoređuj sa stvarnim troškovima. Na primer: „zadaci procenjeni na 3 story point-a u proseku traju 4 dana, a ne 2„. Koristi velocity tima za predviđanje: ako tim zatvori 20 story point-ova po sprintu, ne planiraj 30. Analiza tačnosti prethodnih procena je najbolji trening za veštinu procenjivanja.

Sidrenje i kalibracija

Sidrenje — psihološki efekat gde prva izrečena procena utiče na sve učesnike. Da bi se izbeglo sidrenje, u Planning Poker-u svi pokazuju karte istovremeno, a ne redom. Kalibracija — redovno proveravanje procena sa činjenicama: nakon 10-20 sprint-ova, tim uči da procenjuje tačnije zahvaljujući povratnim informacijama.

Uzimanje u obzir rizika u proceni

Svaki zadatak sadrži skrivene rizike: bolest programera, problem sa API-jem, promena zahteva. Dodaj u procenu faktor prilagođen riziku: za zadatke sa visokim rizikom — množitelj 1.5-2, sa niskim — 1.1-1.2. Transparentno pokaži klijentu koji rizici su uzeti u obzir i kako utiču na rokove.

Tipične greške pri proceni

Greške pri proceni se ponavljaju u većini timova, nezavisno od njihove zrelosti. Poznavanje ovih grešaka je prvi korak ka njihovom ispravljanju.

Optimistična procena

Najčešća greška — procena po najboljem scenariju: „ako sve bude idealno, uradićemo za 3 dana„. U stvarnosti, ništa ne ide idealno: bagovi, pitanja o zahtevima, zavisni zadaci. Rešenje: procenjivati po najverovatnijem scenariju, a ne po optimističnom. Koristi PERT za uzimanje u obzir varijabilnosti.

Procena pod pritiskom

Kada menadžer kaže „potrebno je do petka„, programer podsvesno prilagođava procenu tom roku. Procena pod pritiskom je uvek potcenjena i dovodi do kašnjenja. Rešenje: procena treba da prethodi roku, a ne obrnuto. Prvo tim procenjuje, zatim strane dogovaraju rokove.

Mešanje složenosti i vremena

Složenost zadatka (koliko razmišljati) i vreme (koliko raditi) — različite metrike. Zadatak može biti jednostavan, ali dugotrajan (kodirati 10 ekrana). Ili složen, ali brz (pronaći bag u legacy-ju). U story point-ovima se obično procenjuje složenost, a vreme se izvodi iz velocity-ja tima.

Ignorisanje promena konteksta

Programer ne radi 8 sati neprekidno na jednom zadatku: sastanci, code review, pomoć kolegama, administrativni poslovi oduzimaju 30-50% radnog vremena. Promene konteksta treba uzeti u obzir u proceni: realno, programer piše kod 3-4 sata dnevno.