Voi cum estimati story-urile intr-o echipa Agile? Am avut norocul ca de la inceputul carierei sa lucrez exlusiv pe proiecte in care nu se facea deloc estimare. Chiar am crezut ca este normal asa. Pana am ajuns pe un proiect cu story points. Dupa peste un an pe proiect pot sa spun ca este cel mai stupid lucru posibil din industrie.
E normal ca orice estimare, care pana la urma este doar pe ghicite, sa fie luat ca si un contract de catre management?
Cum e posibil sa estimezi in timp o implementare care, presupunand ca nu e sa adaugi un buton care te duca de pe o pagina pe alta, este practic prima data cand a implementat cineva lucrul respectiv, vreodata? Aici nu punem parchet sa poti sa zici cu un grad ridicat de incredere cam cat iti ia pe metru patrat.
Mi se pare ca treaba asta e boala curata, atat pentru proiect ca si pentru echipa de dezvoltare. Inevitabil se ajunge la presiuni incredibile sa termini, incepi sa reduci drastic calitatea codului si orice garantie ca functioneaza e aruncata pe geam.
Fac eu ceva gresit, sau e timpu sa schimb proiectu?
Disclaimer: estimările sunt cea mai slabă calitate a mea. La modul ăla nasol, de-l inspir pe Hofstadter… (nu m-am uitat la video, răspund doar pe restul textului)
Dacă nu ești sigur de estimare, bagi un timp rezonabil, în care ești absolut sigur că e gata.
Având ceva experiență în domeniu, poți să estimezi așa, ochiometric, efortul necesar pentru un task. De exemplu, dacă vine cineva la mine și-mi spune „vreau să randezi scaunul ăsta în threeJS și să fie embedded într-o pagină web” (adică ceva ce n-am mai făcut niciodată) urmez un raționament de genul:
nu am experiență în threeJS
dar am manualul la dispoziție
și am ceva experiență cu canvas
ar dura două-trei zile să mă obișnuiesc cu three
două trei zile să îmi dau seama cum fac x sau y
o săptămână să implementez
o săptămână să testez
(Și îi spun clientului: „vreo trei luni și jumătate. Minimum.” )
Mai în glumă, mai în serios, când chemi un zugrav să-ți renoveze, parcă ai vrea să știi cât o să dureze, chit că este măcar vag aproximativ, nu? Chiar dacă-ți spune o săptămână și durează trei (deci 200% off) tot te ajută să-ți faci unele planuri decât dacă ți-ar spune „vedem cât durează să dăm faianța jos, să amestec varul, să dau cu amorsa, poate dura între 7 și 300 zile”
Poate storypoint-urile nu sunt implementate bine. Doar tu ai problema asta sau și restul colegilor?
Nu cred ca putem compara zugravitul, care pana la urma e o treaba repetitiva, cu treaba care nu se repeta aproape deloc.
Fiecare implementare e unicata in sensul ca trebuie sa se muleze pe codul existent. Pe masura ce proiectul avanseaza unele implementari au dependinte si consecinte in multe parti ale aplicatiei. Ti se cere sa spui daca termini intr-un sprint sau doua.
Raspunsul corect e “nu stiu, cel mai probabil o sa dureze mult”. Dar esti pus sub presiune sa dai un estimat in timp, care daca il depasesti e complet vina ta
Scopul ar trebui sa fie sa faci un produs de calitate, care functioneaza. Nu sa scoti pe usa mizerii care deabia merg pentru ca se apropie deadline-u, care ai fost obligat sa-l ghicesti
Eu nu cred ca exista client la care daca ii zici “ok termin in sprintu asta da sunt sanse mari sa fie buguri urate in productie. Si eu nu stau toata noaptea sa le rezolv” sa fie de acord cu asta
Actually… Been there, done that. Atunci când beneficiile (ceea ce funcționează) depășesc riscurile (bug-urile) sunt foarte mari șanse să fie de acord clientul.
De vreo cativa ani tot incerc sa explic si sa demonstrez ca estimarile in SP dar si timp sunt fix zero. Un PM ar trebui sa se uite pe nr de taskuri livrate. OK, unele sunt mai mari altele mai mici. Conteaza mai putin asta. In timp ajungi sa le inveti ca PM.
In general businessul nu intelege ca acest lucru dauneaza fix…businessului. Orice dev ajungand involuntar in timp sa “optimizeze pentru sp-uri” din cauza faptului ca businessul vede o estimare ca fiind un commitment. Apoi urmeaza presiuni care duc la stres, stres care duce la under delivery. Under delivery care duce la supra estimari ca dupa 6luni - 1 an toata lumea sa fie la fel de nefericita si proiectul sa isi intre in normalul cu care toata lumea s-a obisnuit. 20% churn rate - scapa cine poate.
P.S1. Definirea baseline-ului (adica ce inseamna 1 SP pentru echipa) nu are nicio influenta.
P.S2. Estimarile ca si proces se complica foarte mult cand lucrezi in echipe de la 3-4 insi in sus. Si se complica 10x cand trebuie sa faci estimari unde depinzi de alte echipe.
P.S3. Eu am renuntat sa ma mai lupt cu sistemul. Pur si simplu trebuie profitat la maximum de hype-ul din jurul agile scrum. Dati-le PM-ilor ce vor sa auda Daca vor SP-uri multe livrate, da-ti-le asta! Multora oricum am impresia ca nu le mai pasa…asa ca de ce sa pui presiune pe tine ca dev? Exemplu Task la mine: Avem nevoie sa setam prometheus si grafana. Poftim si niste metrice care fac blah blah. Estimare: 13SP-uri Nu am mai luat niciun task sprintul ala Ca idee, acum cativa ani faceam asa ceva intr-o zi cu pauze de cafea si tigara destul de dese.
P.S4 Nu cred ca am mai avut o estimare pentru un task serios sub 5SP-uri de 1-2 ani de zile. Motivul? De obicei cand estimam1-2 SP-uri pentru un task aparent trivial, in 95% din cazure exista un “catch”. Ori am nevoie de permisiuni. Ori am nevoie de un endpoint nou de la o alta echipa. Ori am nevoie de un setup mai ciudat pe care nimeni nu mai stie sa il faca pentru ca documentatia e scrisa de unul care a plecat demult…faze d-astea. Si lumea nu intelege pentru ca estimare = commitment in ochii oricarui PM.
@tacheshun Suna a program foarte “aerisit” modul asta de a estima. Sunt curios, e vorba de o firma mamut sau unde sunt așa permisivi? Ma gândesc ca intr-o firma mică / start-up nu prea ar merge abordarea asta.
Cel mai corect mod de a estima e de a evidenția fiecare subtask, inclusiv unit testele, testarea manuală și e2e-urile.
După estimezi ~1 SP/subtask. Dacă sunt triviale mai ignori câteva
În acest mod activarea unui feature flag/schimbat ceva text 1SP.
Orice necesita ceva testare manuală sau/și e2e minim 2-3SP.
Orice task care iese de 5 SP fără să fie clare 6-8 sub task-uri automat devine un spike înainte de implementare. Pe Spike pui timebox de 2-3 zile.
După spike o să ai vreo 3-4 task-uri de 2-3 SP, ceea ce automat te duce din 5SP în 9-12SP.
Dacă ai un task care are dependințe se pune flag și nu se estimează până nu e deblocat.
Dacă ai un task urât de 8SP care nu se poate împărți joci puțin la caterincă. Pui un task de 5SP de refactorizare/consolidare backend dar de fapt tot la cel de 8 lucrezi și pui 5 la cel de 8, deci o să ai 2 task-uri cu 10SP în loc de 8.
Dacă n-ai mai făcut ceva pui task de POC/Spike/hackathon/benchmarking. Minim 5-8 SP. După vine tot pe atât și pe task-ul real.
Pui refactorizare și reduce technical debt sau consolidare cât de des poți. Nu e livrabil cu demo și te ajută să corectezi un task subestimat.
Estimările se fac de echipă, dacă clientul e de acord cu ce estimează echipa și e mulțumit de rezultate nu o să îți spună nici un manager să estimezi mai puțin.
Am vazut totuși senior devi care subestimau intenționat ca să impresioneze la demo. Respectiv fiecare task era gândit să fie prezentabil. E foarte stresant să lucrezi așa, cineva dictează ritmul și te sabotează ca să impresioneze. Rezultatul e că se va lucra la greu în weekend și fiecare sprint va avea task-uri trase, dar se va livra mult.
Asta se face garantat peste tot unde clientul are un hard deadline, adică te uiți la velocity, la task-urile care trebuie făcute până la data X și cu complicitatea unui senior dev faci estimările să intre în deadline, dacă chiar nu e viabil se mai taie din feature-uri cu acordul PO-ului.
Te mai poate ajuta un Gantt chart dacă sunt mulți in echipă.
sau poti sa nu arunci cifre din burta la misto ci sa iei urmatoarea prioritate in progress si , presupunand ca nu joci FIFA tot sprintu, o termini cand o termini
Ironic faptu ca story points au fost inventate ca sa nu se mai faca estimari in timp, ci complexitate, dar tot estimari in timp au ajuns sa reprezinte.
E ca in jocuri pe mobil. Mai intai cumperi epic tokens pe bani adevarati si dupa aia cumperi chestii pe epic tokens
In loc sa zici 2 saptamani acuma zici [cat crede echipa ca inseamna 2 saptamani in puncte]
Ori story points, ideal, nu indica deloc cat dureaza ceva, ci cat de complex este acel ceva.
In functie de client, “demo” e doar un deadline mascat. De multe ori se ajunge in presiuni de timp sa faci ceva ca sa “aratam la demo”. Deobicei “sprint goalu” care se considera sfant si neaparat de realizat pentru “demo”
Da, este vorba despre o firma mamut, insa nu are legatura. Si la alte 2 firme anterioare era fix la fel. Firme nu chiar “mamut”. Inainte de 2015 eu ne-lucrand agile.
Eu doar incerc sa arat faptul ca estimarile, dupa un timp, sunt minciuna pe care multi PM isi doresc sa o auda. In loc sa ii intereseze sanatatea produsului si cat de multumit este clientul final, ei se orienteaza pe cate SP-uri livram si sprintul asta. Inca nu am vazut un PM preocupat de altceva. Or exista, nu zic nu. Dar nu am dat eu de ei.
Eu as vrea sa citesc si niste inside stories pe tema asta. Stiu ca exista foarte multe. Doar ca unii colegi de forum sunt mai rusinosi din fire.
Incep eu cu un exemplu de la o firma care se lauda cu productivitatea si eficienta angajatilor ei:
Acum vreo 4-5 ani, a fost o perioada de 3-4 luni in care am livrat 2 cronuri. Bineinteles ca pe hartie sunt zeci(poate sute) de SP-uri adunate. Pentru ca business-ul se razgandea de multe ori in timpul sprintului. Apoi, api-ul pe care il loveam nu a fost gata initial…apoi s-a schimbat si ala de vreo 3 ori. Si tot asa. Intr-adevar, erau cronuri putin mai sofisticate. Aveau query-uri destul de stufoase. Foloseau si un sistem de queuing. Foloseau si caching. Testarea lor era foarte grea si implica o anumita stare a sistemului. Dar tot 2 cronuri in 4 luni sunt, indiferent cat de mult as invarti situatia.
Taskul nu trebuia luat deloc in sprint, din punctul meu de vedere. Avea mai multe zone unde se depindea de alte echipe. Zone care nu erau gata. Dar businessul nu a dorit sa facem taskurile marunte, de consolidare, refactoring sau cum se mai numesc in ziua de azi. Nu au dorit sa facem training in perioada aia. Au vrut doar sa parem ocupati. Ca se suparau aia mai mari daca nu eram.
Îi spui clientului[1] că tu ești profesionistul și că știi mai bine decât el să estimezi complexitatea unui task.
Dacă sunteți mai mulți în echipă care ar putea face un anumit task, discutați între voi, de ce un dev crede că un task va lua 5SP iar alt dev estimează la 21SP? Ori cădeți de acord ori luați estimarea cea mai mare.
Uncle Bob a zis ceva foarte mișto:
The only way to go fast is to go well.
De fapt… e o combinație între cele două:
Story points define the effort in a time-box, so they do not change with time.
Tu ești plătit pentru complexitate sau pentru timp? Ți-ar conveni ca la sfârșitul lunii/sprint-ului să vină clientul să-ți spună „ai lucrat doar la task-uri simple, deci te plătesc atât”?
Trebuie să te raportezi la ceva când spui „task-ul ăsta are 13SP”. Ai nevoie de un baseline despre ce înseamnă 1SP.
clientul poate fi PM-ul, angajatorul sau chiar beneficiarul direct. ↩︎
exact asa si la noi in echipa/departament. Sprintul avand 2 saptamani, se incearca ca SPurile per dev sa fie in jur de 13. Ideal un task de 5, altul de 8. Daca exista taskuri care se presupun a avea 21 sau mai mult, se incearca spargerea lui si trecerea in 2 sprinturi, ajungi tot la un 8 si 13. Calculate in timp, 13SPuri ar ajunge la cele 10 zile lucratoare (1.3sp/zi). Calculate in complexitate … greu de explicat.
De ex, o sa am un task in care am de modificat denumiri de parametrii. Ca, complexitate, e un task de 1 SP. Ca timp, poate sa-mi ia 5 zile (jumatate din sprint), atunci zic 8 SPuri. Combinandu-le, imi da 5 SP. Trebuie sa tin cont si de celelalte taskuri din sprint. Daca depasesc 13, inseamna ca e prea mult. Daca e prea putin, inseamna ca ai timp de youtube prea mult pana la urma ajungi sa-l aproximezi tot din burta, cat sa se potriveasca cu “cerintele”
Tot cu story points este si pe proiectul pe care sunt eu. Pentru estimari facem un meeting, discutam task-urile, fiecare propune cate story points ar trebui sa fie si in general se alege estimarea mai mare. Daca sunt discrepante mari se argumenteaza si de ce. Se calculeaza un velocity dupa numarul de story points care reusim sa le atingem pe sprint si asta e folosit pentru a estima cam cate sprint-uri ne mai trebuie pentru un feature.
In general se incearca ca user story-urile sa fie cat mai detaliate cand vine vorba de functionalitate, task-urile sa se tina cat mai mici, sa nu se modifice pe parcursul sprint-ului si sa se tina evidenta de care sunt dependintele care ar cauza blockers.
Nu mi se pare foarte normal sa fie luat ca un contract, ci ca o estimare care se poate schimba din diverse motive: mai vin oameni pe proiect, mai pleaca, isi mai iau concediu, se mai greseste la story points, la cerinte etc. Cred ca problema e mai degraba management-ul, ceea ce nici nu ma mira, proiectul pe care sunt acuma e primul proiect in care am o parere buna despre… o parte… din cei de pe rolurile manageriale…
Am auzit si horror stories de la colegi pe tema asta de genul ca vine niscaiva “manager” / “leader” type care nu s-o mai atins de cod de cativa ani (asta daca s-a atins vreodata de cod de productie) si iti estimeaza el tie cum ca ceva interactive chart in canvas e gata in doua zile.
Acum știi cum e, depinde și de urgență. (și dacă toate lucrurile sunt urgente atunci nu e nici un lucru urgent)
Concret: dacă fiecare task este urgent și trebuie terminat ieri, probabil este o problemă în organizarea internă. Poate PM-ul nu își face treaba bine, poate colegii, poate chiar tu.
Ocazional se mai poate întâmpla câte un sprint de forță, în care bagi ca disperatul (e.g. vreo campanie prin social media) dar dacă se întâmplă frecvent, clar este o problemă.
Eu sunt curios dacă ai vorbit cu ceilalți colegi, să vezi cum se încadrează ei în estimările astea.
De ce nu? Viața e prea scurtă pentru a te bloca în job-uri de rahat
client/PM nu are incredere in developer sau e vorba de o relatie la inceput de drum si exista suspiciuni
client cu care nu ar trebui sa lucrezi in primul rand
Cu cei din prima categorie de obicei se rezolva in 3-6 luni problema increderii dupa ce se lamureste ca poti livra si ulterior devine relatia una normala.
Cei din a doua categorie sunt clientii care nu pot fi convinsi nici dupa 3 luni si de obicei au la randul lor alte probleme (restrictii de buget etc… sau sunt pur si simplu assholes) si atunci pe tot parcursul proiectului va fi colaborarea dificila.
Am avut un client care tot i-mi spunea ca un alt developer X cu care a colaborat in trecut rezolva acelasi task in timp mai putin decat mine si atunci i-am spus sa mearga sa vorbeasca cu el, daca a gasit developerul ideal cu care lucra asa de bine de ce sa schimbe.
Era de fapt un pretext sa puna presiune si sa scada bugetul.
O alta poveste funny legata de estimari, am avut un PM care la orice estimare dadeai in secunda urmatoare, fara sa se gandeasca la ce explicam acolo despre task intreba da se poate face in jumate de timp?. Cred ca a citit pe undeva in ceva carte de management de smecheria asta altfel nu-mi explic de ce facea asta si pentru taskuri de 2-4 ore
Cei care ziceți de probleme cu Agile n-ati înțeles care e rolul lui.
Nu există manager în Agile, Scrum master-ul poate fi oricine din echipa.
Refinement-ul la backlog și planning-ul la sprint e diferit de planning-ul la deadline, de obicei pe proiect/quarter (commitmentul adevărat cu clientul)
Dacă ai un deadline pui toate epic/task-urile în backlog, le supraestimezi puțin și vezi dacă ai destui oameni că să livrezi sau nu la timp. Mai angajezi pe cineva dacă permite bugetul sau reduci din feature-uri. În cel mai rău caz trimiți clientul la plimbare sau te riști știind că vei fi foarte la limită.
Când un manager întreabă dacă se poate face ceva mai rapid probabil întreabă dacă există dependințe pe care dacă le ai îți dă un avantaj. Eventual vrea să se asigure că nu faci over-engineering când clientul vrea ceva minim funcțional dar cât mai rapid. Poate vrea să zică să trântești acolo un buton fără teste că oricum se va schimba și un endpoint cu copy paste fără teste că oricum se va rescrie tot ce faci. Doar că mulți au orgoliu și nu fac asta dacă nu le zice managerul.
Nu te apuci să faci TDD când proiectul trebuie terminat în 3 luni și după clientul mai mult ca sigur pleacă.
P.S. Managerul n-are nimic deaface cu Agile sau echipa, dacă aveti cumva unul enervant sugerați să luați rolul de Scrum master și lead la daily prin rotație și managerul devine inutil și il dați afară din loop, eventual nu îi dați acces la repo. Dar doar dacă nu aveți probleme cu livratul. El o să fie obligat să țină 1:1 și retro oricum.
Ca să scoateți managerul și din slack/meetinguri/mesaje cu oricine la ore random introduceți un support role la echipă prin rotație. Adică un om se uită efectiv pe slack/build/mesaje și ia task-uri mai simple. Ceilalți nu sunt întrerupti dacă support person-ul poate da status update/raspunde la întrebări. Dacă tot se face puneți managerul la colț la 1:1 cu managerul lui că nu știe să lucreze cu voi.
Sunt clienți care sunt mai bătuți la cap, acolo trebuie cineva cu nervi de oțel ca și proxy PO.
Hai boss, fii serios cu neintelegerea rolului agile. Majoritatea problemelor vin de la bagarea pe gat a acestei metodologii pentru orice proiect si in orice conditii. Cu tot cu structura ierarhica si deadline-uri pe langa. Realitatea este ca Agile™ nu se preteaza decat pentru poate maximum 50% din proiecte. Nu toti lucram la interfete web cu api-uri rest sau graphql in spate. Unii lucram pe lucruri destul de inchise, gen embedded, jocuri sau software pentru automotive. Si astea nu sunt niste exemple mai duse la extrem. Dar chiar si in lumea web sunt foarte frecvente cazurile in care se doreste un livrabil fixed scope…este evident ca e fixed scope insa se baga agile pentru ca twice the productivity for half the time™.
)
pana la urma ajungi sa-l aproximezi tot din burta, cat sa se potriveasca cu “cerintele” 
