Sissejuhatus

Üks tarkvaraarenduse raskemaid asju on teha kindlaks, kui kaua ja kui palju uue tarkvaratoote tarnimine võtab. Kas see peaks olema nii raske? Vastus pole selge.

Tarkvarakulude hindamine on oma olemuselt keeruline ja inimesed oskavad absoluutseid tulemusi ennustada kohutavalt halvasti. Ei ole kahte ühesugust projekti; kumbki on ainulaadne selles, mida ta kavatseb saavutada, ja kordumatu arvukates parameetrites, mis moodustavad tema olemasolu. Sageli on see, mis näib pinnal olevat lihtne probleem, reaalsuses palju raskem või tehniliselt keerulisem. Ja kahtlemata on projektiga ka „tundmatuid“, keda saab tuvastada alles siis, kui need tekivad.

Lisaks pole kaht ühesugust inimest, olenemata sellest, kas olete klient, arendaja või kasutaja. Eelnevalt laadime oma teadmiste, kogemuste, väärtuste, ootuste, suhtumise riskidesse ja kohanemisvõime.

Hea kvaliteediga tarkvara kirjutamine on vaneminseneridele leib ja või; vingete tarkvaratoodete loomine võib olla kõigile asjaosalistele palju raskem ettevõtmine.

Awesome tarkvara tarnimine on tasakaalustav seadus Piiksuma

Tarkvara osas on strateegiliste äriotsuste tegemisel võtmetähtsus kestuse ja kulude mõistmisel ning see kehtib nii alustava ettevõtte loomisel, uue ärivõimaluse realiseerimisel kui ka ettevõtte paremal toimimisel. Ajastus, investeeringutasuvus ja saadav kasu võivad teie äri muuta, raputada või rikkuda. Te küsite endalt: mida me oma raha eest saame? Kas me saame oma kulusid ennustada? Mis maksab soovitud toote loomine? Millal saame käivitada? Kas saame oma investeeringuks kvaliteetse toote? Kas see kasvab koos meie äriga? Kas see annab äriväärtust?

Kuidas siis projekti suurust, kestust ja maksumust hinnata? Uurime Agile projekti hindamise ja tarkvaraarenduse kulusid ning seda, kuidas me seda ApeeScape'is teeme.

Traditsiooniline lepinguline hinnakujundus ja hindamine

Tavapäraselt on tarkvaraprojektid mitte-agiilseid tavasid kasutades püüdnud fikseerida funktsionaalsust või ulatust ning lasta aja ja kulude muutujaks. See põhjustab probleeme:

1. Kuidas teada saada, et funktsionaalsus, mille projekti alguses fikseerite, on tõesti see, mis teie ettevõtet või kliente kõige paremini teenib? Sageli muutub funktsionaalsus või ulatus, mistõttu kuuleme „ulatuse libisemisest”, kus soovitud vajaduste tulemus tuvastatakse projekti elutsükli jooksul ja määratakse vajalikuks või kohustuslikuks

2. Kui kulu muutub muutujaks, kaotame kontrolli investeeringutasuvuse (ROI) üle, mida soovime saavutada. Suurenenud kulu on sageli tuvastamata riskide või muutuvate nõuete tulemus, mis tähendab, et peame lisama meeskonnaliikmed, et teha rohkem tööd samal ajavahemikul või hoida meeskonnaliikmeid kauem. Kumbki pole soovitav

   
   
   

3. Kui aeg on muutuv, kaotame kontrolli oma turupositsiooni üle. Võib-olla jätame olulise tööstusharu kuupäeva vahele või kui meie konkurendid saavad toote enne meid välja, kaotades seeläbi igasuguse meie projekti võimaliku konkurentsieelise.

Muutuva aja ja kuluga on palju muid tulemusi, mis on sageli negatiivsed ja ebasoovitavad.

Muidugi püüavad paljud kliendid ja organisatsioonid selle „võlukolmnurga” kõiki kolme komponenti parandada. Kahjuks on võimatu reaalselt saavutada. Selle ideaali rahustamiseks on liiga palju elemente, mis lõppevad lõpuks toodetega, mis ei vasta vajadustele, võtavad liiga kaua aega klientidele kasuks või maksavad liiga palju ettevõtte väärtuse realiseerimiseks.

Agile lepingud tarkvaraprojektide jaoks

Maksumus on aja ja inimeste (meeskonnaliikmete) korrutis. Lisage rohkem aega ja lisate kulusid inimeste pikemaks tööhõiveks. Kui lisate meeskonnaliikmeid, suurendate sama ettevõtte väärtuse pakkumise kulusid. Asjad, mida me tõesti tahame vältida. Sellepärast usuvad Agile põhimõtted aja ja meeskonnaliikmete fikseerimises ning muutuva komponendi ulatuse lubamises.

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

Muidugi on oluline, et toode täidaks oma lubadusi ja klientide vajadusi. Ei ole hea kulutada täpset aega ja täpset rahasummat, kui lõpuks on teil mõni toode, mida keegi ei soovi ega saa tõhusalt kasutada.

Niisiis keskenduvad agiilsed lepingud järgmisele:

kuidas ruby ​​on rails töötab

• Fikseeritud hinnaga tööpaketid - Kogu projekt on jaotatud loogilisteks mini-väljaanneteks, mis aitavad kaasa toote täielikule tulemusele. Iga väljaanne on tööpakett, mille hind on vastavalt hinnatud. Kui tööpakett on valmis, hinnatakse tulevased tööpaketid eelmise põhjal õpitu põhjal ümber. See väldib tarbetut juhuslikkust ja võimaldab kliendil määrata prioriteetide määramise taseme ning uued / muudetud funktsioonid.

• Ennetähtaegne lõpetamine - See võimaldab kliendil püüda projekt varakult lõpetada, kui toodet on tarnitud piisavalt ja investeeringutasuvust ei ole võimalik saavutada, säilitades projektimeeskonna, kes jätkab vaid marginaalset kasumit. See klausel on tavaliselt lubatud igal ajal ja kehtib seni, kuni projektimeeskond ja klient on säilitanud tugeva, usaldusväärse ja tiheda koostöösuhte. Kliendi eelis on see, et projekt lõpeb varakult, olles andnud kõik toote elujõuliseks muutmiseks vajalikud väärtuslikud omadused. Vastutasuks makstakse tarnijale 20 protsenti lepingu järelejäänud väärtusest ja see korvab töötajate säilitamise riski.

• Paindlikud muudatused - Muutus on teema, mis jookseb tugevalt läbi Agile tarkvara edastamise. Eeldame, et me ei tea algusest peale kõike, mida vajame toote edukaks muutmiseks. Niisiis propageerime asjakohaste andmete ja tagasiside põhjal muudatusi, et tagada õige toote tarnimine. Korduse lõpus saab muudatused vahetada vanade funktsioonide vastu, mida ei peeta enam vajalikuks või prioriteetseks. Kuni muudatus on võrdse väärtusega, ei ole täiendavaid kulusid. Kui muudatus on väiksema väärtusega, saab järelejäänud mahajäämusest lisatööd tuvastada või edasi tõmmata. See klausel kehtib seni, kuni projekti meeskond ja klient on kogu projekti vältel hoidnud tugevat, usaldavat ja tihedat koostööd.

• Lisatöö - Projekti elu jooksul võib tuvastada rohkem funktsioone, mida olemasoleva fikseeritud hinnaga lepingu alusel ei oleks võimalik saavutada. Selle stsenaariumi korral võib projekti lõppu lisada kas täiendavaid äsjahinnatud tööpakette või naasta aja ja materjalide juurde.

• Erinevad hinnangud - Agile projekti lepingus saab hinnanguid varieerida kahel viisil: kestuse vahemik või funktsioonide vahemik. Kestusevahemik võimaldab hinnanguliselt öelda, et projekt või tööpakett võtab antud ulatuse jaoks 12–16 nädalat. Kestuse lisamine lisab aga kulusid, kuna hoiate projektimeeskonna liikmeid kauem või see tähendab, et neid ei saa vabastada teiste arendusprojektidega töötamiseks. ApeeScape'is eelistame funktsioonide valikut erinevates jutupunktides, hoides ulatust muutujana, kuid lubades pakkuda kliendile minimaalset väärtust tööpaketi või kogu projekti kindla aja jooksul.

Tasub meeles pidada, et saate hiljem alati suurema ulatuse lisada. Võib-olla olete hakanud tulu teenima, olete suurendanud kasutajaid või vähendanud kulusid. Mõlemal juhul on palju lihtsam küsida rohkem raha ja aega, kui olete juba näidanud tootlust või paranemist ja annate äriväärtust.

Meie lähenemine 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 planeerimise pideva väljatöötamise ja kohandamise abil algselt kõrgel tasemel üksikasjalikumate detailideni, kui see on asjakohane ja vajalik jäätmete vältimiseks ja hallatud muudatuste võimaldamiseks.

Hinnangulise ja fikseeritud hinnaga projekti väljatöötamisel tehakse järgmised sammud:

1. Esialgne kõrgetasemeline ulatus

Projekti alguses teame kõige vähem selle lõplikust tulemusest. On rumal ette kujutada, et on võimalik täpselt teada, milliseid funktsioone meie kliendid ja kasutajad algusest peale vajavad.

Alustame projekti hartast ja kõrgel tasemel „eepiliste” funktsioonide komplektist, mis juhivad projekti suunda, tuginedes kindlale visioonile ja eesmärkidele

kuni. Visiooni ja eesmärgi seadmine Mida peame ehitama? Mida peate saavutama ja millised on teie ärieesmärgid? Nende küsimuste mõistmine võimaldab meil määrata 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 ehitama oma esimese minimaalse elujõulise toote ( MVP )? Või laiendate oma olemasolevat ettevõtet või toodet, et viia see uuele tasemele?

b. Kõrgtasemel „eepiline” funktsioon Liiga detailidesse laskumata soovite määratleda funktsioonid, mida teie toode peab teie kliendi vajadustele vastama. See on struktureeritud ostunimekiri, mis kirjeldab teie toote paljaid luid; sageli nimetatakse neid Kasutaja lood ”Ehk eeposed

c. MoSCoW analüüs MoSCoW analüüs on tehnika, mis lihtsustatult aitab tuvastada, mis on toote elujõuliseks muutmiseks tegelikult vajalik ja mida on tore omada. Need, mis on määratletud kui „must”, rahuldavad seda, mis julgustab kasutajaid teie toodet kasutama ja seda kasutusele võtma. Need funktsioonid, mis on määratletud kui „Peaks“, üllatavad ja rõõmustavad teie kliente, kuid neid saab hiljem luua. Üksused „Võiksid” ei anna sageli olulist äriväärtust, ei pruugi tootlust suurendada ja on teie prioriteetidest kõige madalamad. Funktsioonid 'Ei tee' võivad ühel päeval olla olulised, kuid jäävad selle projekti korduse ulatusest välja. Kuid nende tuvastamine võib aidata meeles pidada toote potentsiaalset ulatust ja suurust tulevikus.

2. Ettepanek

Projektiga jätkamise otsustamiseks on vaja lähtuda hästi informeeritud andmetest: maksumus ja kestus. Need on miinimumid, mida peate endalt küsima: mida on vaja soovitud toote loomiseks? Millal saame käivitada? Kas see sobib meie äristrateegia ja finantsidega?

Ülaltoodud üksikasjadega oleme võimelised ettepanekut esitama. Meie insenerid valitakse konkreetsete projektinõuete järgi ja töötavad koos projektijuhiga, et saada vähemalt üks tehniline lahendus, eeldatav kestus, mis annab teadaoleva ulatuse, ja hinnangulised kulud projekti lõpuleviimiseks.

Nagu me varem mainisime, teame projekti alguses kõige vähem seda, mida tarnitakse. Hoiame teadlikult funktsioone ja ulatust ebamäärasena, kuna muul juhul soovitame täpselt teada, mida on vaja. Hinnang selles etapis oleks kõige vähem täpne, kuid annab juhiseid selle kohta, kas tasub projektiga jätkata.

Ettepanek on esimene vahend projekti kestuse ja maksumuse väljatöötamisel. Kui ettepanek on vastu võetud, saame edasi liikuda ja pakkuda fikseeritud hinnaga pakkumist.

3. Vabastamise planeerimine

Hinnangu väljatöötamise järgmine tase on luua a vabastamiskava mis pakub etteantud aja jooksul erinevaid funktsioone. Selle tuletame funktsioonide loendist, projekti suurusest, sellest, kui kiiresti suudab meie meeskond välja töötada kvaliteetse tarkvara, mis vastab kliendi ootustele ja tehnikatele ebakindluse riski maandamiseks.

kuni. Toote mahajäämus The toote mahajäämus on lihtsalt tellitud loend „Eepostest” või „Kasutajate lood”, mis tähistab toote jaoks vajalikke funktsioone. See loetelu alustab elu varem käsitletud eeposena, kuid määratud projekti meeskonna, projektijuhi ja kliendi vahel jagame need nüüd sisukamateks osadeks. Iga üksus esindab osa ettevõtte väärtusest kliendi jaoks. Me ei lähe selles etapis üksikasjalikumalt, me ei pea teadma aktsepteerimise kriteeriume, me ei pea teadma, kas nupp on sinine või roheline, me peame lihtsalt teadma, et seal on nupp, mis võimaldab mõnda ülesannet tuleb täita.

b. Hinnang Nüüd, kui meil on oma funktsioonide loend, mida kirjeldatakse kasutajalugudena, hindab meeskond neid eraldiseisvaid funktsioone, kasutades tehnikat nimega 'Pokkeri planeerimine'. See on kasulik tehnika, mis tagab eksperdi arvamusel ja analoogsel suurusel põhineva kiire ja usaldusväärse tulemuse. Planning Poker määrab igale üksusele kokkulepitud numbri, mis tähistab selle suurust ja keerukust. Seda nimetatakse jutupunktiks. Muu Agile hinnang tehnikat ja suurust, näiteks ideaalsed päevad ”On saadaval.

Selle protsessi lõpp määrab projekti suuruse ja funktsioonide vahelised sõltuvused. Suurus määratakse, kui liidetakse kõik toote mahajäämuse üksustest pärit jutupunktid. Kui see arv võrdub 120-ga, siis on meie projekti suurus 120-korruseline.

c. Prioriteetide seadmine Nüüd, kui meil on projekti mahajäämus ja suurus, saame selle kliendiga esmatähtsaks pidada. See seisneb tegelikult selle väljaselgitamises, mis on kliendi jaoks kõige väärtuslikum, et saavutada soovitud tulemusi. Loendi ülaosas olevat üksust peetakse kõige olulisemaks, teist üksust vähem oluliseks ja nii edasi loendi kaudu. Ükski üksus ei saa olla sama oluline kui teine, iga üksuse prioriteet on kõigi teiste üksuste jaoks suhteliselt oluline või väärtuslik.

Selline lähenemine prioriteetide seadmisele on tarkvaraprojekti kavandamisel oluline verstapost. Nüüd teame, mis on kliendi jaoks oluline ja millises järjekorras töö lõpule viia, hoolides sõltuvustest, tarnida ootustele vastav toode.

d. Väljalaske planeerimine Tänaseks oleme kindlaks teinud, milline toode meie arvates on ja kui suur see on.

Nüüd määrame kindlaks, kui kaua võtab vabastatava toote tarnimine aega. Klient ja meeskond, sealhulgas disainerid, insenerid, testijad, scrum master ja projektijuht, teevad koostööd, et teha kindlaks, mida on võimalik saavutada ja kui kiiresti saab väljalaskeplaani koostamiseks tööd teha.

Väljaandmiskava annab ülevaate ka sellest, kuidas projekt kliendi strateegiliste plaanidega sobitub.

Ja lõpuks tagab see plaan, et projekti meeskonnal on suunav valgus, mis juhatab teed ja määratleb arengu loogilise lõpp-punkti.

Enne alustamist veendume, et mõistame „valmis“ kokkulepitud määratlust. See on etteantud kriteeriumide kogum, mille klient aktsepteerib kui täielikku ja vastab ka kõigile insenerinõuetele, et neid saaks vabastada.

Põhistsenaariumi võtmiseks võtame kogu mahajäämuse suuruse põhjal saadud loo punktide koguarvu ja jagame selle meie eeldatavate meeskondade kaupa kiirus . (NB-kiirust väljendatakse tavaliselt vahemikuna, kuid lihtsuse huvides kasutame siin ühte numbrit.) Töötame kahenädalases korduses, nii et meie kiirust kajastab see, kui palju suudame saadaoleva kahenädalase tsükli jooksul täita meeskonna suutlikkus. Kui meie loo punktid olid kokku 120 ja eeldame, et ühe iteratsiooni kohta saab 20 punkti, oleks arenduse kogukestus 12 nädalat ehk 6 iteratsiooni. Lisame sellele sprindi 0 kahest nädalast ja vabastamise ettevalmistuse sprindi kahest nädalast. Kokku on meie projekti pikkus 16 nädalat. On tehnikaid, mida saame kasutada, mis aitaksid meie planeerimisel luua sobiva riskipuhvri, mida arutame hiljem. Lühidalt öeldes kasutame puhvrit ebakindluse riski maandamiseks ja oodatavate loo punktide miinimumkokkuleppele jõudmiseks. Tulemuseks võib olla vahemik 90–150 jutupunkti, millest 90 on miinimum, mis oleks vastuvõetav elujõulise toote loomiseks.

Teise võimalusena, kui projekt peab olema lõpule viidud määratud kuupäevaks, näiteks 10 nädala jooksul, määrab meeskond kindlaks, kui palju mahajäämust selle aja jooksul täita saab. Kui prognoosime 20 jutupunkti sprindi kohta, lisaks Sprint 0 ja vabasprint, oleksime sihtinud 60 punkti, mis on projekti lõpuks täidetud. Jällegi sooviksime riski maandada sobiva puhvri lisamisega, mille tulemuseks võib olla 45–75 loo punkti täitmine ja vabastamiseks valmis sihtmärk. 45 lugu on kooskõlas minimaalse vastuvõetavaga, et pakkuda elujõulist ja väärtuslikku toodet. See on üks stsenaarium, kus võite eeldada kiiruse suurendamiseks meeskonna liikme lisamist, kui see on asjakohane.

Muidugi toetab kõike ülaltoodut kõigi osapoolte hea kvaliteediga suhtlus ja koostöö, et saada kliendile saavutatav, realistlik ja vastuvõetav vabastamiskava.

4. Fikseeritud hinnaga leping

Kui väljalaskeplaan on kokku lepitud, saame luua fikseeritud hinnaga projekti lepingu pakkumise. Nagu varem mainitud, on soovitatav hoida projekti kestus ja meeskond fikseeritud ning ulatuse muutuja.

Fikseeritud hinnaga lepingu pakkumine edastatakse koos tööaruande ja kokkulepitud maksegraafikuga.

Niikaua kui on olemas Agile tarkvaraprojekti usaldus, suhtlus, koostöö ja valmisolek vaimu sisse viia, võimaldavad kõik ülaltoodud toimingud meil pakkuda realistlikult kindla hinnapakkumise, et projekt toimetatakse õigeaegselt ja eelarvest. Muidugi võib juhtuda, et projekt esitatakse varakult või hilja ning me tegeleme nende variatsioonidega ülima läbipaistvusega.

Tehniline hinnang

Agiilset planeerimist ja hindamist toetavad mitmed tehnikad, mida arendustiim saab kasutada oma suuruse, pingutuste, kestuse ja kulude suhtes enesekindluse saavutamiseks. Siin on mõned neist, mida meie meeskonnad tarkvaraprojekti suuruse ja maksumuse hindamiseks kasutavad.

Suuruse hindamine

Projekti suurus on tõepoolest selle ulatuse, keerukuse, mõõtmete, riski ja ulatuse hindamine. Analoogia põhjal tähendab see mõistmist, kas ehitame Eiffeli torni või Hiina müüri. Eiffeli torn on kõrge, raske ja keeruline ehitis, mis on ehitatud tihedasse linnakeskkonda. Hiina müür on suhteliselt lihtne, kuid pikk ja vastupidav konstruktsioon, mis hõlmab palju miile lainetavat maastikku.

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

Oluline on hallata ootusi hinnangutega. Need pole kunagi ennustused, kohustused ega garantiid. Kogumahu, kogukestuse ja kogukulude arutamisel töötame alati vahemike piires, et leevendada riski, ebakindlust ja tundmatust.

Teie toote omadusi kajastavad lood on individuaalselt suurustatud ja nende hindamiseks kasutatakse jutupunkte või ideaalseid päevi. Nende üksuste koguarv määratleb projekti kogu suuruse.

Jutupunktid

Jutupunktid on mõõtühik, mis väljendab kasutajaloo üldsuurust. Hinnanguliselt hõlmab loo suurus kõiki projekteerimise, projekteerimise, testimise, koodide ülevaatamise, integreerimise jms aspekte.

Iga loo suurus on teise loo suhtes. Nii võib näiteks lugu A olla ühe punktiga, lugu B kahe punktiga ja lugu C kolme punktiga. Siin on lugu C vähemalt kolm korda suurem kui lugu A ja jälle vähemalt poole suurem kui lugu B.

Kui meie toodete mahajäämuse järgmistel lugudel on seotud suurused:

Lugu	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õõt. Sellega eemaldatakse üldkulude mõiste, nagu katkestused, vilgas planeerimistegevus, meilide lugemine ja muud projektivälised tegevused. See keskendub ainult sellele, kui kaua kuluks, kui peaksite pidevalt segamatult midagi kallal töötama, mitte algusest lõpuni kulunud ajani.

Tavaliselt, kui prognoosime kõrgel tasemel, kui me projektist kõige vähem teame, hindaksime seda ideaalsetel päevadel, kuna see on lihtsam mineviku ajaloo ja kogemustega korreleeritav mõiste kui abstraktne arv, näiteks jutupunkt. Eriti kui kõrgel tasemel lood on oma olemuselt rohkem eeposed, vähe üksikasjalikke ja sisaldavad hiljem võib-olla jaotatuna täiendavaid elemente.

Täpsema hinnangu andmisel öelge mõni lugu väljakujunenud toote mahajäämuses, võib kasutada mõlemat lähenemist ja selle otsustab insenerimeeskond. Mõlemal lähenemisel on eeliseid ja iga meeskond saab oma eelistuse.

Hindamise tehnikad

Jagatud hinnangud Hinnanguid ei tehta eraldi. Neid teostab koostöös kogu inseneride meeskond koos ja need hõlmavad disaini, andmebaasi, serveri, esiotsa kasutajaliidese, kvaliteedi tagamise ja muid funktsionaalseid funktsioone. See väldib probleeme, mis kaasnevad töö kõigi aspektide mittearvestamisega funktsiooni lõpuleviimiseks, ja tagab, et ühelgi inimesel pole koormust või ebaõnne tunnuse suuruse üle või alahindamisest. Ühendatud meeskonnal on kõigil seisukoht, mida saab arutada ja kokku leppida.

Analoogsed hinnangud Siinkohal kaalume kahte diskreetset tunnust ja otsustame, et üks on teisest suhteliselt väiksem või suurem. Saame antud lugu vaadata ja nõustuda, et see on väikese suurusega, ja kui kasutada jutupunkte, võime selle anda kaheks. Järgmist lugu võib pidada esimesega võrreldes suureks ja me annaksime selle suuruseks viis. See viitab sellele, et suur on vähemalt kaks korda väiksem kui väike funktsioon.

Jätkaksime seda harjutust kõigi lugudega. Kui see on lõpule jõudnud, saame seejärel paigutada kõik väikesed, keskmised, suured ja eriti suured lood kõrvuti ja kontrollida meie suurust, et tagada meie hinnangu ühetaolisus.

Pokkeri planeerimine Pokkeri planeerimisest on palju kirjutatud; Mainisin seda ka oma eelmises Ajaveeb . Üks parimatest ressurssidest selle mõistmiseks on siin .

Sisuliselt ühendab see ekspertarvamused, analoogia ja meeskonna koostöö üheks lihtsaks, kiireks ja usaldusväärseks protsessiks.

See ühendab mitu eksperti, kes sobivad kõige paremini tehnilise ja valdkondliku kogemuse, elava dialoogi ja usaldusväärse põhjenduse põhjal hinnangu koostamiseks.

Kiirus

Kiirus on meeskonna võime mõõta tööd antud iteratsioonis (või sprindis).

Seda väljendatakse vahemikus, näiteks 23–32 lugu punkti sprindi kohta, eriti projekti alguses. Üldiselt on see tingitud sellest, et kui sama meeskond pole varem sama probleemiga tegelenud, on raske täpselt kirjeldada meeskonna kiirust. Pange tähele, me peame silmas meeskonna, mitte üksiku kiirust!

Kasutame kiirust väljalaskete kavandamiseks ning oma plaanide ja tööpakettide kohandamiseks projekti edenedes, võimaldades meil korrigeerida oma valmimisprognoosi regulaarselt ja täpselt teostamise kaudu.

Alustades oleme sunnitud määrama väga väheste andmetega kiirusvahemiku. Ajaloolisi väärtusi saame kasutada, kui meeskond ja probleemiruum on ühesugused, mis on sageli kõige vähem tõenäoline. Me võime käivitada iteratsiooni, et saada kiirusega ettekujutus meeskonnalt, kes tegelikult töötab projektiga, kuid see on kulukas ja ei toimi, kui projekti alustamise nõusoleku osas tuleb veel otsustada. Või võime koostada prognoosi.

Kiiruse prognoosimine hõlmab sprindi väärtuses lugude võtmist ja nende jagamist ülesanneteks, mida loo lõpuleviimiseks täidetakse. Me hindaksime tundide arvu, mida iga ülesanne võtab, mis hõlmab disaini, arendust, testimist ja muud, ning hindaksime, kui palju meeskonnal oleks antud sprindis võimsust. 70-protsendiline koormus koormamata meeskonna jaoks on hea lähteülesanne. Nii et lihtsas olukorras, kui meeskonnale kättesaadavad tunnid on kokku:

• 4 meeskonnaliiget * kaks nädalat * 40 tundi nädalas = 320 tundi
• Korrutatud meie 70-protsendilise mahutavusega = 224 tundi
• Lisage kõik funktsiooniga seotud ülesanded ja lõpetage 224 lugemine
• Võtke kõik täidetud funktsioonid, lisage nende jutupunktid ja saate oma kiiruse, ütleme 36
• Rakendage 20 protsenti mõlemalt poolt, et saada madalaima ja kõrgeima vahemik, et saada hinnanguline kiirus 29–43 lugu.

Kiirus varieerub tavaliselt esimeses kahes kuni neljas korduses ja seejärel stabiliseerub väikeses punktide vahemikus. Niisiis, kui meie esialgne vahemik enne esimest sprinti oli 29–43, võib neljanda sprindi korral platoo olla 34–38. See annab meile suurema kindluse oma lõpliku lõpukuupäeva prognoosimisel.

Riskide ja ebakindluse puhverdusplaanid

Kõik tarkvaraprojektid on seotud ebakindlusega. See ebakindlus muutub projekti edenedes vähemaks ja rohkem on teada meie tehnoloogiast, keskkonnast, jõudlusest ning kliendi ja kasutajate vajadustest.

Maandame seda ebakindlust või riski ajakavas oleva puhvriga, mis moodustab meie hinnangus vea ja tundmatu, mida me ei saa enne arenduse algust kindlaks teha.

Tavaliselt on kahte tüüpi puhvreid: funktsioon ja ajakava. Kuna määratleme sageli fikseeritud hinda fikseeritud kohaletoimetamise kuupäevaks, on eelistatav kasutada funktsioonipuhvrit.

See lähenemisviis annab meile usaldusväärse riskide maandamise strateegia ja annab kliendile kindlustunde, mida nad peaksid projekti lõppedes ootama kui tulemust.

Funktsioonipuhvrid

Funktsioonipuhvriga prognoosime, et edastame etteantud funktsioonide komplekti, kuid ideaaljuhul täiendame täiendavaid funktsioone. See peaks kajastama vähemalt minimaalset funktsioonikomplekti, mida klient peab elujõulise toote turule toomiseks vajalikuks, kuid aja jooksul võib neid tarnida rohkem, kui kõik erinevad sisemised ja välised mõjud seda võimaldavad.

Seega võib klient otsustada, et kõige olulisemad on toote mahajäämusest kõige olulisemad funktsioonid, lisades kuni 100 lugu. Seejärel võivad nad kaaluda lisafunktsioone, mis lisavad veel 30 lugu. Seetõttu kavandab meeskond 130 lugupunkti edastamist, kusjuures vähemalt 100 täidetakse antud fikseeritud hinnaga lepingu kavandatud valmimistähtaja lõpuks.

Mõned lõpumõtted

Agile võib olla väga keeruline mõiste, mida on täielikult võimalik mõista ja omaks võtta. See pole vähem tõsi tundlike teemade nagu hind, ulatus ja kestus haldamisel. Kahjuks tean omast käest, et nõudlikud kliendid soovivad, et kõik asjad saaksid juba enne korda ja tahavad innukalt tarnijat süüdistada, kui see kõik lahti hakkab. Samuti olen teadlik müüjatest, kes kaevavad oma kontsad sisse, muutuvad reageerimatuks ega reageeri klientide vajadustele. Vilgas rada on rajatud põhimõtteliselt usaldusele, headele suhetele ja tähesuhtlusele. Need peavad olema mõlema osapoole valduses olevad väärtused, et säilitada tervislik projekt kõigile asjaosalistele võrdselt kasuks, rahuloluks ja edukaks. Avatud meele ja konstruktiivse suhtumise säilitamine koostöösse ja läbirääkimistesse on parim viis vältida suhete halvenemist.

Olen töötanud klientidega, kellel on olnud raske omaks võtta Agile'i adaptiivset olemust ja loobuda käsu ja kontrolli suhtumisest. Raske on lahti lasta ja panna kogu oma usk ja usaldus meeskonda, mida te ei tunne. Sageli võivad kliendid soovida kõik nõuded juba ette valmistada, täpsustades, mida tarnitakse. See annab neile kindlustunde, et projekti ulatus on hästi määratletud. Kuid lõpuks ei õnnestu seda edukaks lähenemiseks realiseerida. Kui oleme lepingus piiratud oma ulatuse ja ebareaalsete nõudmistega, tekivad probleemid väga kiiresti.

Seda lähenemist traditsioonilistes meetodites kasutades teame, et rakendusala muutub, tundmatud avastatakse või see, mida arvasime, et klient soovib, ei vasta enam tõele ega kaugele. Kohanduv lähenemine hinnakujundusele, planeerimisele ja ulatusele võimaldab klientidel tõeliselt tuvastada, et nende toode vastab täpselt nende turule. See võimaldab ka müüjal olla reageeriv, fantaasiarikas ja tõhus. Kliendi ja müüja koostöö valimine lepinguläbirääkimistel on võtmetähtsusega.

Müüjad peavad olema ausad ja kliendid realistlikud selles osas, mida on võimalik algusest peale saavutada. Müüja, kes lubab ebareaalseid eesmärke ja seejärel suurendab kulusid, võib küll esialgse lepingu võita, kuid kaotab peagi rahulolematu kliendi poolehoiu. Liiga sageli lagunevad suhted osapoolte vahelise usalduse puudumise tõttu. Usaldus tuleb üles ehitada algusest peale ja säilitada kogu projekti vältel. Müüja peab olema paindlik ja tegema koostööd muutuvate vajadustega. Kliendid tahavad alati rohkem; see on äritegevuse loomulik tagajärg. Mõlema poole vahel peab toimuma võrdne ja kasulik väärtusvahetus. Klientide jaoks soovivad nad oma ettevõttele väärtust luua. Müüjate jaoks peaksid nad püüdma luua väärtust, luues klientidega pikaajalisi suhteid. Agile manifesti väärtuste ja juhtpõhimõtete järgimine on tugev alus tugevate, tasakaalustatud ja pikkade suhete loomiseks.

mis on telegrammi bot

Kokkuvõte

Loodan, et see on andnud teile ülevaate kontserni hinna planeerimisest, hindamisest ja määratlemisest Vilgas tarkvaraprojekt. Kõik ülaltoodud lähenemisviisid ja tehnikad on loodud meeskonna usalduse suurendamiseks ja klientide meeltes usalduse suurendamiseks selle kohta, kui kaua ja kui palju kulub tarkvaratoote ehitamiseks. Lõppkokkuvõttes selleks, et tekitada enesekindlust jätkamise otsuse tegemisel.

Järgige neid juhiseid ja leiate kindlasti rahuldava tee tarkvaratoote ellu äratamiseks.