Scrum - management mai eficient al proiectelor
- Detalii
- Categorie: Tehnologii Informaţionale
- Accesări: 2,411
Pentru a putea implementa cu succes cadrul de lucru Scrum trebuie mai întâi înțelese principalele provocări ale proiectelor. Identificarea factorilor determinanți ai succesului Scrum-ului oferă un șablon de lucru și recomandările necesare pentru a ajunge la un management al proiectelor mai eficient. Bineînțeles, probleme pe durata implementării pot apărea dar literatura de specialitate oferă prin studiile de caz prezentate posibile soluții.
Provocările unui proiect
Principalele probleme ale proiectelor pleacă chiar de la prima etapă a managementului. Practica în privința planificării proiectelor este undeva la extreme: fie nu se planifică deloc, fie se pierde prea mult timp cu planificarea. În primul caz nu se va putea ști când se poate livra produsul, în al doilea caz planul va părea atât de bun încât orice modificare a planului va fi cu greu realizată.
Dezvoltarea software nu trebuie luată ca pe o competiție internă: cine cere mai mult, cine câștigă lupta cu estimarea. Dacă se dezvoltă funcționalități greșite, pe care clientul nu le-a cerut și nu le va folosi, pierde atât echipa care a depus efort într-o direcție greșită cât și clientul care va trebui să mai aștepte o perioadă până ce funcționalitățile corespunzătoare se vor dezvolta. Pentru echipa planul reprezintă o perspectivă asupra viitorului, dar pe parcursul proiectului, cu cât se câștigă mai multă experiență și cunoștințe, această perspectivă se schimbă.
În august 2007, Dynamic Markets a realizat o anchetă pe 800 de manageri IT din opt țări și au descoperit:
- 62% din proiecte depășeau timpul alocat;
- 49% din proiectele depășeau bugetul;
- 47% din proiectele necesită costurile de întreținere mai mari decât cele estimate;
- 28% dintre organizații au implementat proiecte care nu se potrivesc cerințelor;
- 25% dintre organizații sunt reticente în a adopta noi tehnologii;
- 13% din organizații spun că proiectele nu au adus valoarea adaugată la care se așteptau.
Statisticile variază între studii, în funcție de aspectele individuale examinate, dar este clar că în industria IT proiectul este în criză continuă și suferă în mod repetat rezultate negative, ca urmare a depășirilor de buget sau de timp, a livrării unor cerințe greșite sau dezvoltate greșit.
Într-un studiu realizat de IBM cu scopul de a investiga motivele pentru eșecul proiectelor IT s-au identificat cinci domenii cheie care influențează succesul sau eșecul unui proiect:
- Managementul proiectelor (54%);
- Mediul de afaceri (21%);
- Oamenii (14%);
- Procedurile(8%);
- Tehnologia(3%).
Studiul demonstrează că un management mai eficient ar crește probabilitatea de succes a proiectelor și acest beneficiu îl oferă Scrum-ul.
Rețeta unui Scrum reușit
Șansele de reușită a managementului unui proiect Scrum cresc exponențial cu înțelegerea rolurilor pe care le au membrii Echipei Scrum, ce pot face și ce nu și mai ales cine poate lua sau nu, un anumit rol în cadrul echipei; tabelul nr. 1 – Matricea de Înțelegere a Componenței Echipei Scrum soluționează toate aceste întrebări legate de membrii Echipei Scrum:
Tabel nr. 1 Matricea de înțelegere a componenței Echipei Scrum
(sursa: prelucrare după Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org, SUA)
|
Scrum Master |
Product Owner |
Echipa se Dezvoltare |
|
|
Cine poate fi? |
Scrum Master-ul poate fi un membru al Echipei dar acest lucru duce adesea la conflicte în momentul când va trebui să aleagă între a rezolva problemele ca Scrum Master și a îndeplini sarcinile din Sprint |
Dacă proiectele sunt pentru clienți poate fi chiar managerul de produs Dacă proiectele vor fi folosite intern, Product Owner poate fi managerul departamentului care va folosi acel produs Product Owner poate fi chiar un membru al Echipei care face și muncă de implementare, însă această responsabilitate îl poate împiedica să lucreze corespunzător cu toți cei implicați) |
Membru al echipei devine cel care are abilitățile necesare de a transformă o sarcină într-un livrabil al produsului Membri Echipei sunt cei ce au deschiderea de a prelua sarcini, chiar dacă acest lucru înseamnă să învețe noi lucruri |
|
Cine nu poate fi? |
Scrum Master-ul nu poate fi Product Owner |
Product Owner-ul nu poate fi Scrum Master |
Scrum Master-ul și Product Owner-ul nu pot fi considerați membri ai Echipei de Dezvoltare decât în cazul în care au sarcini de îndeplinit în cadrul unui Sprint sau mai multora |
|
Ce este? |
Este ”veriga” ce conectează organizația și Echipa Scrum la practicile, valorile li regulile Scrum Este mentor pentru Product Owner privind modul de a prezenta, creea și coordona Backlog-ul Produsului Este cel care înțelege și explică modul de lucru Agile în organizație |
Este o singură persoana responsabilă cu Backog-ul produsului |
O echipă cu un număr de membri suficient pentru a fi agili și pentru a finaliza munca O echipă care are capacitatea de a transforma cerințele prezentate în Backlog-ul Produsului în Produsul Final |
|
Ce nu poate fi? |
Nu poate fi un comitet |
Nu poate fi un comitet |
Nu pot exista sub-echipe axate pe un domeniu specific (de exemplu sub-echipa de Testare) |
|
Ce poate face? |
Îi poate ajuta pe cei din exteriorul Echipei Scrum să înțeleagă procesul și să descopere care dintre interacțiunile cu Echipa sunt benefice și care nu |
Poate reprezenta cerințele unui comitet în Backlog-ul Produsului; Este singurul care poate schimba prioritățile în Backlog-ul Produsului |
Sunt singurii care pot livra la sfârșitul fiecărui Sprint câte o componentă a ceea ce se va numi la sfârșitul proiectului ”Produsul Finalizat” (componentă pe care autorii Ken Schwaber și Jeff Sutherland o numesc Increment) |
|
Ce nu poate face? |
Nu poate schimba prioritățile în Backlog-ul Produsului Nu poate spune Echipei de Dezvoltare cum să își ducă la îndeplinire sarcinile din Sprint |
Chiar dacă rolurile Product Owner-ului pot fi preluate de Echipa de Dezvoltare, acesta nu poate dispărea din componența Echipei |
Fiecare membru al Echipei poate avea abilități pe o anumită specializare dar Echipa per ansamblu nu poate să se comporte altfel decât ca un TOT responsabil pentru calitatea livrabilelor |
Un alt factor important în reușita managementului proiectelor folosind Scrum este înțelegerea modului corect de desfășurare a ședințelor, a rolului și a utilizării acelor întrebări cheie care definesc fiecare tip de ședință (tabelul nr. 2 – Cum să înțelegem corect ședințele Scrum? prezintă un șablon de organizare):
Tabel nr. 2 Cum să înțelegem corect ședințele Scrum?
(sursa: prelucrare după Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org; Schwaber, K., Agile Project Management with Scrum, Microsoft Press, Washington, 2004)
|
Ședința de Planificare a Sprint-ului |
Ședința Scrum Zilnică |
Ședința de Revizuire a Sprint-ului |
Ședința Retrospectivă a Sprint-ului |
|
|
Rol |
Ședința de planificare este formată din două părți: în prima se va decide ce va fi efectuat în Sprint iar în a doua Echipa identifică modalitatea de implementare a funcționalităților |
Ședința Scrum Zilnică are loc pentru a inspecta munca realizată de la ultima ședința, a stabili și adapta din mers munca care trebuie realizată până la următoarea ședința. Ședințele Zilnice îmbunătățesc comunicarea, elimină obstacolele care apar în dezvoltare, promovează luarea rapidă a deciziilor și îmbunătățesc nivelul cunoștințelor despre proiect |
La sfârșitul fiecărui Sprint are loc o Ședință de Revizuire a Sprint-ului unde pe baza a ceea ce s-a finalizat și a modificărilor efectuate în Backlog-ul Produsului pe parcursul Sprint-ului se stabilește planul pentru următorul Sprint |
În urma Ședinței de Revizuire a Sprint-ului și înainte de următoare Ședință de Planificare, Echipa Scrum susține Retrospectiva Sprint-ului cu scopul de a revizui procesul de dezvoltare în vederea eficientizării acestuia Cu fiecare Ședință Retrospectivă, Echipa Scrum găsește noi modalități de a îmbunătăți calitatea produsului și definiția ”Produs Finalizat” se adaptează |
|
Obiectiv |
Până la sfârșitul ședinței Echipa de Dezvoltare va fi capabilă să explice Product Owner-ului și Scrum Master-ul cum intenționează să se autoorganizeze pentru a îndeplini Scopul Sprint-ului |
Obiectivul Ședințelor Scrum zilnice este creșterea probabilității de îndeplinire a Obiectivului Sprint-ului |
Până la sfârșitul ședinței se va obține un Backlog-ul al Produsului revizuit care va defini cel mai probabil itemii pentru următorul Sprint |
Până la sfârșitul ședinței Echipa Scrum va identifica măsuri de îmbunătățire a proceselor, relațiilor, oamenilor și instrumentelor folosite, măsuri ce se vor implementa în Sprint-ul următor |
|
Participanți |
Echipa Scrum Pot participa consultanți ce pot oferi sfaturi tehnice sau recomandări |
Echipa Scrum Participă doar acele persoane care transformă elementele din Backlog-ul Produsului în componente ale produsului software final |
Echipa Scrum + stakeholderi- persoane interesate de proiect (acționari, clienți, etc.) |
Echipa Scrum |
|
Algoritm de calcul durată ședință |
Sprint = 1 lună => Ședința = 8 ore =>2 părți= 2*4 ore Sprint = 2 săpt. => Ședința = 4 ore =>2 părți= 2*2 ore |
Ședința =15 minute la aceeași oră și în același loc pe parcursul tuturor Sprint-urilor |
Sprint = 1 lună =>Ședința = 4 ore Sprint = 2 săpt. =>Ședința = 2 ore |
Sprint = 1 lună =>Ședința = 3 ore Sprint = 2 săpt. =>Ședința = 1.5 ore |
|
Întrebări cheie |
1.Ce vom livra la sfârșitul Sprint-ului? 2.Cum vom reuși să realizăm obiectivul Sprint-uli? |
1.Ce s-a realizat de la ultima întâlnire până acum? 2.Ce se va realiza până la următoarea ședință? 3.Ce obstacole sunt? |
1.Ce s-a făcut? 2.Ce nu s-a făcut? 3.Ce a mers bine? 4. Ce probleme au fost și cum s-au rezolvat? 5.Care sunt următorii pași? |
1.Ce a fost bine? 2.Ce am greșit? 3.Ce trebuie să încercăm în Sprint-ul următor? 4.Ce nu mai are rost să facem? |
|
Mod de desfășurare |
Prima parte : Product Owner-ul prezintă elementele prioritare din Backlog-ul Produsului și împreuna cu Echipa va identifica ce funcționalități se vor implementa În funcție de funcționalitățile alese de Echipă se va stabili Obiectivul Sprint-ului A doua parte : Echipa stabilește cum va transforma elementeledin Backlog-ul produsului în software funcțional. Se începe prin proiectarea muncii=>lista de activități=>Sprint Backlog |
Scrum Master-ul se asigură că Echipa susține ședința, se aplică regulile și ședința durează 15 minute, fiecare membru vorbind pe scurt Pe parcursul Ședinței Zilnice fiecare membru al Echipei de dezvoltare va răspunde la întrebările cheie |
Product Owner-ul identifică ce a fost finalizat și ce nu. Echipa discută despre ce a mers bine în timpul Sprint-ului și ce probleme au întâmpinat, precum și modul cum au fost rezolvate. Echipa apoi demonstrează munca efectuată și răspunde la întrebări. Product Owner-ul discută apoi despre Backlog-ul Produsului dând o estimare privind finalizarea acestuia. Întregul grup colaborează apoi în privința lucrurilor discutate pentru a vedea cum le pot folosi in Sprint-urile viitoare |
ScrumMaster-ul încurajează Echipa Scrum să își revizuiască, în cadrul procesului și practicilor Scrum, procesul de dezvoltare, urmărind să se obțină răspunsul la întrebările cheie Pe baza analizei proceselor, oamenilor, relațiilor și instrumentelor folosite se identifică ce a mers bine și ce trebuie îmbunătățit și se creează un plan de implementare a măsurilor de îmbunătățire identificate |
Reușita implementării Scrum depinde și de înțelegerea modului de structurare a elementelor din Backlog-ul Produsului pentru a putea fi gândite ca finalizabile în Sprint-uri.
Elementele trebuie să fie bine înțelese și ușor de selectat în cadrul ședinței de planificare a Sprint-ului.
Elementele din Backlog-ul Sprint-ului trebuie să fie descompuse în așa fel încât progresul să fie ușor de înțeles în Ședința Scrum Zilnică. Durata tipică pentru un element din Backlog-ul Sprint-ului este de cel mult o zi.
Echipa este cea care controlează Backlog-ul Sprint-ului:
- adaugă activitățile adiționale necesare;
- modifică Backlog-ul Sprint-ului în decursul Sprint-ului, inclusiv elementele ce apar în decursul Sprint-ului;
- actualizează timpul estimat pentru finalizarea celor în curs de dezvoltare;
- șterge activitățile care se dovedesc inutile.
Implementarea cu succes a Scrum-ului presupune ca membrii echipei să fie motivaţi şi să posede abilităţile de a crea produsul fără a avea prea multă documentaţie şi prea multe informaţii despre design. Atât echipa, cât şi organizaţia trebuie să înţeleagă şi să accepte cadrul de lucru.
Probleme și rezolvări
Ca în orice cadru de lucru și în Scrum pot apărea probleme sau neînțelegeri. Mai ales pentru echipele care experimentează Scrum-ul și învață din experiențe este destul de dificil de definit Sprint-ul, Backlog-ului Produsului și Backlog-ul Sprint-ului și mai ales de estimat corect durata de implementare a cerințelor.
Trebuie prevenite blocarea activităților și înlăturarea tendinței absolut firești de a lucra astfel încât sarcina de lucru să acopere perioada programată În cazul în care echipa simte că a promis mai mult decât poate livra, se întâlnește cu Product Owner-ul pentru a elimina sau reduce din activitățile ce fac parte din Backlog-ul Produsului ce au fost selectate pentru Sprint. În cazul în care echipa simte că are timp suplimentar la dispoziție, poate lucra cu Product Owner-ul pentru a selecta activități suplimentare din Backlog-ul Produsului.
De obicei, numai 60-70% din Backlog-ul Sprintului va fi tratat în ședința de planificare a Sprint-ului. Restul sunt detaliate ulterior sau sunt date estimări mari, ce vor fi segmentate pe parcursul Sprint-ului.
Product Owner-ul este singurul care are autoritatea de a anula un Sprint, deși de multe ori această decizie se ia sub influența Scrum Master-ului, Echipei de Dezvoltare sau a alor părți interesate de proiect.
Anularea unui Sprint poate fi necesară din mai multe motive:
- schimbare de strategie a companiei
- schimbare a tehnologiei
- a circumstanțelor de utilizare a produsului
Dar se recomandă doar în cazuri excepționale pentru că se consumă inutil foarte multe resurse (trebuie evaluat cât s-a realizat până la anularea Sprint-ului, trebuie reestimați elementele nerealizate din Backlog- ul Produsului, trebuie reorganizată echipa pentru a planifica un alt Sprint).
În unele organizații, mai multă muncă este adăugată la Backlog decât este finalizată. Acest lucru poate duce la o tendință constantă sau crescătoare. Pentru a compensa, un nou prag poate fi creat când se adaugă sau scade in muncă.
Se recomandă desenarea pe o pagină mare de hârtie afișată în zona de lucru a Echipei. Echipele vor observa mai ușor o diagramă mare și vizibilă decat o diagrama dintr-un fișier Excel sau din altă aplicație. Cerințele nefinalizate se acumulează într-o categorie din Backlog-ul de produs numită “De finalizat” sau “De implementat”.
Astfel, cand se acumulează multe cerințe, burndown-ul pe Backlog-ul Produs-ului nu este afectat și reflectă mai corect starea produsului.