ii explici. si tu si clientul ar trebui sa folositi aceiasi metoda. daca nu… e ceva ciudat.
Poate va ajuta prezentarea asta in limba romana (are 3 ore) https://www.youtube.com/watch?v=5ovmq4p4dvw (Avangate Tech Sessions, “Estimarea Agile a proiectelor de dezolvare software” cu Mihai Olaru). A spus multe lucruri acolo pe care mi-e greu sa le sumarizez intr-un post.
Pe mine Agile ma ajuta sa fiu focusat doar pe task-urile asumate in planning, fac pre-demo-uri pentru ca inainte de demo-ul final sa nu am surprize, si daily standup-ul de dimineata e foarte bun pentru a informa mai departe statusul si blocajele.
1 Like
Mihai Olaru îmi aduce aminte - cel puțin în primele 30 secunde - de Jared din Silicon Valley:
3 Likes
funny! Sunt asemanari, o sa-i arat videoul 
1 Like
Comunicare, exemple, feedback,valoare pentru client. Dar astea poate sunt doar buzz-words. Do or do not, there’s no try
1 Like
Tot ce am retinut e:
“This wall of psych 101 MBA mind control bullshit is gonna motivate us…(Dinesh)”*
Cea mai realista descriere a scrum…evah 
2 Likes
@tacheshun stai ma ca o intalnire dimineata cu colegii de echipa despre statusul taskului la care lucrezi, ce probleme/blocaje intampini si ce vei face azi nu e bullshit
Atunci si communication == bullshit … which is not
1 Like
Revin după jumătate din film vizionat: foarte interesant. Nu s-au spus multe lucruri necunoscute dar m-a ajutat să înțeleg lucrurile cunoscute.
Urmează partea a doua
1 Like
Nu m-as grabi la concluzia communication == bullshit. Depinde de experienta fiecaruia.
Experienta mea cu daily standups se rezuma la sedinte de minim 30 de minute in care o treime din devi aveau/aveam un status de genu “La fel ca ieri…”, o treime aveau/aveam status “ok, am lucrat la asta, terminat. move on” iar ceilalti aveau/aveam probleme si lungeau discutiile inevitabil la mai mult decat era prevazut. Practic nu se aduce niciun fel de valoare adaugata, mai mult se discuta despre cod in loc sa se scrie
Daily standups de 15 minute, cum se zice ca ar fi ideal pentru o sedinta de genul asta, am avut 1 singura data cand dintr-o echipa de 8 insi lipseau 4.
Pentru mine, genul asta de sedinte sunt bullshit. Frecventa sedintelor din Scrum lor mi se pare insultator de ridicata si vrei-nu vrei se incadreaza in “micromanagement”.
Prefer oricand un 1-1 cu superiorul direct in caz ca sunt probleme sau un pair-programming cu un coleg ce stapaneste mai bine decat mine o zona a proiectului.
3 Likes
Sunt curios cât de realist e universul Agile pentru o echipă de o singură persoană? Pentru că sunt de cele mai multe ori singur, nu am probleme în a mă organiza (ba am) în schimb am probleme serioase în a-mi educa/înțelege clienții (ex: le spun să-mi trimită feedback printr-o anumită metodă. Le spun degeaba. Câteodată primesc SMS-uri cu feedback).
Cât despre estimarea unui proiect, este o operă de artă care trebuie realizată ca o biblie, numită caiet de sarcini, preferat să fie realizat de o un terț care stabilește și un preț estimativ. Cum acest caiet de sarcini este doar un mit(chiar și obligatoriu cum este la bugetari) cel mai cinstit este să estimezi prețul corect și să-l înmulțești cu >1;
Ce am scris mai sus se referă la ceea ce cred/fac eu.
@tacheshun omg, sedinte de 30 min? 15 minute? What happened to 5 minutes?
Iti dai seama ca prin faptul ca oamenii nu ajung la scrum sau ca sunt dezinteresati nu tine de Agile, cred ca mai degraba de oamenii si cultura de acolo … Noi facem scrum dimineata in echipe de 4-5 oameni.
Bineinteles ca te poti duce sa discuti si 1 on 1 cu cine e expert pe zona respectiva, nu-ti interzice nimeni.
Micromanagement este atunci cand vrea cineva sa controleze totul in mici detalii, in cazul lui Agile echipele se organizeaza singure. Spre exemplu la noi se auto desemneaza cineva Scrum Master sa paseze mai departe statusul ca sa nu fie surprize cu produsul.
Cand zici “frecventa sedintelor de Scrum” la ce frecventa de referi? Noi facem una dimineata.
Eu cand ma refer la senditele scrum nu ma refer doar la daily standups. Sunt mai multe tipuri.
Din ce am vazut in clipul colegului tau si din ceea ce ne expui tu, se vede ca sunteti la un alt nivel.
Vreau sa avem o discutie constructiva si pentru asta vreau sa iti detaliez cam la ce ma refer prin sedinte dese:
-Daily standups, cca 30 de minute, zilnic. 10-11 oameni. Era clar ca ceva nu era in regula, s-a incercat reducerea timpului, fara rezultat.
- Sedinta de estimari 1 data pe saptamana(vineri) care putea tine si 3 ore insa niciodata nu a tinut sub 1. Sedinta se continua luni cu o retrospectiva in care se strecurau si estimari. Minim 2h.
- Sedinte de tip product meeting, in care, pe langa expunerea anumitor lucruri ce tinea de produs(strategie, vazari, status) erau prezentate si taskurile la care fiecare programator lucra. Evident, insotite de explicatii in caz ca nu erau in grafic. Sedinta tinea minim 1h si era saptamanala. De foarte multe ori a tinut 2h.
- Sedinte tehnice in care se discutau diverse lucruri legate de arhitectura aplicatiei, code-review, etc. Astea erau aproape saptamanale, dar erau mai lungi de 1h.
Sprintul era de 1 saptamana.
Ti sa pare ok? Mie mi se par destul de dese. Iar ritmul impus este destul de agresiv. As vrea sa aflu parerea ta aici.
Aveați mai mult 8h de lucru efectiv (adică ceva ce nu avea legătură cu vreo ședință) într-un sprint?
Mă gândesc că (în ritmul ăsta) după două săptămâni epuizați toate subiectele de discuție. Ce mai vorbeați în ședințe? 
@tacheshun Sigur, constructiv, pe mine ma intereseaza diverse case studies!
-Daily standups, cca 30 de minute, zilnic. 10-11 oameni. Era clar ca ceva nu era in regula, s-a incercat reducerea timpului, fara rezultat.
- 30 de minute este enorm, noi facem 5 minute
- 10-11 oameni este mult, noi facem 4-5 oameni
- noi suntem impartiti in mai multe echipe de 4-5 oameni pentru a preveni haosul si complexitatea
- Sedinta de estimari 1 data pe saptamana(vineri) care putea tine si 3 ore insa niciodata nu a tinut sub 1. Sedinta se continua luni cu o retrospectiva in care se strecurau si estimari. Minim 2h.
- Sprint de 1 saptamana? Faza e ca din start trebuie sa tai o zi pentru demo, retrospectiva si planning. Mai raman 4 zile de dev, 6 ore pe zi
- Vineri e nasol sa ai meetinguri dar nu exclus, noi avem program scurt vineri.
- In aceasta saptamana cand faceati demo-ul la product owneri?
- Retrospectiva cu estimari nu este retrospectiva. Noi in retrospectiva notam ce a fost bine si ce a fost mai putin bine si ce trebuie imbunatatit.
- Sedinte de tip product meeting, in care, pe langa expunerea anumitor lucruri ce tinea de produs(strategie, vazari, status) erau prezentate si taskurile la care fiecare programator lucra. Evident, insotite de explicatii in caz ca nu erau in grafic. Sedinta tinea minim 1h si era saptamanala. De foarte multe ori a tinut 2h.
- Asta e demo-ul la ce ai lucrat in saptamana aia?
- Sedinte tehnice in care se discutau diverse lucruri legate de arhitectura aplicatiei, code-review, etc. Astea erau aproape saptamanale, dar erau mai lungi de 1h.
- Noi facem asta de obicei vineri. Sunt prezentari din proprie initiativa, optionale.
Sprintul era de 1 saptamana.
- Eu iau in calcul ca pot sa lucrez bine 6 ore pe zi, intr-un sprint de 1 saptamana trebuie sa tai o zi pentru sedinte si nu am timp de pre-demo-uri … Nu zic ca nu e bine, mie imi place sa-mi bucatesc taskurile astfel incat sa pot sa fac release la ceva cat mai rpd. Noi avem sprint-ul de 3 saptamani. In trecut l-am avut de 2 saptamani.
1 Like
@tacheshun de curiozitate, Agile a fost implementat de cineva de la produs sau tehnic sau persoana dedicata?
Initial a fost implementata de produs si a fost ok. Erau si mai putine sedinte. Din motive “politice” ce nu doresc sa le descriu aici s-a mutat pe tehnic si a dus la o supra-solicitare a devilor, demotivare si “fuck it, I´m gonna find another job” attitude.
Anyways, asta a fost doar la o companie. Am mai lucrat si la altele Scrum, cu un oarecare nivel de fail la fiecare, desi nu la fel de mare ca la asta de o descriu mai sus. O sa revin cu detalii.
2 Likes
Nu faceam demo per se. Se punea codul pe staging in momentul cand se primea ok de la QA. Apoi daca se primea ok de la Product Manager se facea deploy live.
Again, nu era un demo Mai mult o prezentare a ceea ce s’a livrat si ce nu.
Pai noi aveam 1 zi taiata din sprint oficial pentru treburile expuse mai sus, desi in practica tot timpul ramaneai doar cu 3 zile de dev efective. Aici am avut discutii de ore intregi cu CTO-ul, dupa program, pentru schimbare. Nu s-a putut.
Mai conta si faptul ca se facea deploy “semi-manual” si era nevoie tot timpul de cineva zilnic, prin rotatie, pentru “release management”. Era o chestie ok asta pentru ca nu se facea merge daca pull requestul nu avea review, de exemplu, se facea deploy in liniste, rollback daca era necesar, pentru ca era timp pus deoparte pentru asta. Partea nasoala e ca nu mai aveai suficient timp pentru dezvoltare efectiv.
Sprintul de 1 saptamana e un sacrilegiu. La o alta companie aveam sprinturi de 2 saptamani si nici atunci nu mi s-a parut chiar ok.
Cel mai ok mi s-a parut cand nu existau sprinturi si faceai release in momentul cand aveai terminat ceva. Adica zilnic 
@tacheshun task-uri mai mari (epics) ati avut vreodata? Adica un task pe care trebuie sa-l bucatesti foarte mult, si pe care sa fii nevoit sa-l pui pe rand.
Planningul cum se facea? Va alegeati voi task-urile fiecare sau pe echipa?
Din punctul meu de vedere Scrum este o gresala nu numai aplicat incorect. Chiar aplicat si ca la carte, eventual implementat si de niste consultanti platiti cu o galagie de bani
Se porneste cu ideea gresita ca un programator poate livra azi ceva la fel ieri, la fel ca acum 1 saptamana, etc. Ceea ce e complet fals chiar si pentru un programator cu 10 ani+ experienta. Si nu, motivarea cum ca “el isi face estimarile” nu mi se pare deloc matura, mai ales in anul 2015 cand se presupune ca avem asumata ideea ca oamenii nu sunt masini.
Ideea de sprint este orientata agresiv catre “a livra” si indirect se pozitioneaza impotriva Research&Development. Cei care chiar faceti scrum de ani buni, cand a fost ultima oara cand ati dedicat sprinturi intregi pentru research? Sau macar 1 sprint? Eu am lucrat scum la 3 companii pana acum. Cred ca adun cativa ani si nu am auzit vreodata cuvantul “research”. Ala se presupunea ca trebuie sa il faci tu, in timpul tau. Doar esti pasionat de munca ta, nu?
Mentalitatea asta de a livra ceva no matter what cand se termina sprintul, determina in timp acumularea de technical debt, despre care am mai discutat.
Pe langa asta am descoperit pe propria piele ca sprinturile astea, in special cele de 1 saptamana(foarte agresive) nu sunt sustenabile pe termen lung. Sunt ok-ish pentru proiecte de 2-3 luni, insa nu mai mult. Mentinut ritmul asta, se ajunge la o demotivare a dezvoltatorilor si chiar depresie in cazuri mai speciale(am vazut asta).
2 Likes
Am avut si Epics. Mie personal mi-au placut mai mult astea, insa noul PM nu le-a mai folosit.
Exista o lista de taskuri facuta de PM. Unele erau taskuri de dezvoltare features dupa cum dorea PM, altele erau requests de la stakeholderi. Apoi mai erau si bugs.
Taskurile le discutam in echipa, estimam in echipa si in final erau asignate de CTO. Dar nu neaparat celui care a estimat cel mai putin.
Disclaimer: In actualul meu loc de munca nu facem Scrum and I´ve never been more happy