Satura rādītājs:
programmatūras projekta novērtēšana
Pixabay
Ievads
Novērtēšana ir vienkārši grūta. Diemžēl tas ir arī ļoti nepieciešams. Uzņēmumi izmanto aprēķinus, lai izstrādātu izlaišanas grafikus, uzņemtos saistības ar klientiem, izlemtu, vai piedāvāto funkciju ir vērts ieviest, izseko komandu ātrumu un efektīvi nosaka darbu. Vadītāji bieži vēlas uzzināt, kad kāda funkcija vai produkts būs gatavs ražošanai. Galu galā programmatūras izstrāde nav niecīgs ieguldījums. Bez projekta aprēķiniem, kā projekta vadītājs veiktu novērtējumu? Ja cilvēki varētu precīzi paredzēt nākotni, zirgu skriešanās sacīkstēs cilvēki neuzvarētu 2% gadījumu. Novērtējums ir lieliskā mīkla. Uzņēmumiem ir svarīgi un nepieciešams lūgt savus cilvēkus darīt neiespējamo: paredzēt nākotni.
Pirmkārt, apskatīsim dažas populāras novērtēšanas metodes (ja jums pietrūka kāda satraukuma). Tad mēs varam apskatīt, ko tas nozīmē mums un mūsu projektiem.
Fortune Teller modelis
Šis modelis gandrīz neprasa pūles, lai izveidotu tāmi. Aplēsēji mazliet padomā par to, kas jādara, lai ieviestu un pārbaudītu funkciju, pēc tam izmet numuru. Tas izklausās daudz kā "… (ilga pauze)… Ummmmm… 6 nedēļas." Tad visi pamāj un mēs dodamies tālāk. Viņi varētu pavadīt diezgan ilgu laiku priekšpusē, runājot ar to, ko viņi zina par prasībām (kas, iespējams, nav pilnīgs attēls). Šī rūpīgā analīze ļauj viņu aplēsēm justies uzticamākām. Projekta beigās vienmēr ir pieņemts pamatojums, kāpēc aprēķins bija tik tālu no realitātes. Vienmēr ir neparedzēti apstākļi, kas var kalpot par grēkāzi. Bieži vien nevienam neienāk prātā, ka modelis ir nopietni kļūdains.
Tātad, kā mēs varam uzlabot šo procesu? Es zinu! Mēs varam izmantot sadalīšanās paņēmienu (ti, sadalīt un iekarot). Šajā pieejā tiek pieņemts, ka jūs zināt visas funkcijas vai projekta priekšpusē esošo darbības jomu. Katra funkcija ir sadalīta koduma lieluma gabalos. Katrs gabals tiek aplēsts (zīlnieka stils), pēc tam mēs tos summējam, lai iegūtu vispārēju iezīmi / projekta novērtējumu. Šī noteikti ir sarežģītāka pieeja, taču šķiet labāka divu iemeslu dēļ:
- Mazākus darba gabalus parasti ir vieglāk ticami novērtēt.
- Lai gan joprojām pastāv iespēja kļūdīties (+/- kāda summa), tiek pieņemts, ka kļūdas atcels viena otru, kad to visu saskaitīsit, un jūs saņemsiet ticamāku kopējo novērtējumu.
Šīs pieejas būtisks trūkums ir tāds, ka individuālie ieguldītāji (cilvēki, kas faktiski strādā) vispārīgi nenovērtē. Viņi joprojām ir ievērojami labāki par tiem, kas atrodas virs un ap tiem, taču tas nav augsts latiņš. Tas nešķiet tā, jo mēs visi esam redzējuši gadījumus, kad izstrādātāji pārsteidza sevi, paveicot kaut ko pirms grafika. Bet tas ir viens datu punkts, nevis tendence. Cilvēki kazino reizēm tiešām uzvar; katru gadu tērē naudu kazino katru dienu, un tev būs mazāk naudas, nekā esi sācis. Ja izsekojat aprēķinus un faktiskos datus par gadu vai diviem, jūs atklāsiet, ka tāmes neatbilst realitātei. Lai gan daudzi uzņēmēji ir pilnīgi pārliecināti, ka izstrādātāji slinki papildina savas aplēses un izmanto papildu laiku, lai "zelta plāksnes" vai pārbaudītu savus krājumus,dati rāda citādi. Stratēģija “atcelšana” nedarbojas.
Tātad, ko tagad? Nogremdēsim zīlnieces modeli un pāriesim uz izmēriem balstītu pieeju. Izrādās, ka, lai gan cilvēki ir diezgan šausmīgi, novērtējot pabeigšanas laiku, mēs faktiski diezgan labi varam pateikt, cik kaut kas ir liels. Mēs īpaši labi spējam salīdzināt lielumus ("tas ir lielāks par to, bet mazāks nekā tur"). Ja domājam lieluma vai sarežģītības, nevis laika ziņā, mūsu smadzenes to apstrādā ticamāk. Tad mēs varam ņemt lieluma vērtības un aprēķināt faktisko stundu skaitu projektam, pamatojoties uz izveicīgu burvju formulu! Un tieši tad populārais funkciju punktu modelis ienāk skatījumā (posms pa kreisi).
Funkciju punktu analīze (FPA)
Funkciju punktu analīzei mūsu lietojumprogrammā ir jāidentificē piecu veidu lietas: ārējās ieejas, ārējās izejas, ārējie vaicājumi, ārējās saskarnes faili un iekšējie loģiskie faili (neuztraucieties pārāk daudz par definīcijām; tās varat izpētīt vēlāk). Katram no tiem (funkcijai) ir saistīta sarežģītība (zema, vidēja vai augsta). Mēs izmantojam zemāk esošo tabulu, lai noskaidrotu, cik punktus piešķir katrai funkcijai.
Tagad, summējot punktus visām funkcijām, mēs savam projektam varētu iegūt tādu skaitu kā 457 funkciju punkti. Tad mums vienkārši nepieciešama formula, lai noteiktu stundu skaitu… Pamatojoties uz mūsu pēdējo projektu, mūsu “piegādes ātrums” mēnesī bija 15 funkciju punkti vienai personai. Tas ir aptuveni 30 cilvēku mēnešu vērts darbs, kam manai 12 cilvēku komandai vajadzētu aizņemt nedaudz vairāk kā divarpus mēnešus. Ta-da!
Tas noteikti ir sarežģītāk nekā mūsu iepriekšējais modelis. Faktiski jāatzīst četras galvenās sarežģītības jomas.
- Pieci komponentu tipi ne vienmēr ir intuitīvi, un ir viegli aizmirst kaut ko ievietot sarakstā vai piešķirt nepareizai grupai.
- Funkciju punktu reālai ģenerēšanai izmantotajā tabulā ir maģiski skaitļi, kuru validēšanai būtu jāpieliek daudz pūļu. Vai šie skaitļi ir pareizi kalibrēti, lai manām komandām izveidotu ticamus aprēķinus?
- Piegādes ātrums (kritisks puzles gabals) tiek aprēķināts, pamatojoties uz jūsu komandas produktivitāti. Cik bieži mums jāaprēķina jauns skaitlis? Par to faktiski ir ļoti maz norādījumu.
- Kas ir zems, vidējs vai ļoti sarežģīts? Kā mēs to definējam, lai visi to saprastu? Vai mūsu aprēķinu precizitātei nav izšķiroša nozīme?
Šajā ļoti vienkāršajā piemērā ir vairākas kustīgas detaļas, un mēs pat neesam apsprieduši sarežģītākus sarežģītības modeļus un citus datus, kas var parādīties (piemēram, izmaksu likme, atbalsta pakāpe, defektu blīvums utt.). Vairāk kustīgu daļu nozīmē vairāk iespēju kļūdām. Vai mēs tagad veicam novērtēšanu pārāk sarežģīti? Mēs nemaksājam izstrādātājiem, lai viņi daudz laika veltītu novērtēšanai. Es nevaru pārdot tāmi saviem klientiem. Man ir nepieciešama darba programmatūra. Vai tur ir vēl kaut kas?
Ejot veikls
Tagad īsi aplūkosim veiklu skrāpējumu (tieši tik daudz, lai veiktu salīdzinājumu). Kā minēts iepriekš, cilvēki ir briesmīgi, novērtējot laiku, un diezgan labi spēj salīdzināt lielumu. Šeit ir pāris termini, lai saprastu:
- Sprints - laika sprīdis (parasti divas nedēļas).
- Lietotāja stāsts - diskrēts darbs, vēlams pietiekami mazs, lai to paveiktu viena persona sprintā. Šī ir lieta, ko mēs novērtējam.
Vispopulārākā stratēģija ir aplēsēm izmantot fibonači secību (0, 1, 2, 3, 5, 8, 13). Tas nav lineārs - pieaugot skalai, atstarpju lielums palielinās. Galvenais ir tas, ka atstarpēm jābūt pietiekami plašām, lai nebūtu pamata strīdēties par nenozīmīgām atšķirībām. Kad esat sasniedzis virs 3, starpība starp 4 un 5 vai 7 un 8 ir tik nenozīmīga, ka ir bezjēdzīgi pavadīt laiku, sajaucot, kurš tas ir. Derētu arī bāzes 2 secība (0, 1, 2, 4, 8, 16 utt.).
"Bet pagaidiet, tas ir tikai skaitlis. Ko tas nozīmē? Cik stundas ir punkts? ” Punkti nav tieši saistīti ar stundām, jo, ja viņi to izdarītu, komandām būtu kārdinājums atgriezties pie stundu aprēķināšanas un pēc tam kaut kā pārvērst to punktos. Kā jau tika apspriests iepriekš, mūsu aprēķinu precizitāti nosaka salīdzinošais lielumu noteikšana un stundu nenovērtēšana, kas kaut ko prasīs. Ja komandai dodat iespēju domāt stundās, jūs apdraudat spēju precīzi novērtēt.
Pieņemsim, ka jūs sākāt ar kalibrēšanas vingrinājumu. Ievelciet savu komandu telpā un izstaigājiet 10-12 lietotāju stāstu sarakstu. Izvēlieties vienu mazu, bet ne mazāko un vispirms izdariet to. Pārskatiet to un paziņojiet, ka šis stāsts ir “3”. Jūs nejautājat. Jūs sakāt. Pēc tam pārejiet pie nākamā stāsta. "Ja tas bija 3, kas tas ir?" Tagad komanda nosaka stāstus, salīdzinot ar citiem stāstiem. Galu galā viņiem būs diezgan laba ideja, kas ir “1”, “2” utt. Viņi to nenovērtē. Laikam nav nozīmes. Viņi izšķir stāstus, salīdzinot ar citiem stāstiem, kuriem jau ir numurs. Pēc tam jūs varat ievietot paraugu stāstus par katru kārtas numuru dokumentā, ko sauc par lineālu. Viņi var to izmantot kā atsauci, ja viņi nav pārliecināti, kas ir “5”.
Tagad šeit ir atslēga. Burvju mērce, kas padara šo darbu, ir "ātrums" (punktu skaits, ko komanda var izpildīt sprintā, vidēji aprēķinot 3-4 sprintus). Pieņemsim, ka jūsu sprints ir divas nedēļas, un jūsu 8 cilvēku komandai vidējais ātrums ir 35 punkti. Jūs saņemat 35 punktus 640 stundu darba laikā (8 x 80 stundas). Ja mēs izdomājam, ka kāda funkcija būs jāpabeidz aptuveni 100 punktu vērtībā, tad es zinu, ka tas ir apmēram 6 darba nedēļas un ~ 1900 stundas. Komandai ļoti labi padodas konsekventi veidot stāstus, un jūs to izmantojat, plānojot projektu. Šis aprēķins darbojas, jo ilgums ir vienāds no sprinta līdz sprintam.
Lai veiktu ilgtermiņa augsta līmeņa plānošanu, varat lūgt saviem klientiem sadalīt augsta līmeņa funkcijas pagaidu vienas līnijas stāstos un likt tiem punktu vērtības. Būs zināma precizitātes pakāpe, taču jūs izmantojat modeli, kuru viņi jau saprot. Precīzāks ceļš būtu relatīvais izmērs objektu līmenī. "Šī funkcija ir lielāka nekā šī 40 punktu īpašība, mazāka nekā šī 120 punktu funkcija un nedaudz lielāka par 65 punktu funkciju, ko tikko izdarījām." Stāsti ir sagrupēti “epos”. Ja katra funkcija ir epika, beigās jūs zināt, cik punktu bija nepieciešams, lai pabeigtu šo funkciju. Saglabājiet to vēsturi, un jūs varat to izmantot izlaišanas plānošanai.
Secinājums
Mūsdienās tiek izmantots daudz metodiku. Katram ir plusi un mīnusi. Kaut kā mums ir jāizdomā, kā maksimizēt mūsu aprēķinu precizitāti, lai mēs varētu pieņemt labus lēmumus. Tas nenozīmē, ka mūsu aprēķiniem jābūt precīziem. Viņiem vienkārši jābūt pietiekami precīziem, lai tie būtu noderīgi. Ja nesaprotat novērtējumu, varat pieņemt, ka aprēķini nebija precīzi, jo komanda nedarīja labu darbu. Viņi nenovērtēja pareizi vai arī neizpildīja projektu pareizi. Pukstēšana turpināsies, līdz uzlabosies aplēses. Bet aprēķinus nekad nevajadzētu izmantot kā saistības. Tas ir labākais minējums, pamatojoties uz ierobežoto informāciju, kas mums šodien ir. Kad parādās jauna informācija, mums jāļauj pārskatīt aplēses. Viss pārējais gaida neiespējamo, kas ir problēma ar vadību (nevis ar komandu).
Scrum pieeja ir daudz vienkāršāka nekā tas, ko mēs redzam funkciju punktu analīzē. Un es teiktu, ka tas ir daudz uzticamāks nekā burvju galdi ar burvju numuriem. Tas saņem vislielāko sprādzienu (minimālas pūles ar samērā augstu precizitāti). Raugoties no piepūles viedokļa, tas nerada smagu procesu, ko komandas varētu saprast un izmantot. Novērtēšanas veiklais gabals faktiski var notikt ļoti ātri, tiklīdz visi ir sapratuši novērtējamā darba detaļas. Tas noteikti ir labāk nekā izvilkt ciparus no zila gaisa. Ātruma piesaistīšana ir kaut kas ļoti svarīgs: tas aprēķinos iekļauj vēsturiskos datus. Katru sprintu jūs pārrēķināt savu ātrumu. Tas ir kritiski, jo laika gaitā mainās caurlaide. Komandas, kas izmanto FPA, piegādes ātrumu var iegūt no iepriekšējā projekta,kas dažos gadījumos bija pirms vairākiem mēnešiem. Kopš tā laika, iespējams, daudz kas ir mainījies. Es iesaku jums izpētīt veiklību un patiešām pielikt pūles, lai izprastu stāsta punktus un ātrumu. Neatgriezieties pie aprēķināšanas stundās tikai tāpēc, ka to saprotat. Es ticu, ka vēlāk pateiksies sev.