Realizarea unor estimări exacte ale proiectelor software

estimarea proiectului software

Pixabay

Introducere

Estimarea este doar grea. Din păcate, este și foarte necesar. Companiile folosesc estimări pentru a proiecta programele de lansare, pentru a-și asuma angajamente față de clienții lor, pentru a decide dacă merită implementată o caracteristică propusă, pentru a urmări viteza echipelor și pentru a stabili prioritățile în mod eficient. Executivii doresc adesea să știe când o caracteristică sau un livrabil vor fi gata de producție. La urma urmei, dezvoltarea de software nu este o investiție banală. Fără estimări, cum ar face managerul de proiect o evaluare? Dacă oamenii ar putea prezice viitorul cu precizie, oamenii nu ar câștiga la curse de cai 2% din timp. Estimarea este marea enigmă. Este esențial și necesar ca companiile să-și ceară oamenii să facă imposibilul: prezice viitorul.

În primul rând, să trecem în revistă câteva metode populare de estimare (în cazul în care ați ratat o parte din entuziasm). Apoi, ne putem uita la ce înseamnă acest lucru pentru noi și proiectele noastre.

Modelul Fortune Teller

Acest model nu necesită aproape niciun efort pentru a produce o estimare. Estimatorii se gândesc puțin la ce trebuie făcut pentru a implementa și testa o caracteristică, apoi aruncă un număr. Suna foarte mult ca „… (pauză lungă)… Ummmmm… 6 săptămâni.” Apoi toată lumea dă din cap și continuăm. Aceștia ar putea petrece destul de mult timp pe front-end vorbind despre ceea ce știu despre cerințe (ceea ce probabil nu este imaginea completă). Această analiză atentă face ca estimarea lor să se simtă mai fiabilă. La sfârșitul proiectului, există întotdeauna o justificare acceptată a motivului pentru care estimarea a fost atât de departe de realitate. Există întotdeauna circumstanțe neprevăzute care pot servi drept țap ispășitor. Adesea nimănui nu îi vine în minte că modelul este grav defectuos.

Deci, cum putem îmbunătăți acest proces? Stiu! Putem folosi tehnica de descompunere (adică împărțiți și cuceriți). Această abordare presupune că cunoașteți sfera completă a caracteristicii sau proiectului din partea frontală. Fiecare caracteristică este împărțită în bucăți de mărime. Fiecare bucată este estimată (stil ghicitor), apoi le adăugăm pentru a obține o estimare generală a caracteristicii / proiectului. Aceasta este cu siguranță o abordare mai complicată, dar pare mai bine din două motive:

• Bucăți mai mici de muncă tind să fie mai ușor de estimat în mod fiabil.
• Deși există încă posibilitatea de eroare (+/- o anumită sumă), există o presupunere că erorile se vor anula reciproc atunci când adăugați totul și veți obține o estimare generală mai fiabilă.

Defectul fundamental al acestei abordări este acela că contribuitorii individuali (oamenii care fac efectiv munca) subestimează universal. Sunt încă semnificativ mai buni decât cei de deasupra și din jurul lor, dar asta nu este o bară ridicată. Acest lucru nu pare a fi cazul, deoarece am văzut cu toții cazuri în care dezvoltatorii s-au surprins realizând ceva înainte de termen. Dar acesta este un singur punct de date, nu o tendință. Oamenii câștigă de fapt ocazional la cazino; cheltuiești bani la un cazinou în fiecare zi timp de un an și vei avea mai puțini bani decât ai început. Dacă urmăriți estimările față de valorile efective pentru un an sau doi, veți descoperi că estimările nu corespund realității. În timp ce mulți oameni de afaceri sunt absolut siguri că dezvoltatorii își umplu alene estimările și folosesc timpul suplimentar pentru a „plăti cu aur” sau pentru a-și verifica stocurile,datele arată altfel. Strategia de „anulare” nu funcționează.

Si acum ce? Să renunțăm la modelul ghicitorului și să trecem la o abordare bazată pe dimensiuni. Se pare că, în timp ce oamenii sunt destul de îngrozitori în estimarea timpului de finalizare, suntem de fapt destul de buni în a spune cât de mare este ceva. Suntem deosebit de buni la dimensionarea comparativă („este mai mare decât atât, dar mai mic decât cel de acolo”). Dacă gândim mai degrabă în funcție de dimensiune sau complexitate decât de timp, creierul nostru îl procesează mai fiabil. Apoi putem lua valorile mărimii și putem calcula numărul real de ore pentru proiect pe baza unei formule magice inteligente! Și atunci intră în scenă popularul model de puncte de funcție (stânga).

Analiza punctelor funcționale (FPA)

Pentru analiza punctelor funcționale, trebuie să identificăm cinci tipuri de lucruri în aplicația noastră: intrări externe, ieșiri externe, interogări externe, fișiere de interfață externe și fișiere logice interne (nu vă faceți griji prea mult cu privire la definiții; le puteți cerceta mai târziu). Fiecare exemplu dintre acestea (o funcție) are o complexitate asociată cu aceasta (scăzută, medie sau ridicată). Folosim tabelul de mai jos pentru a afla câte puncte sunt atribuite fiecărei funcții.

Acum, dacă adunăm punctele pentru toate funcțiile noastre, am putea obține un număr ca 457 puncte de funcție pentru proiectul nostru. Apoi, avem nevoie doar de o formulă pentru a afla numărul de ore… Pe baza ultimului nostru proiect, „rata de livrare” a fost de 15 puncte funcționale pe persoană pe lună. Este o muncă în valoare de aproximativ 30 de luni, ceea ce ar trebui să dureze puțin peste două luni și jumătate pentru echipa mea de 12. Ta-da!

Acest lucru este cu siguranță mai complex decât modelul nostru anterior. De fapt, există patru domenii cheie de complexitate de recunoscut.

1. Cele cinci tipuri de componente nu sunt neapărat intuitive și este ușor să uitați să introduceți ceva în listă sau să îl atribuiți cupei greșite.
2. Tabelul folosit pentru a genera efectiv punctele funcționale conține numere magice care ar necesita mult efort pentru validare. Sunt aceste numere calibrate corespunzător pentru a genera estimări fiabile pentru echipele mele?
3. Rata de livrare (o piesă critică a puzzle-ului) este calculată pe baza productivității echipei dvs. Cât de des trebuie să calculăm un număr nou? De fapt, există foarte puține îndrumări în acest sens.
4. Ce constituie complexitate scăzută, medie sau ridicată? Cum definim asta pentru ca toată lumea să o înțeleagă? Obținerea corectă nu este critică pentru acuratețea calculelor noastre?

Există mai multe părți în mișcare în acest exemplu foarte simplu și nici măcar nu am discutat despre modele de complexitate mai complicate și despre celelalte date care pot intra în joc (de exemplu, rata de cost, rata de suport, densitatea defectelor etc.). Mai multe piese în mișcare înseamnă mai multe oportunități de a apărea erori. Facem estimarea prea complicată acum? Nu plătim dezvoltatorilor pentru a dedica mult timp estimării. Nu pot vinde o estimare clienților mei. Am nevoie de software de lucru. Mai este ceva acolo?

Mergând agil

Acum să ne uităm scurt la scrum agil (suficient cât să facem o comparație). După cum sa menționat anterior, oamenii sunt teribili la estimarea timpului și sunt destul de buni la dimensionarea comparativă. Iată câțiva termeni de înțeles:

• Un sprint - o perioadă de timp în cutie (de obicei două săptămâni).

• Povestea utilizatorului - o lucrare discretă, de preferință suficient de mică pentru a fi realizată de o persoană într-un sprint. Acesta este lucrul pe care îl estimăm.

Cea mai populară strategie este utilizarea unei secvențe Fibonacci (0, 1, 2, 3, 5, 8, 13) pentru estimări. Nu este liniar - pe măsură ce urcați scala, dimensiunea decalajelor crește. Cheia este că decalajele ar trebui să fie suficient de mari încât să nu existe niciun motiv pentru a argumenta diferențe nesemnificative. Odată ce ai ajuns peste 3, diferența dintre 4 și 5 sau 7 și 8 este atât de neglijabilă încât nu are rost să-ți petreci timpul eliminând care este. O secvență de bază-2 ar funcționa, de asemenea (0, 1, 2, 4, 8, 16 etc.).

„Dar așteaptă, acesta este doar un număr. Ce înseamnă? Câte ore este un punct? ” Punctele nu intenționează să se coreleze direct cu orele, deoarece dacă ar face acest lucru, echipele ar fi tentate să revină la estimarea în ore și apoi să transforme acest lucru în puncte cumva. După cum s-a discutat mai devreme, acuratețea estimărilor noastre provine din dimensionarea comparativă și din estimarea numărului de ore pe care le va dura ceva. Dacă oferiți echipei capacitatea de a gândi în termeni de ore, vă compromiteți capacitatea de a estima cu exactitate.

Să presupunem că ați început cu un exercițiu de calibrare. Trageți echipa într-o cameră și parcurgeți-le printr-o listă de 10-12 povești ale utilizatorilor. Alegeți unul mic, dar nu cel mai mic și faceți-l mai întâi. Revedeți-o și anunțați că această poveste este un „3”. Nu întrebi. Spui. Apoi treceți la povestea următoare. „Dacă a fost un 3, ce este acesta?” Acum echipa dimensionează poveștile în raport cu alte povești. În cele din urmă, vor avea o idee destul de bună despre ceea ce constituie un „1”, un „2”, etc. Nu estimează. Timpul nu contează. Sunt povești de dimensiuni, în raport cu alte povești care au deja un număr. Puteți pune apoi povești de exemplu pentru fiecare număr din secvență într-un document numit riglă. Ei pot folosi acest lucru ca referință dacă nu sunt siguri ce înseamnă „5”.

Iată cheia. Sosul magic care face ca acest lucru să funcționeze este „viteza” (numărul de puncte pe care o echipă le poate parcurge într-un sprint în medie pe 3-4 sprinturi). Să presupunem că sprintul tău este de două săptămâni, iar echipa ta de 8 persoane are o viteză medie de 35 de puncte. Obțineți 35 de puncte în 640 de ore de lucru (8 x 80 de ore). Dacă ne dăm seama că o caracteristică va dura aproximativ 100 de puncte de lucru începe să se termine, atunci știu că sunt aproximativ 6 săptămâni de muncă și aproximativ 1900 de ore. Echipa se pricepe foarte bine la dimensionarea constantă a poveștilor și le folosiți pentru a vă planifica proiectul. Acest calcul funcționează deoarece durata este consistentă de la sprint la sprint.

Pentru a face planificare la nivel înalt pe termen lung, puteți solicita clienților dvs. potențiali să descompună caracteristicile de nivel înalt în povești interimare one-liner și să le puneți valori punctuale. Se va pierde un anumit grad de acuratețe, dar folosiți modelul pe care îl înțeleg deja. O cale mai precisă ar fi dimensiunea relativă la nivelul caracteristicii. „Această caracteristică este mai mare decât acea caracteristică de 40 de puncte, mai mică decât acea caracteristică de 120 de puncte de acolo și puțin mai mare decât caracteristica de 65 de puncte pe care tocmai am făcut-o.” Poveștile sunt grupate în „epopee”. Dacă fiecare caracteristică este o epopee, la final veți ști câte puncte a fost nevoie pentru a finaliza acea caracteristică. Păstrați un istoric al acestui lucru și îl puteți folosi pentru planificarea lansării.

Concluzie

Există o mulțime de metodologii utilizate astăzi. Fiecare are argumente pro și contra. Cumva, trebuie să ne dăm seama cum să maximizăm acuratețea estimărilor noastre, astfel încât să putem lua decizii bune. Asta nu înseamnă că estimările noastre trebuie să fie corecte. Trebuie doar să fie suficient de exacte încât să fie utile. Dacă nu înțelegeți estimarea, ați putea presupune că estimările nu au fost exacte, deoarece echipa nu a făcut o treabă bună. Nu au estimat corect sau nu au executat corect proiectul. Bătăile vor continua până când estimările se vor îmbunătăți. Dar estimările nu trebuie folosite niciodată ca angajament. Este cea mai bună presupunere bazată pe informațiile limitate pe care le avem astăzi. Când apar informații noi, trebuie să permitem revizuirea estimărilor. Orice altceva așteaptă imposibilul, ceea ce reprezintă o problemă cu conducerea (nu cu echipa).

Abordarea Scrum este mult mai simplă decât ceea ce vedem în analiza punctelor funcționale. Și aș spune că este mult mai de încredere decât mesele magice cu numere magice. Obține cel mai mult bang pentru dolar (efort minim cu un grad rezonabil de mare de precizie). Din perspectiva efortului, nu creează un proces greu pentru înțelegerea și utilizarea echipelor. Piesa de estimare a agilității se poate întâmpla de fapt foarte repede odată ce toată lumea înțelege detaliile lucrării estimate. Cu siguranță este mai bine decât să scoți numerele din aer. Viteza de pârghie face ceva foarte important: aduce date istorice în calcul. La fiecare sprint, îți recalculezi viteza. Acest lucru este esențial, deoarece în timp, fluxul se modifică. Echipele care utilizează FPA ar putea obține rata de livrare din proiectul anterior,care în unele cazuri a fost acum câteva luni. Probabil s-au schimbat multe de atunci. Sugestia mea este să explorați Agile și să depuneți eforturi în înțelegerea punctelor și vitezei poveștii. Nu renunțați la estimarea în ore doar pentru că asta înțelegeți. Cred că îți vei mulțumi mai târziu.

Sondaj rapid