Poznáte to.
Stojíte pred úlohou vypracovať odhady pre nový projekt a váš team vám v lepšom
prípade tvrdí, že bez poznania detailov, kontextu systému a dôkladnej analýzy
nie je možné odhady vytvoriť, v tom horšom budú ľudia v teame iba bezradne
krčiť plecami, lebo s danou technológiou alebo na podobnom projekte ešte
nepracovali. Na druhej strane klient z rozpočtových alebo iných dôvodov požaduje
informáciu o celkových nákladoch projektu vopred.
V Conim na
to máme riešenie ! Pri odhadovaní nákladov a trvania IT projektov sa
opierame o dlhoročné skúsenosti a osvedčené postupy odhadovania
pomocou tzv. zástupných jednotiek. Azda najznámejšou zástupnou jednotkou, s ktorou pracujeme aj my v našich iniciálnych odhadoch, je Story Point. Časové a nákladové
jednotky prídu v procese odhadovania do hry až neskôr. Avšak ešte pred
tým, ako s teamom pristúpime k odhadovaniu práce, zdôraznime jeden
dôležitý aspekt každého odhadovania: Odhad nie je záväzok ! Odhady sú odhady,
ich presnosť je na začiatku projektov nízka a úplne presný odhad získame až po
skompletizovaní samotnej práce, ktorú odhadujeme. Takže, prečo sa báť odhadovať
?! Story Point je perfektná jednotka na odbúranie tejto obavy z odhadovania.
Poďme sa pozrieť na to, ako odhadujeme
v Conim.
V závislosti
od projektu a od toho, či team má s danou oblasťou skúsenosť
a od toho, koľko času na odhadovanie máme, rozhodujeme o miere
dekompozície práce. Ak team na podobnom zadaní v minulosti už pracoval
a máme dosť času, môžeme si dovoliť detailnejší rozpad práce
a vytvárame menšie user stories, ktoré následne odhadujeme (používame
Fibbonacciho sekvenciu). Ak team má iba málo skúseností alebo je na odhadovanie
málo času, vytvárame väčšie celky – epiky, ktorým následne prideľujeme vyššie
odhady v story points (stále z Fibbonacciho sekvencie).
Keď máme tieto
odhady hotové, potrebujeme pokryť riziko, že sme na niečo zabudli alebo sme naše
odhady podcenili pridaním rezervy. Na určenie adekvátnej rezervy
využívame v Conim nami vytvorený nástroj, ktorý pomocou matematických
výpočtov určí výšku rezerv – v story points. Nástroj dokonca umožňuje 2
alternatívy výpočtu rezervy – automaticky alebo pomocou 2 úrovní odhadov.
Poďme si to
ukázať na príklade:
Dajme tomu, že máme definované 3 user stories. Prvú
sme odhadli na 5 Story points, druhú na 13 a tretiu na 8. Spolu je to 26
Story points a k tomuto číslu náš nástroj odporúča prideliť rezervu
10 bodov. Náš
celkový backlog práce je teda odhadnutý na 36 Story Points.
Až po získaní
finálnej veľkosti backlogu práce, pristupujeme k ďalšiemu kroku –
a tým je odhad trvania nákladov na projekt.
Trvanie projektu
je funkciou velocity teamu počas definovanej dĺžky sprintu. Určíme si teda
dĺžku sprintu a odhadneme velocitu.
Náklady projektu
sa odvíjajú od jeho trvania a použitých ľudských a materiálových
zdrojov. Keďže v IT projektoch sú hlavnou nákladovou položkou (tzv. "cost
driver") ľudia, kalkulujeme v našich odhadoch s kapacitou teamu, ktorú
predpokladáme, že budeme mať na projekte k dispozícii.
A tu
prichádza do hry opäť náš nástroj, ktorý nám pomocou matematicko-štatistických
výpočtov rýchlo vypočíta odhadované trvanie a objem práce v MD
jednotkách.
Opäť si to
modelujme na príklade:
Sprint sme si
určili ako dvojtýždňový. Produktívna kapacita nášho teamu je 60 hodín za Sprint
a požadujeme 95% úroveň spoľahlivosti odhadov. Ďalej potrebujeme určiť
alebo odhadnúť velocitu teamu. Vychádzať môžeme z historických dát alebo si
výšku velocity simulujeme pomocou nášho nástroja. V našom príklade ju sme
určili na 12 Story Points za sprint. Po vložení týchto údajov do výpočtov,
získavame odhadovanú dĺžku projektu 3 až 4 sprinty a odhadovaný objem
pracnosti v rozsahu 22.5 až 30 MD.
Ostáva posledný
krok - a to je určenie cenovky za
odhadnuté Men Days.
Prax nám ukázala
vysokú spoľahlivosť odhadov získaných týmto spôsobom. 80% našich projektov skončilo
v reále tak, ako boli odhadnuté – z hľadiska trvania aj
z hľadiska objemu vynaloženej práce.
