Definirea problemei

Globalizarea aduce cu sine în toate domeniile de activitate o lume tot mai fluidă. Însuși Umberto Ecco – înainte de a „pleca puțin” – ne-a lăsat o ultimă carte publicată intitulată „Cronicile unei societăți fluide”. În aceste condiții, managerii de proiect (fie ei formali sau… informali :lol:) au început să se confrunte cu probleme, mulți dintre ei înțelegând că a devenit tot mai dificilă ținerea sub control a proceselor, inclusiv cele productive. Chiar dacă, așa cum ne tot spune Nassim Nicholas Taleb, tentația de a „ține lucrurile sub control” și modelarea lumii reale nu poate fi decât o iluzie, oamenii nu pot renunța la iluzii. Și încearcă mereu și mereu să găsească modele și metode pentru a face acest lucru.

La prima mână, se pot enumera tentative de „control” al proceselor pe care oamenii le-au tot încercat: inițial, procesele productive „beneficiau” de CTC (Controlul Tehnic de Calitate), analizând aleatoriu un anumit procent din produsele finite, asumând astfel că dacă cele analizate respectă standardele, atunci „aproape” toate vor fi conforme. Era o metodologie axată pe produs.

Ulterior, atenția s-a orientat către proces, asumând ideea că dacă procesul de producție este repetitiv și identic pentru fiecare produs în parte, atunci și produsele vor fi identice (și, desigur conforme). Așa s-a ajuns la exagerarea formalismului prin crearea Sistemelor de Management al Calității. Dar, tocmai datorită acestei exagerări și a birocratizarea excesivă a organizațiilor prin crearea unor structuri (neproductive) care se ocupă exclusiv cu întreținerea acestor sisteme, pare că nu s-a găsit SOLUȚIA (atenție, am scris-o cu majuscule!).

Iată că pasul următor a fost inventarea metodologiei Agile…

Ce este Agile?

Conform Forbes, iată cam ce ar fi metodologia Agile:

Se pare că în cadrul metodologiei Agile, se pune pe primul plan empirismul, în defavoarea unei planificări exagerate, urmărind să răspundă mai mult nevoii de schimbare:

Mai mult, se consideră că „Agile este mai degrabă o filosofie, un mod de gândire”.

O introducere în SCRUM

Pentru a înțelege ce este Scrum, trebuie înțeleasă mai întâi metoda Agile. Inițial creată pentru a ajuta dezvoltatorii de software să gestioneze mai eficient proiectele, Agile se referă la un set de valori, principii și practici. Echipele de dezvoltare folosesc Agile pentru a-și realiza proiectele.

Scrum este o metodologie care aplică valorile și principiile Agile. Ca și Agile, Scrum a fost folosit pentru prima oară de dezvoltatorii de software. Cu toate acestea, s-a răspândit și este acum folosită de alți dezvoltatori de produse, antreprenori și oricine altcineva încearcă să ducă la bun sfârșit un proiect complex.

De obicei, Scrum implică o echipă de colaborare formată din cinci până la șapte persoane. Există trei roluri în cadrul echipei Scrum: Product Owner-ul, Scrum Master-ul și membrii echipei generale. Membrii echipei vor fi cei care fac munca de dezvoltare a produsului.

Product Owner-ul este investitorul cheie al proiectului sau clientul proiectului. Rolul lui este de a oferi membrilor echipei generale o direcție prin compilarea informațiilor despre nevoile esențiale ale produsului final. Scrum Master-ul are rolul de a se asigura că echipa implementează corect metodologia.

Echipa Scrum lucrează în scurte explozii cu durate cuprinse între trei săptămâni și o lună, numite „sprint-uri”. Fiecare sprint va avea un anumit set de obiective pe care echipa să le realizeze. De-a lungul sprintului, echipa desfășoară întâlniri regulate pentru a împărtăși actualizările, pentru a delega și pentru a oferi un feedback unul altuia.

Beneficiile Scrum comparativ cu metodele tradiționale de dezvoltare

Pe lângă Scrum, una dintre cele mai populare strategii de management al proiectelor este metodologia Waterfall. Ea se compune dintr-un plan liniar în care echipa face pași până la finalizarea secvențială a etapelor. Proiectele care utilizează metoda Waterfall încep de obicei cu o perioadă de planificare, în care echipa încearcă să proiecteze produsul în întregime înainte de a ajunge la dezvoltare.

Cu toate acestea, o problemă obișnuită constatată la aplicarea acestei metode este aceea că echipa va trece de la un pas la altul, doar pentru a realiza, la un moment dat, că planurile inițiale nu vor funcționa sau că sunt incomplete. Asta duce echipa înapoi, deoarece trebuie să revină la stadiul de planificare și să reia procesul.

Scrum este menită să fie mai eficientă decât această metodă, deoarece oferă echipei obiective clare și concentrate. Este proiectată pentru a fi adaptabilă – una dintre calitățile cheia ale Agile – pentru a preveni apariția unor obstacole majore. În plus, Scrum încorporează feedback de la proprietarul produsului pe parcursul întregului proces pentru a preveni nemulțumirea clientului.

Cum se implementează Scrum (în 7 pași cheie)

Scrum implică un proces foarte specific, încorporând anumite documente și întâlniri de-a lungul drumului. În timp ce la început poate părea puțin prescriptivi, pașii oferă efectiv echipelor o mai mare flexibilitate și fac posibilă adaptarea la probleme neprevăzute.

Pasul 1: Crearea Backlog-ul produsului pentru a-i detalia caracteristicile esențiale

Scrum împarte proiectul în sprint-uri. O echipă poate executa cât mai multe sprint-uri pe care și le impune pentru a crea cea mai bună versiune a produsului final. Primul sprint începe cu Product Owner-ul creând „Product Backlog”.

Acesta este un document care include toate caracteristicile esențiale ale produsului final. Product Backlog nu ar trebui să precizeze sarcini de nivel inferior care ar putea ajunge la crearea produsului, trebuind să se concentreze pe imaginea de ansamblu. Product Backlog-ul inițial trebuie să includă numai caracteristicile elementare necesare ale produsului final.

De exemplu, dacă utilizați Scrum pentru a construi o casă, produsul inițial ar putea include fundația, pereții și acoperișul casei. Nu ar fi necesare precizări asociate unor lucruri precum pardoseala sau corpurile de iluminat, deoarece acestea sunt detalii tehnice finale.

Pasul 2: „Întâlnire de planificare Sprint-ului” pentru stabilirea obiectivelor

După ce Product Owner-ul a finalizat primul Product Backlog, întreaga echipă ar trebui să dețină o „întâlnire de planificare a Sprint-ului”. În această întâlnire, se vor stabili obiectivele pentru viitorul sprint, care va avea loc în următoarele 1 până la 3 săptămâni.

Această întâlnire nu ar trebui să arate ca sesiunile de planificare extinse utilizate în metoda Waterfall. În schimb, echipa ar trebui să examineze Product Backlog-ul, apoi să stabilească care dintre obiective pot fi realizate în mod realist, în perioada de timp dedicată sprint-ului.

Pentru a ne întoarce la exemplul casei, la prima întâlnire de planificare Sprint s-ar putea stabili că echipa are doar timpul necesar fundației, urmând ca realizarea casei să se facă în sprintul viitor. Acestea sunt singurele sarcini de discutat în timpul întâlnirii. Se lasă restul obiectivelor din Product Backlog pentru următorul sprint.

Pasul 3: Adăugarea de elemente Sprint Backlog-ului pentru a rămâne pe activitate

Odată ce s-au stabilit obiectivele pentru primul sprint, echipa poate crea un „Sprint Backlog” – un alt document conceput pentru a ajuta la menținerea echipei concentrată pe sarcină. Multe echipe creează Sprint Backlogs folosind o tablă (whiteboard) și note adezive organizate în trei coloane: „to-do” (de făcut), „in progress” (în curs de execuție) și „done” (îndeplinite).

Notele adezive ar trebui să conțină sarcini specifice legate de obiectivele selectate din Product Backlog în timpul întâlnirii de planificare a Sprint-ului. Membrii echipei pot muta notele lipicioase între coloane în timp ce lucrează la sarcinile lor. În acest fel, toată lumea știe întotdeauna la ce se lucrează și ce trebuie încă abordat.

În exemplul dat, unele sarcini legate de obiectivele de așezare a fundației și încadrare a casei ar putea fi colectarea de materiale, amestecarea betonului și tăierea plăcilor pentru cadru la lungimile corecte. Aceste elemente pot fi scrise pe note adezive și adăugate la Sprint Backlog.

Pasul 4: Scurte întâlniri zilnice de întreținere pentru a menține comunicarea

În fiecare zi, pe durata alocată fiecărui sprint, echipa va avea câte o scurtă întâlnire de cel mult cincisprezece minute. Acestea sunt uneori numite „Daily Stand-Ups” și sunt de obicei ținute în cerc. În timpul acestor întâlniri, membrii echipei pot oferi actualizări privind articolele listate în prezent ca fiind „în desfășurare” în Sprint Backlog. De asemenea, se pot delega sarcini care sunt încă indicate în coloana „to-do”.

Aceasta este o șansă pentru echipă să discute despre orice probleme care au apărut și ar putea provoca obstacole. Echipa poate oferi sugestii pentru depanarea sau realocarea resurselor, pentru a ajuta la rezolvarea problemei, înainte de sfârșitul sprintului.

Pasul 5: Prezentarea rezultatului Sprint-ului către Product Owner pentru feedback

La sfârșitul sprintului, echipa trebuie să prezinte produsul proprietarului produsului. El va evalua dacă este gata de lansare sau dacă este necesar un alt sprint înainte de a face produsul disponibil. Acesta este modul în care Scrum încorporează feedback-ul clientului în proces pentru a preveni nemulțumirea lui.

Un sprint suplimentar ar putea fi necesar dintr-o varietate de motive. Uneori, scopul unui sprint este de a potrivi produsul cu caracteristicile sale cele mai importante, ca în exemplul casei. Product Owner-ul ar putea alege să vândă casa doar cu fundația și structura de rezistență. Cu toate acestea, va fi mai valoroasă dacă un alt sprint este programat pentru a-i adăuga caracteristici.

Uneori, sfârșitul unui sprint va dezvălui faptul că nu sunt de fapt necesare unele caracteristicile esențiale. În acest caz, echipa ar putea modifica produsul în următorul sprint pentru a le elimina. Product Owner-ul poate, de asemenea, să realizeze nevoia de caracteristici pe care nu le-a crezut necesare anterior, alegând să solicite un alt sprint pentru a încorpora aceste noi idei.

Pasul 6: Efectuarea unei ședințe retrospective Sprint pentru a discuta despre ceea ce echipa poate îmbunătăți

La sfârșitul fiecărui sprint, echipa trebuie să organizeze o așa-numătă „Sprint Retrospective Meeting” pentru a discuta despre ce poate îmbunătăți. Aceasta este o șansă de a vorbi despre problemele apărute în sprintul anterior și de a reține zonele în care echipa își poate crește eficiența.

Scopul acestei întâlniri nu este acela de a se contra unul pe altul sau de a se plânge de alți membri ai echipei. În schimb, trebuie privit grupul ca un întreg. Întâlnirea retrospectivă ar trebui să se străduiască să îmbunătățească comunicarea între membrii echipei și să se concentreze mai degrabă pe procesul de dezvoltare decât pe produs.

Pasul 7: Repetarea pașii anteriori pentru a executa produsul final

După ce Product Owner-ul revizuiește produsul și are loc „Sprint Retrospective Meeting”, echipa se poate pregăti pentru următorul sprint. Proprietarul produsului ar trebui să revizuiască Product Backlog pentru a adăuga sau elimina orice caracteristici discutate în timpul revizuirii produsului. Apoi, o nouă întâlnire de planificare Sprint ar trebui să determine obiectivele pentru următorul sprint.

Echipa poate continua să ruleze sprinturi până când proprietarul produsului este complet mulțumit de produsul final. Proprietarul Produsului ar putea alege să lanseze versiuni ale produsului de-a lungul procesului, cu lansări suplimentare pe măsură ce produsul se îmbunătățește. Obiectivele și sarcinile pot fi mai specifice de la sprint la sprint.

Concluzie

Proiectele pe termen lung se pot sfârși prost dacă eșecurile repetate duc la lipsa termenelor limită și a rezultatelor sub așteptări. Clientul poate chiar decide că produsul finit nu-i satisface nevoile, făcând ca toate eforturile depuse să devină deșeuri. Metoda Scrum urmărește să evite aceste probleme prin implementarea feedback-ului clientului, stabilirea de obiective clare și construirea de echipe colaborative.

Odată înțelese aceste etape, depinde de fiecare dintre noi, dar mai ales de organizația din care facem parte, să încercăm să folosim (și) această metodologie în cadrul proiectelor la care lucrăm…

Din proprie experiență 🙄 

Bibliografie:

• A Simple Guide to the Scrum Collaboration Methodology

Provocare

Ar fi chiar interesante comentarii care să ne împărtășească tuturor experiențe personale și de echipă, despre încercări (reușite sau nu), de aplicarea a unor astfel de metodologii de (să le spunem generic)… „management de proiect”…