Se baga fiindcă arata profesional sau e ușor de vândut, există și Kanban la tipul de proiecte precizate de tine. Se poate tranforma din Scrum în kanban și invers.
Dezvoltarea unui proiect nu este ceva garantat, nu vinzi produsul, vinzi dezvoltarea, experienta și efortul de a crea soluția după specificatii. (care sunt foarte interpretabile, altfel clientul ar scrie direct codul)
Clientul își poate chiar introduce propriul om în Scrum team și atunci are o vizibilitate mare asupra progresului. (Cu care trebuie să ai mereu foarte mare grijă)
Discutabil. Eu zic ca arata fix amateurish, dar na.
Iar Kanban…pfff…faptul ca folosesti un kanban board…cand in spate ai tot ce tine de waterfall… nu prea poti zice ca esti Agile.
Evident ca nu faci implementari serioase sau TDD pe un MVP. Dar cand treci de faza de MVP si ajungi sa fie un proiect de lunga durata, cu multi oameni, si se doreste in continuare sa trantesti acolo functionalitate fara teste, fara nimic consider ca avem o problema.
Ori eu am senzatia ca de la mine asta se doreste pana la urma, sa scot functionalitatea pe usa inainte de deadline, fie ea oricat de urata in spate. Cand ajunge destul de urat codebaseul imi dau demisia si devine problema altuia. Daca asa se face treaba da-o in ceva
Există așa numitul Definition of Done și chiar Ways of Working.
E o convenție intre client și echipă, dacă definition of done-ul spune clar că clientul vrea unit teste, e2e-uri și calitate peste cantitate (code coverage/track technical debt) la fiecare feature atunci nu ai ce să discuți. Nu se pune în done un task care nu are tot ce se cere în definition of done. Desigur că estimezi tot, dacă vrei să fii foarte profi nu pui task separat pe teste dar le estimezi și zici cât de greu e de testat acel ceva.
Calitatea oricum e la fel de relativă ca și estimările. Ca să estimezi bine îți trebuie story/task-uri rafinate bine. Ca să implementezi ceva cu TDD, să faci ceva cu cât mai puține bug-uri îți trebuie acceptance criteria cât mai clar.
Ways of working e o convenție între colegi și client, manager ca să nu fie discuții interminabile.
Cand ii aud pe unii cu Agile in vine sa ii plesnec, deci s-au strans unii si-au dat si eu cu parerea, au venit cu unele ideii etc, apoi altii au mirosit oportunitatea de face bani si scris carti, ca ai vb de dailly, la mn in echipa a devinit doar dat raportul catre manager, doar atat, colegii nici nu se asculta intre ei, iar daca ai nevoie de ceva vb cu un coleg apoi, desigur fan boys vor spune ca nu e “true” agile, la fel ca si comunismul nu a fost “true comunism”, unde vreau sa ajung, sa nu mai traim dupa ideologii impuse de altiii.
E ok, daily-ul e status update si un mod de a evidenția că ai un blocker și să te ajute cineva. Trebuie să fie cât mai scurt. Nu e status update doar pentru manager dacă sunt task-uri cu care creezi conflicte altuia. Code review-ul e un blocker la care te poate ajuta managerul.
Se poate ține meeting-ul de daily deschis toată ziua și rămâi în meeting ca să mai discuti de una alta. (Cu breakout rooms) Dar nu e obligatoriu.
Eu am ridicat subiectul ca Agile e o prostie și colegi care au lucrat acum 15-20 ani la Google, în Silicon Valley, la Microsoft au explicat că era dezastru fără Agile.
Depinde de mediul in care lucrezi, eu nu am prea avut probleme in majoritatea locurilor, daca am estimat ceva 5 SP si dura 7-8, de exemplu.
Oricum, in general estimez in plus semnificativ. Si oricat haterim, o boaba de estimare e normal sa astepte si clientul / managementul. Mi se pare de bun simt comparatia cu zugravul de mai sus.
Iar pt cine zice “pai da, dar poti da de ceva care iti lungeste efortul de la 3SP la 20” - de acord, dar atunci comunici din timp de cum iti dai seama. Oricum, nu e ceva care se intampla frecvent, sau daca e, posibil sa fie si o problema la tine.
Agile, Waterfall, etc sunt doar niste guidelines Iei ce iti place de la ele.
Important e sa gasesti ceva care functioneaza pentru tine si echipa ta. E absolut inutil sa te blochezi in procese foarte stricte. Procesul este menit sa te ajute nu sa iti stea in cale, daca simti ca te blocheaza atunci il schimbi. E ok ca un proces sa evolueze in timp.
La nivel mai sus de echipa in care lucrezi, problema cu estimarile nu este ca sunt gresite. Ca daca nimeni nu ar depinde de acel feature, de ce i-ar pasa cuiva ca tu intarzii 2-3 zile? Problema este cand bazat pe acele estimari, oamenii isi fac planurile, seteaza intalniri cu viitori clienti, samd.
In loc de estimari, mai degraba setezi deadline-uri. Intrebi si tu sales-ul/business side-ul: “Cand e ultima data posibila cand poate sa fie gata asta?” si scazi un anumit buffer. Negociezi daca nu esti de acord cu ultima data posibila sau daca e prea din scurt. Vorbesti cu echipa, revii si mai negociezi putin. Culmea, este ca acest dute vino si negocieri este mult mai ok decat sa zici de la inceput: “Dureaza X”. Practic tu zici: o sa fie gata cand o sa ai nevoie de acest lucru, dar negociem pe parcurs asteptarile. Asta trebuia practic sa fie Agile la inceput, dar s-au bagat niste puncte virtuale la mijloc care nu au nici o treaba cu vreun deadline real.
Daca ma gandesc putin mi se pare absolut hilar ca 5-6 programatori sa se adune in cerc si sa tipe numere aparent aleatorii si sa faca medii la acele numere. Seamana a shamanism si sunt vinovat ca am practicat si eu asta cu echipa in trecut.
Pai nu zice nimic nou, decat ca trebuie sa estimezi pentru ca business.
Dar pana la urma tu o musti daca gresesti. Mi se pare stupid si ca business sa faci un “contract” pe ceva ce e din start pe ghicite si cel mai probabil, statistic vorbind, o minciuna
O extrema e industria jocurilor, care e probabil cea mai infecta nisa de dezvoltare soft. Businessu face un contract turnat in fier beton ca jocul o sa fie lansat pe 15 Decembrie. Patronii care fac asta merg linistiti acasa la 6 si programatorii, care stiu din start ca e imposibil, lucreaza toata ziua si toata noaptea.
A ajuns atat de rau incat se considera serios sindicalizarea
De fapt estimarea are un alt scop decat cel de a planifica data exacta de terminare a unui proiect.
Uite cum sta treaba din punctul de vedere al managementului. Se da o echipa si un proiect si se apuca toti sa lucreze, ca e euforie mare la un proiect nou. Dupa un timp incep lucurile sa se miste incet, se pierde timp, iar managementul are o dilema: e clar ca ritmul s-a incetinit, dar cum sa demonstrezi asta, ca daca ii intrebi pe fiecare in parte vei primi argumente ca s-a lucrat chiar si peste program. Aici intervine agilul si estimarea: pune echipa sa promita ca fac taskul in X ore si nu o sa poata sa spuna ca a durat 2X. Deci nu exactitatea estimarii e importanta ci actiunea in sine. Chestie de psihologie. Si macar din punctul asta de vedere a estima este mult mai bine decat a-i urmari pe fiecare cat lucreaza, la minut.
A incetinit ritmul pentru ca aplicatia incepe sa se maturizeze si am inceput-o in graba sa facem MVP. Nu putem sa trantim jeguri in codebase fara consecinte grave. Ori managementul daca vrea ritm constant trebuie sa ne lasa sa facem treaba buna, care evident dureaza mai mult decat jegu. Daca le grabim toate chiar ca o sa se duca dracu proiectu
Iar ce zici aici mi se pare manipulare de cea mai joasa speta, daca am inteles bine la ce te-ai referit. Defapt nu conteaza estimatul, vrei doar sa se puna omu cu mana lui sub presiune de timp ? Incep sa inteleg de ce schimba lumea firmele pe rupte
Da, de fapt am citit un articol pt manageri, si se stie ca programatorii sunt bad-optimistic estimators, cand estimezi ceva, creierul o face face in conditiil ideale ca nu ai cum sa prevezi probleme, de care nu stii, bine sa zicem ca iti iei un buffer, dar si ala optimism, plus ca instinctiv nu vrei sa pari incompetent, dar zicea sa fortezi o estimare, in felul asta, omul o sa munceasca mai mult ca sa isi respecte cuvantul dat, sa nu para incompetent etc, nimanui nu ii place sa constate ca a gresit.
Un coleg cu foarte multa experienta are filozofia de a adauga cat mai mult in sprint si de il faci si de nu, dar incerci sa faci cat mai mult. Dar daca nu adaugi mai mult decat poti nu afli niciodata cat poti in realitate. Aveam sprint-uri in care am facut mai mult decat toata aplicatia de pana atunci si tot aveam cateva task-uri neterminate. El mai lucra si pe 2 proiecte deodata si facea acelasi lucru pe amandoua proiectele…
Adica e genul de om care se duce hardcore cu estimari de 1-2 puncte pe task-uri de 5-8 puncte. Dar stie si exact ce sa faca. Cand intreba scrum master-ul inainte sa deschida sprint-ul daca e mult sau putin mai punea pe tava jumatate de backlog
Nu mai ai timp nici sa dai drumul la muzica pe youtube, dar livrezi. Problema e ca dupa vine managerul si iti zice ca tot ai task-uri de pe un sprint pe altul, ca nu lucrezi destul si tu ai livrat mai mult decat poate PO-ul sa inventeze. Pe colegul cu ideea de go hard or go home nu il intereseaza ca n-are treaba cu performance review-uri.
Deci cum a mai spus cineva mai sus, cel mai bine e sa joci jocul de sprint de 100% daca te intereseaza sa ai un performance review cat mai usor. Pe un PM nu il intereseaza ca tu livrezi cu mult peste ce se cere/lucrezi peste program, il intereseaza ca sprint-ul sa fie de 100%
dupa aia iti dai demisia ca nu mai poti lucra pe codebase
vorbesc din experienta aici
cand m-am intalnit la bere cu colegu care mi-a mostenit treaba, primul lucru a fost sa ma injure. Dupa vreo 2-3 luni a plecat si el la alta firma. PMu era foarte fericit ca se livreaza tot, evident.
Nu stiu. Poate sunt eu prea idealist si ar trebui sa ma intorc la facut treaba de mantuiala, dar rapid.
Cauti o firma care se potriveste mai bine cu stilul tau de lucru.
Am un coleg care in zona de MVP i-ti livreaza produsul dupa in weekend de lucru, sta si munceste de rupe dar la un produs in zona enterprise nu se descurca.
Suntem cu totii diferiti si tu trebuie sa cauti contextul potrivit, echipa unde aceste calitati sunt de real folos. Poti intreba pe acest forum si o sa vezi ca sunt firme care apreciaza treaba facuta cum trebuie, in special cele din zona de produs propriu unde un produs e dezvoltat o perioada mai lunga de timp. In outsourcing livrezi produsul si pe urma nu mai e problema ta asa ca nici nu prea esti interesat sa produci la cea mai buna calitate ci doar sa respecti parametrii de livrare.
Am vazut de-astea, da. Cand developerul care a scris codul acela infect zice ca trebuie sa rescrie tot de la 0, e clar ca esti pana la brau si nu mai poti sa iesi. Asta pentru mine denota cateva lucruri:
Directia tehnica a fost una proasta. Domnul team-lead sau manager ce a facut? A intrebat echipa: “Ba, mai puteti?”
Standardele de cod nu au fost impuse de la bun inceput.
Domain knowledge-ul a fost inexistent.
Arhitectura este una rea daca nu iti permite usor rescrierea anumitor bucati din sistem. Totul cuplat, nimic spart in module, haos, fara niste strict typing, interfete non-existente
Tu ai mai avea incredere in acelasi dev sa rescrie totul? Eu unul nu as mai avea. Avantajul devului original este ca are acum domain knowledge, deci eu as lua pe altcineva mai senior sa-l ajute sa rescrie totul.
In orice echipa trebuie sa fie cineva responsabil de arhitectura sistemului, cineva care stie cateva lucruri, care are experienta. Iti garantez ca daca iei pe cineva cu experienta pe bune in arhitectura, chiar daca scoti un MVP, acel produs o sa fie mentenabil. Pana la urma, nu scoatem softuri sa mearga 3 luni, scoatem softuri sa mearga 10 ani si pana nu realizam cu totii ca 80% din munca de developer este mentenanta situatiile acestea vor continua sa se intample.
Sunt total de acord, dar nu poti face totu frumos sub presiuni imense de timp.
Ce faci cand iti apare PRu cu cod mizerabil, care cel mai probabil trebuie rescris, dar trebuie sa fie gata sprintu asta pentru ca asa ai estimat, cele doua fiind incomptibile? Il bagi asa si zici ca il cureti mai incolo, ori mai incolo ala probabil nu o sa vina ca vine sprintu urmator cu alta distractie.
O alta idee vehiculata in targ este ca scrum-ul nu trebuie aplicat mai mult de 3-4 luni consecutive. Motivele sunt alea pe care le stim cu totii: este o metodologie orientata short term care produce calitate sub-par, produce burn-out si demotivare in echipele de devi, etc.
Ideea era ca dupa astea 3-4 luni sa intri intr-o perioada de freeze( hypercare, consolidation sau numeste-o si fasole batuta ca tot ideea aia e in spate: fara scrum urmatoarea perioada). Dar da, cu un kanban board pentru suport tasks, buguri, refactorizari si chiar analize pentru urmatoarele sprinturi. Dupa perioada asta, iar bagi scrum 3-4 luni. si tot asa.
Era sa imi iau bataie cand am propus asta in echipa mea…
Iei ce iti place de la ele.
