Obsah:
odhad softvérového projektu
Pixabay
Úvod
Odhad je len ťažký. Je to bohužiaľ tiež veľmi potrebné. Spoločnosti používajú odhady na plánovanie vydaní, prijímanie záväzkov voči zákazníkom, rozhodovanie o tom, či sa navrhovaná funkcia oplatí implementovať, sledovanie rýchlosti tímov a stanovenie efektivity práce. Vedúci pracovníci často chcú vedieť, kedy bude funkcia alebo produkt pripravený na výrobu. Vývoj softvéru nie je koniec koncov triviálna investícia. Ako by bez odhadov urobil projektový manažér hodnotenie? Keby ľudia dokázali presne predpovedať budúcnosť, ľudia by nevyhrali na dostihoch 2% času. Odhad je veľká hádanka. Je nevyhnutné a nevyhnutné, aby spoločnosti požiadali svojich ľudí o nemožné: predpovedanie budúcnosti.
Najskôr si prečítajme niektoré populárne metódy odhadu (pre prípad, že by ti chýbalo vzrušenie). Potom sa môžeme pozrieť na to, čo to znamená pre nás a naše projekty.
Model veštkyne
Tento model nevyžaduje takmer nijaké úsilie na vypracovanie odhadu. Odhadcovia sa trochu zamyslia nad tým, čo je potrebné urobiť pre implementáciu a testovanie funkcie, potom vyhodia číslo. Znie to veľa ako „… (dlhá pauza)… Hmmmmm… 6 týždňov.“ Potom všetci prikyvujú a ideme ďalej. Môžu stráviť nejaký čas na klientskom rozhraní rozhovorom o tom, čo vedia o požiadavkách (čo pravdepodobne nie je úplný obraz). Vďaka tejto starostlivej analýze sa ich odhad bude cítiť spoľahlivejší. Na konci projektu vždy existuje prijateľné odôvodnenie, prečo bol odhad tak ďaleko od reality. Vždy existujú nepredvídané okolnosti, ktoré môžu slúžiť ako obetný baránok. Často sa nikomu nestane, že by model mal vážne chyby.
Ako teda môžeme tento proces vylepšiť? Viem! Môžeme použiť techniku rozkladu (tj. Rozdeľ a panuj). Tento prístup predpokladá, že poznáte úplný rozsah funkcie alebo projektu v klientskom rozhraní. Každá funkcia je rozdelená na kúsky veľké ako sústo. Každý blok je odhadovaný (štýl kartárky), potom ich sčítame a získame tak celkový odhad funkcie / projektu. Toto je určite komplikovanejší prístup, ale zdá sa byť lepší z dvoch dôvodov:
- Menšie časti práce sa dajú spoľahlivo ľahšie odhadnúť.
- Aj keď stále existuje možnosť chyby (+/- nejaká suma), existuje predpoklad, že sa chyby vzájomne zrušia, keď to všetko spočítate, a získate spoľahlivejší celkový odhad.
Zásadnou chybou tohto prístupu je, že jednotliví prispievatelia (ľudia, ktorí prácu skutočne vykonávajú) sa všeobecne podceňujú. Stále sú výrazne lepšie ako tie nad nimi a okolo nich, ale to nie je vysoká latka. Zdá sa, že to tak nie je, pretože sme všetci videli prípady, keď sa vývojári prekvapili tým, že dosiahli niečo pred termínom. Ale toto je jediný údajový bod, nie trend. Ľudia skutočne príležitostne vyhrávajú v kasíne; utrácajte peniaze každý rok v kasíne a budete mať menej peňazí, ako ste začínali. Ak sledujete odhady a skutočnosti za rok alebo dva, zistíte, že odhady zaostávajú za realitou. Zatiaľ čo mnoho podnikateľov si je úplne istých, že vývojári lenivo dopĺňajú svoje odhady a využívajú čas navyše na „pozlátenie“ alebo kontrolu svojich zásob,údaje ukazujú inak. Stratégia „zrušenia“ nefunguje.
Takže, čo teraz? Zbavme sa modelu veštca a prejdime k prístupu založenému na veľkosti. Ukázalo sa, že aj keď ľudia vedia odhadnúť čas dokončenia, celkom príšerne, v skutočnosti dokážeme celkom dobre povedať, aké niečo je veľké. Sme obzvlášť dobrí v komparatívnych veľkostiach („je to väčšie ako toto, ale menšie ako tamto“). Ak myslíme skôr na veľkosť alebo zložitosť ako na čas, náš mozog to spracuje spoľahlivejšie. Potom môžeme vziať hodnoty veľkosti a vypočítať skutočný počet hodín pre projekt na základe šikovného magického vzorca! A to je prípad, keď na scénu vstúpi populárny model funkčných bodov (scéna vľavo).
Analýza funkčných bodov (FPA)
Pri analýze funkčných bodov musíme v našej aplikácii identifikovať päť typov vecí: externé vstupy, externé výstupy, externé dotazy, súbory externých rozhraní a interné logické súbory (s definíciami sa príliš netrápte; tieto môžete preskúmať neskôr).. Každý príklad z nich (funkcia) má s tým spojenú zložitosť (nízka, priemerná alebo vysoká). Pomocou nasledujúcej tabuľky zistíme, koľko bodov získa každá funkcia.
Ak teraz spočítame body za všetky naše funkcie, môžeme pre náš projekt získať číslo ako 457 funkčných bodov. Potom potrebujeme iba vzorec na výpočet počtu hodín… Na základe nášho posledného projektu bola naša „rýchlosť doručenia“ 15 funkčných bodov na osobu za mesiac. To je práca na zhruba 30 osôb mesačne, čo by pre môj tím 12. malo trvať niečo vyše dva a pol mesiaca. Ta-da!
Toto je určite zložitejšie ako náš predchádzajúci model. V skutočnosti je potrebné rozpoznať štyri kľúčové oblasti zložitosti.
- Päť typov komponentov nemusí byť nevyhnutne intuitívnych a je ľahké zabudnúť niečo vložiť do zoznamu alebo priradiť k nesprávnemu vedru.
- Tabuľka použitá na skutočné generovanie funkčných bodov obsahuje magické čísla, ktorých overenie by vyžadovalo veľa úsilia. Sú tieto čísla správne kalibrované, aby generovali spoľahlivé odhady pre moje tímy?
- Rýchlosť doručenia (kritická časť skladačky) sa počíta na základe produktivity vášho tímu. Ako často potrebujeme vypočítať nové číslo? V skutočnosti k tomu existuje len veľmi málo usmernení.
- Čo predstavuje nízku, priemernú alebo veľkú zložitosť? Ako to definujeme, aby to všetci pochopili? Nie je to správne kritické pre presnosť našich výpočtov?
V tomto veľmi jednoduchom príklade je niekoľko pohyblivých častí a nehovorili sme ani o zložitejších modeloch zložitosti a ďalších údajoch, ktoré môžu vstúpiť do hry (napr. Miera nákladov, miera podpory, hustota chýb atď.). Viac pohyblivých častí znamená viac príležitostí na výskyt chýb. Robíme teraz odhad príliš komplikovaným? Neplatíme vývojárom, aby venovali veľa času odhadom. Nemôžem svojim zákazníkom predať odhad. Potrebujem funkčný softvér. Je tam ešte niečo?
Ideme agilne
Teraz sa pozrime v krátkosti na agilnú skrumáž (stačí na porovnanie). Ako už bolo uvedené skôr, ľudia vedia odhadnúť čas strašne a vedia sa dobre porovnávať. Tu je potrebné pochopiť niekoľko výrazov:
- Šprint - časovo ohraničený časový úsek (zvyčajne dva týždne).
- Príbeh používateľa - samostatná práca, najlepšie taká malá, aby ju mohla vykonať jedna osoba v šprinte. To je vec, ktorú odhadujeme.
Najobľúbenejšou stratégiou je na odhadovanie použitie fibonacciho sekvencie (0, 1, 2, 3, 5, 8, 13). Nie je to lineárne - s rastom stupnice sa zväčšujú medzery. Kľúčové je, že medzery by mali byť dostatočne široké, aby neexistoval dôvod na hádky o nepodstatných rozdieloch. Akonáhle sa dostanete nad 3, rozdiel medzi 4 a 5 alebo 7 a 8 je taký zanedbateľný, že je zbytočné tráviť čas hashovaním, ktorý to je. Fungovala by aj sekvencia báza 2 (0, 1, 2, 4, 8, 16 atď.).
"Ale počkaj, toto je iba číslo." Čo to znamená? Koľko hodín je bod? “ Body nie sú určené na to, aby priamo korelovali s hodinami, pretože ak by to tak bolo, tímy by boli v pokušení vrátiť sa k odhadovaniu v hodinách a potom to nejako prepočítať na body. Ako sme už diskutovali, presnosť našich odhadov vychádza z komparatívneho určovania veľkosti a z neodhadnutia počtu hodín, ktoré niečo bude trvať. Ak dáte tímu schopnosť premýšľať o hodinách, zhoršujete svoju schopnosť presného odhadu.
Povedzme, že ste začali s kalibračným cvičením. Vytiahnite svoj tím do miestnosti a prechádzajte ním zoznamom 10 až 12 používateľských príbehov. Vyberte ten, ktorý je malý, ale nie najmenší, a urobte ho ako prvý. Skontrolujte ho a oznámte, že tento príbeh je „3“. Nepýtaš sa. Hovoríš. Potom prejdite na ďalší príbeh. "Keby to bola trojka, čo je táto?" Tím teraz upravuje veľkosť príbehov v porovnaní s inými príbehmi. Nakoniec budú mať celkom dobrý nápad, čo predstavuje „1“, „2“ atď. Neodhadujú. Na čase nezáleží. Zmierňujú veľkosť príbehov v porovnaní s inými príbehmi, ktoré už majú číslo. Potom môžete vložiť ukážky príbehov pre každé číslo v poradí do dokumentu nazývaného pravítko. Môžu to použiť ako referenciu, ak si nie sú istí, čo je „5“.
Teraz je tu kľúč. Čarovná omáčka, ktorá umožňuje túto prácu, je „rýchlosť“ (počet bodov, ktoré môže tím absolvovať v šprinte, v priemere za 3 - 4 šprinty). Povedzme, že váš šprint je dva týždne a váš tím 8 ľudí má priemernú rýchlosť 35 bodov. Za 640 hodín práce (8 x 80 hodín) získavate 35 bodov. Ak prídeme na to, že dokončenie funkcie bude trvať asi 100 bodov, potom viem, že je to asi 6 týždňov práce a ~ 1 900 hodín. Tím je veľmi dobrý v dôslednom dimenzovaní príbehov a vy ich využijete pri plánovaní projektu. Tento výpočet funguje, pretože doba trvania je rovnaká od šprintu k šprintu.
Ak chcete urobiť dlhodobé plánovanie na vysokej úrovni, môžete požiadať svojich potenciálnych zákazníkov, aby rozdelili funkcie na vysokej úrovni na dočasné príbehy jedného riadku a dali im bodové hodnoty. Stratí sa určitý stupeň presnosti, ale využívate model, ktorému už rozumejú. Presnejšia cesta by bola relatívna veľkosť na úrovni funkcií. "Táto funkcia je väčšia ako táto 40-bodová funkcia, menšia ako táto 120-bodová funkcia tam a o niečo väčšia ako 65-bodová funkcia, ktorú sme práve vytvorili." Príbehy sú zoskupené do „eposov“. Ak je každá funkcia epická, na konci budete vedieť, koľko bodov potrebných na dokončenie tejto funkcie. Zaznamenajte si to do histórie a môžete ich použiť na plánovanie vydania.
Záver
V súčasnosti sa používa veľa metodík. Každá má svoje plusy aj mínusy. Nejako musíme prísť na to, ako maximalizovať presnosť našich odhadov, aby sme mohli robiť dobré rozhodnutia. To neznamená, že naše odhady musia byť presné. Musia byť dostatočne presné, aby boli užitočné. Ak nerozumiete odhadom, môžete predpokladať, že odhady neboli presné, pretože tím neodviedol dobrú prácu. Neodhadli správne alebo projekt nevykonali správne. Bitie bude pokračovať, kým sa odhady nezlepší. Odhady by sa však nikdy nemali používať ako záväzok. Je to najlepší odhad na základe obmedzených informácií, ktoré dnes máme. Keď sa objavia nové informácie, musíme umožniť opätovné prehodnotenie odhadov. Čokoľvek iné očakáva nemožné, čo je problém s vedením (nie s tímom).
Scrumov prístup je oveľa jednoduchší ako to, čo vidíme v analýze funkčných bodov. A povedal by som, že je oveľa dôveryhodnejší ako magické tabuľky s magickými číslami. Za babku dostane maximum (minimálne úsilie s primerane vysokou mierou presnosti). Z hľadiska úsilia to nevytvára pre tímy ťažký proces na pochopenie a použitie. K agilnému odhadu môže skutočne dôjsť veľmi rýchlo, keď všetci pochopia podrobnosti odhadovanej práce. Je to určite lepšie ako vyťahovať čísla zo vzduchu. Využitie rýchlosti robí niečo veľmi dôležité: prináša do výpočtu historické údaje. Pri každom šprinte si prepočítate svoju rýchlosť. To je kritické, pretože sa časom mení priepustnosť. Tímy, ktoré používajú FPA, môžu odvodiť svoju mieru doručenia od svojho predchádzajúceho projektu,čo v niektorých prípadoch bolo pred niekoľkými mesiacmi. Odvtedy sa pravdepodobne veľa zmenilo. Navrhujem, aby ste preskúmali Agile a skutočne sa snažili porozumieť bodom a rýchlosti príbehu. Nepodľahnite odhadu za niekoľko hodín len preto, že tomu rozumiete. Verím, že sa neskôr poďakujete.