Becslés mobil projektekhez — mi ez, feladatok értékelésének módszerei

Mi az a becslés?

Becslés (az angol estimate szóból) — egy feladat elvégzéséhez szükséges idő vagy erőfeszítés mennyiségének előrejelzése. Mobilfejlesztésben a becsléseket órákban, napokban, story pontokban vagy pénzbeli egyenértékben fejezik ki. A becslés célja nem a pontos előrejelzés, hanem a bizonytalanság csökkentése a döntéshozatalhoz.

Miben különbözik a becslés a kötelezettségvállalástól

Becslés — előrejelzés hibahatárral. Kötelezettségvállalás (commitment) — ígéret a feladat adott dátumig történő elvégzésére. A különbség kritikus: a becslés azt mondja „valószínűleg 5 nap„, a kötelezettségvállalás — „megcsináljuk 5 nap alatt„. A menedzserek gyakran összekeverik ezeket a fogalmakat, a becslést hibalehetőség nélküli határidővé változtatva.

A becslés mint kommunikációs eszköz

A becslési folyamat nem kevésbé fontos, mint annak eredménye. Amikor a csapat megvitatja egy feladat értékelését, rejtett követelmények, függőségek és kockázatok kerülnek felszínre. Még ha a végső szám pontatlan is, a megbeszélés minden résztvevő számára megértést ad a feladatról. Ezért a kollektív értékelési módszerek (Planning Poker) hatékonyabbak, mint az egyéniek.

Becslési módszerek a fejlesztésben

Több becslési módszer létezik, mindegyik a projekt különböző szakaszaihoz és részletességi szintjeihez igazodik. A módszer kiválasztása a rendelkezésre álló adatoktól és a szükséges pontosságtól függ.

Planning Poker

Planning Poker — a legnépszerűbb értékelési módszer az Agile-ben. Minden fejlesztő kap egy pakli kártyát Fibonacci-számokkal (1, 2, 3, 5, 8, 13, 21). A feladat megvitatása után mindenki egyszerre mutatja fel a kártyáját. Ha a becslések eltérnek — a legalacsonyabb és legmagasabb becslést adó fejlesztők elmagyarázzák a logikájukat, majd újabb szavazás következik. A módszer kiküszöböli a tekintélyek befolyását és pontosabb becslést ad.

T-Shirt sizing

T-Shirt sizing — durva becslés pólóméret alapján: XS, S, M, L, XL, XXL. A módszert nagy feladatok (epikek) gyors becslésére használják korai szakaszban, amikor a részletek még nem ismertek. Később minden ilyen feladatot dekomponálnak és Planning Poker-ben értékelnek. A T-Shirt sizing feladatonként 5-10 percet vesz igénybe, de csak nagyságrendet ad.

Three-point estimation (PERT)

PERT három becslést használ: optimista (O), pesszimista (P) és legvalószínűbb (M). A végső becslés a képlet alapján számítható: (O + 4M + P) / 6. A módszer figyelembe veszi a bizonytalanságot és reálisabb eredményt ad, mint az egyetlen becslés. A PERT különösen hasznos magas kockázatú vagy új technológiás feladatoknál.

A becslés pontossága: elvárások vs valóság

A becslés pontossága a projekt szakaszától és az ismert információ mennyiségétől függ. Minél korábban történik az értékelés, annál nagyobb a hibahatár — ez normális, és a tervezésben figyelembe kell venni.

Bizonytalansági kúp

Bizonytalansági kúp (Cone of Uncertainty) — egy modell, amely leírja, hogyan csökken a becslés hibahatára a projekt előrehaladtával. A koncepció szakaszban a hibahatár 400% (a feladat 1-4 hónapig tarthat). A sprint időpontjában — 20% (1-1.2 hónap). Ennek a modellnek a tudatosítása segít, hogy a korai szakaszban ne követeljünk pontos becsléseket.

A pontosságot befolyásoló tényezők

• A feladat komplexitása — új technológia vagy ismert? Az ismeretlen 2-3-szorosára növeli a hibahatárt.
• A feladat mérete — a kis feladatokat (2 napig) pontosabban becsülik, mint a nagyokat. A dekompozíció javítja a pontosságot.
• A csapat tapasztalata — egy 6+ hónapja együtt dolgozó csapat 30-50%-kal pontosabban becsül, mint egy új.
• Történeti adatok — velocity és ciklometria mérőszámok megléte növeli az előrejelzések pontosságát.

Relatív vs abszolút becslés

Relatív becslés (story pontokban) pontosabb, mint az abszolút (órákban), mert az emberek jobban tudják összehasonlítani a feladatokat, mint megbecsülni az időt. „Ez a feladat kétszer olyan összetett, mint az„ — megbízhatóbb ítélet, mint „ez a feladat 8 órát vesz igénybe„. A relatív becslések nem függnek az adott fejlesztőtől, és megőrzik pontosságukat a végrehajtó személyének változásakor.

Hogyan javítsuk az értékelés pontosságát: legjobb gyakorlatok

A becslés pontossága szisztematikus megközelítéssel, kollektív megbeszéléssel és a múltbeli hibák elemzésével javítható. Számos bevált gyakorlat létezik.

Dekompozíció 1-2 napra

Minden 2 napnál többre becsült feladatot dekomponálni kell alterületekre. Elv: ha egy feladat nem becsülhető 50%-os pontossággal, akkor túl nagy. Oszd fel érthető és becsülhető lépésekre. A dekompozíció után a teljes becslés gyakran 1.5-2-szer nagyobb, mint az eredeti.

Történeti adatok és mérőszámok

Vezess becslési előzményeket és hasonlítsd össze a tényleges költségekkel. Például: „a 3 story pontra becsült feladatok átlagosan 4 napig tartanak, nem 2„. Használd a csapat velocity-jét az előrejelzéshez: ha a csapat sprintenként 20 story pontot zár le, ne tervezz 30-at. A korábbi becslések pontosságának elemzése a legjobb gyakorlat a becslési készség fejlesztéséhez.

Horgonyzás és kalibráció

Horgonyzás — pszichológiai hatás, amikor az első hangoztatott becslés befolyásolja az összes résztvevőt. A horgonyzás elkerülése érdekében a Planning Poker-ben mindenki egyszerre mutatja a kártyákat, nem sorban. Kalibráció — a becslések rendszeres egyeztetése a valósággal: 10-20 sprint után a csapat a visszajelzések révén pontosabban becsül.

Kockázatok figyelembevétele a becslésben

Minden feladat rejtett kockázatokat tartalmaz: fejlesztő megbetegedése, probléma az API-val, követelmények változása. Adj a becsléshez kockázati tényezőt: magas kockázatú feladatoknál — 1.5-2-szeres szorzó, alacsony kockázatúnál — 1.1-1.2. Mutasd meg átláthatóan az ügyfélnek, milyen kockázatokat vettél figyelembe, és azok hogyan befolyásolják a határidőket.

Tipikus hibák a becslés során

A becslési hibák a legtöbb csapatban ismétlődnek, függetlenül azok érettségétől. E hibák ismerete az első lépés a kijavításuk felé.

Optimista becslés

A leggyakoribb hiba — a legjobb forgatókönyv szerinti becslés: „ha minden tökéletesen megy, 3 nap alatt megcsináljuk„. A valóságban semmi sem megy tökéletesen: hibák, kérdések a követelményekkel kapcsolatban, függő feladatok. Megoldás: a legvalószínűbb forgatókönyv szerint becsülj, ne az optimista szerint. Használd a PERT-et a változékonyság figyelembevételéhez.

Becslés nyomás alatt

Amikor a menedzser azt mondja „péntekig kell„, a fejlesztő tudat alatt hozzáigazítja a becslést ehhez a határidőhöz. Becslés nyomás alatt mindig alulbecsült, és határidő-túllépéshez vezet. Megoldás: a becslésnek meg kell előznie a határidőt, nem fordítva. Először a csapat becsül, aztán a felek egyeztetnek a határidőkről.

A komplexitás és az idő összekeverése

A feladat komplexitása (mennyit gondolkodni) és idő (mennyit csinálni) — különböző mérőszámok. Egy feladat lehet egyszerű, de időigényes (10 képernyő kódolása). Vagy összetett, de gyors (hiba megtalálása legacy kódban). Story pontokban általában a komplexitást becsülik, az időt pedig a csapat velocity-jéből vezetik le.

A kontextusváltások figyelmen kívül hagyása

A fejlesztő nem dolgozik 8 órát megszakítás nélkül egy feladaton: megbeszélések, kódellenőrzés, kollégák segítése, adminisztratív feladatok a munkaidő 30-50%-át veszik el. Kontextusváltásokat figyelembe kell venni a becslésben: a valóságban a fejlesztő napi 3-4 órát kódol.