Respectați-vă termenele limită: metode pe care dezvoltatorii le folosesc pentru a estima efortul

Bună ziua tuturor! Există o cantitate colosală de teorie pe care trebuie să le cunoști pentru a începe dezvoltarea de software. Unii specialiști (de exemplu, dezvoltatorii backend care folosesc Java și alte limbaje) știu mai multe despre asta, în timp ce alții (de exemplu, dezvoltatorii frontend care folosesc JavaScript și React Native) pot cunoaște puțin mai puțin. Acestea fiind spuse, ambele grupuri trebuie să posede un corp mare de cunoștințe nu numai tehnice, ci și „organizaționale”. Aceste cunoștințe „organizaționale” reprezintă un domeniu de suprapunere pentru dezvoltatorii de front-end și backend. Astăzi vreau să vorbesc despre un aspect al acestor cunoștințe non-tehnice, organizaționale. Astăzi vom vorbi despre estimarea efortului . Pentru că am doar experiență în utilizarea metodologiei Agile(care este considerat cel mai popular), mai precis cadrul Scrum, voi lua în considerare estimarea efortului în contextul Scrum . De la bun început, trebuie să spun că estimarea efortului este dificilă. Pentru mine, este unul dintre cele mai provocatoare/neplăcute aspecte ale meserii mele de dezvoltator. Există mulți factori diferiți de luat în considerare care vă pot afecta estimarea efortului necesar pentru o sarcină. În plus, planurile de dezvoltare viitoare se vor baza pe estimările dumneavoastră.

Ce se întâmplă dacă oferiți o estimare proastă?

Dacă un dezvoltator estimează mult mai multe ore pentru o sarcină decât cele petrecute în cele din urmă pe sarcină, expertiza sa poate fi pusă la îndoială, deoarece estimarea a fost atât de inexactă. Cu alte cuvinte, a fost o presupunere sălbatică. În același timp, dacă un dezvoltator nu realizează munca în timpul prevăzut, el pune în pericol planurile clientului de a lansa produsul sau noua funcție. Acestea sunt afaceri, iar afacerile sunt bani. Puțini clienți vor fi mulțumiți de un astfel de derapaj. De fapt, de aceea nu-mi place estimarea - pentru că uneori este foarte dificil să determine cu exactitate timpul necesar pentru a finaliza o sarcină.

Cum să faci o estimare de timp

De regulă, estimările se fac în ore sau puncte de poveste. Preferința mea personală este să fac procesul de estimare folosind puncte de poveste . Este greu să te înșeli în privința obiectelor fizice concrete, dar punctele de poveste sunt puțin mai abstracte. Echipele de dezvoltare de software oferă de obicei estimări ca cantități de timp: ore, zile, săptămâni, luni. Aceste estimări de timp se bazează în principal pe experiența personală, presupuneri și/sau intuiție. În acest caz, dezvoltatorii se uită pur și simplu la sarcină și își exprimă presupunerea cu privire la cât timp le va lua. Ca urmare, aceste estimări sunt foarte rar precise, deoarece există prea mulți factori care pot afecta durata lucrării. De aceea, multe echipe care folosesc metodologia Agile folosesc și puncte de poveste. Să ne scufundăm!

Care sunt punctele de poveste?

Un punct de poveste este o unitate de măsură pentru exprimarea unei estimări a efortului total necesar pentru implementarea completă a unei anumite piese de funcționalitate. Adică vorbim de rudăcomplexitate. Echipele atribuie o estimare în puncte de poveste în funcție de complexitatea muncii, volumul de muncă și riscul sau incertitudinea. Aceste valori sunt de obicei atribuite pentru a împărți mai eficient lucrarea în bucăți mai mici, eliminând astfel ambiguitatea. De-a lungul timpului, acest lucru ajută echipele să înțeleagă ce pot realiza într-o anumită perioadă de timp și le ajută să planifice cu mai multă precizie părțile ulterioare de lucru. Acest lucru poate suna complet contraintuitiv pentru tine, dar această abstractizare este într-adevăr utilă: împinge echipa să ia decizii dificile cu privire la complexitatea muncii. Să aruncăm o privire la câteva dintre motivele pentru a folosi punctele de poveste atunci când planificați:

• Puteți evita estimările inexacte ale timpului.
• Spre deosebire de estimările făcute în unități de timp, punctele de poveste vă permit să contabilizați costurile generale: comunicări între membrii echipei și client, diverse discuții în echipă și activități de planificare, precum și situații neprevăzute.
• Fiecare echipă își va estima munca folosind scale diferite, ceea ce înseamnă că capacitatea lor (măsurată în puncte) va fi diferită.
• Prin definirea unei scale pentru atribuirea fiecărui punct de poveste, puteți aloca rapid puncte fără prea multe controverse.

Cum să NU folosești punctele de poveste

Din păcate, punctele de poveste sunt adesea folosite greșit. Poveștile pot induce în eroare atunci când sunt folosite pentru a evalua oamenii, pentru a defini termene și resurse detaliate și când sunt confundate cu o măsură de performanță. În schimb, echipele ar trebui să le folosească pentru a înțelege sfera/complexitatea fiecărei sarcini și pentru a stabili priorități. Poate că părțile care sunt considerate mai dificile ar trebui abordate mai întâi, astfel încât să poată fi făcute înainte de sfârșitul sprintului , eventual transferând sarcinile mai ușoare la mai târziu. Permiteți-mi să vă reamintesc ce este un sprint în contextul metodologiei Scrum : Durata acestei perioade de timp este determinată când începe dezvoltarea și este convenită între echipă și client. Aceasta poate fi o perioadă de două săptămâni sau o lună sau orice altă perioadă. De regulă, estimările de efort se fac la începutul fiecărui sprint pentru a planifica lucrarea care poate fi finalizată până la sfârșitul sprintului, când lucrarea finalizată este livrată clientului. Demo vă ajută să vedeți progresul dvs. în dezvoltarea produsului, să primiți feedback de la client și să ajustați traiectoria proiectului în funcție de viziunea clientului. Dar ne abatem puțin. Să revenim la estimări. Ar fi prea subiectiv ca un singur dezvoltator să furnizeze estimări pentru toate sarcinile. Deci, acest proces este de obicei un efort de echipă. Există destul de multe tehnici pe care echipele le pot folosi pentru a genera estimări. Astăzi ne vom uita la cea mai populară tehnică: Scrum Poker . Această tehnică necesită un manager care va acționa ca moderator pentru Scrum Poker . Acesta poate fi cineva care este un scrum master sau eventual un PM .

Ce este Scrum Poker?

Scrum poker , sau planning poker, este o tehnică de estimare care se bazează pe ajungerea la un acord. Este utilizat în principal pentru a estima complexitatea lucrărilor care urmează sau dimensiunea relativă a sarcinilor de dezvoltare software. Voi spune imediat acel Scrum Pokereste o practică comună de dezvoltare de software și trebuie să știți despre ce este vorba. De obicei, implică o aplicație sau un site web pentru a facilita crearea în colaborare a unei echipe a unei estimări pentru o anumită sarcină. Cum se întâmplă asta? Echipa preia ceva din restanță (o sarcină nouă, unele funcționalități) și discută pe scurt posibilele capcane și alte nuanțe asociate cu aceasta. Apoi fiecare participant alege un card cu un număr care reflectă estimarea complexității lor. O, încă ceva, atunci când facem aceste estimări, folosim numere din șirul Fibonacci mai degrabă decât numere obișnuite. Numerele Fibonacci sunt populare în Scrum Poker, deoarece între ele există un decalaj din ce în ce mai mare (seamănă cu nivelurile unei piramide). Unele sarcini vor fi foarte complexe și nu vom putea scăpa cu un număr mic de puncte de poveste. Există câteva cărți neobișnuite care au următoarele semnificații:

Număr necunoscut de puncte finale

Sarcină infinit de lungă

Am nevoie de o pauza

Metodele de estimare mai puțin obișnuite folosesc:

• Mărimi tricouri - S, M, L, XL
• Rase de câini - chihuahua, pug, teckel, buldog și așa mai departe (personal, cred că aceasta este cea mai ciudată unitate de măsură pentru estimarea efortului =D)

Echipa compară apoi estimările date de diferiți dezvoltatori pentru aceeași sarcină. Dacă sunt de acord, atunci grozav! Dacă nu, atunci motivele (argumentele) pentru diferitele estimări trebuie discutate. După aceea, echipa lucrează împreună pentru a forma o singură estimare pe care toată lumea o acceptă, mai mult sau mai puțin. Deci, de ce este folosit pokerul pentru a planifica proiecte software serioase? Trebuie să recunoști că acest lucru este ciudat. Cert este că acest tip de gamification încurajează membrii echipei să gândească independent, invitându-i să-și dezvăluie estimările în același timp cu colegii lor. Acest lucru, la rândul său, evită crearea unei situații în care unii membri ai echipei depind de opiniile altora. Dacă nu s-ar proceda astfel, atunci dezvoltatorii mai puțin experimentați s-ar uita și s-ar concentra asupra estimărilor furnizate de membrii echipei mai experimentați, și asta ar face propriile lor estimări mai puțin utile. Dar afișarea simultană a estimărilor face acest lucru practic imposibil. oferte Atlassiano aplicație Scrum Poker pentru utilizare în procesul de planificare.

Exemplu de estimare a efortului

Să presupunem că echipa dvs. a stabilit următoarea scală pentru atribuirea punctelor de poveste estimărilor: Scrum Poker este jucat pentru fiecare sarcină și oferiți o estimare după cum urmează:

• Nu ați mai implementat niciodată o funcționalitate similară: +3
• Funcționalitatea este de dimensiune medie: +2
• Implementarea va fi foarte complexă: +3
• Scrierea testelor pentru funcționalitate va fi foarte complexă: +3

Adunând fiecare componentă, obțineți un total de 11 puncte de poveste, dar nu există o astfel de carte, așa că sugerați 13. Un coleg prezintă următoarea estimare pentru sarcină:

• A mai lucrat cu o sarcină similară: +1
• Funcționalitatea este de dimensiune medie: +2
• Implementarea va fi de complexitate medie: +2
• Testele de scriere pentru funcționalitate vor fi de complexitate medie: +2

Rezultatul său intermediar este de 7 puncte de poveste, dar acel număr nu există în seria Fibonacci, așa că trimite cardul cu cel mai aproximativ număr - 8. Alți membri ai echipei își fac, de asemenea, estimările pe baza opiniilor lor subiective. Apoi toată lumea își arată cărțile și descoperi că aproape toți colegii tăi au dat o estimare de 13, cu excepția unui dezvoltator care a sugerat un 8. În acest caz, i se permite să vorbească și dă motive pentru estimarea sa mai mică. Să presupunem că oferă această justificare: a lucrat anterior la aceeași sarcină și nu este atât de dificil pe cât ar părea. În cele din urmă, el convinge restul echipei să se răzgândească de la 13 la 8 puncte de poveste, spunând că va ajuta pe oricine va ajunge să-și asume această sarcină. Sau poate o va face singur. În orice caz, nu Nu contează dacă ceilalți îi acceptă sau nu argumentele, pentru că într-un fel sau altul i se va atribui o estimare sarcinii, iar echipa va trece la analiza următoarea. Inițial, estimările vor fi inexacte, la fel ca și estimările cantității de muncă pe care intenționați să o efectuați în următoarea perioadă de timp (sprint). La urma urmei, aceste estimări făcute folosind estimări. După ceva timp, poate trei luni mai târziu, echipa va începe să estimeze timpul necesar sarcinilor cu mai multă precizie, iar cantitatea medie de muncă pe care echipa este capabilă să o desfășoare într-un sprint va deveni evidentă. Dar acesta este un proces pentru a face un plan general pentru domeniul de activitate. Se concentrează în principal pe timp, dar în acest caz pot exista mulți factori relevanți diferiți. De exemplu, să presupunem că un dezvoltator a plecat în vacanță timp de două săptămâni. Va trebui să reduceți o anumită cantitate de muncă planificată (funcționalitate planificată). Sau să presupunem că un nou dezvoltator s-a alăturat echipei, dar nu este încă pe deplin la viteză, așa că trebuie să îi acordați timp să se familiarizeze cu proiectul printr-unprocesul de îmbarcare . Acest lucru ar putea dura două săptămâni, da sau ia o săptămână, în funcție de complexitatea proiectului. Asta e tot pentru azi! Sper că v-am îmbunătățit ușor cunoștințele despre estimarea efortului, un aspect non-tehnic necesar al dezvoltării software. Dacă doriți să aprofundați acest subiect și detaliile despre scrum, vă recomand cu tărie să citiți cartea „SCRUM” de Jeff Sutherland. Nu pot face nicio promisiune cu privire la consecinte, pentru ca dupa ce o citesti o sa ai o dorinta enervanta de a deveni scrum master =D