Sissejuhatus

Üks tarkvaraarenduse raskemaid asju on uue tarkvaraprojekti elluviimiseks kuluva aja ja vaeva määramine. Kas see peaks olema nii raske? Vastus pole nii lihtne.

Tarkvara maksumuse hindamine on sisuliselt keeruline ja inimesed oskavad absoluutseid tulemusi ennustada üsna halvasti. Ei ole kahte ühesugust projekti; igaüks neist on ainulaadne selle poolest, mida ta kavatseb saavutada, ja parameetrite arvu järgi, mis selle olemasolu moodustavad. Sageli on see, mis näib pinnal olevat lihtne probleem, tegelikkuses rakendatuna palju keerulisem või tehniliselt problemaatilisem. Ja kahtlemata on projektis 'võõraid', kes tuvastatakse alles siis, kui nad esile kerkivad.

Lisaks ei ole kaks inimest ühesugused, olenemata sellest, kas olete klient, arendaja või kasutaja. Me oleme programmeeritud omaenda teadmiste, kogemuste, väärtuste, ootuste, suhtumise riskida ja kohanemisvõimega.

Kvaliteetse tarkvara kirjutamine on vaneminseneride leib ja või; Erakordsete tarkvaratoodete loomine võib olla kõigi asjaosaliste jaoks veelgi keerulisem ülesanne.

Muljetavaldav tarkvara edastamine on ka tasakaalustav tegevus.

Tarkvara osas on peamine mõista strateegiliste äriotsuste langetamise kestust ja maksumust ning see on tõde, kas loote uut ettevõtet, täidate uut ärivõimalust või võimaldate oma ettevõttel paremaid tulemusi saavutada. Ajastus, investeeringutasuvus ja saadav kasum võivad teie äri muuta, raputada või rikkuda. Avastate endalt küsimuse: mida me oma raha eest saame? Kas saame kulusid ennustada? Kui palju maksab soovitud toote loomine? Millal saame selle käivitada? Kas saame oma investeeringuks kvaliteetse toote? Kas see kasvab koos meie äriga? Kas see pakub ärilist väärtust?

Niisiis, kuidas saate hinnata projekti suurust, kestust ja maksumust? Uurime tarkvaraarenduse kulude hindamist kiires projektijuhtimises ja seda, kuidas me seda ApeeScape'is teeme.

Traditsiooniline lepinguline hind ja hinnang

Traditsiooniliselt on tarkvaraprojektid mitte-agiilseid tavasid kasutades püüdnud fikseerida funktsionaalsuse või ulatuse ning jätta muutujate hulka aeg ja kulu. See põhjustab probleeme:

1. Kuidas sa tead, et funktsionaalsus, millele sa projekti alguses keskendud, on tegelikult see, mis sinu äri või kliente kõige paremini teenib? Sagedamini kui kunagi varem muutub funktsionaalsus või ulatus, mistõttu kuuleme sageli „reguleerimisala korruptsioonist”, mis tuleneb soovitud vajaduste tuvastamisest kogu projekti elutsükli jooksul ja määramisest vastavalt vajadusele. või kohustuslik.

2. Kui kulu muutub muutujaks, kaotame kontrolli investeeringutasuvuse (ROI) üle, mida püüame saavutada. Kulude kasv on sageli tuvastamata riskide või muutuvate nõuete tulemus, mis tähendab, et peame lisama meeskonnaliikmed, et samal ajal rohkem tööd teha, või lahkuma meeskonnaliikmetest kauemaks. Kumbki pole soovitav.

3. Kui aeg on muutuv, kaotame kontrolli oma turupositsiooni üle. Võime kaotada olulise tarneaja või võivad konkurendid oma toote enne meid välja saada, kaotades nii meie toote võimaliku konkurentsieelise.

Aja ja kulu muutujatel on erinevad tulemused, mis on sageli ebasoovitavad ja negatiivsed.

Muidugi püüavad paljud kliendid ja organisatsioonid lahendada selle 'võlukolmnurga' kõik kolm komponenti. Kahjuks on selle realistlik saavutamine peaaegu võimatu. Selle ideaali ärritamiseks on liiga palju elemente, mis võiksid kaasa mõelda, mis lõpeb toodetega, mis ei vasta vajadusele, võtavad klientide kasuks liiga palju või on äriväärtuste realiseerimiseks liiga suured kulud.

Agile lepingud tarkvaraprojektide jaoks

Kulu on toode, mis tekib ajast ja inimestest (meeskonnaliikmetest). Lisage rohkem aega ja sinna lisanduvad kulud inimeste pikemaks palkamiseks. Kui lisate meeskonnaliikmeid, suurendate sama ettevõtte väärtuse pakkumise kulusid, mida me soovime vältida. Sellepärast usuvad Agile põhimõtted aja ja meeskonnaliikmete lahendamisse ning võimaldavad muutuvaks komponendiks ulatust.

Mis kõlab paremini ja suurendab sidusrühmade usaldust, püsikulusid või muutuvkulusid?

Ilmselt on oluline, et toode täidaks lubaduse ja kliendi vajadused. Pole hea investeerida rangelt aega ja raha, kui lõpuks on teil toode, mida keegi ei soovi ega saa tõhusalt kasutada.

Agile lepingud keskenduvad järgmisele:

• Fikseeritud hinnaga tööpaketid: Kogu projekt on jaotatud 'mini' loogilisteks versioonideks, mis aitavad kaasa toote üldisele tulemusele. Iga versioon on tööpakett, mille hind on vastavalt hinnatud. Kui tööpaketid on valmis, hinnatakse tulevased tööpaketid eelmise põhjal õpitu põhjal ümber. See väldib tarbetut juhuslikkust ja võimaldab kliendil määratleda prioriteetide ümberkorraldamise taseme ja uued / läbi vaadatud omadused.

• Eeldatav lõpetamine: See võimaldab kliendil projekti varem lõpule viia, kui on tarnitud suur protsent tootest, ja enam ei ole ROI-d saavutada, kui säilitada meeskond, kes annab ainult marginaalset kasumit. See klausel on üldjuhul lubatud igal ajal ja kehtib seni, kuni projekti meeskond ja klient on säilitanud tugeva, siira ja tiheda koostöösuhte. Kliendi eelis on see, et projekt lõpeb varem, olles andnud kõik toote teostatavaks muutmiseks vajalikud eelised. Vastutasuks makstakse tarnijale 20 protsenti lepingu järelejäänud väärtusest ja töötajate kinnipidamise oht kompenseeritakse.

• Paindlikud muudatused: Muutus on teema, mis läbib tarkvara Agile veenid. Loodame, et me ei tea kõike, kui peame tegema eduka toote nullist. Niisiis propageerime muutusi, tuginedes asjakohastele andmetele ja toote tagasisidele, et veenduda õige pakkumises. Korduse lõpus saab muudatused vahetada vanade funktsioonide vastu, mida enam ei peeta vajalikuks ega prioriteetseks, kui uus muudatus on võrdse väärtusega ja sellega ei kaasne lisakulusid. Kui muudatus on väiksema väärtusega, saab lisatööd tuvastada või teha mahajäämusest. See klausel kehtib seni, kuni projekti meeskond ja klient on kogu projekti vältel hoidnud siirast, tugevat ja tihedat koostöösuhet.

• Lisatöö: Kogu projekti elu jooksul saab tuvastada rohkem funktsioone, mida ei oleks juba hinnatud projekti raames võimalik saavutada. Seda stsenaariumi arvestades võib projekti lõppedes lisada mis tahes uue tööpaketi või keskenduda ajale ja materjalidele.

• Hinnangulised kaugused: Agile projekti lepingus saab prognoose kaugeks teha kahel viisil: kestusvahemik või funktsioonivahemik. Kestusintervalliga saab prognoosiga kindlaks teha, kas projekti paketi valmimine võtab aega 12–16 nädalat. Kestuse lisamine lisab aga kulusid, hoides projektimeeskonna liikmeid kauem või tähendab, et nad ei saa vabalt töötada teiste arendusprojektidega. ApeeScape'is eelistame mõõta funktsioone punkti ajaloos, hoides muutujana ulatust, kuid lubades pakkuda minimaalset kliendiväärtust tööpaketi või kogu projekti jaoks määratud aja jooksul.

Tasub meeles pidada, et tulevikus saate alati katvuse lisada. Võib-olla hakkasite saama sissetulekut, olete suurendanud kasutajate arvu ja vähendanud kulusid. Mõlemal juhul on palju lihtsam küsida rohkem raha ja aega, kui olete juba näidanud kasu või paranemist ja annate äriväärtust.

Keskendume tarkvarakuludele ja hinnakujundusele

ApeeScape'is teeme tihedat koostööd oma klientide ja inseneridega, et rakendada tehnikaid, mis suurendavad sidusrühmade usaldust projekti kestuse ja kulude suhtes. Töötame pidevalt välja ja kohandame planeerimist kõrgest algtasemest kõige täpsemate detailideni, kui see on asjakohane ja vajalik raiskamise vältimiseks ja hallatud muudatuste võimaldamiseks.

Projektide prognoosi ja fikseeritud hinna ettevalmistamiseks tehakse järgmised sammud:

üks. Kõrgel tasemel esialgne haare

Projekti alguses on selle võimalikest tulemustest vähe teada. Hull on varakult ette kujutada, milliseid funktsioone klient ja kasutajad võiksid soovida, nii et alustame projekti skeemist ja kõrgel tasemel „eepiliste” funktsioonide komplektist, mis juhivad projekti suunda, tuginedes visioonile ja ülevaatlikele eesmärkidele .

kuni. Visiooni ja eesmärkide kohandamine - Mida me peame ehitama? Mida peame saavutama ja millised on teie ärieesmärgid? Nende küsimuste mõistmine võimaldab meil kindlaks teha projekti ulatuse. Kas vajate esialgse idee, kontseptsiooni või tehnoloogia testimiseks prototüüpi? Kas olete tuvastanud selge pakkumise, mida on teie turul testitud, ja kas olete valmis oma esimest üles ehitama? Minimaalse elujõulise toote MVP )? Või võimendate oma olemasolevat ettevõtet või toodet, et see uuele tasemele viia?

b. 'Epic' funktsioonid - Kõrgel tasemel üksikasjadesse laskumata soovite määratleda omadused, millele teie toode peab vastama vastavalt teie kliendi vajadustele. Seda nimetatakse struktureeritud ostunimekirjaks, mis kirjeldab teie toote skeleti; neid nimetatakse tavaliselt 'kasutajalugudeks' või eeposteks.

c. MoSCow analüüs (MoSCoW analüüs) - See on tehnika, mis aitab lihtsalt tuvastada, mida on toote teostatavuseks tegelikult vaja ja mida on hea omada. See, mida määratletakse kui 'must', hõlmab seda, mis julgustab kasutajaid toodet kasutama ja seda kasutama. Funktsioonina määratletud funktsioonid peaksid üllatama ja rõõmustama teie kliente, kuid nendega saab hiljem tegeleda. Niinimetatud 'võiksid' üksused ei anna sageli olulist äriväärtust, ei pruugi kasumit suurendada ja on teie prioriteetide loendis vähe. 'Ei' või lihtsalt 'ära' omadused võivad ühel päeval olla olulised, kuid on projekti iteratsiooni jaoks käeulatusest väljas. Kõigi nende üksuste või omaduste tuvastamine võib siiski aidata kindlaks teha toote võimaliku ulatuse ja suuruse tulevikus.

Peaks, peaks, võiks, ei peaks

2. Ettepanek

Otsuse langetamiseks selle kohta, kas projektiga jätkata või mitte, on vaja selle otsuse aluseks võtta väljakujunenud andmed: maksumus ja kestus. See on vähim, mida peaksite endalt küsima: mida on vaja soovitud toote loomiseks? Millal saame selle käivitada? Kas see sobib meie äri- ja finantsstrateegiaga?

Mainitud üksikasjadega oleme võimelised ettepanekut esitama. Meie insenerid valitakse hoolikalt vastavalt projekti konkreetsetele nõuetele ja töötavad koos projektijuhiga, et saada vähemalt tehniline lahendus, hinnanguline kestus, mis ütleb meile teadaoleva ulatuse ja kulude hinnang projekti lõpuleviimiseks.

Nagu me varem mainisime, on projekti alguses see, kui me teame kõige vähem sellest, mida tarnitakse. Hoiame teadlikult funktsioone ja ulatust ebamäärases vormis, sest vastasel juhul näitaks see, et teame täpselt, mida on vaja. Hinnang selles etapis oleks ebatäpne, kuid see oleks juhend, kas jätkata projektiga või mitte.

Ettepanek on esimene vahend projekti kestuse ja maksumuse täpsustamiseks. Kui ettepanek on vastu võetud, võime jätkata ja pakkuda fikseeritud hinnapakkumist.

3. Käivitage planeerimine

Järgmine samm hindamisel on luua a vabastamiskava mis annab kindla ajavahemiku jooksul rea funktsioone. See tuletatakse omaduste loendist, projekti suurusest, sellest, kui kiiresti meie meeskond saaks kvaliteetset tarkvara vastavalt klientide ootustele ja ebakindluse riskijuhtimise tehnikatele arendada.

kuni. Toote mahajäämus: The toote mahajäämus see on lihtsalt järjestatud loend 'eepostest' või 'kasutajalugudest', mis tähistab toote nõutavaid funktsioone. See loend algab nagu eelpool loetletud eeposed, kuid projekti meeskonnale, projektijuhile ja kliendile määratud meeskonna vahel jagame need nüüd sisukamateks üksusteks. Kõik need üksused tähistavad osa äriväärtusest kliendi jaoks. Me ei süvene selles etapis täpsemalt, me ei pea teadma vastuvõtukriteeriume, me ei pea teadma, kas nupp on sinine või roheline, me peame teadma ainult seda, et on olemas nupp, mis võimaldab mõnel ülesandel läbi viia.

b. Hinnang - Nüüd, kui meil on kasutajate lugude põhjal välja toodud funktsioonide loend, hindab meeskond neid diskreetsete funktsioonide elemente, kasutades “Pokkeri planeerimise” tehnikat. See on kasulik tehnika, mis tagab eksperdi arvamusel ja analoogsel suurusel põhineva kiire ja usaldusväärse tulemuse. Pokkerikava määrab igale esemele kokkulepitud numbri, mis tähistab selle suurust ja keerukust. Seda nimetatakse jutupunktiks. Muud tehnikad Agile hinnang ja suuruse määramine, näiteks “Ideaalsed päevad” (ideaalsed päevad) on ka saadaval.

Selle protsessi lõpp määrab projekti suuruse ja funktsioonide vahelised sõltuvused. Suurus või mõõde määratakse, lisades kõik loo punktid toote mahajäämuse üksustest. Kui see arv on võrdne 120-ga, siis on meie projekti suurusel 120 lugu.

c. Prioriteet - Kui meil on projekti mahajäämus ja suurus, saame selle kliendiga prioriseerida. See seisneb selle väljaselgitamises, mis on kliendi jaoks kõige väärtuslikum soovitud tulemuste saamiseks. Loendi ülaosas olevat üksust peetakse kõige olulisemaks, teist üksust vähem tähtsaks ja nii kogu loendis. Kaks üksust ei saa olla üksteisele nii olulised, igal üksuse prioriteedil on teiste elementide suhtes oma suhteline tähtsus või väärtus.

Selline lähenemine prioriteetidele on tarkvaraprojekti kavandamisel oluline verstapost. Me teame, mis on kliendi jaoks oluline ja milline on tellimuse täitmise järjekord, võttes arvesse sõltuvusi, tarnimaks ootustele vastavat toodet.

d. Käivitamise planeerimine - Tänaseks oleme kindlaks teinud, milline oleks toode ja kui suur see oleks.

Nüüd on kindlaks määratud, kui kaua kulub teostatava toote tarnimiseks. Klient ja meeskond, sealhulgas disainerid, insenerid, testijad, scrum-meistrid ja projektijuhid teevad koostööd, et teha kindlaks, mida on võimalik saavutada ja kui kiiresti nad saaksid töötada väljalaskeplaani loomisel.

Käivitamiskava annab ka visiooni, kuidas projekt vastaks kliendi strateegilistele plaanidele.

Lõppkokkuvõttes tagab see plaan, et projektimeeskonnal on suunav valgus, mis valgustab teed ja määratleb arendamiseks loogilise lõpp-punkti.

Enne alustamist veendume, et mõistaksime „valmis“ kokkulepitud määratlust. See puudutab teatud kriteeriumide kogumit, mille klient aktsepteerib täidetuna ja vastab ka kõigile inseneride nõuetele, et neid saaks lugeda valmis ja teostatavaks.

Põhistsenaariumi käivitamiseks võtsime kogu mahajäämise suuruse põhjal saadud loo punktide koguarvu ja jagasime selle oma meeskonnale kiirus oodatud. (NB kiirust väljendatakse tavaliselt vahemikuna, kuid lihtsuse huvides kasutame arvu). Töötame kahenädalaste kordustena, nii et meie kiirust kajastaks see, mida on võimalik saavutada meeskonna kättesaadavusega kahe nädala jooksul.

Kui meie loo punktid on kokku 120 ja eeldame, et korduse kohta saab 20 punkti, oleks projekti arendamise kestus kokku 12 nädalat või kuus kordust. Lisage sellele 0–2-nädalane sprint ja 2-nädalane stardi ettevalmistussprint. Kokku on meie projekti kestus 16 nädalat. On tehnikaid, mida saame kasutada ja mis aitaksid luua meie kavandamiseks sobiva vahepealse riskiregulaatori, millest räägitakse hiljem. Kokkuvõtteks võib öelda, et puhvrit või regulaatorit kasutatakse ebakindluse riski ohjamiseks ja loodetavate loodepunktide osas kokkuleppele jõudmiseks. Tulemuseks võib olla vahemik 90–150 jutupunkti, 90 on miinimum, mis oleks vastuvõetav toimiva toote loomiseks.

Teise võimalusena, kui projekt peaks olema valmis teatud kuupäevaks, näiteks 10 nädala pärast, määraks meeskond kindlaks, kui palju mahajäämust saab sel ajal täita. Kui prognoosime 20 jooksupunkti ühe sprindi kohta, lisaks 0 sprinti ja avaldatud sprint, võtaksime eesmärgiks projekti lõpuks täita 60 punkti. Muidugi püütakse riski maandada sobiva puhvri lisamisega. Selle tulemuseks võib olla 45–75-korruseline eesmärk ja see on valmis avalikkusele avaldamiseks. 45 lugu on kooskõlas minimaalse vastuvõetavaga, et pakkuda elujõulist ja väärtuslikku toodet. See on olukord, kus võiksite kiiruse suurendamiseks vajadusel ette näha meeskonnaliikme lisamist.

Muidugi toetab kõike ülaltoodut kõigi osapoolte hea kvaliteediga suhtlus ja koostöö, et saada kliendi jaoks teostatav, realistlik ja usaldusväärne stardiplaan.

1. Fikseeritud hinnaga leping

Kui stardiplaan on kokku lepitud, saame koostada fikseeritud hinnaga lepinguprojekti eelarve. Nagu eespool mainitud, on soovitatav hoida projekti kestus ja meeskond fikseeritud ning ulatuse muutuja.

Fikseeritud hinnaga lepingu pakkumine esitatakse koos tööaruande ja maksegraafikuga.

Niikaua kui on olemas usaldus, suhtlus, koostöö ja tahe jõuda Agile tarkvaraprojekti vaimusse, võimaldavad kõik nimetatud sammud anda kvoodi realistliku kindlusega, et toode tarnitakse õigeaegselt ja eelarvest. Muidugi on olukordi, kus projekt toimetatakse varem või hiljem, kui on ette nähtud, seega tegeleme nende variatsioonidega suurima läbipaistvusega.

Hindamisvõtted

Vilgas kavandamine ja hindamine põhineb mitmel tehnikal, mida arendusmeeskond saab kasutada oma suuruse, pingutuse, kestuse ja maksumuse osas suurema kindluse saamiseks. Allpool on toodud mõned meetodid, mida meie meeskonnad tarkvaraprojekti suuruse ja maksumuse hindamiseks kasutavad.

Hinnake suurust

Projekti suurus on tegelikult selle ulatuse, keerukuse, mõõtmete, riski ja ulatuse hinnanguline hinnang. Selle analoogia oleks teada, kas ehitame Eiffeli torni või Hiina müüri. Eiffeli torn on kõrge, raske ja keeruline ehitis, mis ehitati väikeses linnakeskkonnas. Hiina müür on suhteliselt lihtne, kuid pikk ja vastupidav konstruktsioon, mis ulatub käänulisel maastikul mitu miili.

Ehkki mõlemad oleksid suured projektid, on nende ulatus, keerukus, mõõtmed, suurus ja seetõttu ka suurus.

Oluline on hallata ootusi hinnangutega. Need pole kunagi ennustused, kohustused ega garantiid. Suuruse, kestuse ja kogukulude arutamisel töötage alati vahemikus, et vähendada riski, ebakindlust ja tundmatust.

Toote omadusi kajastavatel lugudel on individuaalsed suurused ja hinnangud, kasutades lugude punkte või ideaalseid päevi. Nende üksuste koguarv määratleb projekti üldise suuruse.

Ajaloopunktid

Jutupunktid on mõõdik, mis tähistab kasutajaloo üldsuurust. Hinnanguliselt võib loo suurus hõlmata kõiki projekteerimise, projekteerimise, testimise, koodide ülevaatamise, integreerimise jms aspekte.

Iga loo suurus on teise loo suhtes. Näiteks saab lugu A mõõta 1 punktina, lugu B 2 punktina ja lugu C 3 punktina. Niisiis on lugu C vähemalt kolm korda suurem kui lugu A ja vähemalt pool lugu B-st.

Kui järgmistel toote mahajäämuse lugudel on seotud suurused:

mysql_set_charset

Ajalugu	Suurus
TO	üks
B	5
C	3
D	üks
ON	2

Projekti kogumaht on 12 lugu.

Ideaalsed päevad

See on päevades väljendatud suuruse mõõtmine. Kõrvaldage üldkulude mõiste, nagu katkestused, vilgas planeerimistegevus, meilide lugemine ja muud projektivälised tegevused. See keskendub lihtsalt sellele, kui kaua selle lõpuleviimine võtab aega, kui teete algusest lõpuni kulunud aja asemel pidevalt midagi segamatult tööd.

Tavaliselt, kui seda hinnatakse kõrgel tasemel, kus me teame projektist vähe, hinnatakse seda ideaalsetel päevadel, kuna varasema kogemuse ja ajalooga korreleerimine on lihtsam mõiste kui abstraktne arv, näiteks ajaloopunkt. Kui lood on kõrgel tasemel, on need eepilisemad, vähese detailsusega ja hiljem jagatuna tõenäoliselt täiendavate elementidega.

Täpsema hinnangu andmisel, näiteks loo väljakujunenud toote mahajäämusele, võib kasutada mis tahes lähenemisviisi ja insenerimeeskond otsustab, millist täpselt kasutada. Mõlemal lähenemisel on eeliseid ja igal meeskonnal on oma eelistused.

Hindamisvõtted

Jagatud hinnangud - Hinnanguid ei tehta eraldi. Need viiakse läbi kogu insenerimeeskonna koostöös ja need hõlmavad disaini, andmebaasi, serveri, kasutajaliidese (esiotsa kasutajaliidese), kvaliteedi tagamise (QA) ja teiste ekspertide funktsionaalsust. See väldib probleeme, mis puudutavad funktsiooni täitmiseks vajalike töö kõigi aspektide arvestamata jätmist, samuti tagatakse, et kellelgi pole kohustust või ebaõnne funktsiooni suurust alahinnata või mitte. Ühendatud meeskonnal on visioon, mille üle saab vaielda ja seejärel otsusega nõustuda.

Analoogsed hinnangud - Nende kahe diskreetse omaduse korral võetakse arvesse ja otsustatakse, et üks neist on suhteliselt väiksem või suurem kui teine. Võiksime vaadata lugu ja nõustuda, et see pole suur, ja kui kasutada jutupunkte, võiks see olla ka kaks. Järgmist lugu võiks pidada sama suureks kui esimest ja me annaksime selle suuruseks viis. See viitab sellele, et suur funktsioon võib olla kaks korda väiksem kui väike.

See harjutus oleks tehtud kõigi lugudega. Ja kui see on valmis, saame kõik oma lood, olgu need väikesed, keskmised, pikad ja eriti pikad, kõrvuti ja kontrollige suurust, veendumaks, et hinnangus on järjepidevus.

Pokkeri planeerimine - Pokkeri planeerimisest on palju räägitud; Mainisin seda teises ajaveeb (Ultimate Introduction to Agile Project Management) . Ja selle mõistmiseks on üks parimaid ressursse siin .

Põhimõtteliselt ühendab see ekspertarvamused, analoogia ja meeskonnatöö ühes lihtsas, kiires ja usaldusväärses protsessis.

See ühendab mitmeid eksperte, kes on kõige sobivamad tehnilise kogemuse ja valdkonna, dünaamilise dialoogi ja kindla põhjenduse põhjal hinnangu koostamiseks.

Kiirus

Kiirus on meeskonna võime teatud korduses (või sprindis) tööd lõpetada.

Seda väljendatakse vahemikus, näiteks 23–32 lugu punkti sprindi kohta, eriti projekti alguses. Üldiselt on see tingitud sellest, et kui sama meeskond ei lahenda sarnast probleemi, on raske kindlaks teha, milline oleks meeskonna kiirus. Pange tähele, et me peame silmas meeskonna, mitte üksiku kiirust.

Kiirust kasutatakse väljalaske kavandamiseks ning tööplaanide ja pakettide kohandamiseks projekti edenedes, mis võimaldab meie vastavuse eeldust korrapäraselt ja täpselt kogu teostuse vältel kohandada.

Alustades oleme sunnitud määrama väheste andmetega kiirusvahemiku. Ajaloolisi väärtusi saab kasutada, kui seadmed ja probleempiirkond on samad, mis pole tõenäoline. Projektis töötava meeskonnaga on võimalik kordamiseks kiiruse tunnet teha, kuid see on kallis ja ei toimi, kui projekti alustamise osas tehakse endiselt otsuseid. Samuti võiks koostada prognoosi.

Kiiruse prognoosimine hõlmab mitme loo sprindi võtmist ja nende jagamist ülesanneteks, mida loo lõpuleviimiseks täidetakse. Hinnanguliselt hinnatakse tundide arvu iga ülesande jaoks, mis hõlmab muu hulgas ka disaini, arendustööd, testimist ja hindab võistkonna suutlikkust antud sprindis. Pühendunud meeskonna 70% võimekus on hea alus. Sel põhjusel on näiteks lihtsas olukorras meeskonna saadaolevate tundide koguarv näiteks:

• 4 meeskonnaliiget * 2 nädalat * 40 tundi nädalas = 320 tundi
• Korrutatud 70% mahutavusega = 224 tundi
• Lisage kõik funktsiooniga seotud ülesanded ja lõpetage 224 lugemine
• Võtke kõik lõpule viidud funktsioonid, lisage jutupunktid kokku ja saate kiiruse, ütleme 36
• Määra 20% mõlemalt poolt, et reastada madalaim ja kõrgeim, et saavutada hinnanguline kiirus 29–43 lugu

Kiirus varieerub tavaliselt esimeses 2–4 korduses ja stabiliseerub seejärel väikeses punktivahemikus. Seetõttu on esialgne vahemik enne, kui esimene sprint oli 29–43, sprindini 4 jõudes võib see stabiliseeruda 34-lt 38-le. Mis annab meile suurema kindluse finišikuupäeva prognoosi suhtes.

Puhverplaanid riski ja ebakindluse jaoks

Kõigi tarkvaraprojektidega kaasneb ebakindluse tase. See ebakindlus väheneb projekti edenedes ning tehnoloogia, keskkonna, jõudluse ning klientide ja kasutajate vajaduste kohta on rohkem teada.

Seda ebakindlust vähendatakse programmeerimise puhvri või regulaatori abil, mida esindab hinnangu veamarginaal ja tundmatused, mida ei saa enne arenduse algust kindlaks teha.

Tavaliselt on kahte tüüpi puhvreid: iseloomulik ja programmeerimine. Kuna määrate alati kindlaksmääratud kohaletoimetamise kuupäeva jaoks fikseeritud hinna, on eelistatav kasutada iseloomulikku puhvrit.

See lähenemisviis pakub usaldusväärset riskide maandamise strateegiat ja annab kliendile enesekindluse seoses projekti elluviimisega või sellega, mida nad projekti lõpus näevad.

Funktsioonipuhvrid

Funktsioonipuhvriga ennustatakse, et teatud funktsioonide komplekt edastatakse, kuid teine ​​funktsioonide komplekt valmib hiljem. See peaks näitama minimaalseid funktsioone, mida klient peab teostatava toote turule toomiseks vajalikuks, kuid antud aja jooksul võiks neid pakkuda rohkem, kui erinevad sisemised ja välised mõjud seda võimaldavad.

Seega võib klient otsustada, et toote mahajäämuse kõige olulisemad funktsioonid, kokku kuni 100 loo punkti, on olulisemad. Seejärel võiks klient kaaluda lisafunktsioone, mis lisavad veel 30 lugu. Sel juhul plaanib meeskond edastada 130 lugu, millest vähemalt 100 on fikseeritud hinnaga lepingu kuupäeva lõpuks täidetud.

Lõpumõtted

Agile mõistet saab mõista ja kohandada. Mis pole vähem tõsi tundlike probleemide nagu hind, ulatus ja kestus käsitlemisel. Kahjuks tean, et nõudlikud kliendid soovivad, et kõik saaks kohe korda ja tavaliselt süüdistavad nad tarnijat, kui kõik hakkab lagunema. Samamoodi olen teadlik, et mõned müügimehed, kellele ei meeldi kompromissid teha, on tundetud ega reageeri klientide vajadustele. Otsustades valida agiilse metoodika tee, on oluline usaldus, head suhted ja suurepärane suhtlus. Mõlemad pooled peavad neid väärtusi toetama, et säilitada tervislik projekt, millest on kasu mõlemale ning mis pakub kõigile rahulolu ja edu. Koostöös ja läbirääkimistes peate hoidma avatud meelt ja konstruktiivset suhtumist, see on parim viis suhete lagunemise vältimiseks.

Mõnikord on mõnel kliendil keeruline kohaneda agiilse metoodika adaptiivse olemusega ning jätta kontrolli ja käsu suhtumine. Pole lihtne panna kogu oma usk ja usaldus meeskonda, mida te ei tunne. Enamasti soovivad kliendid kõik nõuded eelnevalt koostada, täpsustades, mida nad loodavad tarnimisel saada. See jätab neile kindla mulje, et projekti ulatus on hästi määratletud. Kuid lõppkokkuvõttes ei realiseeru see hea lähenemisena. Kui ulatus ja nõuded pole reaalsed ja nendega tuleb lepingu tõttu töötada, tekivad kiiresti paljud probleemid.

On teada, et seda lähenemist traditsioonilistes meetodites kasutades võib rakendusala muutuda, tundmatud ilmneda või see, mida klient arvas soovivat, ei vasta enam tõele või on täiesti erinev. Kohanduv lähenemine hinnakujundusele, planeerimisele ja ulatusele võimaldab kliendil teie toote tuvastada, nii et see on just see, mida teie soovitud turg vajab. See võimaldab pakkujal olla reageeriv, fantaasiarikas ja tõhus. Kliendi ja müüja koostöö võimendamine lepinguläbirääkimistel on võtmetähtsusega.

Müüjad peavad olema ausad ja kliendid peavad olema realistlikud, et mida saaks saavutada. Müüja, kes annab eesmärkide kohta ebareaalseid lubadusi ja seejärel suurendab kulusid, võib küll lepingu võita, kuid peagi on tema käes rahulolematu klient. Suhted lagunevad sageli mõlema poole usalduse puudumise tõttu. Usaldus tuleb üles ehitada algusest peale ja säilitada kogu projekti vältel. Müüja peab olema paindlik ja tegema vajaduse korral koostööd. Kliendid tahavad alati rohkem; See on äri ajamise loomulik tagajärg. Väärtuste vahetus peab olema võrdne, millest on kasu mõlemale. Kliendid püüavad oma ettevõttele väärtust luua. Müüjad peaksid proovima luua väärtust, mis võimaldab neil oma klientidega pikki suhteid luua. Nii agiilsete väärtuste manifesti kui ka selle põhimõtete uurimine on kindel alus pika, tugeva ja tasakaalustatud suhte loomiseks.

järeldus

Loodetavasti andis see teile idee tarkvaraprojekti kavandamisest, hindamisest ja hindade määramisest Vilgas . Kõik siin kirjeldatud lähenemised ja tehnikad olid loodud meeskonna usalduse suurendamiseks ja klientide usalduse suurendamiseks selle suhtes, kui kaua tarkvaratoode püsib ja selle ehitamine maksab. Lõpuks suurendage usaldust, kui on vaja jätkata otsust.

Järgige neid juhendeid ja leiate kindlasti rahuldava tee järgmise tarkvaratoote ellu äratamiseks.