Utilizarea foilor de calcul Agile pentru estimarea descoperirii

Acest articol include o foaie de calcul preformatată pentru a vă ajuta să dezvoltați estimări de descoperire Agile. De asemenea, include informații care să vă ajute să urmați exemplul prezentat. Puteți face o copie editabilă (Fișier>Fă o copie sau Fișier>Descărcați) din șablon aici.

Clienții îmi cer adesea să ofer estimări Agile înainte să am o echipă sau să cunosc cerințele MVP. În această etapă incipientă, nu am acces la valori tradiționale, cum ar fi viteza, numărul de sprinturi sau costul echipei pentru a calcula acele estimări. Dar clienții vor răspunsuri. Pot lansa un produs ipotetic în două sau șase luni? Va fi fezabil pentru bugetul lor (de obicei mic)?

Introduceți foaia de calcul Agile.

Foile de calcul sunt o alegere potrivită – dar adesea trecută cu vederea – pentru o mentalitate Agile. Sunt instrumente low-tech, high-touch, care încurajează colaborarea. Acestea fiind spuse, clientului dumneavoastră probabil că nu îi pasă dacă instrumentele dumneavoastră sunt „aprobate Agile”, atâta timp cât costul și calitatea produsului îndeplinesc cerințele lor. Adevărata valoare a foilor de calcul constă în accesibilitatea lor pentru managerii de proiect și părțile interesate de toate nivelurile de experiență.

Multe instrumente specializate de management de proiect au curbe de învățare prea abrupte pentru utilizatorii fără experiență în proiecte cu mișcare rapidă. Deci, cu cât este mai ușor pentru clienți, proprietari de produse și dezvoltatori să actualizeze cerințele și costurile forței de muncă, cu atât mai repede veți ajunge la o estimare realistă. Cu o foaie de calcul preformatată, managerii de proiect pot ajusta valorile și parametrii pentru a demonstra efectele fiecărei resursă fluctuantă sau cronologie care se schimbă.

Foile de calcul sunt, de asemenea, o modalitate excelentă de a împărtăși cunoștințele cu colegii tăi. Foaia de calcul pe care o folosesc provine de la un coleg Toptal și de atunci am făcut o copie și am modificat-o pentru a se potrivi nevoilor mele. Vă încurajez și pe voi să o faceți.

În acest articol, demonstrez cum să livrez estimări de succes pentru descoperiri, care să permită clienților și părților interesate să se alinieze la obiectivele proiectului și să continue dezvoltarea. Iată cum să completați spațiile libere și să oferiți o estimare în faza inițială pe care o puteți rezista.

Abordați mai întâi viziunea produsului și foaia de parcurs

Să presupunem că clientul tău dorește să dezvolte un site de întâlniri cu un buget fix, dar detaliile produsului sunt neclare. Fără a cunoaște costul și viteza echipei, viziunea despre produs este cel mai bun loc pentru a începe, deoarece necesită ca părțile interesate să cadă de acord asupra unui obiectiv de design și promovează transparența în cadrul echipei.

Îmi place formatul de viziune a produsului Scrum.org pentru stilul său narativ intuitiv. Iată cum arată:

Odată ce viziunea produsului este setată, puteți adăuga foaia de parcurs al produsului într-o nouă filă de foaie de calcul pentru a oferi clientului o idee despre programul de proiect pe termen lung. Foaia de parcurs ar trebui să enumere obiectivele, caracteristicile cheie și termenele limită pentru fiecare versiune a foii de parcurs de produs.

Versiunile roadmap sunt ediții planificate, destinate consumatorilor sau clienților unui produs, care îi ghidează traiectoria pe piață. Prima versiune de roadmap este produsul pe care îl puteți debuta pe piață. Versiunile ulterioare ale foii de parcurs reprezintă lansări de piață cu caracteristici noi convingătoare care se aliniază cu viziunea produsului.

Pentru a folosi Microsoft ca exemplu: Windows 8 a fost probabil o versiune de foaie de parcurs. Windows 10 a fost o altă versiune de foaie de parcurs care a prezentat multe caracteristici noi și de dorit.

Odată ce viziunea produsului și foaia de parcurs sunt complete, este timpul să ceri clientului să se angajeze pentru un MVP.

Negociați caracteristicile MVP cu diagrama de constrângeri triple

Acesta este momentul să modelați așteptările clientului dvs. în funcție de timp și cheltuieli, folosind diagrama Triple Constraint:

Într-o abordare în cascadă, caracteristicile fixe dictează timpul și costul, iar dezvoltarea continuă conform unui plan detaliat al proiectului. În schimb, costurile fixe și programul Agile determină caracteristicile produsului, iar aceste caracteristici sunt reprioritizate în mod constant pe baza viziunii mai flexibile a proiectului.

Diagrama Triple Constraint arată clientului că includerea tuturor caracteristicilor dorite în prima versiune va crește timpul de dezvoltare și costurile de balon. În schimb, colaborați cu clientul pentru a selecta doar funcțiile „must-have” pentru un MVP și pentru a prezenta toate funcțiile rămase pentru versiunile viitoare.

Foile de calcul facilitează gruparea și reatribuirea funcțiilor către diferite versiuni, versiuni și priorități în funcție de nevoile de schimbare ale clientului și afișează instantaneu costurile acestor modificări.

În timp ce identificați funcțiile MVP, cereți-vă experților în domeniu (IMM-uri) ajutor pentru a enumera pașii proiectului pe baza unor proiecte similare la care au lucrat. Veți folosi acești pași pentru a crea epopee mai târziu. Odată ce aveți acele intrări gata, puteți începe să construiți o estimare.

Începeți cu mărimea tricoului

Pentru a începe primul acumulat, cereți proprietarului produsului o descriere detaliată a caracteristicilor produsului, apoi atribuiți o dimensiune de tricou fiecărei caracteristici în funcție de nivelul de dificultate.

Dimensiunea tricoului va arăta complexitatea relativă și durata fiecărei sarcini de dezvoltare înainte de a avea valori absolute. Pe măsură ce trecem mai departe în planificarea proiectelor, vom converti aceste dimensiuni relative în puncte de poveste și ore de lucru.

De exemplu, dacă clientul dvs. dorește să dezvoltați o serie de ferestre pop-up pe site-ul de întâlniri, acest lucru ar consuma mult timp, dar simplu. Ați putea caracteriza această complexitate a sarcinii drept „mică”, dar efortul ar fi un „mediu”. Puteți prescurta aceasta ca „SM”. Pe de altă parte, dezvoltarea unei conexiuni back-end pentru un nou API ar fi o sarcină mai complexă datorită tuturor documentației și testelor necesare. Abilitatea și atenția necesare pentru aceasta ar putea face ca acesta să fie un „Mare” atât în ​​ceea ce privește efortul, cât și nivelul de calificare: „LL”.

Odată ce ați terminat de mărirea tricourilor, veți avea o idee despre volumul de muncă relativ și cerințele de calificare pentru fiecare membru al echipei viitor. Un expert tehnic din echipa de dezvoltare vă poate ajuta apoi să corelați mărimea tricoului cu intervale de ore și puncte de poveste.

Setați-vă parametrii

Acum sunteți gata să puneți foaia de calcul la lucru și să calculați estimarea. Începeți prin a crea o filă Parametri. Aceasta va servi drept cheie pentru calculele dvs., iar valorile pe care le introduceți aici vor fi introduse în formulele utilizate în filele Backlog/User Stories și Estimate Summary by Release.

Iată tot ce aveți nevoie în fila Parametri:

Valută. Aici introduceți conversiile valutare. De exemplu, dacă bugetul clientului este în real brazilian, puteți introduce rata de conversie curentă pentru dolari sau euro.

Data de început. Data estimată de începere a dezvoltării va fi utilizată pentru a crea o cronologie a proiectului. În fiecare exemplu, data noastră de începere este 25 octombrie.

Bugetul Inițial. Bugetul oferă constrângeri care arată dacă toate funcțiile MVP se vor încadra sau nu în el.

Dimensiunea tricoului. Introduceți mărimile tricourilor dvs. ca tabel și atribuiți puncte de poveste și un interval de ore fiecărei combinații de mărimi. În acest exemplu, folosim una până la două ore pentru un SS și 33 până la 48 de ore pentru un LL.

Rețineți că durata sprintului dvs. va limita orele maxime ale mărimii tricoului. Dacă sprintul este de doar o săptămână, cea mai mare dimensiune nu poate depăși 40 de ore. Acesta este motivul pentru care consultarea unui IMM este atât de importantă atunci când atribuiți dimensiunile tricourilor sarcinilor .

Tarife pe oră. Utilizați acest tabel pentru a documenta ratele de plată pentru fiecare rol. Dacă dezvoltatorii dvs. back-end au tarife diferite, utilizați media celor două.

deasupra capului. Alocați un procent din efortul total al proiectului pentru sarcini administrative, cum ar fi întâlniri de stare, sesiuni de feedback și revizuiri ale proiectelor. Zece la sută (sau patru ore din săptămâna de lucru a fiecărui participant) este un loc bun pentru a începe, dar cheltuielile generale pot fi mai mari pentru proiecte mai complexe.

Contingenta. Aceasta indică variația potențială a estimării dvs. Începând cu o contingență de 0%, vă va arăta cel mai bun caz (adică, puțin probabil) buget și cronologie, având în vedere valorile pe care le-ați introdus în foaia de calcul. Mai târziu, în exemplul nostru, vom crește contingența la o variație aproximativă a ordinului de mărime (ROM) de 50% pentru a arăta potențialul final ridicat al costurilor și durata proiectului. Contingenta se va micșora pe măsură ce obțineți numere mai precise.

Dimensiunea fiecărei lansări cu epopee

Începem cu o dimensionare aproximativă a întregului produs pentru a ne asigura că nu pierdem timpul sau banii clientului. În funcție de cât de aproape se apropie dimensionarea de bugetul propus și de termenul limită, clientul poate decide să abandoneze proiectul sau să investească în estimări mai detaliate. Deoarece nu avem prea multe detalii în acest moment, introducem principalele caracteristici ca epopee în fila Backlog/User Stories. Apoi, pentru fiecare epopee, introducem numărul de ore pe care IMM-urile și liderii de dezvoltare le-au sugerat pentru fiecare stivă de dezvoltare pe baza tabelului de mărimi a tricourilor din fila Parametri.

Mai întâi, selectați coloana „EPIC?” și asigurați-vă că este selectat doar „Epic”.

Apoi, scrieți descrierea epică și introduceți numărul de ore pentru fiecare coloană a stivei de dezvoltare. De exemplu, epicul „Conexiune și autentificare sigură” va dura aproximativ opt ore de dezvoltare a interfeței de utilizare, 40 pentru back-end și așa mai departe.

Observați că, în majoritatea cazurilor, celulele din coloana „Punct” afișează „34*”. Dacă reveniți la fila Parametri, veți vedea că 34 de puncte corespund unui interval orar între 33 și 48 de ore. Acest număr de ore este prea mare dacă durata sprintului nostru este de doar o săptămână.

Odată ce avem mai multe detalii, aceste ore vor trebui reduse, sau epopeele trebuie împărțite în povești mai ușor de gestionat. Cu toate acestea, de dragul timpului, vom ignora coloana Puncte și vom continua cu estimarea aproximativă.

Acum accesați fila Rezumatul estimării după lansare. În partea de sus a foii de calcul, veți vedea valorile „General” și „Contingence”, așa cum sunt definite în fila Parametri. Există, de asemenea, un buton pe care îl puteți selecta pentru a afișa estimări după epopee sau povești ale utilizatorilor.

Deoarece nu avem încă povești de afișat, bifați butonul „Mod epic”.

Acum puteți vedea costul aproximativ și termenele pentru MVP și funcțiile și actualizările mai puțin urgente în versiunile viitoare (R3 și R4). În acest exemplu, a doua versiune (R2) este goală, deoarece clientul a solicitat ca toate epicurile MVP să fie lansate în prima versiune.

Acum puteți vedea cel mai optimist cost agregat: 28.810 USD. Această cifră este suma costului fiecărei lansări de la MVP până la R4.

Avem, de asemenea, o estimare a celui mai scurt termen pentru livrarea produsului, care corespunde celei mai recente date de finalizare din stiva de dezvoltare R4. Managerii de proiect numesc aceste stive de dezvoltare mai lente „căi critice”, deoarece ele dictează viteza întregii versiuni.

În acest caz, calea critică este dezvoltarea front-end, cu o dată de finalizare de 31 ianuarie.

Acum este timpul să ajustați parametrii pentru a simula bugetul din cel mai rău caz și cea mai lungă cronologie.

Ajustați situația la 50%

Știm încă relativ puține despre cerințele de efort și expertiză pentru produs, așa că vom adăuga o contingență ROM de 50% în fila Parametri. Contingenta va scadea pe masura ce vom afla mai multe detalii despre proiect.

Din nou, iată estimarea totală a proiectului la 0% contingent.

Și aici este la 50% contingență.

Asta înseamnă că estimarea ROM pentru întregul proiect este între 28.810 USD și 41.860 USD. În cele mai bune și mai rele cazuri, bugetul de 20.000 USD al clientului nu va fi suficient pentru a include toate funcțiile pe lista de dorințe.

Data completă de finalizare a proiectului, la 50% contingent, cade acum pe 14 martie, cu șase săptămâni mai târziu decât data finalizării 0% contingent.

Între timp, MVP-ul va fi gata pe 10 ianuarie.

În loc să abandoneze proiectul, clientul solicită o estimare mai detaliată pentru a vedea dacă ar putea ajunge mai aproape de bugetul țintă într-un timp mai scurt.

Restabiliți prioritățile pentru a respecta termenele limită

Să presupunem că clientul stabilește o dată țintă de 25 decembrie pentru MVP, la două luni de la startul din 25 octombrie.

Pentru a crește data actuală de finalizare a MVP din 10 ianuarie, clientul a fost de acord să amâne două epopee MVP până la următoarea lansare (R2).

Foaia de calcul calculează efectul în cascadă al acestei ajustări. În acest caz, cronologia MVP se scurtează până la 27 decembrie. Dezvoltarea front-end și back-end sunt căile critice în această simulare, deoarece vor dura cel mai mult pentru a fi finalizate.

Pe baza acestor informații, ați putea decide să adăugați încă doi dezvoltatori pentru a alinia datele de finalizare front-end și back-end cu celelalte stive de dezvoltare. Pentru a face acest lucru, creșteți orele de la 40 la 80 în rândul MVP „Ore pe săptămână”.

Ambele stive de dezvoltare front-end și back-end se termină acum în noiembrie, iar QA devine noua cale critică (cu data de finalizare a 20 decembrie). Rețineți că costul nu se modifică. Asta pentru că orele totale de lucru din fiecare stivă rămân aceleași. În loc să lucreze un dezvoltator timp de două săptămâni (80 de ore), doi dezvoltatori lucrează timp de o săptămână (80 de ore).

Foaia de calcul ține seama și de diferențele dintre munca cu normă întreagă și cea cu normă parțială. Să presupunem că dezvoltatorul UI va lucra cu jumătate de normă. Putem schimba interfața de utilizare „Ore de proiectare pe săptămână” la 20 pentru a simula întârzierea livrării.

Într-un program cu normă întreagă, UX/UI va fi finalizat pe 29 noiembrie.

Pe un program part-time, UX/UI va fi finalizat pe 27 decembrie.

Încă o dată, costul nu se schimbă, dar UX/UI devine noua cale critică, prelungind termenul pentru MVP până pe 27 decembrie.

Puteți continua această abordare prin încercare și eroare până când ajungeți la o cale critică acceptabilă, având în vedere resursele dvs. și termenul limită al clientului. Odată ce este stabilit un termen limită adecvat, este timpul să începeți să vă ajustați estimarea.

Rafinați-vă estimarea cu poveștile utilizatorilor

Deoarece estimarea de 50% a căzut în afara bugetului clientului, merită să vă rafinați variabilele, astfel încât să puteți reduce contingența și să obțineți o estimare mai realistă.

Pentru a face acest lucru, colaborați cu dezvoltatorii și IMM-urile dvs. pentru a vă împărți epopeele în povești detaliate ale utilizatorilor. Poveștile sunt mai bine definite decât epicurile, așa că le putem dimensiona mai precis.

Apoi, ajustați valorile din fila Parametri pe baza oricăror informații noi. De exemplu, IMM-urile și echipa dvs. de dezvoltare pot avea un set mai precis de tarife pentru fiecare rol și ar putea dori, de asemenea, să ajusteze mărimile tricourilor și alocările de puncte. Cu acești parametri noi, puteți avea mai multă încredere în calculele dvs. și puteți reduce contingența la 25%.

Să vedem cum am împărțit epopeele în povești mai mici și mai detaliate:

Spre deosebire de estimarea epică care necesita introducerea manuală a orelor estimate pentru fiecare stivă, estimarea poveștii folosește dimensiunea tricourilor ca scurtătură. Aici vă sunt utile mărimile de tricouri pe care le-ați introdus în fila Parametri.

Sub „Mărimea tricourilor” din fila Backlog/User Stories, introduceți combinația de dimensiuni pe care dezvoltatorii și IMM-urile dvs. au atribuit-o stivelor lor pentru fiecare poveste. De acolo, formula foii de calcul va completa automat orele corespunzătoare din fila Parametri. Amintiți-vă că cea mai mare dimensiune, LL, trebuie să rămână sub 34 de puncte pentru a vă asigura că poate fi finalizată în timpul sprintului convenit. Orice povești care încă evaluează 34 de puncte sau mai mult vor trebui să fie subdivizate.

După ce v-ați asigurat că tuturor poveștilor sunt alocate mai puțin de 34 de puncte, debifați butonul „Mod epic” din fila Rezumat estimare după lansare pentru a vedea doar „Povestea”.

Acum veți vedea un nou set de numere:

După ce am detaliat toate sarcinile și ați respectat doar caracteristicile MVP, calendarul și costul se potrivesc acum cerințelor clientului. Deoarece soldul se încadrează în bugetul lor, clientul decide să continue cu MVP-ul și să îl testeze înainte de a se angaja la versiuni suplimentare.

Fă-l al tău

Foile de calcul sunt simplu de utilizat și, cu unele cunoștințe de bază despre formule (nu sunt necesare macrocomenzi), le puteți adapta la aproape orice nevoie. Dacă cunoștințele dvs. de Excel sunt ruginite, cursurile online despre Udemy și edX vă vor ajuta să vă îmbunătățiți aceste abilități.

Acest articol a tratat estimarea descoperirii, dar puteți utiliza aceeași foaie de calcul pentru a produce diagrame de ardere/burndown, pentru a ajusta cronologie și pentru a calcula estimări bazate pe viteză și sprinturi pentru etapele ulterioare. Folosesc foile de calcul personalizate pentru a completa aplicații, cum ar fi Jira, Asana și Trello, și susțin că sunt un instrument puternic în kit-ul meu de management de proiect. Sper că se vor dovedi la fel de utile și versatile pentru tine.

Preferi foile de calcul personalizate decât instrumentele de gestionare a proiectelor disponibile? Spune-ne de ce sau de ce nu în comentarii.