Scrum-moft sau necesitate

Înțelegerea raportul de legături dintre Agile și Scrum, cercetarea principalelor ”mituri” legate de acestea sunt primordiale în cercetare. Imaginea de ansamblul asupra Scrum-ului realizată prin prezentarea conceptelor, a regulilor de desfășurare și a implicațiilor organizaționale oferă premisele cunoașterii metodei de lucru.

Studiul comparativ dintre principalele metode cuprinse în metodologia Agile, realizat cu scopul de a pune accentul pe particularitățile de lucru Scrum, răspunde la întrebarea din titlul capitolului: Scrum nu este doar o înșiruire de reguli, este o necesitate în condițiile actuale de lucru al proiectelor, este un răspuns la nevoia de schimbare.

Scrum și metodologia AGILE

Metodele tradiţionale erau eficiente, produceau software optimizat cu posibilitatea de a reutiliza anumite elemente din procesul de dezvoltare dar costurile utilizării acestor metode era mult prea mare: timpul necesar elaborării documentaţiei era disproporţional raportat la timpul dedicat dezvoltării software-ului; dacă cerinţele se schimbau actualizarea documentaţiei devenea un chin; optimizarea şi reutilizarea codului lua atât de mult timp încât adaptarea la noile tehnologii se transforma în dorinţă imposibilă.

Mai mult, Mike Cohn în ”Agile Estimating and Planning” identifică alte trei probleme ale abordării tradiţionale: sarcinile de lucru se organizează în abordarea tradițională pe individ și nu pe grup, ceea ce duce la probleme; planificarea în abordarea tradițională se realizează plecând de la premisa că toate activitățile identificate se vor realiza, lăsându-se prioretizarea să fie făcută de echipa de dezvoltare; modelele tradiționale se axează foarte mult pe finalizarea activităților și nu pe livrarea produselor/funcționalităților (practica demonstrând de multe ori că s-au implementat funcționalități de care clientul nu avea nevoie).

Raportându-se la aceste probleme şi la cerinţele în continuă schimbare la care abordarea tradiţională nu poate să se adapteze în timp util, perspectiva în managementul proiectelor s-a schimbat radical prin introducerea unei noi abordări: aşa numită „Agile”.

Deși a inceput cu mulți ani înainte, ”mișcarea” Agile a fost declarată oficial prin crearea Manifestului Agile din februarie 2001 (Beck). Autorii manifestului au precizat că ei valorizează:

• Indivizii și interacțiunile dintre aceștia mai mult decât procesele și instrumentele de lucru : se preferă comunicarea, față în față, verbală între persoane și se recunoaște unicitatea fiecărui individ și contribuția pe care o aduce în cadrul proiectului;

• Dezvoltarea soft-ului mai mult decât întocmirea documentelor : această valoare ar putea fi definită mai degrabă ca dezvoltarea produsului în loc de dezvoltarea software-ului pentru că produsul final este cel care contează cel mai mult la sfârșitul unui proiect; echipa ar trebui să depună mai mult efort în activitățile care aduc valoare, dacă se lucrează foarte mult la documentație și mai puțin la dezvoltarea produsului rezultatul nu va fi unul favorabil;

• Colaborarea cu clientul mai mult decât negocierea contractului : clientul trebuie să fie integrat în etapele proiectului, nu doar în fază de analiză; produsul trebuie creat raportat la nevoile clientului și nu la clauzele contractuale;

• Flexibilitatea la schimbare mai mult dec ât urmărirea strictă a planului : dacă s-a urmărit cu strictețe respectarea planificărilor și finalizarea la timp a activităților dar rezultatul nu este pe măsura așteptărilor clientului, proiectul nu va fi unul de succes.

Toate aceste valori fac ca Agile să fie înțeleasă ca o metodologie bazată pe principiul colabărării, toți membri echipei având aceeași misiune: de a livra frecvent, iterativ, la cel mai înalt nivel calitativ posibil, noi funcționalități, noi componente, prioritizate după necesitate și valoarea pe care o aduc, luând în considerare viziunea utilizatorului și feedback-ul de la acesta.

Definiţia Agile pentru mulţi autori de specialitate înseamnă să produci software cu mai puţină documentaţie în condiţiile unor cerinţe care se schimbă rapid şi care satisface toate necesităţile clientului, definiţie care ar deveni adevărată dacă s-ar prezenta şi riscurile.

Presupunerea că Agile înseamnă lipsa documentație este cel mai popular mit legat de această metodologie, abordare cu care eu nu sunt de acord: documentele simple, ușor de înțeles și integrat în modul de lucru al echipei permit evitarea haosului distructiv și nu am lucrat până acum la proiecte în care lipsa unei documentații măcar succinte să nu fie cauză a eșecului.

Boehm şi Turner identifică corect riscurile acestei abordări greșite în lucrarea Balancing Agility and Discipline: A Guide for the Perplexed ca fiind: implementarea proiectelor mari se realizează cu dificultate fără o documentaţie completă; dacă costul identificării tuturor utilizatorilor finali este prea mare, acesta nu va putea fi compensat cu perioada de implementare iar schimbarea unei cerinţe a unuia dintre utilizatori nu va putea fi acoperită în timp util.

Aceeaşi autori susţin că metodele Agile îşi dovedesc eficienţa mai mult în proiectele de dimensiuni mici, 5-10 persoane, opinie cu care sunt de acord. Goodpasture, în lucrarea Project Management the Agile Way. Making it Work in the Enterprise susţine și el această opinie dar lărgeşte numărul de membri la 50 şi adaugă faptul că Agile se potriveşte mai mult echipelor aflate în aceeaşi locaţie decât celor multinaţionale unde comunicarea se realizează cu dificultate.

Totodată el recomandă metodologia Agile pentru acele proiecte realizate intern, „in-house” şi nu pentru cele pe bază contractuală fixă.

Metodologia Agile cuprinde mai multe metode de lucru, toate având un numitor comun: fiecare în modul propriu încearcă să rezolve aceeaşi dilemă, omniprezentă în procesul de dezvoltare software: cum să reuşeşti să livrezi produsul în condiţiile în care cerinţele şi necesităţile clientului sunt incerte.

Dintre metodele Agile se pot enumera:

1. Scrum,
2. Extreme Programming (XP),
3. metode Crystal,
4. EVO (metodă revoluționară brevetată de Tom Gilb),
5. RAD care a evoluat în DSDM (Metodă Dinamică de Dezvotare a Sistemelor- în traducere).

Pe lângă acestea mai sunt:

• modele orientate pe funcţionalităţi („Feature-driven Design)
• modele în vederea adaptării procesului de dezvoltare software (Adaptive Software Development),
• Lean Development,
• Team Software Process (TSP) and Personal Software Process (PSP)

Ultimele fiind create şi folosite în cadrul universităţii Carnegie Mellon. Primele metode Agile erau de tip RUP (Rational Unified Process - create de IBM/Rational), RAD (Rapid Application Development) sau JAD (Joint Application Development). Metode mai noi dar discutabile în privinţa apartenenţei la Agile sunt Kanban şi CleanRoom.

Așa cum se precizează și mai sus: Agile este metodologia iar Scrum este metoda de lucru ce folosește principiile din metodologie dar are propriul set de reguli. În articolul Telling It Like It Is Ken Schwaber folosește și recomandă a se folosi pentru Scrum termenul de framework - tradus cadru de lucru. În opinia mea indiferent de cum îi spunem: metodologie, metodă, important este modul în care se pune în practică.

Primele cercetări care fac referire la metode neconvenționale de management al proiectelor sunt cele ale japonezilor Hirotaka Takeuchi și Ikujiro Nonaka care au studiat proiectele de dezvoltare la companiile: Honda, Fuji-Xerox, Cannon, NEC and Epson. Chiar dacă subiectul studiului nu era dezvoltarea software, în lucrarea acestora The New Product Development Game publicată în anul 1986 în Harvard Business Review au introdus termenul de Scrum pentru a descrie un comportament observat în studiile de caz realizate - foarte apropiat de ce înseamnă Scrum-ul astăzi ca metodă de management al proiectelor. Autorii numeau Scrum o metodă de formare a echipei în rugby ce presupune ca toată echipa să lucreze ca un colectiv. Obiectivul era mutarea mingea folosind anumite tehnici improvizate și executate de membrii echipei cât mai dinamic posibil.

Pentru munca sa creatorul Scrum este desemnat în Statele Unite ale Americii Jeff Sutherland, care a lucrat cu Jeff McKenna și Ken Schwaber, Mike Smith și Chris Martin. Scrum a fost prezentat oficial și publicat la OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) în 1995. Primele proiecte pentru care s-a aplicat Scrum sunt cele de la Individual, Fidelity Investments, și IDX (în prezent GE Medical).

Concepte, reguli și implicații organizaționale în cadrul de lucru Scrum

Scrum nu este un proces sau o tehnică pentru dezvoltarea produselor; este mai mult un cadru de lucru în care se pot dezvolta diferite tehnici și procese. Rolul Scrum-ului este de a pune în evidență eficacitatea relativă a managementului de produs și a practicilor de dezvoltare utilizate astfel încât să fie îmbunătățite, demonstrând astfel necesitatea aplicării lui ca și nou mod de lucru al proiectelor.

Punerea în practică a Scrum-ului depinde de trei piloni importanți ce determină la nivelul organizației schimbări:

• Transparența - toate aspectele semnificative ale procesului trebuie să fie vizibile pentru cei responsabili de rezultatul/finalizarea produsului. Limbajul trebuie să fie unul comun, ușor de înțeles pentru toți participanții;
• Verificarea - diferite aspecte ale procesului trebuie verificate suficient de frecvent, astfel încât să fie identificate din timp problemele. Frecvența verificărilor trebuie totuși să nu afecteze ritmul de lucru, în acest caz pierzându-și utilitatea;
• Adaptarea - dacă pe durata verificării se constantă că s-a deviat de la cerințele inițiale și că produsul final nu va fi acceptat atunci procesul/produsul trebuie ajustat și această corecție trebuie realizată cât mai urgent posibil pentru a minimiza riscul unei viitoare devieri.

Principala componentă a Scrum-ului este Sprint-ul, un interval de timp de o lună sau mai puțin în care o parte ”finalizată”, utilizabilă și potențial livrată a produsului este creată. Un nou Sprint începe imediat după ce precedentul s-a finalizat și s-au stabilit concluziile acestuia. Sprint-ul poate fi considerat un proiect care trebuie finalizat într-o lună cu anumite costuri și riscuri, la finalul căruia va trebui să se livreze ”ceva”. Pentru fiecare Sprint trebuie precizat ce trebuie creat, care este planul de realizare, care va fi efortul de dezvoltare și care va fi produsul rezultat.

Pe durată unui Sprint este esențial să se respecte următoarele reguli:

• Nu se fac schimbări care afectează scopul Sprint-ului;
• Componența echipei de dezvoltare rămâne constantă;
• Calitatea muncii nu trebuie să scadă;
• Scopul Sprint-ului trebuie să fie clar și poate fi renegociat dacă apar noi cerințe/informații

În cadrul unui Sprint se oferă patru oportunități pentru realizarea verificării și adaptării:

• Sprint Planning Meeting (Ședința de Planificare a Sprint-ului - se verifică cum se poate optimiza Sprint-ul, cât de clar este scopul Sprint-ului);
• Daily Scrum (Ședința Scrum Zilnică - se verifică progresul ce se realizează zilnic pe durata proiectului, se corectează neînțelegerile în privința cerințelor (dacă există) și se verifică dacă sunt impedimente)
• Sprint Review (Ședința de Revizuire - se verifică ce și cât din obiectivele stabilite pentru lansarea componentei au fost îndeplinite)
• Sprint Retrospective (Ședinta Retrospectivă - se verifică evoluția Sprint-ului anterior, ce a fost bine și ce nu și se găsesc soluții de îmbunătățire a Sprint-urilor viitoare).

Întâlnirile de mai sus se caracterizează prin stabilirea unei durate maxime a ședinței astfel încât timpul de planificare să fie optim și să nu afectează timpul de dezvoltare. Alături de aceste Ședințe în componența unui Sprint mai intră munca de dezvoltare.

Mediul Scrum presupune formarea unor Echipe Scrum cărora li se asociază roluri, evenimente/intervale de timp fixate, rezultate și reguli (fiecare componentă deservește un scop bine definit și are un rol specific în utilizarea și succesul Scrum-ului). Conform autorilor Ken Schwaber și Jeff Sutherland, Echipa Scrum se organizează singură, lucrează în iterații, se bazează pe feedback-ul obținut cu regularitate, atât în timpul fiecărui Sprint, la final acestora, cât și la livrarea produsului final și este formată din (componența și rolurile Echipei Scrum sunt prezentate detaliat în figura nr 1):

• Scrum Master (Coodonatorul Scrum-ului - pentru a ilustra corespunzător acest rol voi folosi în lucrare termenul în engleză), cel care este responsabil ca tot procesul Scrum să fie înțeles și respectat;
• Product Owner (Proprietarul Produsului - pentru a ilustra corespunzător acest rol voi folosi în lucrare termenul în engleză), cel care stabilește cerințele și evaluează livrabilele;
• Development Team (Echipa de Dezvoltare), cei ce pot finaliza cerințele Product Owner-ului până la sfârșitul Sprint-ului sub forma unui livrabil, parte componentă a produsului final.

Backlog-ul Produsului (Lista de Cerințe a Produsului - pentru a ilustra corespunzător acest concept în lucrare voi folosi termenul de Backlog-ul Produsului) este o listă ordonată a tot ce este necesar pentru dezvoltarea și lansarea unui produs de succes: toate funcționalitățile, funcțiile, tehnologiile, îmbunătățirile și corecțiile care vor fi implementate în vederea lansărilor viitoare a produsului software. Backlog-ul evoluează odată cu produsul și cu mediul în care va fi folosit, dinamică necesară pentru a atinge obiectivele dezvoltării produsului: de a fi corespunzător, competitiv și util.

Tabela nr. 1 Componența Echipei Scrum. Roluri și Caracteristici

(sursa: prelucrare după Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org; Schwaber, K., Agile Project Management with Scrum, Microsoft Press, Washington, 2004)

Elementele din Backlog-ul Produsului se caracterizează prin:

• Descriere
• Prioritatea - este definită pe baza riscurilor, valorii și necesității elementului;
• Estimarea - estimări mai bune se realizează atunci când elementul este definit clar și detaliat

Elementele cu cea mai mare prioritate vor fi dezvoltate imediat. Cu cât mai mare este prioritatea, cu atât elementul este mai urgent, cu atât mai mult a fost analizat și s-a stabilit mai clar care este valorea sa. Cu cât prioritatea elementului este mai mică, cu atât este mai puțin detaliat. Pe măsură ce un produs este folosit, valoarea lui și feedback-ul oferit de piață cresc iar Backlog-ul Produsului crește și se completează (sarcinile se modifică dinamic din cauza modificărilor în cerințele de business, condițiilor de piață, tehnologie și dinamicii echipei).

Adesea, mai multe echipe Scrum lucrează la același produs. În acest caz elementele din Backlog conțin un atribut adițional ce permite gruparea lor seturi de funcționalități, tehnologie sau arhitectură pentru a facilita organizarea muncii în echipe.

Elementele din Backlog-ul Produsului sunt estimate inițial în timpul Planificării Lansărilor (termenul în engleză consacrat Release) și apoi pe măsură ce sunt create. Estimările sunt revizuite și ajustate pe măsură ce backlog-ul este analizat în detaliu și pot fi modificate oricând. Responsabilitatea estimărilor revine echipei și pot fi negociate cu Product Owner-ul.

Monitorizarea efortului rămas pentru elementele din Backlog-ul Produsului în funcție de timp se realizează prin Diagrama Burndown (diagrama de evoluție a proiectului - pentru a ilustra corespunzător acest concept voi folosi în lucrare termenul în engleză). Efortul estimat este măsurat în orice unitate aleasă de către Echipa Scrum și organizație. De obicei unitățile de timp folosite sunt Sprint-urile.

Activitățile pe care echipa le îndeplinește pentru a transforma elementele din Backlog-ul Produsului într-o parte finalizată se concretizează în Backlog-ul Sprint-ului (lista de cerințe realizate în Sprint - pentru a ilustra corespunzător acest concept voi folosi în lucrare termenul în engleză). Multe dintre aceste activități sunt identificate în timpul Planificării Sprint-ului dar pe măsură ce Echipa de Dezvoltare lucrează la sarcini de lucru individuale va afla că mai multe sau mai puține dintre activitățile planificate sunt necesare sau că o anumită activitate durează mai mult sau mai puțin decât durata estimată. Backlog-ul Sprintului este o imagine în timp real, vizibilă, a muncii pe care echipa plănuiește să o îndeplinească în timpul Sprintului.

O sinteză a modului de lucru Scrum este prezentată în figura nr.2 de mai jos:

Figura nr. 1 Reprezentare modului de lucru Scrum

Diagrama Burndown a Backlog-ului Sprint-ului este un grafic al muncii rămase într-un Sprint față de durata Sprint-ului, creat astfel: se calculează munca rămasă prin adunarea zilnică a estimărilor din backlog. Cantitatea de muncă rămasă într-un Sprint este suma muncii rămase pentru întreg Backlog-ul Sprint-ului. Evidența acestor sume zilnice se păstrează și valorile sunt folosite pentru a crea un grafic care arată munca rămasă în funcție de timp. Prin desenarea unei linii prin punctele graficului, Echipa poate observa progresul din cadrul Sprint-ului. Se studiază munca rămasă și data estimată de finalizare.

Una din principalele reguli Scrum este ca la finalul fiecărui Sprint-ului acel increment , parte a produsului potențial livrabilă, să adere la definiția curentă a termenului ”finalizat”: să fie ceva în plus, adăugat la toate îmbunătățirile anterioare, să fie complet testat iar integrarea acestuia să nu afecteze celelalte componente deja integrate.

SCRUM vs. Kanban vs. eXtreme Programming (XP)

În literatura de specialitate se dispută destul de des care dintre metodele Scrum şi eXtreme Programming este cea mai populară. Boehm şi Turner afirmă în lucrarea Balancing Agility and Discipline: A Guide for the Perplexed că Agile se identifică de multe ori cu eXtreme Programming, fiind cea mai vizibilă metodă dar dezaprobă înţelegerea aceste metode ca posibilitate extremistă de înterpretare a bunelor practici Agile (nu poţi să afirmi că foloseşti XP dacă nu utilizezi „codarea în pereche: programator-observator”, „refactoring” sau nici măcar „planificare de tip joc”). Goodpasture, în Project Management the Agile Way. Making it Work in the Enterprise susţine că SCRUM este cea mai populară metodă, fiind şi cea mai simplă prin faptul că nu se prescriu practici, tehnici de lucru, ci doar se oferă un set de reguli Scrum.

Deși considerate două metode de lucru Agile foarte apropiate, eXtreme Programming este considerată a fi mai orientată pe definirea practicilor de dezvoltare software, pe când Scrum mai mult pe practici de management. Pentru că în eXtreme Programming tehnicile de dezvoltare au un caracter obligatoriu de utilizare, numeroși autori recomandă întâi să se înceapă cu Scrum pentru a echipa să câștige încredere în autoorganizare, să își descopere propriul set de tehnici de dezvoltare. Henrik Kniberg în Scrum and XP from the Trenches. How we do Scrum propune chiar un mix dintre cele două metode de lucru pentru eficientizarea atât a managementului proiectului, cât și a modului de dezvoltare.

Dacă în Scrum nu se acceptă schimbări ale scopului Sprint-ului pe durata desfășurării acestuia, XP permite acest lucru, atâta timp cât nu afectează funcționalitatea la care echipa lucrează în acel moment.

Kanban este o metodă de lucru Agile ”JUST-IN-TIME” bazată pe fluxurile sarcinilor de muncă. Raportat la particularitățile Scrum-ului, în Kanban nu există iterații sau Sprint-uri, nici roluri definite (echipa de proiect sau clientul poate specifica orice rol este nevoie în proiect) iar estimările se consideră că nu sunt necesare pentru că oricum nu se respectă. Statusul curent al unei cerințe poate fi unul din următoarele: ”Backlog”, ”În Lucru”, ”Finalizat”. Sarcinile de lucru aflate în lucru sunt limitate pe fiecare etapă permițând urmărirea și rezolvarea blocajelor imediat.

Kanban se potrivește mai mult acelor proiecte de dezvoltare unde sarcinile de lucru sunt în continuă schimbare și nu există o modalitate de a defini iterații/Sprint-uri, dar necesită o foarte bună cunoaștere a ciclului de dezvoltare și o implicare a clientului pentru a livra tot timpul ceea ce el are nevoie și nu ceea ce se poate dezvolta.