Obsah:
odhad softwarového projektu
Pixabay
Úvod
Odhad je jen těžký. Je to bohužel také velmi nutné. Společnosti pomocí odhadů promítají plány vydání, zavazují své zákazníky, rozhodují, zda se navrhovaná funkce vyplatí implementovat, sledují rychlost týmů a efektivně upřednostňují práci. Vedoucí pracovníci často chtějí vědět, kdy bude funkce nebo dodávka připravena k produkci. Koneckonců, vývoj softwaru není triviální investice. Jak by bez odhadů provedl projektový manažer hodnocení? Pokud by lidé dokázali přesně předpovídat budoucnost, nevyhráli by lidé na dostizích 2% času. Odhad je velká hádanka. Je zásadní a nutné, aby společnosti požádaly své zaměstnance, aby udělali nemožné: předpovídali budoucnost.
Nejprve se podívejme na několik populárních metod odhadu (pro případ, že vám nějaké vzrušení uniklo). Pak se můžeme podívat na to, co to pro nás a naše projekty znamená.
Model věštkyně
Tento model nevyžaduje téměř žádné úsilí k vytvoření odhadu. Odhadci se trochu zamyslí nad tím, co je třeba udělat pro implementaci a testování funkce, pak vyhodí číslo. Zní to hodně jako „… (dlouhá pauza)… Hmmmmm… 6 týdnů.“ Pak všichni přikývnou a jdeme dál. Mohli by chvíli strávit na frontě rozhovorem o tom, co vědí o požadavcích (což pravděpodobně není úplný obrázek). Tato pečlivá analýza zvyšuje spolehlivost jejich odhadu. Na konci projektu vždy existuje přijatelné zdůvodnění, proč byl odhad tak daleko od reality. Vždy existují nepředvídané okolnosti, které mohou sloužit jako obětní beránek. Nikoho často nenapadne, že by model měl vážnou chybu.
Jak tedy můžeme tento proces vylepšit? Vím! Můžeme použít techniku rozkladu (tj. Rozděl a panuj). Tento přístup předpokládá, že znáte úplný rozsah funkce nebo projektu na klientském rozhraní. Každá funkce je rozdělena na kousky velikosti kousnutí. Každý blok je odhadován (styl věštkyně), poté je sečteme, abychom získali celkový odhad funkce / projektu. To je určitě složitější přístup, ale zdá se být lepší ze dvou důvodů:
- Spolehlivě lze snadno odhadnout menší části práce.
- I když stále existuje příležitost k chybě (+/- nějaká částka), existuje předpoklad, že se chyby navzájem zruší, když to všechno sečtete a získáte spolehlivější celkový odhad.
Zásadní chybou tohoto přístupu je, že jednotliví přispěvatelé (lidé, kteří skutečně dělají práci) se všeobecně podceňují. Stále jsou výrazně lepší než ti nad nimi a kolem nich, ale to není vysoká laťka. To se nezdá jako případ, protože jsme se všichni setkali s případy, kdy se vývojáři překvapili tím, že dokázali něco před plánovaným termínem. Ale toto je jediný datový bod, ne trend. Lidé skutečně občas vyhrávají v kasinu; utrácet peníze v kasinu každý den po dobu jednoho roku a budete mít méně peněz, než jste začínali. Pokud sledujete odhady vs. skutečnosti za rok nebo dva, zjistíte, že odhady zaostávají za realitou. Zatímco mnoho podnikatelů si je naprosto jistých, že vývojáři líně vyplňují své odhady a využívají čas navíc k „pozlacení“ nebo kontrole svých akcií,data ukazují jinak. Strategie „zrušení“ nefunguje.
Takže, co teď? Vypusťme model věštkyně a přejdeme k přístupu založenému na velikosti. Ukázalo se, že i když lidé odhadují čas dokončení docela hrozně, ve skutečnosti dokážeme docela dobře říci, jak velké něco je. Jsme obzvláště dobří v komparativním dimenzování („je to větší než to, ale menší než to tam“). Pokud přemýšlíme spíše o velikosti nebo složitosti než o čase, náš mozek to zpracovává spolehlivěji. Pak můžeme vzít hodnoty velikosti a vypočítat skutečný počet hodin pro projekt na základě šikovného magického vzorce! A to je, když na scénu vstupuje populární model funkčních bodů (scéna vlevo).
Analýza funkčních bodů (FPA)
Pro analýzu funkčních bodů musíme v naší aplikaci identifikovat pět typů věcí: externí vstupy, externí výstupy, externí dotazy, soubory externího rozhraní a interní logické soubory (s definicemi si příliš nedělejte starosti, můžete je později prozkoumat). Každý příklad z nich (funkce) má s tím spojenou složitost (nízká, průměrná nebo vysoká). V následující tabulce zjistíme, kolik bodů je každé funkci přiřazeno.
Pokud nyní sečteme body za všechny naše funkce, můžeme pro náš projekt získat číslo jako 457 funkčních bodů. Pak už jen potřebujeme vzorec pro výpočet počtu hodin… Na základě našeho posledního projektu byla naše „rychlost dodání“ 15 funkčních bodů na osobu za měsíc. To je práce zhruba za 30 osob na měsíc, což by mému týmu 12 mělo trvat něco málo přes dva a půl měsíce. Ta-da!
To je určitě složitější než náš předchozí model. Ve skutečnosti je třeba rozpoznat čtyři klíčové oblasti složitosti.
- Těchto pět typů komponent nemusí být nutně intuitivní a je snadné zapomenout něco vložit do seznamu nebo to přiřadit k nesprávnému segmentu.
- Tabulka použitá ke skutečnému generování funkčních bodů obsahuje magická čísla, jejichž ověření by vyžadovalo velké úsilí. Jsou tato čísla správně kalibrována, aby generovala spolehlivé odhady pro mé týmy?
- Rychlost dodání (kritická část skládačky) se vypočítá na základě produktivity vašeho týmu. Jak často musíme počítat nové číslo? Ve skutečnosti k tomu existuje jen velmi málo pokynů.
- Co představuje nízkou, průměrnou nebo vysokou složitost? Jak to definujeme, aby tomu všichni rozuměli? Není správnost našich výpočtů rozhodující?
V tomto velmi jednoduchém příkladu je několik pohyblivých částí a my jsme ani neprojednali složitější modely složitosti a další data, která mohou vstoupit do hry (např. Míra nákladů, míra podpory, hustota defektů atd.). Více pohyblivých částí znamená více příležitostí k výskytu chyb. Děláme teď odhad příliš komplikovaným? Neplatíme vývojářům, aby věnovali hodně času odhadům. Nemohu prodat odhad svým zákazníkům. Potřebuji funkční software. Je tam ještě něco jiného?
Jít agilní
Nyní se podívejme krátce na agilní skrumáž (stačí provést srovnání). Jak již bylo uvedeno dříve, lidé jsou hrozní v odhadování času a jsou docela dobří v komparativní velikosti. Tady je několik pojmů, kterým je třeba rozumět:
- Sprint - časově ohraničený časový úsek (obvykle dva týdny).
- Příběh uživatele - samostatná práce, nejlépe dostatečně malá, aby ji zvládla jedna osoba ve sprintu. To je věc, kterou odhadujeme.
Nejoblíbenější strategií je použití fibonacciho sekvence (0, 1, 2, 3, 5, 8, 13) pro odhady. Není to lineární - s rostoucí stupnicí se zvětšují mezery. Klíčem je, že mezery by měly být dostatečně široké, aby neexistoval důvod k hádkám o nepodstatných rozdílech. Jakmile se dostanete nad 3, rozdíl mezi 4 a 5 nebo 7 a 8 je tak zanedbatelný, že je zbytečné trávit čas hašováním, o který jde. Sekvence base-2 by také fungovala (0, 1, 2, 4, 8, 16 atd.).
"Ale počkej, toto je jen číslo." Co to znamená? Kolik hodin je bod? “ Body nejsou zamýšleny tak, aby přímo korelovaly s hodinami, protože pokud by to byly provedeny, týmy by byly v pokušení vrátit se k odhadu v hodinách a poté je nějakým způsobem převést na body. Jak již bylo zmíněno dříve, přesnost našich odhadů pochází z komparativního dimenzování a ne z odhadu počtu hodin, které něco zabere. Pokud dáte týmu schopnost přemýšlet o hodinách, ohrožujete svou schopnost přesně odhadovat.
Řekněme, že jste začali s kalibračním cvičením. Přitáhněte svůj tým do místnosti a projděte jej seznamem 10–12 uživatelských příběhů. Vyberte ten, který je malý, ale ne nejmenší, a udělejte ten první. Zkontrolujte to a oznamte, že tento příběh je „3“. Ty se neptáš. Říkáš. Poté přejděte k dalšímu příběhu. "Kdyby to byla 3, co je tohle?" Tým nyní dimenzuje příběhy ve srovnání s jinými příběhy. Nakonec budou mít docela dobrý nápad, co představuje „1“, „2“ atd. Neodhadují. Na čase nezáleží. Dimenzují příběhy ve srovnání s jinými příběhy, které již mají číslo. Potom můžete pro každé číslo v pořadí vložit ukázkové příběhy do dokumentu zvaného pravítko. Mohou to použít jako referenci, pokud si nejsou jisti, co je „5“.
Tady je klíč. Kouzelná omáčka, která dělá tuto práci, je „rychlost“ (počet bodů, které může tým ve sprintu absolvovat, průměrně přes 3-4 sprinty). Řekněme, že váš sprint je dva týdny a váš tým 8 lidí má průměrnou rychlost 35 bodů. Za 640 hodin práce (8 x 80 hodin) získáte 35 bodů. Pokud zjistíme, že funkce bude trvat asi 100 bodů, než začne práce, pak vím, že je to asi 6 týdnů práce a ~ 1900 hodin. Tým je velmi dobrý v neustálém dimenzování příběhů, což využijete při plánování projektu. Tento výpočet funguje, protože doba trvání je od sprintu ke sprintu konzistentní.
Chcete-li provést dlouhodobé plánování na vysoké úrovni, můžete požádat své potenciální zákazníky, aby rozložili funkce na vysoké úrovni na prozatímní příběhy s jedním řádkem a dali jim bodové hodnoty. Ztratí se určitý stupeň přesnosti, ale využíváte model, kterému již rozumí. Přesnější cesta by byla relativní velikost na úrovni prvku. "Tato funkce je větší než tato 40bodová funkce, menší než ta 120bodová funkce tam a o něco větší než 65bodová funkce, kterou jsme právě udělali." Příběhy jsou seskupeny do „eposů“. Pokud je každá funkce epická, na konci budete vědět, kolik bodů bylo zapotřebí k dokončení této funkce. Uchovávejte si historii toho a můžete ji použít pro plánování vydání.
Závěr
Dnes se používá spousta metodik. Každý má klady a zápory. Nějak musíme přijít na to, jak maximalizovat přesnost našich odhadů, abychom mohli činit správná rozhodnutí. To neznamená, že naše odhady musí být přesné. Musí být dostatečně přesné, aby byly užitečné. Pokud nerozumíte odhadu, můžete předpokládat, že odhady nebyly přesné, protože tým neodvedl dobrou práci. Neodhadli správně, nebo neprovedli projekt správně. Bití bude pokračovat, dokud se odhady nezlepší. Odhady by však nikdy neměly být použity jako závazek. Je to nejlepší odhad na základě omezených informací, které dnes máme. Když se objeví nové informace, musíme umožnit revizi odhadů. Cokoli jiného čeká nemožné, což je problém s vedením (nikoli s týmem).
Scrumův přístup je mnohem jednodušší než to, co vidíme v analýze funkčních bodů. A řekl bych, že je mnohem důvěryhodnější než kouzelné tabulky s magickými čísly. Za babku dostane maximum (minimální úsilí s přiměřeně vysokou mírou přesnosti). Z hlediska úsilí nevytváří těžký proces, kterému by týmy rozuměly a používaly ho. Agilní odhad může ve skutečnosti proběhnout velmi rychle, jakmile každý pochopí podrobnosti odhadované práce. Je to určitě lepší než vytahovat čísla ze vzduchu. Využití rychlosti dělá něco velmi důležitého: přináší do výpočtu historická data. Při každém sprintu přepočítáte svou rychlost. To je zásadní, protože se časem mění propustnost. Týmy, které používají FPA, mohou odvodit svou rychlost dodání z předchozího projektu,což v některých případech bylo před několika měsíci. Od té doby se pravděpodobně hodně změnilo. Můj návrh je, abyste prozkoumali Agile a opravdu se snažili porozumět bodům příběhu a rychlosti. Nepokoušejte se odhadovat hodiny jen proto, že tomu rozumíte. Věřím, že si později poděkujete.