Cu ceva timp în urmă, un coleg de-al meu a scris un articol foarte interesant despre "Best Practices In Agile Methodologies". Titlul te anunță că articolul conține un set de reguli care te-ar transforma instant în cea mai agilă persoană de pe planetă. Dar am descoperit cu mare plăcere că de fapt, în practică, aceste reguli sunt mai mult nişte direcţii şi adaptări la mii de situaţii diferite. Acel articol m-a făcut cumva conştient de următoarea situaţie: de câte ori aţi auzit pe cineva spunând: "În proiectul curent noi implementăm scrum-ul ca la carte"? Este ca şi cum ar zice cineva "am o viaţă perfectă". Se întâmplă foarte rar şi nu pe Pamânt.
Lucrez bazat pe principiile Scrum deja de opt ani. Am fost implicat în câteva proiecte în acest timp şi, totodată, am avut plăcerea de a discuta cu multă lume şi în afara proiectelor curente, cu prieteni din domeniu şi în acelaşi timp cu multă altă lume în interviuri. Nu-mi aduc aminte să fi spus cineva vreodată că lucrează bazat pe un Scrum ca la carte. Întotdeauna ceva lipsea. Putea fi vorba despre unul din meeting-urile zilnice pe care echipa decidea să nu-l mai ţină dintr-un motiv întemeiat. Putea să aibă legătură cu rolul product owner-ului care nu este niciodata bine definit: câteodată îl regăsim în organizaţia clientului, dar după două săptămani de lucru cu el ne dorim cu ardoare să nu-l fi găsit vreodată. Câteodată îl regăsim în organizaţia noastră, foarte bine pregătit, ştiind bine ce are de făcut, dar parcă tot avem o strângere mică de inimă din cauză că nu face parte din echipa clientului, cum ar zice teoria. Altădată poate fi vorba de meeting-ul retrospectiv pe care, pentru motive bune sau rele, echipa a decis să-l ţină o dată la două iteraţii, şi din nou nu e ca la carte. Voi prezenta trei situaţii în care schimbările nu creează complicații , din contră fiind condiții ale succesului.
Primul exemplu are legatură cu lungimea iteraţiei. Dacă luăm trei echipe diferite având iteraţii cu lungimi de o săptămână, două săptămâni, trei săptămâni şi adresăm oricăruia dintre membrii echipelor întrebarea "Care e lungimea iteraţiei voastre? ", în toate cele trei cazuri, răspunsul va fi invariabil: "Ştiu că nu e un Scrum ca la carte, noi lucrăm cu iteraţii de x săptămâni". Pe forumuri sunt multe dezbateri privind acest aspect al perioadei de livrare, dar ideea de bază ar trebui să fie aceeaşi, şi anume că totul are legătură cu periodicitatea cu care livrăm nu cu lungimea perioadei de livrare în sine. Cea mai importantă piesă din acest angrenaj e contextul. În unul dintre proiectele noastre, clientul schimbă priorităţile mai ceva decât Liga 1 antrenorii, fiind bazat pe nevoile sistemelor aflate deja în producţie. Analizând contextul şi modul de evoluţie al lucrurilor s-a realizat că eficienţa maximă se va produce prin iteraţii de o săptămână. Ceea ce e în regulă. Avem alt client care datorită modului său de operare şi organizare e capabil să ne dea specificaţii şi priorităţi pe următoarele trei săptămâni, adoptând această lungime pentru iteraţii. Așadar avem două contexte de lucru total diferite, două soluţii diferite şi rezultate bune în ambele cazuri. Concluzia este că până la urmă totul se reduce la analiza contextului, la soluţia optimă pentru acel context sau într-un cuvânt totul se reduce la adaptare. Regulile sunt grozave ca bază de pornire, dar din acel moment adaptarea e esenţială.
O altă situaţie pe care am întâlnit-o destul de des are legatură cu meeting-urile de final de iteraţie. În mod normal avem două meeting-uri la sfârşitul fiecărei iteraţii: un meeting de validare al iteraţiei şi un meeting retrospectiv. Bazat pe faptul că 63% din datele statistice sunt numere aleatorii, se poate afirma cu exactitate că 80% din persoanele cu care am vorbit nu sunt mulţumite de felul în care se termină iteraţiile. Această nemulțumire se poate explica fie din cauza faptului că numele meeting-ului e greşit (pentru că eticheta e foarte importantă în zilele noastre nu-i aşa?), fie din cauza unor probleme mărunte cum ar fi: nu este un meeting adevărat de validare deoarece clientul este cel care parcurge ce s-a implementat şi demo-ul nu este făcut de echipă. Mult prea concentrată pe notaţii, lumea uită care este scopul final al acestor meeting-uri: analiza lucrului efectuat, prezentarea rezultatului către părţile interesate (imposibil să nu găsim pe cineva interesat de rezultatul muncii noastre căruia să-i putem prezenta rezultatul), planificarea a ceea ce a rămas nefăcut şi îmbunătăţirea procesului. Am trecut prin proiecte unde s-a ajuns la concluzia că o eficienţă rirdicată este obţinută atunci când clientul trece prin procesul de acceptare în timpul iteraţiei, astfel ca meeting-ul de validare de la sfârşit nu-şi mai are rostul. De asemenea, am întâlnit proiecte unde retrospectiva asupra întregului proces era facută o dată la trei iteraţii. Contextul a fost cel care a dictat, cazurile fiind de succes. Vă sugerez o mică idee nebunească: dacă facem meeting-ul retrospectiv doar de dragul de a bifa un alt subpunct din lista scrum-ului ideal şi nu folosim în mod real informaţia obţinută pentru a îmbunătăţi procesul, nu este sfârşitul lumii dacă nu-l mai facem. Economisim timpul şi facem ceva ce poate fi mai util în acest context.
Cel mai "controversat" exemplu mi-a venit în minte cu ocazia unei discuţii interne cu colegii. A pornit de la întrebarea: cum integrăm procesul de testare în iteraţie? La o mică analiză a ceea ce s-a întâmplat sau ce se întâmplă în proiectele cunoscute, mi-au venit în minte tot atâtea abordări câte proiecte: în unele proiecte estimările story-urilor includeau partea de testare; în altele, partea de testare era decuplată de story-ul în sine, dar era parte integrantă din iteraţie, cu estimare proprie, efectuându-se după terminarea fiecărui task; în altele, partea de testare era decuplată de story şi era planificată pentru iteraţia următoare; în altele partea de testare avea segmentul ei special la sfârşitul iteraţiei, într-o scurtă perioadă de stabilizare a iteraţiei curente; probabil aş mai putea enumera multe alte moduri care diferă între ele în puncte mai mult sau mai puţin importante. Destul de des perioada de stabilizare de la sfârşitul iteraţiei survine după o aşa numită îngheţare a dezvoltării efective și concentrare doar asupra corectării erorilor. Am auzit în acelaşi timp destule opinii care spun că nu există aşa ceva, că perioada de îngheţare este o aberaţie. Dacă pentru lungimea iteraţiei posibilităţile sunt cumva reduse la seria 1-2-3 săptămâni în acest caz putem avea câte echipe, atâtea particularizări. Ceea ce este mai important este că fiecare poate fi corectă în contextul dat. Sunt momente când ne-am dori cheia universală pentru această ecuaţie deoarece găsirea soluţiei corecte pentru contextul dat poate fi anevoioasă, dar dacă am avea şablonul universal unde ar mai fi distracţia? Cuvântul Agile, ce apare în faţa cuvântului Scrum vine tocmai de la adaptare, de la încercarea unor noi posibilităţi.
În toate aceste situaţii lumea uită rezultatul final. În nici un caz nu vreau să spun că modul în care ajungem acolo nu e important, din contră, dar înainte să hotărâm că ceea ce facem nu ne aduce fericirea din cauză că un proces nu este urmat 100% ca la carte, am putea să ne răspundem la nişte întrebări: echipa lucrează bine împreună? livrează ce şi-a propus să livreze la timp? clientul este fericit cu rezultatele muncii echipei? De multe ori răspunsul la aceste întrebări este ignorat şi în faţa lui primează trendul, un Scrum ideal la care visăm cu toţii, şi care în contextul dat nu este atins. Şi bineînţeles mai intervine şi natura umană care este dramatic rezistentă la schimbare. Majoriatatea oamenilor preferă, voluntar sau involuntar, calea ușoară, calea cu care sunt obişnuiţi şi uită exact esenţa a ceea ce înseamnă Agile: adaptare. În mod logic, dacă răspunsul la întrebările de mai sus ar fi da şi nu am şti că totul în lumea aceasta gravitează mai nou în jurul modelului (dezbate, planifică, acţionează, întâlneşte-te zilnic ca să-ţi confirmi că acţionezi, arată, pune bine deoparte în catastif învăţămintele şi repetă iar în cicluri de x săptămâni) atunci toată lumea ar fi fericită. Toţi ar fi împăcaţi că fac ceea ce trebuie, că işi fac treaba corect, ceea ce de fapt înseamnă mii de soluții corecte diferite în mii de contexte diferite.
Concluzia a tot ceea ce am expus mai sus este că nu ar trebui să ne fie frică să ne adaptăm pentru că, aşa cum ziceam, aceasta înseamnă de fapt Agile. Fugim cu îndârjire după un Scrum ca la carte şi nu-i nimic rău în asta. Dar sub nicio formă nu trebuie să ne agăţăm cu disperare de acest trend şi să uităm că Scrum vine în contextul Agile. Este important să ne orientăm concentrarea către Scrum. Este o metodologie care a dat rezultate şi dă în continuare rezultate foarte bune.
de Larisa Goța
de Alpar Torok
