Azi vreau să-ți prezint modul în care majoritatea echipelor de dezvoltare software își organizează activitatea, în felul ăsta o să fii mai pregătit atunci când o să începi activitatea la primul job.
Modul în care o echipă de dezvoltare își desfășoară activitatea e ceva mai diferit față de cel al echipelor din alte domenii.
Nu e cazul să te sperii, e de fapt un lucru bun, pentru că sunt de părere că organizarea e ceva mai bună.
Spun asta pentru că am lucrat și în alt domeniu și activitatea era ceva mai haotică si mai bazată pe “ce spune șeful” decât pe decizii luate de comun acord în echipă.
Spuneam că organizarea echipelor de dezvoltare e mai diferită și s-ar putea ca atunci când aterizezi la primul tău job să fii puțin pierdut și să nu înțelegi exact ce se întâmplă.
Ce este SCRUM
Organizarea asta la care ma refer e metodologia denumită SCRUM. O să auzi oameni folosind termenul de SCRUM interschimbabil cu Agile.
Nu e tocmai unul și același lucru, dar să zicem că ambele fac parte din aceeași filozofie.
La modul general, ce trebuie să știi e că SCRUM e o metodologie menită să dea echipelor spațiu pentru flelxibilitate, autonomie și îmbunătățire continuă prin feedback rapid.
Oh știu, te-am băgat și mai rău în ceață așa-i?
Ce trebuie să știi în principiu, e că o să ai multe ședințe. Cel puțin una, în fiecare zi. Fiecare dintre ele are un scop anume și se desfășoară într-un fel anume.
Modul de lucru în SCRUM e sub formă de “sprinturi”.
Asta înseamnă că munca echipei e segmentată în perioade de 2-3-4 săptămâni în funcție de cum e stabilit.
Fiecare iterație din asta poartă denumirea de “sprint” și are un scop definit.
De exemplu, să zicem că echipa lucrează pe o aplicație e-commerce și urmează să se implementeze un modul de plăți. Dacă se decide că dezvoltarea acestei capabilități e posibilă într-un sprint, se creează mai multe sarcini care poartă denumirea de user stories.
Sau tradus pe genunchi în limba română, povești ale utilzatorilor.
Se stabilește ce e de făcut exact pentru implementarea acestui modul și se sparge pe bucățele mai mici, pentru ca mai mulți membri ai echipei să poată lucra în paralel.
Activitatea echipei e segmentată în sprinturi, pentru că ideal la finalul sprintului să se facă release noilor implementări, să fie testate din punct de vedere funcțional și echipa să primească feedback.
Se aleg perioade atât de scurte pentru setarea sprinturilor, tocmai pentru a avea acest feedback cu frecvență destul de ridicată.
Astfel echipa se asigură că în decurs de câțiva ani, produsul pe care îl dezvoltă ajunge la o anumită maturitate și este exact ceea ce utilizatorii au nevoie.
În felul ăsta, nu se investesc o gramadă de timp și bani într-un produs, iar la final să se constate că nu e chiar ce s-a dorit.
În timpul sprintului vei avea o ședință sau un apel zilnic cu ceilalți membri ai echipei pentru a da un status a ceea ce e în lucru.
Fiecare membru va spune la ce lucrează, ce progres a făcut sau dacă întâmpină ceva probleme care ar putea duce la întârzieri.
În funcție de numărul de membri al echipei, ședința asta ar trebui să dureze cam 15 minute în medie.
Dar sunt foarte puține cazurile în care formatul acestei ședințe se respectă, pentru că de multe ori fie se intră în prea multe detalii, fie se pornesc discuții care nu sunt în scopul ședinței.
Aici depinde mult de echipă și de cum au fost obișnuiți oamenii.
Structura echipei și modul de lucru în SCRUM
O echipă SCRUM va fi compusă în general din developeri, testeri, un product owner, care e și cel care definește dezvoltarea produsului, vine cu cerințe noi de dezvoltare etc.
Scrum master, care se ocupă de organizarea tuturor acestor “ceremonii” - da așa le spune tuturor ședințelor care se fac în SCRUM.
Scrum master-ul se mai asigură și de buna funcționare a echipei, interfațând comunicarea cu alte echipe sau cu alți oameni din zona de business, pentru ca oamenii tehnici, developeri sau testeri să se concentreze pe ceea ce e de făcut în sprint.
De multe ori rolul de scrum master e acoperit de unul din membri echipei sau de team lead.
Planificarea sprintului
Începutul unui sprint debutează cu o ceremonie denumită sprint planning, unde se stabilesc efectiv toate lucrurile care vor fi lucrate în sprintul care tocmai începe.
Asta se stabilește de comun acord între product owner și echipă, în funcție de capacitatea echipei și de complexitatea story-urilor.
Amintește-ți, story reprezintă un task, sau o unitate de lucru, dacă vrei.
Ce ajunge în sprint e o combinație între capacitatea echipei și prioritatea noilor dezvoltări, care este dată de product owner.
E o dicuție liberă cu un iz de negociere între echipă și product owner, nu e nimic bătut în cuie, iar product owner-ul nu e acolo ca să te streseze și să stea cu biciul pe tine.
Dacă face asta, probabil nu și-a înțeles prea bine rolul și ar fi bine ca echipa să-i dea de înțeles că ce face nu e bine.
“Șlefuirea” sarcinilor
Cândva pe parcursul sprintului, se mai desfășoară o ceremonie denumită “grooming” sau “refinement”. Tradus în limba română ar fi “rafinare” sau “șlefuire”.
Ăsta e momentul când product owner-ul vine cu cerințe noi de dezvoltare, le expune și le expică echipei.
Le discută împreună cu echipa și răspunde la întrebări, astfel încât să fie clar pentru toată lumea ce trebuie făcut la cerința respectivă.
De asemenea se estimează efortul, ideal în ceea ce se numesc story points, nu în unități de timp.
Dar din păcate estimările cu story points sunt ceva mai complexe și echipa trebuie să aibă o anumită maturitate și nivel de înțelegere al proiectului pentru o estimare cât de cât corectă.
Așa că mulți aleg să folosească estimările cu unități de timp în schimb.
Atenție! Am zis de fiecare dată “estimări” pentru că asta sunt. Asta nu înseamnă că dacă se estimează ceva la un efort de 3 zile, e obligatoriu ca după cele 3 zile să fie gata.
Sunt foarte multe lucruri care se pot întâmpla sau pe care le poți descoperi pe măsură ce lucrezi și evident că niciodată nu vei ști exact cât îți ia să dezvolți ceva anume.
Mai sunt și dependențele de alte echipe.
Se poate întâmpla ca uneori dezvoltarea unui nou modul să depindă și de alte dezvoltări în alte componente ale aplicației, care sunt gestionate de o altă echipă.
Atunci trebuie să te asiguri că echipa respectivă e gata, înainte ca tu să începi pe partea ta, mai mult de atât, trebuie să iei în considerare că e posibil să fie nevoie de ceva cercetare din partea ta înainte să începi să lucrezi efectiv.
Astea sunt lucruri care ridică complexitatea unui story sau unități de lucru și trebuie luate în considerare atunci când se face estimarea.
Revizuirea sprintului
La finalul celor 2-3 săptămâni, sprintul se încheie cu ceea ce se numește sprint review, unde se prezintă de către echipă ceea ce s-a făcut în ultimul sprint.
În ședința asta participă atât membri echipei și product owner-ul dar și alți oameni din partea de business care sunt direct implicați în expansiunea proiectului.
Se prezintă demonstrativ ultimele dezvoltări făcute, se pun întrebări.
Pot participa și membri altor echipe care au legătură direct cu proiectul respectiv, devenind astfel mai conștienți de ceea ce se întâmplă și cum pot folosi soluția pe care echipa ta o dezvoltă.
De asemenea și tu sau echipa ta puteți participa la review-urile altor echipe, tocmai din același motiv.
O să mai auzi de ședința asta sub denumirea de “demo” de la demonstration, dar indiferent de denumire, se referă la același lucru.
Retrospectiva sprintului
Acum s-a ajuns la finalul sprintului, dar asta nu e chiar tot.
Când am zis că o să ai destul de multe ședințe n-am glumit.
Mai e o întrevedere, de data asta doar cu echipa, care se numește “sprint retrospective”, sau retrospectiva sprintului.
Unde nu se discută lucruri legate de proiect, ci mai degrabă legate de echipă, de modul de funcționare, de interacțiune a membrilor etc.
Se pun pe un whiteboard toate punctele bune, cât și cele mai puțin bune, ce nu a mers bine exact.
Apoi se stabilesc câteva acțiuni pentru a îndrepta lucrurile care n-au mers bine.
Scrum master-ul e cel care trebuie să se ocupe de organizarea și desfășurarea acestor ceremonii, echipa trebuie doar să participe și să-și aducă contribuția.
De-aici următorul sprint începe și ciclul o ia de la început.
De-asta spuneam la început că SCRUM e un mod de lucru prin care echipele obțin feedback rapid și se asigură că duc proiectul în direcția în care business-ul are nevoie.
Avantajele folosirii SCRUM
S-a ajuns aici din cauză că proiectele mari enterprise au nevoie de ani să ajungă la un anume nivel de maturitate și dezvoltarea lor într-o fază continuă de la A la Z nu este posibilă.
De fapt ar fi posibilă, dar sigur nu se ajunge la rezultaltul dorit, pentru că sunt foarte multe variabile în joc și riscul să se irosească enorm de multe resurse și timp e unul foarte ridicat.
Asta era modalitatea care se folosea înainte de trecerea la metodologii agile și se numește “waterfall”.
Adică proiectul era împărțit în niște etape extrem de mari și s-a dovedit că lucrurile nu funcționează chiar bine în felul ăsta pentru că chipele care operează în SCRUM sunt ceva mai comunicative și ajung la performanțe mult mai bune.
De-asta cele mai multe companii aleg să adopte stilul ăsta de lucru pentru echipele lor de dezvoltare, care de asemenea nu e bătut în cuie, se mai poate mula pe nevoile companiei sau proiectului.
Se încurajează mult comunicarea între membri, mai degrabă decât urmarea unor reguli stricte într-un mod orbesc.
La început îți poate părea haotic, pentru că nu înțelegi cum decurge tot procesul și ce-i cu atâtea ședințe, dar pe parcurs te vei obișnui.
Nu trebuie să-ți faci griji, că nu se așteaptă nimeni să știi lucrurile astea când intri într-o echipă, te vei obișnui pe parcurs.
Sper doar că descrierea succintă oferită de mine să-ți creeze ceva context și să înțelegi mai bine și mai repede imaginea de ansamblu.
Componența echipelor e de asemenea destul de variată, de exemplu sunt unele echipe care încorporează și rolul unui business analyst, care ajută cu clarificarea funcționalităților, împreună cu product owner-ul, iar altele nu.
Deși e un rol care ar fi util indiferent de situație.
Cam atât pentru azi, pe data viitoare.
