Sadržaj:
procjena softverskog projekta
Pixabay
Uvod
Procjena je jednostavno teška. Nažalost, to je i vrlo potrebno. Tvrtke koriste procjene za projektiranje rasporeda izdavanja, preuzimanje obveza prema svojim kupcima, odlučivanje vrijedi li predloženu značajku, praćenje brzine timova i učinkovito određivanje prioriteta rada. Rukovoditelji često žele znati kada će neka značajka ili isporuka biti spremna za proizvodnju. Napokon, razvoj softvera nije trivijalna investicija. Bez procjena, kako bi voditelj projekta izvršio procjenu? Kad bi ljudi mogli točno predvidjeti budućnost, ljudi ne bi pobjeđivali na konjskim utrkama 2% vremena. Procjena je velika zagonetka. Za tvrtke je neophodno i potrebno tražiti od svojih ljudi da čine nemoguće: predvidjeti budućnost.
Prvo, pregledajmo neke popularne metode procjene (u slučaju da ste propustili neko uzbuđenje). Tada možemo pogledati što ovo znači za nas i naše projekte.
Model gatare
Ovaj model ne zahtijeva gotovo nikakav napor za izradu procjene. Procjenitelji malo razmisle o tome što treba učiniti za implementaciju i testiranje značajke, a zatim izbacuju broj. Zvuči otprilike kao "… (duga stanka)… Ummmmm… 6 tjedana." Tada svi kimnu i idemo dalje. Mogli bi provesti prilično vremena na prednjem kraju razgovarajući kroz ono što znaju o zahtjevima (što vjerojatno nije cjelovita slika). Ova pažljiva analiza čini njihovu procjenu pouzdanijom. Na kraju projekta uvijek postoji prihvaćeno obrazloženje zašto je procjena bila toliko udaljena od stvarnosti. Uvijek postoje nepredviđene okolnosti koje mogu poslužiti kao žrtveni jarac. Često nikome ne padne na pamet da je model ozbiljno manjkav.
Pa kako možemo poboljšati ovaj proces? Znam! Možemo se poslužiti tehnikom razlaganja (tj. Podijeliti i osvojiti). Ovaj pristup pretpostavlja da znate cijeli opseg značajke ili projekta na prednjem kraju. Svaka se značajka raščlanjuje na komade veličine zalogaja. Procjenjuje se svaki dio (gatarski stil), a zatim ih zbrajamo kako bismo dobili ukupnu procjenu značajke / projekta. Ovo je zasigurno složeniji pristup, ali čini se boljim iz dva razloga:
- Manji dio posla obično je lakše pouzdano procijeniti.
- Iako još uvijek postoji mogućnost pogreške (+/- neki iznos), postoji pretpostavka da će se pogreške međusobno poništiti kad sve zbrojite i dobit ćete pouzdaniju ukupnu procjenu.
Osnovna mana ovog pristupa je ta što pojedinačni suradnici (ljudi koji zapravo rade posao) univerzalno podcjenjuju. Još uvijek su znatno bolji od onih iznad i oko sebe, ali to nije visoka ljestvica. To se ne čini slučaj, jer svi smo vidjeli slučajeve kada su se programeri iznenadili postižući nešto prije roka. Ali ovo je jedna podatkovna točka, a ne trend. Ljudi zapravo povremeno pobjeđuju u kasinu; trošite novac u casinu svaki dan tijekom godine i imat ćete manje novca nego što ste započeli. Ako godinu ili dvije pratite procjene u odnosu na stvarne, otkrit ćete da procjene ipak nisu stvarne. Iako su mnogi poslovni ljudi apsolutno sigurni da programeri lijeno popunjavaju svoje procjene i koriste dodatno vrijeme za "zlatnu pločicu" ili provjeru zaliha,podaci pokazuju suprotno. Strategija "otkazivanja" ne funkcionira.
Pa, što sad? Odbacimo gatarski model i prijeđimo na pristup zasnovan na veličini. Ispostavilo se da, iako ljudi prilično grozno procjenjuju vrijeme završetka, mi zapravo prilično dobro govorimo koliko je nešto veliko. Posebno smo dobri u usporedbenom dimenzioniranju ("veće je od toga, ali manje od onog tamo"). Ako razmišljamo u smislu veličine ili složenosti, a ne vremena, naš mozak to pouzdanije obrađuje. Tada možemo uzeti vrijednosti veličine i izračunati stvarni broj sati za projekt na temelju izvrsne čarobne formule! I tada na scenu stupa popularni model funkcijskih točaka (pozornica lijevo).
Analiza funkcionalnih točaka (FPA)
Za analizu funkcionalne točke moramo identificirati pet vrsta stvari u našoj aplikaciji: vanjski ulazi, vanjski izlazi, vanjski upiti, datoteke vanjskog sučelja i interne logičke datoteke (ne brinite previše oko definicija; to možete istražiti kasnije). Svaki primjer te (funkcije) povezan je s složenošću (niskom, prosječnom ili visokom). Upotrijebimo tablicu u nastavku kako bismo shvatili koliko bodova dobiva svaka funkcija.
Sada ako zbrojimo bodove za sve naše funkcije, mogli bismo dobiti broj poput 457 funkcijskih bodova za naš projekt. Tada nam treba samo formula za izračunavanje broja sati… Na temelju našeg zadnjeg projekta, naša „stopa isporuke“ iznosila je 15 funkcionalnih bodova po osobi mjesečno. To je posao vrijedan otprilike 30 mjeseci, što bi za moj tim od 12 godina trebalo malo više od dva i pol mjeseca. Ta-da!
Ovo je sigurno složenije od našeg prethodnog modela. Zapravo postoje četiri ključna područja složenosti koja treba prepoznati.
- Pet vrsta komponenata nije nužno intuitivno i lako je zaboraviti staviti nešto na popis ili ga dodijeliti pogrešnoj skupini.
- Tablica koja se zapravo koristi za generiranje funkcijskih točaka sadrži magične brojeve za čije je validiranje potrebno puno truda. Jesu li ove brojke pravilno kalibrirane kako bi se stvorile pouzdane procjene za moje timove?
- Stopa isporuke (kritični dio slagalice) izračunava se na temelju produktivnosti vašeg tima. Koliko često moramo izračunati novi broj? O tome zapravo postoji vrlo malo smjernica.
- Što predstavlja nisku, prosječnu ili visoku složenost? Kako to definiramo tako da ga svi razumiju? Nije li postizanje tog prava presudno za točnost naših izračuna?
U ovom vrlo jednostavnom primjeru nalazi se nekoliko pokretnih dijelova, a nismo čak ni razgovarali o složenijim modelima složenosti i ostalim podacima koji mogu doći u obzir (npr. Stopa troškova, stopa podrške, gustoća kvarova itd.). Više pokretnih dijelova znači više mogućnosti za pojavu pogrešaka. Činimo li procjenu prekompliciranom sada? Ne plaćamo programerima da posvete puno vremena procjeni. Ne mogu prodati procjenu svojim kupcima. Treba mi radni softver. Postoji li još nešto tamo?
Agilan
Pogledajmo sada ukratko okretni skrum (tek toliko da napravimo usporedbu). Kao što je ranije rečeno, ljudi su užasni u procjeni vremena i prilično su dobri u usporedbenom dimenzioniranju. Evo nekoliko pojmova koje treba razumjeti:
- Sprint - vremenski okvir (obično dva tjedna).
- Priča o korisniku - diskretan posao, po mogućnosti dovoljno malen da ga jedna osoba u sprintu može obaviti. Ovo je stvar koju procjenjujemo.
Najpopularnija strategija je korištenje fibonaccijeve sekvence (0, 1, 2, 3, 5, 8, 13) za procjene. Nije linearno - kako se penjete prema ljestvici, veličina praznina se povećava. Ključno je da praznine budu dovoljno široke da nema razloga za raspravu oko beznačajnih razlika. Jednom kad prijeđete iznad 3, razlika između 4 i 5 ili 7 i 8 toliko je zanemariva da je besmisleno trošiti vrijeme na raspršivanje o kojem se pitanju radi. Slijed baze-2 također bi radio (0, 1, 2, 4, 8, 16, itd.).
“Ali pričekajte, ovo je samo broj. Što to znači? Koliko sati ima smisla? " Bodovi nisu namijenjeni izravnoj korelaciji sa satima, jer ako bi to učinili, timovi bi bili u iskušenju da se vrate na procjenu u satima, a zatim to nekako pretvore u bodove. Kao što je ranije spomenuto, točnost naših procjena dolazi iz usporednog određivanja veličine i ne procjene broja sati koji će vam trebati. Ako timu date sposobnost razmišljanja u smislu sati, ugrožavate svoju sposobnost preciznog procjenjivanja.
Recimo da ste započeli s vježbom baždarenja. Povucite svoj tim u sobu i prođite kroz popis od 10-12 korisničkih priča. Odaberite jedan koji je mali, ali ne i najmanji i prvo napravite taj. Pregledajte ga i objavite da je ova priča "3". Ne pitate. Kažete. Zatim prijeđite na sljedeću priču. "Ako je to bilo 3, što je ovo?" Sada tim određuje veličine priča u odnosu na druge priče. Na kraju će imati prilično dobru ideju što čini "1", "2" itd. Ne procjenjuju. Vrijeme nije važno. Oni određuju veličine priča, u odnosu na druge priče koje već imaju broj. Tada možete staviti primjere priča za svaki broj u nizu u dokument koji se naziva ravnalo. To mogu koristiti kao referencu ako nisu sigurni što je "5".
Evo ključa. Čarobni umak koji čini ovaj posao je "brzina" (broj bodova koje tim može postići u sprintu u prosjeku na 3-4 sprinta). Recimo da je vaš sprint dva tjedna, a vaš tim od 8 ljudi ima prosječnu brzinu od 35 bodova. Dobivate 35 bodova za 640 sati rada (8 x 80 sati). Ako shvatimo da će značajka trebati oko 100 bodova da se posao započne do kraja, onda znam da je to oko 6 tjedana rada i ~ 1900 sati. Tim postaje vrlo dobar u dosljednom određivanju priča, a vi to iskoristite za planiranje svog projekta. Ovaj izračun djeluje jer je trajanje konzistentno od sprinta do sprinta.
Da biste dugoročno planirali na visokoj razini, možete zatražiti od svojih potencijalnih kupaca da značajke na visokoj razini raščlane na privremene priče s jednom linijom i na njih stave bodove. Izgubit će se određeni stupanj točnosti, ali koristite model koji oni već razumiju. Točniji put bio bi relativno dimenzioniranje na razini značajke. "Ova je značajka veća od one od 40 točaka, manja od one od 120 točaka tamo i nešto veća od značajke od 65 točaka koju smo upravo napravili." Priče su grupirane u "epove". Ako je svaka značajka ep, na kraju ćete znati koliko je bodova bilo potrebno da biste dovršili tu značajku. Vodite povijest toga i možete ga koristiti za planiranje izdanja.
Zaključak
Danas se koristi mnoštvo metodologija. Svaka ima prednosti i nedostatke. Moramo nekako shvatiti kako maksimizirati točnost naših procjena kako bismo mogli donijeti dobre odluke. To ne znači da naše procjene moraju biti točne. Oni samo trebaju biti dovoljno precizni da bi bili korisni. Ako ne razumijete procjene, mogli biste pretpostaviti da procjene nisu bile točne jer tim nije dobro obavio posao. Nisu točno procijenili ili nisu pravilno izvršili projekt. Premlaćivanja će se nastaviti dok se procjene ne poboljšaju. Ali procjene se nikada ne smiju koristiti kao obvezu. Najbolja je pretpostavka na temelju ograničenih podataka koje danas imamo. Kad se pojave nove informacije, moramo omogućiti ponovno pregledavanje procjena. Sve drugo očekuje nemoguće, što je problem s vodstvom (ne s timom).
Scrumov pristup mnogo je jednostavniji od onoga što vidimo u analizi funkcijskih točaka. I rekao bih da je puno pouzdaniji od čarobnih tablica s čarobnim brojevima. Dobit će najviše novca (minimalan napor uz razumno visok stupanj točnosti). Iz perspektive napora, to ne stvara težak postupak koji bi timovi mogli razumjeti i koristiti. Agilan procjenitelj zapravo se može dogoditi vrlo brzo nakon što svi shvate detalje rada koji se procjenjuje. To je sigurno bolje nego izvlačiti brojeve iz zraka. Korištenje brzine čini nešto vrlo važno: u izračun unosi povijesne podatke. Svakim sprintom preračunavate brzinu. To je kritično, jer se s vremenom protok mijenja. Timovi koji koriste FPA možda će stopu isporuke izvesti iz svog prethodnog projekta,što je u nekim slučajevima bilo prije nekoliko mjeseci. Od tada se vjerojatno puno toga promijenilo. Moj je prijedlog da istražite agilnost i zaista uložite napor u razumijevanje poanta i brzine priče. Ne vraćajte se procjenjivanju u satima samo zato što to razumijete. Vjerujem da ćete se zahvaliti kasnije.