Da, agile este orientat pe produs si te face sa dezvolti si sa livrezi mai rapid features noi pentru produs.
Din experienta mea cu Agile de pana acum, cei de la produs vor incerca mereu sa “vanda” feature-uri noi in sprint, fara sa ia neaparat in calcul taskuri de tip technical debt. Cred ca treaba asta tine de cultura si de educatia de management de produs.
La noi exista task-uri de tip technical debt, cateodata facem subtask-uri la task-ul initial, daca descoperim pe parcurs si invatam ceva ce poate fi aplicat imediat si cateodata iti poti alege un promotor care sa te ajute sa “vinzi” task-ul de technical debt astfel incat sa intre in sprint.
Nu e Agile de vina ca PM sau product owneri sau CTO nu stiu de technical debt. La noi treaba asta vine de obicei din interiorul echipelor. Smecheria e sa se creeze un cadru optim pentru code quality si technical debturi asumate. In asta consta dificultatea, asa cum o percep eu. Cred ca aici poti sa completezi Agile si cu alte metodologii, cum ar fi XP, TDD si “lean startup”.
Daca nu e o cultura bine definita in sensul asta, fiecare e pe cont propriu si se ocupa de “proiectul” lui.
Este extrem de frustrant ca programatori sa explici de ce trebuie technical debt pe anumite segmente din task.
Legat de estimari, noi facem estimarile in cadrul echipei, votam cu story points. Daca task-ul nu e studiat indeajuns ca si complexitate imi mai aloc 1-2 zile si revin cu o estimare si cu explicatii.
@tacheshun in task-urile pe care le faceai in saptamana de sprint intrau si teste (unit, integration, manual)? Pentru ca intr-o estimare, la noi, se tine cont si de complexitatea la testare.
Spre rusinea mea am foarte putine unit testuri scrise. Nu neaparat la proiectul descris mai sus, ci si la altele.
Abia la actualul loc de munca am luat in calcul un coverage macar pentru core features.
Salut, sunt Mihai Olaru, sau “Jared” cum mi-ati zis voi mai sus
Vad ca e o discutie veche, dar pentru ca acum o gasesc incerc sa nu las lucrurile nelamurite. Multumesc lui Serban ca a promovat Agile ca mod de lucru pe threadul asta.
Ce pot eu sa va spun ca beneficiu general al lucrului Agile, dupa ce am trecut prin mai multe sisteme de organizare a municii, e ca Agile, dintre toate, a permis cele mai multe initiative si oportunitati de invatare pentru noi, cei din echipa. Ne-am simtit mult mai liberi sa experimentam, si tehnic dar si ca mod de lucru. Deci “Agile” pana la urma e sinonim si cu adapatabilitate, din mers. Nu e un context fix in care trebuie sa incapi ca turnat. Desigur sunt cateva roluri si reguli care trebuie respectate, dar partea mult mai benefica e libertatea de a alege in toate celelelate aspecte: solutie, design, tehnologii, estimare, proces, spatiul de lucru, interactiunile din echipa.
So… daca sunt ceva intrebari la care va pot raspunde, sau inca nu stiti daca va place sau nu Agile, ce inseamna sau de ce va cer clientii din business o orgaizare de tipul asta, sunt aici si sunt bucuros sa va raspund.
Btw, intre timp, mi-am dat seama ca este mai bine sa ai demo-uri de sfarsit de sprint pre-recorded decat live.
Mai ales cand audienta este internationala (si pe alte timezones).
@serbanghita: Imi place si nu prea ideea cu pre-recorded Sprint review.
Adica da, inteleg ca poate fi un avantaj pentru echipa pentru ca elimina eventuale balbe in prezentare sau timpii morti dar parca taie un pic din interactivitate, modul asta de prezentare, nu crezi? Feedback-ul cum se obtine in acest caz, poti sa explici?
Merci pentru raspuns @serbanghita!
Vad avantajele unui demo pre-recorded, despre care povestesti si mai pot chiar intui cateva, cum ar fi ca iti ramane inregistrarea pentru a o revedea daca iti mai vin idei ulterior, merge flaw-less totul si se poate optimiza timpul pentru tot meetingul
Desi nu am participat la un demo pre-recorded si nu pot zice ca spun asta din experienta, recunosc ca sunt in continuare un pic ingrijorat de aceasta abordare Sa explic de ce.
Cu o inregistrare video la Sprint Review in loc de “live demo”:
lipseste conversatia directa prilejuita de eveniment: “uite, ne-am adunat sa va aratam rezultatul muncii noastre, check it out”. Asta e o forma de “stakeholder engagement” in termeni Agile si are rolul sa obtina maxim de implicare din partea celor care pot da feedback.
ca urmare a punctului de mai sus mi-e teama ca scade si reversul, adica si sentimentul de “recunoastere” a succesului, pe care il are echipa, daca in loc sa arate ei propriu-zis solutia, se uita cu totii la un filmulet.
dispare sau e diminuata si “asumarea” solutiei de catre echipa .Nu aratam chiar noi stakeholderilor cum am gandit functionalitatea, ci lasam un filmulet sa curga in fundal, pare cumva ca nu ne asumam solutia pe de-a intregul. OK, tot noi am facut si inregistrarea dar parca e altfel sa arati live, ca si asumare a solutiei, nu crezi?
ce faci daca la sesiunea de Q&A de la final te roaga cineva sa arati un flow putin diferit fata de ce ai inregistrat tu? Esti pregatit? Ai mediul, datele de test la indemana? Sau te poate lua prin surprindere o astfel de cerere?
Pentru mine Sprint Review are ca obiectiv principal culegerea de feedback si asta se face cel mai bine in urma unei conversatii directe, conversatie pe care eu o prefer chiar daca aduce putin neprevazut sau nu garanteaza un demo curat ca lacrima
Intro si summary sunt parte din video. Eu, spre exemplu, montez YouTube style.
Daca in 3 minute nu ti-am explicat bine ce am facut, inseamna ca ti-am pierdut timpul tie + celor care se uita.
Cei targetati de obicei multumesc verbal sau in chat.
Asumarea este implicita, noi am facut feature-ul.
Echipa monteaza video-ul. Pot fi mai multi prezentatori, in functie de item-urile aratate.
Un flow diferit inseamna un task diferit.
Demo-ul este pe specificatiile descrise la Conditions of Satisfaction din task (sau epic).
Pe tema Agile Software Development si cum apropiem lumea tech de cea de business, am scris acum vreo 2 luni un articol pe blogul PM Community.
Las aici linkul catre articol si daca va place puteti sa-l distribuiti sau sa puneti acolo pe blog un comentariu, o intrebare, o experienta personala.
Merci!
Un mod de a obtine acest limbaj comun, cu care sa patrundem dintr-o parte spre cealalta, este parcurgrea curriculei de certificare pentru examenul PMI-ACP (Agile Certified Practitioner), sustinut la PMI.
Nu dau cu piciorul lui PMI-ACP dar abordarea este un pic prea rigida si matematica. As zice ca e buna pentru palmares si pentru cei ce vor sa faca data science pe datele din backlog.
Si ar mai fi ceva pe langa lucrul colaborativ. Dezvoltarea unui limbaj comun.
Absolut. As zice ca e mai usor sa obtii un limbaj comun daca trimiti lumea la training-uri si cumperi niste carti bune: Clean Code, Legacy Code, Lean, Retrospectives in Teams, etc.
Cred ca partea asta cu limbajul comun este cel mai sub-apreciat lucru din cei ce implemeneaza ceva Agile.
Funny, stiu, dar chiar mi-a adus aminte de cateva situatii reale, de prin echipe. Ca atunci cand toata lumea il astepta pe unul mai relaxat sa ajunga la daily sau cand am aruncat PO-ul pe gea… just kidding.
Voi ce experiente inedite aveti legate de rolul de Scrum Master?
@mihaio Am mixed feelings despre cum este interpretat rolul asta.
Daca esti la inceput cu software development e bine sa ai pe cineva sa te pazeasca de posibile greseli in relatia cu stakeholders (ce promiti in principiu).
Dar mai bine este sa inveti cum se dezvolta software decat sa ocupi timpul cuiva cu a fi paznic sau secretara.
Am senzatia ca exista persoane care considera ca “Scrum master” este un job. Boss, in anumite organizatii poate e nevoie, dar eu personal nu as plati pe cineva in organizatia mea sa fie “Scrum master”.
Daca PO este pervers cu requirements si baga pe sub mana lucruri in mod nejustificat, mai bine il trimit la training-uri si mai invata despre asta. Dar nu ma obliga pe mine sa pun un programator sa isi ocupe timpul cu a fi caine de paza sau secretara. Programatorii trebuie sa-si vada de computer science, dev, research si self-organizare … eu cred ca e suficient.
N-am un verdict clar legat de topicul asta, cred ca tine de maturitatea echipei din care faci parte.
Am senzatia ca exista persoane care considera ca “Scrum master” este un job. Boss, in anumite organizatii poate e nevoie, dar eu personal nu as plati pe cineva in organizatia mea sa fie “Scrum master”.
ma bucur, e bine, inseamna ca ScrumMasterii cu care ai lucrat si-au facut treaba bine. Chiar vorbesc serios. Se zice ca un Scrum Master foarte bun e cel care reuseste la un moment dat sa devina inutil echipei pentru ca atunci inseamna ca ei au preluat in totalitate guvernanta procesului si se auto-organizeaza fara ajutorul lui/ei.
Am totusi cateva argumente pentru tine, in sprijinul ideii de pastrare a rolului distinct de ScrumMaster pentru unul din membrii echipei Scrum. Desigur, nu vreau sa te conving, doar ca ma simt dator sa raspund provocarii.
In primul rand ScrumMasterul e cel care introduce modul acesta de lucru in echipe si de multe ori ii invata pe ceilalti cum sa il foloseasca. Se mai spune despre el ca are in responsabilitate procesul Scrum, nu sa il impuna ci sa il explice, sa ii familiarizeze pe membrii echipei, sa le dea puterea de a se auto-organiza. Imi amintesc din propria experinta ca multi oameni nu erau obisnuiti sa isi asume aceste responsabilitati ci se rezumau la a primi sarcini pe care sa le execute
In al doilea rand, am o intrebare pentru tine: Cat timp ii ia unui membru de echipa, neobisnuit sa lucreze Scrum, sa ajunga la concluzia ca se poate auto-organiza?Este probabil vorba si de o perioada de acomodare cu procesul, mai ales daca nu l-ai mai practicat, perioada care Scrum Masterul o poate scurta.
Cine ai prefera sa se ocupe de impedimente de genul: ne-a picat netul, nu ne raspund cei de la departamentul cutare, avem nevoie de un mod nou de a schimba informatia cu stakeholderii, VP-ul de la Sales ti-a cerut azi-dimineata sa lucrezi “2 ore” la un raport pentru el personal, Product Ownereul nu e de gasit sa valideze niste scenarii de acceptanta pe care se asteapta sa le vada la Demo,etc? Tu personal sau cineva dedicat rezolvarii acestui tip de blocaje care nu tin neaparat de contextul echipei? Nu uita ca echiap are un commitment pe livrabil intr-un timp scurt (cateva saptamani)
Cine propui sa faciliteze evenimentele din Sprint (Planning, review, retrospectiva) adica sa le planifice, sa tina agenda, sa dea tuturor ocazia sa se exprime, sa mentina focusul si in acelasi timp sa se asigure ca obiectivele fiecarui eveniment sunt intelese de participanti si sunt atinse de fiecare data? Nu doar ca ne intalnim ca sa bifam o activitate.
ScrumMasterul are rol de Coach, nu de Manager, adica ii ajuta pe cei din echipa sa isi indeplineasca obiectivele dar nu le spuna ce si cum sa faca. Le sta la dispozitie, le aduce lucrurile necesae, chiar daca astea se numesc, un spatiu de lucru mai deschis si colaborativ, un workshop/training/eveniment de echipa, o interactiune crescuta cu un stakeholder, sau accesul la resurse de care au nevoie.
Pe de alta parte, si aici iti dau dreptate:
Simt si de ce vrei tu sa optimizezi atunci cand vorbesti de un business propriu. Intr-adevar eficienta nu este maxima cand iti asumi ca platesti unul dintre membrii echipei fara ca el sa aiba neaparat o contributie directa la fragmentul de produs dezvoltat in Sprint. Totusi, Scrum NU promoveaza eficienta cu orice pret. Scrum nu este echivalent cu modul de gandire Lean, din acest punct de vedere, al pierderilor si al eficientei. Mai degraba Scrum promoveaza posibilitatea de a livra constant Valoare de Business clientilor, asigurand feedbackul lor frecvent, poate cateodata chiar cu pretul unei eficiente mai scazute (vezi re-work, regresii de testare in fiecare iteratie, overhead te timp generat de evenimentele de Sprint).
Multumesc pentru discutie, mi-a facut placere sa argumentez.
Nici eu nu vreau sa te conving, vreau doar sa inteleg anumite puncte.
Senzatia mea (poate fi de la Internet) este ca luam Agile + Scrum + Scrum Master ca litera de lege in dezvoltarea de software, cand ele sunt doar niste metodologii, abstractii sau metafore ale unor reguli de bun-simt de comunicare.
Si cum bunul simt se invata, se aplica si nu se evoca explicit (“sunt cel mai de bun-simt baiat”), la fel si aceste metodologii de software nu trebuie sa fie purtate ca niste badge-uri de self-entitlement.
Punctual:
Introducerea in sistemul de lucru al echipei o poate face Team Lead-ul.
Cand zic “Lead” ma refer chiar la un business title in organizatie prin care omul respectiv este recunoscut ca lider + coach + tech excellence.
Dupa introducere, urmeaza perioada de ramp-up, unde in urma unor task-uri mici se poate exersa Self-organize.
Nu pot sa raspund la intrebare pt ca depinde de om si context. Pentru mine mai eficient este sa incurajez Face-to-Face interactions din sensul noului venit. Adica vreau sa ma feresc de situatia: “tu stai acolo pe scaun, ca ti-am luat o secretara, ii zice Scrum Master, cand ai o problema ridici mana. Nu … ala nu are si alte treburi de facut gen … scris cod, ci e sclavetul tau”.
“Ne-a picat netul” deci Scrum Master-ul sa vina sa-mi bage cablul la loc? Aici nu am inteles.
Restul situatiilor descrise tin de cultura organizationala. Fallback-ul pentru genul asta de decizii este “stai ca trebuie sa intreb echipa”. Din punct de vedere al programatorului X, nu e vina lui ca vine cineva de mai de sus si solicita mizerii. As trimite pe VP si pe PO la training. Bag mana in foc ca totusi e o problema de cultura si de bun-simt.
Outlook, Calendar & friends
Obiectivele pot fi refined la un grooming cu PO.
“sa tina agenda, sa dea tuturor ocazia sa se exprime, sa mentina focusul si in acelasi timp sa se asigure ca obiectivele fiecarui eveniment sunt intelese de participanti” - asta tine de cultura, discutiile pot fi moderate de oricine din echipa. Ce, vrei sa tina cineva de manuta pe niste oameni adulti sa poarte o conversatie in limita unui timp dat? Daca nu se poate din prima se exerseaza. Am trecut cu totii prin asta. Tine de bun simt.
Team Lead-ul este un Coach.
Aici cred ca iar s-au mixat niste detalii. Adica daca eu am nevoie de training … trebuie sa vb cu Scrum Master-ul? Daca vreau sa tin o prezentare trebuie sa ma tina el de manutza?
“o interactiune crescuta cu un stakeholder” - nu am nevoie de Scrum Master. Incurajezi de la inceput Face-to-Face interactions by any means. Si daca nu poti asa, dai un email sau un telefon.
Motivul pentru care incurajez orice programator sa creeze un produs (inclusiv pe cont propriu) este pentru am fost in situatii in care echipele de dezvoltare software discutau mai multe despre Agile decat despre R&D.
Facand un produs cap coada, design, implement, test, learn, repeat, launch iti dai seama cat de triviale sunt la un moment dat discutiile pe marginea metodologiilor … cand tot ce conteaza este daca ai facut release la ceva bun pentru clienti si daca ai facut $$$$ cu produsul respectiv.
Dupa numai dupa ce ai trecut de etapa asta, poti sa te detasezi si sa apreciezi munca tuturor indiferent de metodologiile alese.
Sa explic de ce.
ma bucur, e bine, inseamna ca ScrumMasterii cu care ai lucrat si-au facut treaba bine. Chiar vorbesc serios. Se zice ca un Scrum Master foarte bun e cel care reuseste la un moment dat sa devina inutil echipei pentru ca atunci inseamna ca ei au preluat in totalitate guvernanta procesului si se auto-organizeaza fara ajutorul lui/ei.