Puncte de poveste Agile față de ore: cum să estimați mai bine dezvoltarea de software

Înfășurarea minții în jurul proceselor de dezvoltare software poate fi dificilă. Când veniți cu o idee și abordați dezvoltatorii cu ea, primele două lucruri pe care le întrebați sunt cât va costa implementarea și cât va dura construirea . Estimarea este unul dintre primii pași în dezvoltarea aplicațiilor.

În acest articol, comparăm cele mai populare două modele de estimare în dezvoltarea software-ului modern: puncte de poveste Agile vs. ore .

Citiți mai departe pentru a afla cum să estimați timpul în Agile, să obțineți esența ambelor modele de estimare, să înțelegeți diferențele lor și să vedeți de ce dezvoltatorii ar putea alege unul peste celălalt.

Orele sunt destul de ușor de înțeles și au fost de mult timp modelul principal de estimare în dezvoltarea de software. Orele, cunoscute și sub numele de ore de muncă sau ore de lucru, reprezintă numărul de ore pe care un dezvoltator le petrece în proiect.

Deci, ce sunt punctele de poveste și de ce au apărut dacă avem deja un model de estimare simplu și direct?

Conținut:

1. Ce anume sunt punctele de poveste?
2. Iată cum sunt calculate punctele de poveste în Agile
3. Avantajele estimării în puncte de poveste
4. Dezavantaje ale estimării în puncte de poveste
5. Avantajele estimării în ore
6. Dezavantaje ale estimării în ore
7. Puteți converti punctele de poveste în ore?
8. Puncte de poveste vs ore: Ce să alegi pentru dezvoltarea de software?

Ce anume sunt punctele de poveste?

Punctele de poveste sunt un model relativ de estimare originar din Agile și Scrum. Ei estimează efortul de a construi un produs abordând trei aspecte ale dezvoltării:

• cantitatea de muncă necesară produsului

• complexitatea caracteristicilor produsului

• riscuri și incertitudini care ar putea afecta dezvoltarea

La începutul evaluării proiectului, dezvoltatorii aleg cea mai mică și simplă poveste de utilizator pe care o are un produs - de exemplu, o poveste de utilizator înscrisă - și o setează ca o poveste de utilizator de 1 punct. Aceasta este povestea de bază : o poveste a utilizatorului care va fi utilizată pentru comparații de complexitate. Toate celelalte povești ale utilizatorilor vor primi un număr de puncte de poveste în funcție de cât de complexe sunt de dezvoltat în comparație cu povestea de bază.

Pare destul de simplu la suprafață, dar cine decide numărul de puncte din fiecare poveste?

Iată cum sunt calculate punctele de poveste în Agile

Ca și în cazul orelor, oamenii care vor lucra la produs estimează de obicei punctele de poveste pentru dezvoltare. Cu toate acestea, procesul de estimare este ușor diferit cu punctele de poveste.

Pentru a atribui puncte de poveste unei povești de utilizator, sunt implicați mai mulți dezvoltatori . Ar trebui să fie cel puțin două, dar compania le poate cere tuturor dezvoltatorilor să contribuie jucând ceea ce industria numește Planning Poker . Iată regulile jocului:

1. Fiecare dezvoltator primește un set de cărți Planning Poker.

2. Dezvoltatorii aleg o poveste de utilizator și discută despre complexitatea acesteia și despre efortul de dezvoltare necesar.

3. Fiecare dezvoltator prezintă un card corespunzător numărului de puncte pe care le-ar atribui poveștii.

4. Dacă estimările punctului de poveste sunt aceleași, numărul estimat de puncte este atribuit poveștii.

5. Dacă punctele de poveste sugerate diferă, dezvoltatorii discută despre povestea utilizatorului până când vin cu un număr de puncte aprobate de majoritate.

6. Dezvoltatorii aleg următoarea poveste a utilizatorului.

7. Repetați pașii de la 3 la 5.

Când toate activitățile noastre s-au îndepărtat, acest proces a fost modificat. În loc de cărți și întâlniri, punctele de poveste se decid în discuții online, în timpul întâlnirilor Zoom sau în mesageri.

Arată cam așa:

Asta nu înseamnă că toți dezvoltatorii implicați în estimarea punctelor de poveste vor lucra la proiect, desigur. Dar un avantaj cheie al sistemului de puncte de poveste este acela că creează un cadru mai mult sau mai puțin universal care poate fi folosit nu doar pentru proiectul în cauză, ci și pentru proiectele viitoare cu caracteristici similare.

Există două opțiuni utilizate frecvent pentru estimarea punctelor de poveste. Puteți atribui puncte:

• folosind orice numere întregi (1, 2, 3 ... 13,14,15 etc.)

• folosind numere în secvența Fibonacci (1, 2, 3, 5, 8, 13 ... 55, 89, 144 etc.)

Secvența Fibonacci este o opțiune mai convenabilă pentru estimarea dezvoltării, deoarece lasă o marjă de aproximare. Modelul de ordine numerică este puțin prea precis pentru comparații convenabile.

În timpul dezvoltării și între proiecte, dacă povestea utilizatorului ajunge să fie mai mult sau mai puțin complexă decât se estimase inițial, punctele de poveste atribuite ar putea fi modificate.

Avantajele estimării în puncte de poveste

Dacă procesul de atribuire a punctelor povestirii pare puțin complex, nu lăsați-l să vă dea jos. Există avantaje în planificarea capacității cu puncte de poveste.

1. Punctele de poveste sunt independente de dezvoltator

Punctele de poveste pentru fiecare poveste sunt atribuite de mai mulți dezvoltatori în cadrul negocierilor , iar motivul este că numărul este atribuit nu doar pentru un anumit produs și un anumit dezvoltator, ci „în medie”. De ce este un lucru bun?

Se intampla. Uneori, dezvoltatorul proiectului dvs. ar putea părăsi proiectul dvs. și va fi înlocuit. Poate că se vor îmbolnăvi, vor decide să-și ia concediu pentru creșterea copilului sau un sabat sau pur și simplu să părăsească compania. Poate că se vor dovedi a fi insuficient calificați sau supracalificați pentru proiect.

Când sunt înlocuiți, un dezvoltator nou ar putea avea o viteză de lucru diferită , ceea ce va duce la reestimarea orelor de lucru necesare creării produsului.

Punctele de poveste minimizează această problemă . Alocate de mai mulți dezvoltatori diferiți, acestea oferă o privire generală asupra cât de complexă este o anumită poveste de utilizator. Punctele de poveste funcționează pentru toți dezvoltatorii dintr-o anumită companie. (Deși vă rugăm să rețineți că estimările punctelor istorice nu vor fi corecte pentru diferite companii.)

2. Punctele de poveste facilitează recalcularea timpului de dezvoltare

În estimarea timpului Agile cu puncte de poveste, echipele folosesc termenul viteză pentru a se referi la numărul de puncte de poveste eliberate într-un singur sprint.

Echipele își monitorizează constant viteza și este destul de variabilă la început. O echipă poate lansa caracteristici în valoare de cinci puncte de poveste într-o săptămână și douăzeci de puncte de poveste în următoarea. Dar asta este doar la început. Pe măsură ce proiectul progresează, graficul vitezei se va uniformiza .

Cu orele, dacă un membru al echipei se schimbă, fiecare sarcină în care este implicat va trebui să fie reestimată pentru a ajusta termenele. Cu puncte de poveste, acest lucru nu este necesar - echipa poate ajusta termenul limită al proiectului după următorul sprint cunoscând schimbarea vitezei totale.

Punctele de poveste evaluează performanța echipei în ansamblu , eliminând necesitatea reestimării în funcție de sarcină.

3. Punctele de poveste sunt bune pentru monitorizarea performanței echipei

Când aveți echipe care lucrează la proiecte și / sau sarcini similare în momente diferite, viteza vă poate arăta cu ușurință progresul realizat de fiecare echipă. S-au îmbunătățit și cu cât? Care echipă sau dezvoltator se luptă și ar putea avea nevoie de o pregătire suplimentară? Care este curba de învățare? Poate o altă echipă are performanțe mai bune?

Viteza este un instrument excelent pentru a evalua performanța echipelor dvs. nu doar pe loc, ci continuu.

4. Estimarea timpului de lansare cu puncte de poveste este mai precisă

Urmărind viteza, echipa știe cu mare precizie câte puncte de poveste pot elibera într-un sprint. Deși echipa de dezvoltare a aplicației necesită ceva timp pentru a-și calcula viteza, odată calculată, data estimată a lansării este ușor de prezis .

Mai mult, schimbările în membrii echipei, cerințele sau numărul / complexitatea caracteristicilor nu provoacă multe lupte cu reestimarea.

5. Puteți reutiliza punctele de poveste pentru proiecte viitoare pentru a accelera estimarea

Nu este neobișnuit ca o companie să fie bine versată într-o nișă specifică (sau mai multe) și să construiască mai multe produse cu un set similar de caracteristici. După finalizarea unui singur proiect estimat în puncte de poveste, dezvoltatorii pot consulta această estimare pentru proiecte noi . Acest lucru va scurta timpul pentru estimare.

Cu toate acestea, este important să urmăriți în continuare viteza pentru fiecare proiect, deoarece circumstanțele se pot schimba.

6. Punctele de poveste îmbunătățesc munca în echipă

În mod tradițional, companiile de dezvoltare au mai multe echipe de dezvoltatori, fiecare lucrând la proiecte separate. Atunci când se estimează în ore, dezvoltatorul care lucrează la proiect este cel care face o estimare. Acesta este un lucru bun, în general, deoarece cine știe mai bine cât va dura ceva decât persoana care o face?

Cu toate acestea, estimarea complexității punctelor de poveste oferă o oportunitate dezvoltatorilor din același domeniu de a coopera - lucru care se întâmplă rar altfel. Acest tip de lucru în echipă oferă o mare șansă de a împărtăși experiențe și de a se motiva reciproc.

Dezavantaje ale estimării în puncte de poveste

Există întotdeauna cealaltă parte a argumentului, care este modul în care se nasc sistemele grozave. Estimarea bazată pe complexitate are și dezavantajele sale și fiecare echipă trebuie să decidă singură dacă depășește avantajele.

1. Punctele de poveste ar trebui să fie atribuite de mai mulți dezvoltatori

Punctul de vânzare al modelului punctelor de poveste este obiectivitatea și valoarea sa pentru estimări viitoare. Dar pentru ca acest lucru să fie adevărat, estimarea trebuie făcută de mai mulți dezvoltatori . Pentru companiile mici cu o singură echipă sau companiile în care există un singur specialist într-un domeniu (adică un singur designer sau dezvoltator iOS), punctele de poveste nu aduc atâtea avantaje. Astfel de companii mici aleg în mod tradițional orele de lucru ca model de estimare.

2. Estimarea în puncte de poveste necesită o întârziere considerabilă

Pentru a realiza întregul potențial al punctelor de poveste, echipa dvs. va trebui să petreacă o cantitate considerabilă de timp . Dacă lucrați la un proiect cu funcții la care echipa nu a lucrat anterior (sau nu a lucrat la normă întreagă), primele două până la trei sprinturi vor fi greu de prezis în funcție de performanță. Acordat, cu cât echipele dvs. au mai multe articole restante, cu atât mai precise sunt estimările lor datorită abundenței datelor statistice. Dar Story Points nu este un sistem care este gata să funcționeze imediat.

3. Punctele de poveste sunt mai complexe pentru bugetare

Punctele de poveste sunt minunate pentru stabilirea termenelor precise și a datelor de lansare, care pot fi importante pentru dezvoltatori și pentru marketingul clientului. Cu toate acestea, atunci când vine vorba de estimarea costurilor de dezvoltare a aplicațiilor, acestea sunt mai puțin convenabile .

Problema este că dezvoltatorii petrec timp într-un proiect nu numai scriind cod (sau realizând desene sau testând). Se petrece ceva timp în cercetare, discuții - în interiorul echipei și cu clientul - făcând schimbări etc. Timpul petrecut estimând punctele de poveste este, de asemenea, timpul petrecut în proiect, dar nu este inclus în punctele pe poveste.

Este posibilă bugetarea atunci când se estimează în puncte de poveste, dar de obicei este mai rapid și mai ușor să echivalăm banii cu timpul petrecut în proiect.

4. Viteza este calculată pe echipă

Ceea ce înseamnă acest lucru este că, dacă echipele se amestecă între proiecte, va trebui să calculați viteza pentru fiecare combinație de dezvoltatori separat. Prin urmare, estimarea pentru o echipă nu va fi neapărat adevărată pentru o altă echipă și chiar și schimbarea unui singur membru al echipei poate invalida estimările anterioare.

Pe de altă parte, puteți utiliza estimarea complexității pentru a găsi combinațiile cele mai performante. Va dura totuși.

Avantajele estimării în ore

În timp ce unele echipe Agile folosesc puncte de poveste, multe nu au trecut încă de la orele de lucru. Există motive importante pentru asta. Să le acoperim și noi.

1. Ore este un model familiar

Inovația este grozavă, dar este nevoie de timp. Dezvoltatorii și clienții lor sunt, deopotrivă, cunoscuți în estimarea orelor de lucru. Pentru mulți, ideea este „dacă nu se rupe, nu o rezolva”. Atâta timp cât sistemul oferă estimări viabile, de ce să treceți la altceva?

S-ar putea ca diferența în precizia estimărilor să nu fie suficient de mare pentru ca unii dezvoltatori să schimbe modul în care fac lucrurile.

2. Clienții plătesc de obicei ore întregi

Acest lucru are nevoie de puține elaborări. Pentru clienți, estimarea bazată pe complexitate poate fi confuză . Mai mult, dacă pentru client bugetul este mai important decât data lansării (ceea ce este deseori), punctele de poveste nu vor fi relevante pentru ei.

3. Estimarea bazată pe ore poate fi făcută de un singur dezvoltator

Pentru echipele mici sau freelanceri, punctele de poveste sunt în mare măsură inutile, deoarece necesită mai multe puncte de vedere. Fără nicio referință, estimarea în puncte de poveste este o problemă inutilă.

Ore, pe de altă parte, oferă dezvoltatorului care lucrează la proiect o modalitate de a face estimări destul de precise .

Același lucru este valabil și pentru viteza echipei. Când echipele se schimbă de fiecare dată, așa cum se întâmplă cu freelanceri sau externalizarea parțială, viteza de monitorizare are foarte puțin sens. Estimarea bazată pe ore este cea mai bună alegere aici.

Dezavantaje ale estimării în ore

Iată motivele pentru care echipele ar putea decide să nu mai folosească orele ca model de estimare.

1. A fi singurul responsabil pentru estimare înseamnă multă presiune

Pe de o parte, estimarea propriilor cerințe de timp poate fi mai ușoară, deoarece te bazezi doar pe tine.

Pe de altă parte, dacă nu reușiți să vă îndepliniți estimările, este o lovitură uriașă. Mai mult, dacă echipa care așteaptă să-și înceapă sarcinile depinde de finalizarea ta.

Mai mult decât atât, stresul cauzat de presiunea de a îndeplini ceea ce ați promis dumneavoastră poate perturba o sarcină de altfel bună.

2. Estimarea unui dezvoltator este întotdeauna mai puțin precisă decât cea a unei echipe

Estimările individuale sunt subiective și sunt legate de circumstanțele emoționale și psihologice ale estimatorului.

Unii dezvoltatori tind să se supraestimeze și să stabilească perioade de timp pe care ulterior se luptă să le susțină. Acest lucru nu numai că perturbă dezvoltarea (și stabilește costuri suplimentare pentru echipă dacă există amenzi), dar provoacă și stres și burnout în dezvoltatori .

Alții își subestimează propriile abilități , prelungind dezvoltarea mai mult decât este necesar în mod obiectiv. Insecuritatea și obiceiul de a regândi, verifica și re-verifica munca duc adesea la stabilirea termenelor de dezvoltare la date ulterioare - iar sarcinile sunt rareori finalizate înainte de termenele limită . Contribuția echipei permite estimări mai obiective.

3. Cu cât este mai mare sarcina, cu atât este mai greu de estimat în ore

Acest lucru se corelează și cu situații de nedezvoltare. Este ușor de spus cât timp va dura pentru a citi o broșură universitară de trei pagini, dar mai greu de estimat cât va dura până la finalizarea Războiului și păcii .

Același lucru este valabil și pentru dezvoltare. Sarcinile mici sunt ușor de estimat pentru dezvoltatorii cu o anumită experiență. Cu cât sarcina este mai mare, cu atât mai multe lucruri - care se întâmplă atât în ​​interiorul proiectului, cât și în afara acestuia - pot afecta dezvoltarea. Estimările bazate pe ore nu oferă marjele pe care le au punctele de poveste, făcând estimările mai aspre.

4. Puțină flexibilitate

Estimarea bazată pe ore este bazată pe dezvoltatori. Dacă un membru al echipei care lucrează la produs se schimbă la jumătatea proiectului, echipa va trebui să recalculeze fiecare poveste de utilizator afectată încă în curs de dezvoltare sau programată pentru sprinturi viitoare. Poate fi o mulțime de muncă, în funcție de stadiul în care se află proiectul și de diferența de competențe dintre dezvoltatorul original și cel nou. Estimarea timpului pe ore este destul de rigidă.

Puteți converti punctele de poveste în ore?

Clienții pot solicita unei echipe care face estimări în puncte de poveste pentru a converti maparea Agile a punctelor de poveste în ore . Majoritatea oamenilor care nu sunt familiarizați cu cele mai recente tendințe de dezvoltare software nu vor ști ce să facă din punctele de poveste.

Cu toate acestea, atunci când un client întreabă câte ore este egal un punct de poveste, este imposibil să răspunzi definitiv. Una dintre componentele cheie ale estimării bazate pe complexitate este efortul depus pentru a finaliza povestea. Dar efortul nu se traduce direct în timpul petrecut . Orele abordează incertitudinea într-un mod mai vag decât punctele din poveste.

Cu cât sarcina este mai complexă, cu atât există mai multe incertitudini și riscuri. Conversia punctelor de poveste în ore într-un mod simplu și bazându-se doar pe viteză nu contează multe astfel de riscuri, deoarece estimarea bazată pe ore este mai aproximativă decât punctele de poveste atunci când vine vorba de riscuri și incertitudini.

Într-o anumită măsură, utilizarea secvenței Fibonacci în atribuirea punctelor de poveste va explica incertitudinea în timpurile de dezvoltare, dar nu permite exact o conversie directă.

Iată un exemplu.

O poveste cu 1 poveste (poveste de bază) durează, să zicem, două ore pentru a fi finalizată.

O poveste cu 13 etaje ar putea dura 26 de ore în cel mai bun caz - dacă nimic nu se strică sau nu se împiedică. De exemplu, dacă API-ul utilizat se potrivește perfect, punct final la punct final. Dar dacă nu, povestea ar putea necesita oriunde, să zicem, 30 și 50 de ore - în funcție de câte nepotriviri există. Nimeni nu poate spune în prealabil cum va merge dacă dezvoltatorul nu a lucrat încă cu API-ul în cauză.

Deci, în traducerea punctelor de poveste în ore, trebuie să existe un multiplicator pentru creșterea exponențială pentru a aborda incertitudinea. Și acel multiplicator va diferi de la o echipă la alta.

Puncte de poveste vs ore: Ce să alegi pentru dezvoltarea de software?

După cum puteți vedea, atât punctele de povestire, cât și orele sunt alegeri valabile pentru un dezvoltator pentru a estima proiectele.

Una peste alta, am spune că mai multe companii de produse aleg puncte de poveste, în timp ce externalizatorii tind să se aplece spre ore.

Companiile care lucrează cu un model de preț fix optează de obicei pentru estimări bazate pe ore. Echipele care preferă Scrum aleg deseori puncte de poveste, deoarece literalmente s-au născut din Scrum și sunt originare din această metodologie.
În anii noștri de experiență, am ajuns să o vedem astfel:

• Dacă estimarea exactă a datei de lansare este mai importantă decât ajustarea bugetului, alegeți puncte de poveste.

• Dacă bugetul este mai important decât o dată precisă de lansare, luați în considerare orele.

Sau, cel mai bine, combinați-le pe cele două.

Punctele de poveste sunt extrem de convenabile pentru echipele de dezvoltare care lucrează la proiecte lungi în care viteza de monitorizare va face diferența.

Orele sunt importante pentru clienții care se îngrijorează să se strângă în bugetul lor. De asemenea, orele au mai mult sens pentru proiectele pe termen scurt.

Sistemul bazat pe complexitate este încă destul de tânăr, la fel ca Scrum în sine, și este încă în curs de dezvoltare. Combinarea ambelor modele de estimare și elaborarea unui sistem pentru schimbarea rapidă a fiecărui punct de poveste în ore oferă beneficii ambelor modele, reducând în același timp dezavantajele.