Articolul de față e o replică la un alt articol apărut în numărul 47 al TSM, și anume Cunoaște-ți inamicul realizat de Vasile Selegean. Lectura acestui articol m-a determinat să abordez problemele semnalate dintr-o altă perspectivă.
Ceea ce veți găsi în articolul de față sunt răspunsuri la chestiunile discutate, însă nu și o descriere completă a Scrum-ului. Rezultatul, la care sper eu să ajungem, e o mai bună înțelegere a acestei metode în rândul comunității noastre, o dorință de a reflecta și de a ne îmbunătăți cunoștințele teoretice și practice de Scrum și, de ce nu, cunoscându-ne mai bine, să devenim prieteni.
Să reluăm, deci, cele patru principii ale manifestului Agile:
Articolul inițial se întreabă retoric ce altceva e Scrum dacă nu un proces. Răspunsul meu: Scrum e un framework de proces, nu un proces. Care e diferența? Un framework de proces e lejer. El oferă structură și direcție fără a fi detaliat sau rigid. În schimb, un proces e un set predefinit de pași și decizii de urmat pentru a atinge un anumit scop.
Scrum definește: rolurile și responsabilitățile lor, meeting-urile, existența și scopul a două gateway-uri, o listă de artefacte (product backlog, user stories, etc.) și un schelet al procesului - sprintul, deci, în mare, cele trei roluri și interacțiunile principale dintre ele. Pornind de aici, fiecare echipă își construiește procesul de care are nevoie, plecând de la nevoile și cerințele pe care le are de rezolvat. Procesul poate descrie noi pași, artefacte (ex: documentație), și chiar gateway-uri noi și va detalia părțile lipsă, de exemplu, va crea definițiile gateway-urilor "Done" și "Ready", negociate între echipa de dezvoltare și Product Owner.
Framework-urile de proces și metodologiile oferă, deci, un punct de plecare care ne dă un limbaj comun și pe care putem construi procesul de care avem acum nevoie, fără să fie nevoie să reinventăm roata la fiecare produs nou.
Product Owner-ul ca reprezentant al tuturor stakeholder-ilor, trebuie să compileze toate cerințele diferiților stakeholder-i într-o listă unificată și prioritizată de user stories, în Product Backlog. Aceasta nu îl obligă să colecteze și să redacteze personal întregile cerințe pentru toată echipa de dezvoltare, lucru care ar putea fi chiar imposibil, însă ceea ce e cel mai important este că oferă echipei de dezvoltare un mare ajutor prin a rezolva conflictele apărute între priorități și acordă un singur punct de acces pentru lămurirea neclarităților legate de cerințe.
Echipa de dezvoltare e multifuncțională și trebuie să aibă abilitățile necesare rezolvării problemelor încredințate. Însă la orice situație pe care nu o poate rezolva singură, echipa are responsabilitatea de a cere ajutorul Scrum Master-ului și/sau Product Owner-ului. Problemele posibile sunt: lipsa anumitor calificări, resurse, specificații etc. .
În paradigma Agile trebuie să învățăm un nou mod de a interacționa și colabora cu membrii echipei. Nu mai există "command and control", nu există ierarhie sau competiție și accentul se pune pe colaborare și responsabilitate. Știu cât de ciudat sună aceasta pentru noi, care am învățat mai mult cum să nu luăm inițiativa și să nu ne asumăm responsabilitatea. E ilustrativ în acest sens graficul dintr-un alt articol, din numărul 48 al TSM, din care mie mi-a sărit în ochi cât de puțin ne dorim, în Europa de Est, ca managerul să ne ofere libertate. Însă pentru mine, asumarea responsabilității e aspectul cel mai provocator din tot framework-ul de față și filozofia Agile. Cred că aici avem cea mai importantă șansă să creștem, nu doar ca profesioniști, ci și ca oameni.
Estimările nu sunt definite clar, nefiind fundamentale pentru Scrum. Sunt parte esențială a altor metode de dezvoltare pe care cred că ne e greu să le lăsăm în urmă. Dar, trebuie să ne întoarcem la care e scopul lor, și anume: pentru stakeholder-i, scopul estimărilor e acela de a ști când primesc o anumită funcționalitate și pentru echipa de dezvoltare sunt importante doar că să poată ști care e volumul de muncă pe care să și-l asume într-un sprint. Fiecare echipă poate decide care e nivelul și metoda de estimare de care are nevoie pentru a îndeplini aceste cerințe. În plus, legat de cum să folosim estimările în practica Scrum, am întâlnit mai multe recomandări de a folosi mai degrabă estimări relative, cel mai des story points, în loc de estimări ale efortului (Man Days, Man Hours), însă nu întru aici în detalii.
În Scrum, scopul sprintului nu trebuie să se schimbe niciodată. Ce se poate face, ca măsură excepțională, e oprirea sprintului și reluarea meeting-ului de sprint planning cu începerea unui nou sprint. Durata scurtă a sprintului e o măsură tocmai împotriva acestei situații: sunt rareori situații în care un feature nou nu mai poate aștepta două săptămâni, dacă acum două săptămâni nu era urgent. Excepție pot face defectele majore din producție, care însă, probabil nu necesită participarea întregii echipe în timpul unui întreg sprint. Iar user story-urile insuficient specificate, trebuie să fie interceptate la Sprint Planning, ca nerespectând definiția lui "Ready". E de datoria Scrum Masterului să descurajeze Product Owner-ul să recurgă la întreruperi ale sprintului ca mod de lucru, din cauza efectului demoralizator asupra echipei și să se asigure că atât Product Owner-ul, cât și echipa înțeleg și verifică dacă user story-urile îndeplinesc definiția lui "Ready" înainte de a le introduce în sprint.
Uneltele de dezvoltare ca IDE sau tool-ul de versionare nu sunt definite în Scrum, pentru aceleași motive pentru care nu sunt definite în alte framework-uri de proces sau metodologii. Acestea sunt detalii care rămân la latitudinea echipei de dezvoltare. Bineînțeles că în ziua de azi nu mai putem să ne imaginăm cum să lucrăm fără ele. Însă identificarea uneltelor folosite și a modului de utilizarea sunt demersuri care trebuie aplicate de fiecare echipă în parte, în funcție de nevoile proiectului.
Scrum și Agile nu se pierd în detalii legate de documentație, pentru că doar oamenii implicați în proiect pot să știe care e nivelul de documentație de care are nevoie produsul la care muncesc. Diferite produse necesită diferite feluri și nivele de documentație. Există prototipuri care se creează într-o lună, se livrează și nu mai auzi de ele niciodată. Alte produse sunt în producție de 25 de ani, sunt menținute și extinse în continuare și au lucrat la ele sute sau mii de programatori. Faceți atâta documentație câtă aveți nevoie. Însă nu măsurați progresul în documentație: un user story trebuie să fie în primul rând implementat ca să poată fi "Done".
O altă obiecție des întâlnită e aceea că arhitectura "iese la suprafață", în loc să fie bine definită la început, ca în binecunoscutul model Waterfall. Însă eu nu văd cele două situații în opoziție. Nimic nu oprește echipa să înceapă cu definirea arhitecturii. Cred însă, că participarea întregii echipe e binevenită.
Consider că cele mai importante puncte aici sunt cerințele și estimările. Având posibilitatea să schimbe și să adauge cerințe chiar și într-o etapă târzie de dezvoltare precum și vizualizarea progresului echipei, clientul va fi mult mai dispus la flexibilitate.
Datoriile tehnice se pot acumula folosind orice alt schelet pentru proces și eu nu cred că e o consecință a Scrum-ului. Ca programator într-o firmă de outsourcing, am băgat sub preș de multe ori orele petrecute optimizând sau rescriind bucăți de cod existent și nu era întotdeauna ușor să introduc în project plan un task de curățare a codului vechi și foarte vechi. Cu Scrum, în schimb, dacă nu trebuie să justifici fiecare oră muncită separat, cred că libertatea e un pic mai mare decât am experimentat-o eu și că "technical dept" e mai mult o consecință a stilului personal de muncă decât a Scrum-ului ca unealtă.
E important de știut că nu este nimic care să oprească echipa de dezvoltare să se considere un stakeholder în proiect. Echipa poate cere Product Owner-ului să pună modificările pe care echipa le consideră necesare în Product Backlog și să ceară introducerea lor, poate treptată, în câte un sprint. Dar aceasta se leagă din nou de asumarea responsabilității. Doar atunci când echipa își asumă cu adevărat responsabilitatea asupra muncii sale, intervine echilibrul în relația dintre echipa și Product Owner instaurându-se o relație de colaborare în loc de subordonare.
Receptivitatea la schimbare nu se referă la faptul că Product Owner-ul sau clientul schimbă cerințele oricând, chiar și în timpul sprintului. Nu. Înseamnă că procesele agile prevăd faptul că cerințele întregului produs vor fi incomplete la începerea dezvoltării, că se schimbă, astfel încât procesele sunt organizate în așa fel încât să poată încorpora modificările, câte o iteratie o dată. Ştiind că cerințele se schimbă, în Scrum, momentul când un user story trebuie să fie complet specificate abia la Sprint Planning, când user story-ul trebuie să satisfacă definiția lui "Ready" preacceptată de toate părțile pentru a fi admis în sprint.
Articolul la care se face referire și acest "cod roșu" m-a pus un pic pe gânduri. Chiar ne face Scrum să lucrăm într-o stare de permanentă urgență? Faptul că avem sprint după sprint înseamnă că nu avem timp de respiro? Mi-am adus aminte, din nou, că am întâlnit problema aceasta și în mediu non agil. Ce ne face să ne simțim a fi în "code red"? Eu cred că ne simțim în stare de urgență din cauza vizibilității care se cere să o oferim asupra muncii noastre, a deadline-urilor și sprinturilor, a faptului că știi că după ce termini un sprint te așteaptă altul sau din cauza Scrum meeting-urilor zilnice. Dar aceste situații și probleme există cu sau fără Scrum.
În concluzie, aș vrea să nu uităm că Scrum e un schelet, pe care construim ceea ce avem nevoie pentru proiectul nostru și că Scrum presupune îmbunătățirea procesului, dezvoltat de echipa pe baza lui, la fiecare iterație, analizând în întâlnirea retrospectivă ce se poate îmbunătăți. În plus, cred că e esențial să acceptăm faptul că Scrum e o unealtă și ca orice unealtă are un domeniu predefinit de aplicabilitate. Nu va rezolva problema discuțiilor în open space și a versionării, însă cu cât o înțelegem mai bine, cu atât putem să o folosim mai eficient în sprijinul muncii noastre. Scrum nu ne va oferi soluții la toate problemele, dar oferă cadrul să colaborăm în echipă și să optimizăm procesul.
de Ovidiu Mățan
de Vasile Boris
de Paul Hrimiuc
