Managementul unei echipe de dezvoltare software este o meserie pe care trecerea timpului nu a transformat-o, așa cum se întâmplă de obicei, într-una mai ușoară. De la publicarea lucrării Agile Manifesto, în 2001, multe companii și echipe care dezvoltă produse soft au practicat și testat metodele și tehnicile Agile cu succes.
Cunoscută și sub numele de Extreme Project Management (XPM), această abordare a managementului de proiect are ca scop îmbunătățirea răspunsului produsului la schimbarea specificațiilor clientului. Așadar, în timp ce echipa Agile se concentrează pe creșterea nivelului de adaptabilitate, se pierde din importanța acordată în mod normal, predictibilității.
Lipsa de predictibilitate a echipei este într-adevăr dezavantajul metodologiei Agile. Acest articol vorbește despre modul în care metodele Agile sunt aplicate în XPM și prezintă câteva exemple, sperăm noi utile, legate de modul în care putem traduce teoria Agile în proiecte de succes pentru echipă și profit pentru organizație.
Întâi de toate, XPM nu se potrivește oricărei echipe. După cum se specifică în Agile Manifesto, vorbim despre echipe care se organizează singure, formate dintr-un număr mic de dezvoltatori seniori, care lucrează pe proiecte ale căror specificații se schimbă frecvent. De aceea, am avea nevoie de o cultură în echipă bazată pe un răspuns pozitiv la schimbări - o echipă în care există comunicare, colaborare și în care rolurile se pot schimba în orice moment.
Rolurile într-o echipă Agile sunt de asemenea foarte importante. O echipă Agile nu are nevoie de managerul clasic, membrii acesteia sunt direct resposabili de munca lor. Scrum Master este managerul echipei, iar rolul său este ca acela al unui antrenor. El are abilități de organizare, obține resurse pentru echipă și conduce echipa spre realizarea obiectivelor sale. Alte roluri în echipa Agile sunt: Domain Expert, Technical Lead, Independent Tester, Product Owner și alți Stakeholders. Așa cum vom vedea mai târziu, fiecare dintre acești membri se concentrează pe diferite aspecte ale proiectului în care sunt toți implicați și aceasta este adevărata provocare a echipei Agile.
Aspectele pe care metodele Agile își propun să le dezvolte într-o echipă, le-am structurat în trei categorii: comunicare, eficiență și calitate.
După cum am menționat mai sus, XPM se bazează pe o comunicare constantă și productivă. Prin intermediul procedurilor Agile un astfel de mediu de lucru poate fi construit pentru a asigura evoluția și optimizarea proceselor. Iată care sunt instrumentele Agile: ședința de planificare (Iteration Planning), Poker Planning, sistemul de urmărire a vitezei de lucru a echipei (Velocity Tracking), ședințele de retrospectivă.
Eficiența echipei este asigurată de ședințele zilnice de Scrum (stand-ups) și obținerea de feed-back în timp scurt, ceea ce conduce la un ciclu de lucru (Sprint) foarte adaptabil. Echipa Agile se concentrează, în același timp, pe calitate, prin procesul de integrare continuă, pair-programming, procesele de testare, refactorizare și review al codului, D3 (Design Driven Development) și TDD (Test Driven Development).
Metodologia Agile ne învață multe lucruri și abordează dezvoltarea de produs din diferite puncte de vedere. Cred că una dintre cele mai importante dimensiuni ar fi Procesul Agile Nedefinit (the Agile Undefined Process) - principiul conform căruia un proces sau proiect Agile nu este în nici un moment pe deplin definit. De asemenea, se referă la conceptul de Agile Modeling: documentare, arhitectură și cerințe care se pot schimba în orice moment și care trebuie să fie întotdeauna clare și transparente. Este principiul care pune accentul pe diferența dintre Development Release și Production Release, sau diferența dintre viteza de lucru a echipei și îndeplinirea angajamentelor privind lansarea produsului la client.
Așa cum am menționat mai sus, Agile nu vizează proiecte care necesită previziuni. Nu se focalizează pe proceduri sau artefacte, ci pe metodologii pentru oameni. În terminologia Agile acestea sunt numite Crystal Methods: lansarea frecventă de cod utilizabil pentru client, îmbunătățirea prin re-evaluare, testarea prin intermediul utilizatorilor experți, teste automate.
O altă dimensiune Agile este Feature Driven Development. Aceasta prezintă cele mai bune practici din perspectiva înțelegerii businessului și a clientului, așa numitul Domain Driven Development (D3), lansări regulate și transparență în ceea ce privește progresul proiectului și rezultatele sale. Și cu aceste practici ne apropiem tot mai mult de cealaltă parte a Agile: managemenul resurselor și livrarea la timp.
În Agile, managementul timpului, al calității și al costului se numește Dynamic System Development Method. Se referă la concentrarea pe necesitățile businessului, dezvoltarea și lansarea rapidă, fără a se compromite însă calitatea, la demonstrarea controlului prin dezvoltarea graduală și la comunicarea constantă. Această dimensiune introduce termenul de prioritizare (the musts, the shoulds, the coulds and the won"t haves).
Chiar dacă voi prezenta utilizarea Scrum în XPM, există următoarele principii din metodologia Kanban, care vin să completeze foarte bine ideea pe care încerc să o conturez privind livrarea la timp și controlul resurselor. Și aceste principii ar putea fi rezumate prin fraza: "Oprește-te să începi și începe să termini" ("Stop starting and start finishing"). Cu alte cuvinte, echipa ar trebui să convină să urmărească schimbarea progresivă și să respecte procesul curent și rolurile care s-au stabilit la începutul proiectului.
Am spus deja că Agile nu se concentrează pe proceduri, ci pe oameni și metode pentru oameni. Există această ultimă dimensiune Agile care se referă la ce anume se dezvoltă, mai degrabă decât la cum se dezvoltă. Este vorba de teoria Agile cunoscută sub numele de Lean Software Development - politici și proceduri scrise în scopul de a controla consumul de resurse. Unele dintre aceste politici sunt: eliminarea pierderilor, luarea unor decizii cât mai târziu posibil, livrarea cât mai rapidă posibil, asigurarea unei viziuni de ansamblu și demonstrarea integrității.
Ne vom întoarce acum la mențiunea mea cum că membri diferiți ai echipei Agile au interese diferite atunci când participă la dezvoltarea unui proiect. Desigur, cu toții își fac treaba în cel mai bun mod posibil și înțeleg și respectă Scopul Proiectului Agile (ce software trebuie construit și livrat). Dar, în timp ce membrii echipei sunt interesați de metodele de inginerie și de practicile Extreme Programming (XP), precum și de scrierea de cod de calitate, Scrum Master se axează pe adaptarea la cerințelor de sistem imprevizibile, în același timp fiind capabil să măsoare viteza de lucru a echipei. Pe de altă parte, Product Owner-ul nu este interesat însă nici de viteza echipei, nici de calitatea codului. El ar dori ca echipa să fie în măsură să facă estimări exacte privind termenul de finalizare a proiectelor. Cu alte cuvinte, Product Owner-ul, precum și alți Stakeholders, ar dori ca echipa să fie ... previzibilă.
Pentru a putea prezice lansarea produsului, o echipă trebuie să fie capabilă să estimeze, în primul rând, etapele de dezvoltare. Pentru aceasta avem instrumentele Scrum pentru managementul de proiect: Poker Planning, Velocity Tracking și Sprint Retrospectives.
Vă voi prezenta în continuare câteva exemple concrete despre cum Scrum și XP pot conlucra pentru a ne ajuta să atingem scopul predictibilității.
De obicei, veți găsi mai multe articole care vorbesc despre diferențele dintre Scrum și XP. Deși ambele se concentrează pe producerea de software funcțional în cel mai scurt timp posibil și pun accentul pe importanța comunicării între echipe, ele sunt descrise mai degrabă ca abordări opuse în dezvoltarea de produse soft.
Acum că am văzut care sunt diferențele dintre Scrum și XP, ne vom axa pe instrumentele care îmbină avantajele celor două metodologii.
O echipă Scrum cuprinde toate persoanele necesare în dezvoltarea de software funcțional. Acest lucru înseamnă dezvoltatori, testeri și analiști care lucrează împreună pentru un obiectiv comun. Chiar dacă am acceptat principiile Agile de dezvoltare, managementul de livrare și planificarea proiectului se fac în continuare în concordanță cu modelul Waterfall. Realitatea Agile în cadrul organizațiilor a deviat de la ideile inițiale descrise în Agile Manifesto și a devenit mai mult o abordare hibridă a managementului unui ciclu de dezvoltare, numită Water-Scrum-Fall.
Water - Cerințe și specificații (toate documentele necesare, actualizate)
Scrum - Proiectare și implementare (practici de inginerie)
Fall - Verificare, întreținere (testare automată, lansare și livrare)
XPM se referă la crearea de rezultate de calitate, funcționale, care furnizează cea mai mare valoare financiară posibilă, în același timp reducând riscul de eșec. Prin adoptarea Water-Scrum-Fall, se face în mod subtil trecerea de la modelul Agile, axat pe echipă, la modelul Agile axat pe nevoile de business. Prin combinarea beneficiilor aduse de metodologiile de dezvoltare Agile și Waterfall, se preia controlul asupra felului în care echipa interacționează cu alte părți ale organizației, reducând treptat consumul de resurse și crescând predictibilitatea în ceea ce privește estimările și livrarea.
În Scrum, viteza este reprezentată de cât de mult poate dezvolta o echipă în cadrul unei iterații. Acest lucru poate fi estimat analizând iterații anterioare, presupunând că membrii echipei și durata sprintului rămân aceleași. Rapoartele de viteză sunt folosite la ședințele de planificare, cu scopul de a defini următorul sprint. Odată stabilită, viteza va fi folosit pentru planificarea livrărilor.
Grafice de măsurarea a vitezei unei echipe:
Cu XP, sprint-urile sunt flexibile și noi task-uri pot fi integrate pe măsură ce apar, în timpul unei iterații. Această abordare îngreunează procesul de măsurare a vitezei și face aproape imposibilă folosirea unui Burndown Chart.
Atunci când un nou task este adăugat în timpul unui sprint, un altul ar trebui să se întoarcă în backlog. În acest fel, numărul de puncte (story points) stabilite pentru un sprint rămâne așa cum a fost plănuit inițial. Dacă acest lucru nu se întâmplă și task-uri noi sunt adăugate la volumul de lucru existent, echipa nu va putea să completeze sprint-ul conform planului și, prin urmare, nu-și va putea respecta angajamentele.
Ecuația Velocity Tracking:
Planned (sp) + Added (sp) - Removed (sp) = Assigned (sp) = Burned (sp)Un principiu important al XP este proprietatea colectivă asupra codului: e important să vă asigurați că nici o bucată de cod nu ajunge în producție fără a fi revizuită de o a doua persoană. Scopul acestei abordări nu este numai de a livra cod de calitate, cu mai puține bug-uri, ci și de a face informația și cunoștințele să circule între membrii echipei. Totodată, un alt scop este acela de a da o șansă developer-ilor să preia ideile bune de la colegii lor.
Pentru a vă asigura că toate costurile de revizuire a codului nu depășesc beneficiile, vă oferim o idee privind ce ar putea funcționa și când.
S-ar putea să cunoașteți care sunt etapele unei echipe Agile: Forming, Storming, Norming și Performing.
În funcție de etapa în care se află echipa în momentul respectiv, anumite abordări pentru revizuirea de cod sunt mai potrivite decât altele.
În etapa de Forming, este indicat ca membrii echipei să formeze perechi și să lucreze împreună. În felul acesta, cei cu mai puțină experiență pot lucra cu senior developers și membrii echipei care au mai multe cunoștințe despre proiect pot comunica din informații și celorlalți. În felul acesta, echipa este mai productivă și mai eficientă decât dacă fiecare membru ar lucra pe cont propriu.
Când echipa se află în faza Norming, sesiunile de revizuire a codului sunt mai eficiente dacă participă întreaga echipă. Acesta este momentul în care echipa își stabilește standardele și principiile pentru codare și când se iau multe decizii importante.
În cele din urmă, dacă echipa este matură și în faza de Performing, lucrul individual este mult mai eficient decât dacă mai multe persoane lucrează pe aceeași bucată de cod. Peer-reviewing este tipul de verificare cel mai potrivit în acest caz.
Ultima, dar și cea mai importantă regulă în XPM este să ne asigurăm că punem în practică cât mai multe dintre cunoștințele pe care le avem, cât mai repede posibil. Fiecare ședință a echipei ar trebui să se finalizeze cu un set de concluzii și propuneri de acțiuni și nicio retrospectivă nu ar trebui să stabilească noi scopuri pentru echipă atâta timp cât cele anterioare nu au fost îndeplinite. Trebuie să menținem echipa responsabilă, concentrată și conștientă de propriile responsabilități.
de Ovidiu Mățan
