Curs Metodologii agile. Scrum.

Numele și prenumele

Departamentul de Resurse Umane al companiei energetice Iberdesa are în vedere

adoptarea a ceea ce sunt cunoscute sub denumirea de metodologii Agile.

Lucrezi pentru o consultanță strategică cu multă experiență Agile și ți s-a cerut

să ajuți la demararea acestei adoptări Agile.

Departamentul HR Este alcătuit din 50 de profesioniști, împărțiți în șapte echipe,

fiecare cu un director.

Se solicita:

1. Are sens să folosească „metodologii Agile”? Și scrum?

Are sens că folosesc Agile. Deși atunci când a fost creată această metodologie
se intenționa să fie implementată doar în dezvoltarea de software și în
sectoare mai tehnice, adoptarea unei metodologii Agile în orice alt context
poate deveni un avantaj competitiv. În ceea ce privește cadrul SCRUM, acesta
le-ar permite să creeze echipe autogestionate și autoresponsabile, care în timp
se vor maturiza și vor îmbunătăți timpul de livrare, precum și rezultatele.

2. Îți cer o propunere de 3 valori care sunt aliniate cu Agile. Ceea ce ar fi?
Ele trebuie comentate.

Valorile Agile sunt scrise în manifestul semnat de 17 dezvoltatori de software

în 2001. Trei dintre ele ar fi următoarele.

- Indivizi și interacțiuni asupra proceselor și instrumentelor . Una

dintre principalele caracteristici ale metodologiilor agile, dacă nu
chiar cea mai importantă, este că totul este concentrat pe oamenii care
alcătuiesc echipa (umanismul) spre deosebire de taylorismul care a
domnit în anii precedenți. Și, pe de altă parte, interacțiunile
fiecăruia dintre membrii grupului cu alți membri, superiori, părți
interesate, clienți etc. care formează un mediu mai deschis și mai
transparent. Acest lucru nu înseamnă că procesele și instrumentele sunt
lăsate deoparte, deoarece fără ele ar fi imposibilă finalizarea
proiectelor.
- Software care rulează pe o documentație extinsă . Ceea ce este important
și ceea ce are o valoare reală care poate fi livrat clientului și
transferat pe piață este software-ul sau produsul/serviciul care se
dezvoltă; din acest motiv, nu este atât de necesară redactarea unei
documentații extinse și voluminoase. Acest lucru nu înseamnă că
documentația respectivă nu va fi realizată, dar ceea ce trebuie evaluat
cu adevărat sunt diferitele elemente de lucru care compun proiectul.
- Răspuns la schimbare cu privire la respectarea unui plan . Dezvoltarea
de software este o lume a schimbărilor și încercărilor și erorilor,
astfel încât întreaga echipă trebuie să fie aclimatizată pentru a
reacționa rapid la evenimente neprevăzute, erori sau schimbări în
nevoile clienților. Prin urmare, lucrul important va fi ca
 produsul/serviciul pe care îl dezvoltați să răspundă acelor nevoi.

3.
• Cum ar fi formate echipele?

O echipă Scrum este compusă dintr-un Scrum Master (1), un Product Owner
(1) și o echipă de dezvoltare (3 – 9 membri). Scrum Master este
responsabil să se asigure că echipa funcționează corect în jurul
valorilor Scrum. Pe de altă parte, funcția principală a Product
Ownerului este de a maximiza și optimiza valoarea; este responsabil
pentru problemele în legătură cu produsul/serviciul care pot apărea. Și
în sfârșit, echipa de dezvoltare, care este cea care trebuie să
îndeplinească sarcinile și subsarcinile necesare realizării proiectului.
In acest din urma caz, idealul este sa fie alcatuit din 6 persoane.

• Care ar fi dimensiunea echipelor?

Departamentul de Resurse Umane este alcătuit din 50 de persoane,

împărțite în 7 echipe, fiecare având câte un director.

Prin urmare, o posibilă diviziune a echipelor ar putea fi următoarea: 6

echipe de 7 persoane și una de 8. Toți vor avea directorul (menționat în
declarație), Scrum Master și Product Owner. În ceea ce privește echipa
de dezvoltare, 6 echipe vor avea 4 membri și una dintre ele va avea 5.

• Ce roluri ar avea?

Rolurile sunt cele menționate mai sus. Un Scrum Master responsabil cu

supravegherea faptului că evenimentele, artefactele, sarcinile etc. se
desfășoară corect. de Scrum; un Product Owner care este cel care va
ghida echipa și va fi responsabil pentru optimizarea valorii
produsului/serviciului și gestionarea backlog-ului de produse; și, în
sfârșit, echipa de dezvoltare care execută sarcinile legate de un produs
sau serviciu și este responsabilă de livrarea unui increment de produs
care poate fi pus în producție la sfârșitul fiecărei iterații.

• Ar fi manageri în echipe?

Nu există manageri în echipa Scrum; este un rol care nu există. Vor fi

directori, manageri sau superiori în proiect, dar aceștia nu fac parte
din echipa Scrum. În plus, Scrum Master va fi responsabil cu medierea
între restul echipei Scrum și director.

• Care sunt abilitățile pentru fiecare rol?

- Scrum Master : joaca un rol foarte important intrucat el este cel

mai responsabil pentru aplicarea corecta a framework-ului Scrum,
dar niciodata intr-un mod exhaustiv, daca nu cu recomandari,
sfaturi si sugestii; explică persoanelor din afara echipei Scrum
ce interacțiuni trebuie efectuate, precum și promovarea unei bune
relații între echipă și manageri și directori; Pe scurt,
încurajează lucrul corect sub Scrum, făcând modificările necesare
pentru a îmbunătăți calitatea produsului.

- Product Owner : trebuie sa cunoasca perfect producatorul sau

serviciul care urmeaza a fi dezvoltat pentru a putea gestiona
backlog-ul de produse , obtine cele mai bune performante posibile
 din partea echipei de dezvoltare pentru a maximiza valoarea
produsului de dezvoltat. De asemenea, este important să filtrați
posibilele solicitări de la membrii organizației care nu fac
parte din Echipa Scrum pentru a nu deturna dezvoltatorii de la
sarcinile lor.
- Echipa de dezvoltare : se organizeaza pentru ca nimeni nu ar trebui
sa le spuna ce sarcini sa indeplineasca sau cum sa le
indeplineasca, au cunostinte in diferite domenii care le permit sa
creeze un increment de produs, toti au acelasi rol in cadrul
echipei, astfel încât niciunul nu iese în evidență față de restul
și, din acest motiv, responsabilitatea finală revine fiecărui
membru, indiferent de specializare.

4. Ce evenimente ar avea? Care ar fi lungimea sprinturilor? Cine i-ar facilita?

Ce să faci dacă majoritatea membrilor unei echipe nu doresc să efectueze
planificarea?

- Sprint – Reprezintă o iterație în care au loc restul evenimentelor

Scrum. Lucrul obișnuit este că durează 2 sau 3 săptămâni, fără să
depășească niciodată 4 săptămâni.
- Zilnic : este o întâlnire de 15 minute care are loc în fiecare zi.
Sunt planificate sarcinile care trebuie efectuate pentru
următoarele 24 de ore.
- Review : este revizuirea sprintului, adică se evaluează creșterea
făcută în săptămânile în care a durat sprintul. În plus, se vor
lua în considerare ceea ce trebuie îmbunătățit pentru a optimiza
valoarea.
- Retrospect : Este ultimul eveniment al sprintului, în care echipa
se autoinspectează și creează un plan de îmbunătățiri care vor fi
implementate în următorul sprint.
- Rafinament - Nu este un eveniment Scrum, dar important așa cum
este folosit
pentru a gestiona stocul de produse (adăugați sau eliminați
articole, reordonați-le etc.)

Ele sunt facilitate de Scrum Master, adică el este cel care ar trebui să
încurajeze restul echipei să organizeze aceste evenimente.

Cât despre ultima întrebare; Principalul lucru este ascultarea activă pe

care Scrum Master trebuie să o aibă cu restul echipei și, ulterior, să le
explice în detaliu de ce ar trebui urmat framework-ul Scrum și
beneficiile acestor evenimente.

5. Cum ați sugera să fie plăcile? (Maximum 6 coloane).

În acest caz, s-ar alege o tablă cu 5 coloane: Sprint Backlog (unde apare
backlog-ul curent de sprint), To do (sarcinile care trebuie făcute în acel
moment), Doing (activitățile care se desfășoară în prezent) , Testare (ceea
ce s-a făcut este în curs de revizuire pentru a putea să-i dea voie sau nu)
și Terminat (sarcinile care au trecut de filtru și au fost catalogate ca
finalizate).

Pe o tablă fizică (folii) sau pe o tablă virtuală (Asana, Trello etc.),

faceți capturi de ecran care indică modul în care ar fi tabla în următoarele
faze:
 Începutul primului
sprint

Sfârșitul
primului sprint

• Mijlocul celui de-al

doilea sprint

Cât de previzibil ar fi graficul planificat vs. planificat? făcute între

6
. sprinturile 5 la 9? Include captura și comentariu.

Viteza estimată vs viteza reală

Graficul planificat vs. realizat reflectă posibilele divergențe între viteza
care fusese estimată înainte de sprint și viteza efectivă de lucru a echipei. Se
știe că în timpul primelor iterații aceste divergențe se accentuează; ceva
normal dacă vorbim despre echipe care tocmai au început să adapteze această
metodologie sau o nouă tehnologie, de exemplu. Între sprinturile de la 5 la 9
(echipa lucrează de câteva luni sau chiar mai mult de un an), se poate observa
că în aceste iterații echipa este într-o perfecționare continuă. Deși, după cum
se vede, va rămâne uneori deasupra sau sub estimare, dar întotdeauna aproape de
acesta. La fel, prezintă o tendință de creștere până când își atinge pragul de
eficiență.

7. Cum ar fi de așteptat să fie graficul de ardere în sprintul 2? Și în sprintul

6? Include captura și comentariu.

În sprintul 2, echipa este încă imatură, așa că, așa cum se vede în graficul de
mai jos, linia roșie urcă de mai multe ori în loc să coboare. Acest lucru este
valabil atunci când trebuie să efectuați sarcini suplimentare. Soluția ar fi să-
l informezi pe Product Owner să elimine unele articole cu prioritate scăzută,
deoarece totul nu a putut fi finalizat.
Chiar acum, în sprintul 6, puteți vedea cum echipa funcționează foarte bine.
În primele zile nu reușesc să termine nicio sarcină, dar pe măsură ce
sprintul progresează, echipa termină articole din stocul de produse.