Estimarea costurilor software în managementul agil de proiect

Introducere

Unul dintre cele mai dificile lucruri de făcut în dezvoltarea de software este să determinați cât timp și cât va dura pentru a livra un nou produs software. Ar trebui să fie atât de greu? Răspunsul nu este simplu.

Estimarea costurilor software este în mod inerent dificilă, iar oamenii sunt teribil de prost să prezică rezultate absolute. Nu există două proiecte la fel; fiecare este unic în ceea ce își propune să realizeze și unic în multitudinea de parametri care îi formează existența. Adesea, ceea ce pare a fi o problemă simplă la suprafață este mult mai greu sau mai dificil din punct de vedere tehnic de implementat în realitate. Și, fără îndoială, vor exista „necunoscute” cu proiectul care pot fi identificate doar atunci când vor apărea.

În plus, nu există două persoane la fel, indiferent dacă ești client, dezvoltator sau utilizator. Venim preîncărcați cu propriul nostru set de cunoștințe, experiențe, valori, așteptări, atitudine față de risc și capacitate de adaptare.

Scrierea de software de bună calitate este o idee bună pentru inginerii seniori; crearea de produse software minunate poate fi un efort mult mai dificil pentru toți cei implicați.

Dar când vine vorba de software, înțelegerea duratei și a costurilor sunt esențiale în luarea deciziilor strategice de afaceri și acest lucru este adevărat indiferent dacă creați un startup, realizați o nouă oportunitate de afaceri sau vă permiteți afacerii să performeze mai bine. Momentul, randamentul investiției și beneficiile oferite pot face, zgudui sau distruge afacerea dvs. Vă veți întreba: ce primim pentru banii noștri? Ne putem prezice costurile? Cât va costa crearea produsului pe care ni-l dorim? Când putem lansa? Vom primi un produs de calitate pentru investiția noastră? Va crește odată cu afacerea noastră? Va oferi valoare afacerii?

Deci, cum estimați dimensiunea, durata și costul unui proiect? Să explorăm estimarea proiectelor Agile și costurile de dezvoltare software și cum o facem la Toptal.

Prețurile și estimarea contractelor tradiționale

În mod tradițional, folosind practici non-Agile, proiectele software au căutat să stabilească funcționalitatea sau domeniul de aplicare și să lase timpul și costul să fie o variabilă. Acest lucru cauzează probleme:

1. De unde știi că funcționalitatea pe care o rezolvi la începutul unui proiect este într-adevăr funcționalitatea care îți servește cel mai bine afacerea sau clienții? De cele mai multe ori, funcționalitatea sau domeniul de aplicare se vor schimba, motiv pentru care auzim despre „sploarea domeniului”, rezultatul nevoilor dorite fiind identificat pe parcursul ciclului de viață al unui proiect și fiind determinat ca fiind necesar sau obligatoriu.

2. Când costul devine o variabilă, pierdem controlul asupra rentabilității investiției (ROI) pe care căutăm să o obținem. Costul crescut este adesea un produs al riscurilor neidentificate sau al cerințelor în schimbare, ceea ce înseamnă că trebuie să adăugăm membri ai echipei pentru a lucra mai mult în același interval de timp sau să păstrăm membrii echipei mai mult timp. Nici unul nu este de dorit

3. Când timpul este o variabilă, pierdem controlul asupra poziției pe piața noastră. Poate că ratăm o întâlnire importantă în industrie sau concurenții noștri își scot produsul înaintea noastră, pierzând astfel orice avantaj competitiv pe care l-ar fi avut proiectul nostru.

Există multe alte rezultate ale timpului și costurilor variabile, care sunt adesea negative și nedorite.

Desigur, mulți clienți și organizații caută să repare toate cele trei componente ale acestui „triunghi magic”. Din păcate, este aproape imposibil de realizat în mod realist. Există prea multe elemente care conspiră pentru a tulbura acest ideal, care în cele din urmă se termină în produse care nu satisfac o nevoie, durează prea mult pentru a beneficia clienții săi sau costă prea mult pentru a realiza valoarea afacerii.

Contracte Agile pentru proiecte software

Costul este un produs al timpului și al oamenilor (membrii echipei). Adăugați mai mult timp și adăugați costuri pentru angajarea oamenilor pentru mai mult timp. Adăugați mai mulți membri ai echipei și creșteți costul pentru a oferi aceeași valoare comercială. Lucrurile pe care dorim cu adevărat să le evităm. Acesta este motivul pentru care principiile Agile cred în fixarea timpului și a membrilor echipei și în a permite ca domeniul de aplicare să fie componenta variabilă.

Care sună mai bine și crește încrederea părților interesate, costul fix sau costul variabil?

Desigur, este important ca un produs să își respecte promisiunile și nevoile clienților săi. Nu este bine să cheltuiești o cantitate exactă de timp și o sumă exactă de bani dacă, în cele din urmă, ai un produs pe care nimeni nu-l dorește sau nu îl poate folosi eficient.

Prin urmare, contractele Agile se concentrează pe următoarele:

• Pachete de lucru cu preț fix - Întregul proiect este împărțit în „mini” versiuni logice care contribuie la rezultatul complet al produsului. Fiecare versiune este un pachet de lucru care are un preț corespunzător. Pe măsură ce un pachet de lucru este finalizat, pachetele de lucru viitoare sunt re-estimate pe baza a ceea ce am învățat din cel precedent. Acest lucru evită situația inutilă și permite un nivel de re-prioritizare și caracteristici noi/revizuite care urmează să fie definite de către client.

• Terminare anticipată - Acest lucru permite clientului să încerce să încheie proiectul mai devreme dacă a fost livrat suficient produs și nu mai există nicio rentabilitate suplimentară a investiției de atins prin păstrarea unei echipe de proiect care va continua să furnizeze doar câștiguri marginale. Această clauză este de obicei permisă în orice moment și este valabilă atâta timp cât echipa de proiect și clientul au menținut o relație de colaborare puternică, de încredere și strânsă. Beneficiul pentru client este că proiectul se va termina mai devreme, având livrate toate caracteristicile valoroase necesare pentru a face produsul viabil. În schimb, furnizorul este plătit cu 20% din valoarea rămasă a contractului și compensează riscul reținerii personalului.

• Schimbări flexibile - Schimbarea este o temă care curge puternic prin venele livrării de software Agile. Ne așteptăm să nu știm tot ce avem nevoie pentru a face un produs de succes încă de la început. Prin urmare, promovăm schimbarea, pe baza datelor și feedback-ului relevante, pentru a ne asigura că este livrat produsul potrivit. La sfârșitul unei iterații, modificările pot fi schimbate cu funcții vechi care nu mai sunt considerate necesare sau prioritare. Atâta timp cât modificarea este de valoare egală, nu există costuri suplimentare. Dacă modificarea este de valoare mai mică, pot fi identificate lucrări suplimentare sau pot fi retrase din restul rămas. Această clauză este valabilă atâta timp cât echipa de proiect și clientul au menținut o relație de colaborare puternică, de încredere și strânsă pe tot parcursul proiectului.

• Lucrări suplimentare - Pe parcursul duratei de viață a unui proiect, pot fi identificate mai multe caracteristici care nu ar fi realizabile în baza contractului de preț fix existent. Pentru acest scenariu, fie pachete de lucru suplimentare cu prețuri noi pot fi adăugate la sfârșitul proiectului, fie pot reveni la timp și materiale.

• Estimări variate - Există două moduri în care estimările pot fi variate într-un contract de proiect Agile: o gamă de durată sau o gamă de caracteristici. O gamă de durată permite o estimare pentru a spune că proiectul sau pachetul de lucru va dura 12 până la 16 săptămâni pentru un anumit set de domeniu. Cu toate acestea, adăugarea duratei adaugă costuri, deoarece păstrați membrii echipei de proiect mai mult timp sau înseamnă că aceștia nu pot fi eliberați pentru a lucra la alte proiecte de dezvoltare. La Toptal, preferăm să diferențiem funcțiile într-o serie de puncte de poveste, păstrând domeniul de aplicare ca variabilă, dar promițând să oferim un nivel minim de valoare clientului în intervalul de timp fix al pachetului de lucru sau al proiectului general.

Merită să ne amintim că puteți oricând să adăugați mai mult domeniu de aplicare mai târziu. Poate ați început să obțineți venituri, ați crescut numărul de utilizatori sau ați redus costurile. În orice caz, este mult mai ușor să ceri mai mulți bani și timp dacă ai demonstrat deja o rentabilitate sau o îmbunătățire și oferiți valoare pentru afaceri.

Abordarea noastră cu privire la costurile software și prețurile

La Toptal lucrăm îndeaproape cu clienții și inginerii noștri pentru a folosi tehnici care promovează încrederea părților interesate în durata și costurile proiectului. Lucrăm la elaborarea și adaptarea continuă a planificării de la un nivel inițial înalt până la detalii mai detaliate atunci când este adecvat și necesar pentru a evita risipa și pentru a permite schimbarea gestionată.

În elaborarea unui proiect de deviz și preț fix se parcurg următorii pași:

1. Domeniul de aplicare inițial la nivel înalt

La începutul unui proiect, știm cel mai puțin despre rezultatul final al acestuia. Este o nebunie să ne imaginăm că este posibil să știm exact de ce caracteristici au nevoie clienții și utilizatorii noștri încă de la început.

Așadar, începem cu o carte de proiect și un set de caracteristici „epice” la nivel înalt care ghidează direcția proiectului, bazat pe o viziune și obiective solide.

A. Stabilirea viziunii și a obiectivelor Ce trebuie să construim? Ce trebuie să realizați și care sunt obiectivele dvs. de afaceri? Înțelegerea acestor întrebări ne permite să stabilim amploarea proiectului. Aveți nevoie de un prototip pentru a testa o idee, un concept sau o tehnologie inițială? Ați identificat o propunere clară care a fost testată cu piața dvs. și sunteți gata să vă construiți primul produs viabil minim (MVP)? Sau vă extindeți afacerea sau produsul existent pentru a-l duce la nivelul următor?

b. Caracteristici „epopee” de nivel înalt Fără a intra în prea multe detalii, veți dori să definiți caracteristicile pe care produsul dumneavoastră le are pentru a satisface nevoile clienților dumneavoastră. Aceasta este o „listă de cumpărături” structurată care descrie elementele fundamentale ale produsului dvs.; adesea acestea sunt denumite „Povești utilizator” sau epopee

c. Analiza MoSCoW Analiza MoSCoW este o tehnică care, simplu, ajută la identificarea a ceea ce este cu adevărat necesar pentru a face produsul viabil și a ceea ce este plăcut să aveți. Cele care sunt identificate ca „Trebuie” satisfac ceea ce va încuraja utilizatorii să se implice și să adopte produsul dvs. Acele caracteristici identificate ca „Ar trebui” vor surprinde și vor încânta clienții, dar ar putea fi construite mai târziu. Articolele „Ar putea” de multe ori nu adaugă valoare comercială semnificativă, este posibil să nu mărească rentabilitatea și sunt cele mai mici dintre prioritățile tale. Caracteristicile „Won’t” ar putea fi importante într-o zi, dar sunt în afara domeniului de aplicare al acestui proiect. Cu toate acestea, identificarea acestora acum poate ajuta să țineți cont de dimensiunea potențială a produsului pentru viitor.

2. Propunere

Pentru a lua o decizie cu privire la continuarea unui proiect, este necesar să se bazeze acea decizie pe date bine informate: cost și durată. Acestea sunt minimele pe care trebuie să le întrebați: Ce va fi nevoie pentru a crea produsul pe care ni-l dorim? Când putem lansa? Se aliniază acest lucru cu strategia și finanțele noastre de afaceri?

Cu detaliile de mai sus, suntem în măsură să oferim o propunere. Inginerii noștri sunt aleși cu atenție pentru cerințele specifice ale proiectului și lucrează împreună cu un manager de proiect pentru a obține cel puțin o soluție tehnică, o durată estimată care oferă domeniul cunoscut și un cost estimat pentru finalizarea proiectului.

După cum am menționat anterior, la începutul unui proiect știm cel mai puțin despre ceea ce va fi livrat. Păstrăm în mod deliberat caracteristicile și domeniul de aplicare vagi, deoarece a face altfel sugerează că știm exact ce este necesar. O estimare în această etapă ar fi cea mai puțin precisă, dar oferă îndrumări despre dacă merită să continuați cu proiectul.

Propunerea este primul instrument în elaborarea duratei și costului unui proiect. Odată ce o propunere este acceptată, putem avansa pentru a oferi o cotație cu preț fix.

3. Planificarea lansării

Următorul nivel de elaborare a estimărilor este crearea unui plan de lansare care va oferi o gamă de caracteristici într-un interval de timp dat. Derivam acest lucru dintr-o listă de caracteristici, dimensiunea proiectului, cât de repede echipa noastră poate dezvolta un software de calitate care să îndeplinească așteptările și tehnicile clientului pentru gestionarea riscului de incertitudine.

A. Backlog-ul de produse Backlog -ul de produse este pur și simplu o listă ordonată de „Epopee” sau „Povești utilizator” care reprezintă caracteristicile necesare unui produs. Această listă începe viața ca epicurile discutate mai devreme, dar între echipa de proiect alocată, managerul de proiect și client, acum le împărțim în elemente mai semnificative. Fiecare dintre articole reprezintă o parte din valoarea afacerii pentru client. Nu intrăm în mai multe detalii în această etapă, nu trebuie să știm criteriile de acceptare, nu trebuie să știm dacă un buton este albastru sau verde, trebuie doar să știm că există un buton care permite o anumită sarcină. de efectuat.

b. Estimare Acum că avem lista noastră de caracteristici descrise ca povești de utilizator, echipa estimează aceste elemente discrete de caracteristici folosind o tehnică numită „Planning Poker”. Aceasta este o tehnică utilă care asigură rezultate rapide, fiabile, bazate pe opinia experților și dimensionări similare. Planning Poker atribuie fiecărui articol un număr convenit reprezentând dimensiunea și complexitatea acestuia. Acesta se numește un punct de poveste. Sunt disponibile și alte tehnici și dimensiuni de estimare Agile, cum ar fi „zile ideale”.

Sfârșitul acestui proces va determina dimensiunea proiectului și dependențele dintre caracteristici. Mărimea este determinată prin adunarea tuturor punctelor de poveste din articolele din stocul de produse. Dacă acest număr este egal cu 120, atunci dimensiunea proiectului nostru este de 120 de puncte de poveste.

c. Prioritizare Acum că avem un întârziere și o dimensiune pentru proiect, suntem în măsură să-l acordăm prioritate cu clientul. Este vorba într-adevăr de a identifica ceea ce este cel mai valoros pentru client pentru a obține rezultatele dorite. Elementul din partea de sus a listei este considerat cel mai important, al doilea element este mai puțin important decât primul și așa mai departe prin listă. Nu există două elemente la fel de importante ca altul, prioritatea fiecărui articol este de importanță sau valoare relativă pentru fiecare dintre celelalte elemente.

Această abordare a prioritizării este o etapă importantă în planificarea unui proiect software. Știm acum ce este important pentru client și în ce ordine să finalizezi munca, având grijă de dependențe, pentru a livra un produs care să corespundă așteptărilor.

d. Planificarea lansării Până în prezent, am stabilit ce credem că este produsul și cât de mare este.

Acum, stabilim cât timp va dura livrarea unui produs care poate fi lansat. Clientul și echipa, inclusiv designerii, inginerii, testerii, scrum master și managerul de proiect, lucrează împreună pentru a identifica ce se poate realiza și cât de repede se poate lucra pentru a crea un plan de lansare.

Planul de lansare oferă, de asemenea, o perspectivă asupra modului în care proiectul se va alinia cu planurile strategice ale clientului.

Și, în sfârșit, acest plan asigură că echipa de proiect are o lumină de ghidare care deschide calea și definește un punct final logic pentru dezvoltare.

Înainte de a începe, ne asigurăm că înțelegem definiția convenită a „terminat”. Acesta este un set dat de criterii pe care un client le va accepta ca fiind complet și, de asemenea, îndeplinește toate cerințele de inginerie pentru a fi considerat eliberabil.

Pentru a lua un scenariu de bază, luăm numărul total de puncte de poveste pe care le-am obținut din dimensionarea stocului nostru și îl împărțim la viteza anticipată a echipelor noastre. (Viteza NB este în mod normal exprimată ca un interval, dar pentru simplitate, vom folosi un singur număr aici.) Lucrăm în iterații de două săptămâni, astfel încât viteza noastră se va reflecta de cât de mult putem finaliza într-un ciclu de două săptămâni cu cele disponibile capacitatea echipei. Dacă punctele noastre de poveste au totalizat 120 și anticipăm că vom finaliza 20 de puncte per iterație, durata totală a dezvoltării ar fi de 12 săptămâni sau 6 iterații. Adăugăm la asta un sprint 0 de 2 săptămâni și un sprint de pregătire pentru lansare de două săptămâni. În total, durata proiectului nostru este de 16 săptămâni. Există tehnici pe care le putem folosi care ar ajuta la construirea unui tampon de risc adecvat în planificarea noastră, despre care vom discuta mai târziu. Dar, pe scurt, folosim tamponul pentru a gestiona riscul de incertitudine și pentru a ajunge la un acord minim cu privire la punctele de poveste așteptate pentru a fi livrate. Rezultatul ar putea fi un interval de 90 până la 150 de puncte de poveste livrate, 90 fiind minimul care ar fi acceptabil pentru a crea un produs viabil.

Alternativ, dacă proiectul trebuie finalizat până la o dată dată, de exemplu, în 10 săptămâni, echipa va determina cât de mult din restanță poate fi finalizată în acel timp. Dacă anticipăm 20 de puncte de poveste per sprint, plus Sprint 0 și un sprint de lansare, am viza 60 de puncte finalizate până la sfârșitul proiectului. Din nou, am căuta să gestionăm riscul prin adăugarea unui tampon adecvat, care ar putea duce la un obiectiv de 45 până la 75 de puncte de poveste finalizate și gata de lansare. Cele 45 de puncte de poveste s-ar alinia cu minimul acceptabil pentru a oferi un produs viabil și valoros. Acesta este un scenariu în care vă puteți aștepta să adăugați un membru al echipei pentru a crește viteza, dacă este cazul.

Desigur, toate cele de mai sus sunt susținute de comunicare și colaborare de bună calitate între toate părțile pentru a elabora un plan de lansare care să fie realizabil, realist și acceptabil pentru client.

4. Contract cu preț fix

Odată ce un plan de lansare este convenit, putem crea o ofertă pentru un contract de proiect cu preț fix. După cum s-a menționat anterior, este recomandabil să păstrați fix durata proiectului și echipa și variabila domeniului de aplicare.

Cotația pentru un contract cu preț fix se livrează împreună cu o declarație de lucru și un program de plată convenit.

Atâta timp cât există încredere, comunicare, colaborare și disponibilitatea de a intra în spiritul unui proiect software Agile, toți pașii de mai sus ne permit să livrăm o cotație cu un grad realist de încredere că un proiect va fi livrat la timp și la buget. Desigur, vor exista ocazii în care un proiect este livrat devreme sau târziu și ne ocupăm de aceste variații cu cea mai mare transparență.

Tehnici de estimare

Planificarea și estimarea agilă sunt susținute de o serie de tehnici pe care o echipă de dezvoltare le poate folosi pentru a câștiga încredere în dimensiunea, efortul, durata și costul lor. Iată câteva dintre cele pe care echipele noastre le folosesc pentru a estima dimensiunea și costul unui proiect software.

Estimarea dimensiunii

Mărimea proiectului este într-adevăr o apreciere a sferei, complexității, dimensiunilor, riscului și amplorii acestuia. Pentru a folosi o analogie, este vorba despre înțelegerea dacă construim Turnul Eiffel sau Marele Zid Chinezesc. Turnul Eiffel este o structură înaltă, grea, complexă, construită într-un mediu urban strâmt. Marele Zid Chinezesc este o structură relativ simplă, dar lungă și robustă, care se întinde pe mulți kilometri de teren ondulat.

Deși ambele ar fi proiecte mari de livrat, amploarea, complexitatea, dimensiunile, amploarea și, prin urmare, dimensiunea lor sunt diferite.

Este important să gestionați așteptările cu estimări. Nu sunt niciodată previziuni, angajamente sau garanții. Când discutăm despre dimensiunea totală, durata totală și costul total, lucrăm întotdeauna în intervale, astfel încât să atenuăm riscul, incertitudinea și necunoscutele.

Poveștile care reprezintă caracteristici ale produsului dvs. sunt dimensionate și estimate individual folosind puncte de poveste sau zile ideale. Numărul total al acestor unități definește dimensiunea totală a proiectului.

Puncte de poveste

Punctele de poveste sunt o unitate de măsură care exprimă dimensiunea generală a unei povești de utilizator. Mărimea unei povești, atunci când este estimată, include toate aspectele de proiectare, inginerie, testare, revizuire a codului, integrare etc.

Fiecare dimensiune a unei povești este relativă la o altă poveste. Deci, de exemplu, Povestea A poate avea un punct, Povestea B ca două puncte și Povestea C ca trei puncte. Aici, Povestea C este de cel puțin trei ori mai mare decât Povestea A și cel puțin jumătate mai mare decât povestea B.

Dacă următoarele povești din backlogul nostru de produse au dimensiunile asociate:

Dimensiunea totală a proiectului este de 12 puncte de poveste.

Zilele Ideale

Aceasta este o măsură a mărimii exprimată în zile. Îndepărtează conceptul de cheltuieli generale, cum ar fi întreruperi, activități de planificare agilă, citire de e-mailuri și alte activități non-proiect. Se concentrează doar pe cât timp ar dura dacă ai lucra la ceva continuu fără întrerupere, mai degrabă decât pe timpul scurs de la început până la sfârșit.

De obicei, atunci când estimăm la un nivel înalt, când știm cel mai puțin despre un proiect, am estima în zile ideale, deoarece acesta este un concept mai ușor de corelat cu istoria și experiența trecută decât un număr abstract, cum ar fi un punct de poveste. Mai ales atunci când poveștile la un nivel înalt sunt de natură mai epice, cu puține detalii și, eventual, conțin elemente suplimentare atunci când sunt defalcate la o dată ulterioară.

Când estimăm la un nivel mai granular, să spunem o poveste dintr-un backlog de produse stabilite, oricare abordare poate fi utilizată și ar fi decisă de echipa de inginerie. Există beneficii pentru ambele abordări și fiecare echipă va avea preferința ei.

Tehnici de estimare

Estimări comune Estimările nu sunt efectuate izolat. Acestea sunt realizate în colaborare de către întreaga echipă de inginerie împreună și includ proiectare, baze de date, server, interfață de utilizare front-end, QA și alți experți interfuncționali. Acest lucru evită problemele de a nu lua în considerare toate aspectele muncii implicate pentru a finaliza o caracteristică și se asigură că nicio persoană nu are povara sau ghinionul de a supra sau subestima dimensiunea unei caracteristici. Echipa combinată va avea toți un punct de vedere care poate fi discutat și convenit.

Estimări analoge Aici luăm în considerare două caracteristici discrete și decidem că una este relativ mai mică sau mai mare decât cealaltă. Putem să ne uităm la o anumită poveste și să fim de acord că este de dimensiuni mici, iar dacă folosim puncte de poveste, i-am putea da o dimensiune de două. Următoarea poveste ar putea fi considerată la fel de mare în comparație cu prima și i-am acorda o dimensiune de cinci. Acest lucru sugerează că o dimensiune mare este de cel puțin două ori mai mare decât o caracteristică mică.

Vom continua acest exercițiu cu toate poveștile. Odată finalizate, putem așeza toate poveștile mici, medii, mari și foarte mari una lângă alta și să ne verificăm dimensionarea pentru a ne asigura că există un nivel de uniformitate în estimarea noastră.

Planning Poker S-a scris mult despre Planning Poker; Am menționat-o și pe blogul meu anterior. Una dintre cele mai bune resurse pentru înțelegere este aici.

În esență, combină opinia experților, analogia și colaborarea în echipă într-un singur proces ușor, rapid și de încredere.

Acesta reunește mai mulți experți care sunt cei mai potriviți pentru a construi o estimare bazată pe experiența tehnică și de domeniu, un dialog plin de viață și o justificare solidă.

Viteză

Viteza este o măsură a capacității unei echipe de a lucra într-o anumită iterație (sau sprint).

Este exprimat ca un interval, de exemplu, 23 până la 32 de puncte de poveste per sprint, mai ales la începutul vieții unui proiect. În general, acest lucru se datorează faptului că, cu excepția cazului în care aceeași echipă a mai lucrat la aceeași problemă, este greu de descris exact care va fi viteza echipei. Observați, ne referim la viteza unei echipe și nu la viteza unui individ!

Folosim viteza pentru a ne planifica lansările și pentru a ne adapta planurile și pachetele de lucru pe măsură ce progresăm printr-un proiect, permițându-ne astfel să ne ajustăm prognoza pentru finalizare în mod regulat și precis prin execuție.

Când începem, suntem forțați să definim un interval de viteză cu foarte puține date. Putem folosi valorile istorice dacă echipa și spațiul cu probleme sunt aceleași, ceea ce este adesea cel mai puțin probabil. Putem rula o iterație pentru a ne face o idee despre viteza de la o echipă care lucrează efectiv la proiect, dar acest lucru este costisitor și nu funcționează dacă încă trebuie luate decizii privind acceptarea de a începe un proiect. Sau putem face o prognoză.

Prognoza unei viteze implică luarea poveștilor în valoare de un sprint și împărțirea lor în sarcini care sunt efectuate pentru a finaliza povestea. Am estima numărul de ore pe care le va dura fiecare sarcină, care include proiectare, dezvoltare, testare și așa mai departe, și am evalua cât de multă capacitate ar avea echipa într-un sprint dat. O capacitate de 70 la sută pentru o echipă liberă este o bază bună. Deci, într-o situație simplă, dacă numărul total de ore disponibile echipei este:

• 4 membri ai echipei * două săptămâni * 40 de ore pe săptămână = 320 de ore
• Înmulțit cu capacitatea noastră de 70% = 224 de ore
• Adunați toate sarcinile caracteristice și opriți numărarea la 224
• Luați toate caracteristicile finalizate, adunați punctele lor de poveste și obțineți viteza, să zicem 36
• Aplicați 20% pe fiecare parte pentru a obține o gamă dintre cele mai mici și cele mai mari, pentru a ajunge la o viteză estimată de 29 până la 43 de puncte de poveste.

Viteza variază de obicei în primele două până la patru iterații și apoi se stabilizează într-un interval mic de puncte. Așadar, acolo unde intervalul nostru inițial înainte de sprintul unu era de 29 la 43, până la sprintul patru, acesta poate scădea de la 34 la 38. Acest lucru ne oferă apoi mai multă încredere în prognoza datei finale de finalizare.

Planuri de tamponare pentru risc și incertitudine

Toate proiectele software vin cu un nivel de incertitudine. Această incertitudine scade pe măsură ce progresăm prin proiect și se știe mai multe despre tehnologia noastră, mediu, performanță și nevoile clienților și utilizatorilor.

Atenuăm această incertitudine sau risc cu un tampon în program, care explică o marjă de eroare în estimarea noastră și necunoscutele pe care nu le putem determina înainte de începerea dezvoltării.

De obicei, există două tipuri de buffer: Feature și Schedule. Deoarece definim adesea un preț fix pentru o dată fixă ​​de livrare, este de preferat să folosim funcția tampon.

Această abordare ne oferă o strategie credibilă de atenuare a riscurilor și oferă clienților încredere în ceea ce ar trebui să se aștepte să vadă ca rezultat când proiectul este finalizat.

Funcții tampon

Cu un tampon de caracteristici, prognozăm că vom oferi un anumit set de caracteristici, dar în mod ideal vom completa un set suplimentar de caracteristici. Acest lucru ar trebui să reflecte cel puțin setul minim de caracteristici pe care clientul îl consideră necesar pentru a lansa un produs viabil, dar mai multe pot fi livrate în intervalul de timp dacă toate influențele interne și externe o permit.

Deci, un client poate decide că funcțiile cu cea mai mare prioritate din stocul de produse, adăugând până la 100 de puncte de poveste, sunt cele mai importante. Apoi, ei pot lua în considerare funcții suplimentare care se adună până la încă 30 de puncte de poveste. Prin urmare, echipa va planifica pe baza livrării a 130 de puncte de poveste, minim 100 fiind finalizate până la sfârșitul datei de finalizare programate pentru contractul cu preț fix dat.

Câteva gânduri de încheiere

Agile poate fi un concept foarte dificil de înțeles și adoptat pe deplin. Acest lucru nu este mai puțin adevărat atunci când gestionați subiecte sensibile, cum ar fi prețul, domeniul de aplicare și durata. Din păcate, știu de prima mână că clienții pretențioși doresc toate lucrurile să fie reparate din față și sunt dornici să învinovățească furnizorul când totul începe să se destrame. În egală măsură, sunt conștient de vânzători care se îndepărtează, nu răspund și nu răspund nevoilor clienților. Alegerea unei căi Agile se bazează în mod fundamental pe încredere, relații bune și comunicare excelentă. Acestea trebuie să fie valori deținute de ambele părți pentru a menține un proiect sănătos pentru beneficiul, satisfacția și succesul egal pentru toți cei implicați. Menținerea unei minți deschise și a unei atitudini constructive față de colaborare și negociere este cea mai bună modalitate de a evita ca relațiile să se înrădăcineze.

Am lucrat cu clienți cărora le-a fost greu să îmbrățișeze natura adaptativă a Agile și să renunțe la o atitudine de comandă și control. Este greu să renunți și să-ți pui toată încrederea și încrederea într-o echipă pe care nu o cunoști. Adesea, clienții pot dori să creeze toate cerințele în avans ca o specificație a ceea ce va fi livrat. Acest lucru le oferă un sentiment de încredere că domeniul de aplicare al unui proiect este bine definit. Dar, în cele din urmă, acest lucru nu reușește să se concretizeze ca o abordare de succes. Dacă suntem blocați în domeniul de aplicare și a cerințelor nerealiste într-un contract, problemele apar foarte repede.

Știm, atunci când adoptăm această abordare în metodele tradiționale, că domeniul de aplicare se schimbă, necunoscute sunt descoperite sau ceea ce credeam că își dorește clientul nu mai este adevărat sau nu mai este deloc de acord. Adoptarea unei abordări adaptative a prețurilor, planificarii și domeniului de aplicare permite clienților să-și identifice cu adevărat produsul pentru a fi exact ceea ce are nevoie de piață. Acesta permite unui furnizor să fie receptiv, imaginativ și eficient. Valorificarea colaborării dintre client și furnizor în privința negocierii contractului este esențială.

Furnizorii trebuie să fie onești, iar clienții trebuie să fie realiști cu privire la ceea ce se poate realiza încă de la început. Un furnizor care promite obiective nerealiste și apoi crește costurile poate câștiga contractul inițial, dar va pierde în curând favoarea unui client nemulțumit. Prea des, relațiile se rup din cauza lipsei de încredere între părți. Încrederea trebuie să fie construită de la început și menținută pe tot parcursul unui proiect. Un furnizor trebuie să fie flexibil și să coopereze cu nevoile în schimbare. Clienții își doresc întotdeauna mai mult; este o consecință naturală a afacerilor. Trebuie să existe un schimb de valori egal și benefic între ambele părți. Pentru clienți, ei caută să creeze valoare pentru afacerea lor. Pentru furnizori, aceștia ar trebui să caute să creeze valoare prin formarea de relații de lungă durată cu clienții. Respectarea valorilor și principiilor directoare ale Manifestului Agile este o bază solidă pentru formarea de relații puternice, echilibrate și de lungă durată.

rezumat

Sper că acest lucru v-a oferit câteva informații despre planificarea, estimarea și definirea unui preț pentru un proiect software Agile. Toate abordările și tehnicile de mai sus sunt concepute pentru a construi încrederea într-o echipă și pentru a construi încrederea în mintea clienților cu privire la cât timp și cât va dura construirea unui produs software. Și în cele din urmă, pentru a construi încrederea în luarea unei decizii de a continua.

Urmați aceste instrucțiuni și veți fi sigur că veți găsi o cale satisfăcătoare pentru a vă aduce produsul software la viață.