1. Metodologia Agile – SCRUM
Elaborat: Valentina Jardan

2. Dezavantajele metodelor clasice de management a proiectelor
Forțe uriaşe în timpul etapei de planificare;
Resurse enorme pentru modificarea cerinţele tehnice într-un mediu ce se schimbă rapid;
Tratarea personalului ca factor de producţie;

3. Rezultatul metodelor clasice implementate în IDSI*
Haos datorită schimbării cerinţelor - cerinţele unui proiect pot să se schimbe în faza de design, implementare şi chiar lansare. În mai toate metodologiile de dezvoltare, analiza este făcută în partea de început a proiectului, şi nici o schimbare nu mai este permisă pînă spre final.
Estimări nerealiste de timp, cost şi calitate a proiectelor - managerul de proiect şi dezvoltatorii tind să subestimeze cît timp şi resurse sunt necesare pentru un proiect, şi cîte funcţionalităţi pot fi livrate. Acestea nu pot fi niciodată prevazute 100% în faza de început a ciclului de dezvoltare.

4. Soluţia? Agile Software Development – nume preluat de la sportul de
Rugby unde toată echipa acţionează
împreună - analogie se face la
dezvoltarea software unde echipa
lucrează împreună pentru a dezvolta
cu succes produse de calitate.

5. Ce este Agile?
Metodologie de management a proiectelor ce încearcă să micşoreze riscurile de dezvoltare şi timpul de execuţie prin implementarea proiectelor în formă foarte flexibilă şi interactivă.

6. Caracteristicile Agile
Este iterativ: o iteraţie are între 1-4 saptămîni,în rezultat sunt livrate anumite funcţionalităţi ale proiectului.
Este bazat pe timp:durata iteraţiei e fixă şi nu poate fi modificată pe parcursul proiectului. În acest fel există întotdeauna un rezultat productiv la finalul iteraţiei.
Deschis către client:la finalul fiecărei iteraţii există un rezultat care poate fi prezentat clientului.
Bazat pe livrarea de versiuni intermediare ale produsului: fiecare iteraţie va implementa complet toate “task-urile” cuprinse în acea iteraţie

7. Metodologii care derivează din Agile
AGILE există în mai multe feluri: XP
SCRUM
DSDM,
Crystal,
Feature Driven
Lean Development
etc.
Toate folosesc principii de baza ale filozofiei AGILE, dar o implementează în moduri diferite.

8. Sunt AGILE!
Prioritatea este satisfacerea nevoilor clientului prin livrarea în timp a soft-ului;
Cererile de schimbare sunt binevenite, chiar şi în stadiile avansate ale dezvoltării;
Livrăm frecvent soft funcţional, cu o frecvenţă săptămînală spre lunară, cu preferinţă pentru termenii mai scurţi;

9. Principiul Agile:YAGNI
"You Aren't Going To Need It... unless the business says so!".
Prin acest principiu suntem încurajaţi să
implementăm doar acele elemente pe care le
solicită clientul şi nimic mai mult!

10. Scrum

11. Principiul metodologiei SCRUM
dezvoltarea incrementală a aplicaţiei software;
livrări frecvente - de regulă au loc o dată la 4 săptămâni;
clientul primeşte de fiecare dată o aplicaţie ce conţine un număr tot mai mare de funcţionalităţi şi care se află în perfectă stare de funcţionare.

12. Reguli în Scrum Această metodă necesită patru tipuri de şedinţe :
Şedinţele zilnice: echipa se reuneşte în fiecare zi şi petrece circa 15 minute, în picioare, pentru a răspunde la următoarele trei întrebări: ce am făcut ieri? Ce voi face azi? Cu ce obstacole mă confrunt azi?
Şedinţele de planificare: întreaga echipă se adună pentru a decide care sunt funcţionalităţile care vor alcătui următorul sprint, şi pentru a actualiza lista generală.
Şedinţele de revizuire a activităţii: în timpul acestei şedinţe, fiecare membru prezintă ceea ce a făcut pe durata sprintului. Se organizează o demonstraţie a noilor funcţionalităţi şi o prezentare a arhitecturii. Aceasta este o şedinţă informală, de două ore, la care participă toată echipa.
Şedinţele retrospective: la finalul fiecărui sprint, echipa analizează aspectele care au funcţionat bine, precum şi pe cele care au funcţionat mai puţin bine. În timpul acestei şedinţe de 15–30 de minute, se organizează un vot de încredere pentru a decide ce îmbunătăţiri trebuie implementate.

13. Avantaje
reducerea documentaţiei la minimul cu scopul sporirii productivităţii;
evitarea „efectului de tunel", adică faptul de a obţine rezultatul abia la livrarea finală şi de a nu întrezări nimic concret pe durata întregii faze de dezvoltare;
compunerea secvenţială a conţinutului sprint-urilor permite efectuarea unei modificări sau adăugarea unei funcţionalităţi care nu era prevăzută iniţial. Acesta este principalul aspect care face ca această metodă să fie „agilă“;
metodă participativă: fiecare membru al echipei este invitat să îşi exprime părerea şi poate contribui la toate deciziile luate în cadrul proiectului, fiind astfel mai implicat şi mai motivat;
facilitarea comunicării: lucrînd în aceeaşi sală de dezvoltare sau fiind conectată prin intermediul diferitelor mijloace de comunicare, echipa poate comunica uşor şi poate schimba informaţii despre impedimentele întâlnite în scopul eliminării cât mai rapide a acestora;
ameliorarea cooperării: comunicarea zilnică dintre client şi echipa face posibilă o colaborare mai strânsă între cele două părţi;
creşterea productivităţii: prin eliminarea anumitor „exigenţe" specifice metodelor clasice, precum documentaţia;
timpul de livrare a produsului final se reduce semnificativ.

14. Riscuri şi soluţii
Dimensiunea echipei: fiind limitată la persoane, dimensiunea echipei se poate transforma într-un obstacol dacă se depăşeşte numărul de membri recomandat. În acest caz, organizarea de şedinţe devine imposibilă. Soluţia constă în realizarea unui „Scrum of Scrums“ - împărţirea proiectului în echipe de dimensiuni standard şi adăugarea unei instanţe superioare care să grupeze ScrumMasterii fiecărui Scrum;
Cereri multiple: cererile pot proveni din mai multe surse în cadrul unui proiect şi pot uneori să fie dificil de gestionat datorită aspectului lor contradictoriu. Pentru a remedia această problemă, trebuie să se utilizeze în mod obligatoriu o aplicaţie de gestiune a cererilor;
Calitatea produsului realizat: cu cât numărul echipelor este mai mare, cu atât calitatea este mai greu de controlat. Pentru aceasta, este important să existe o politică de calitate riguroasă şi un plan de calitate a proiectului. Verificarea frecventă a codului şi introducerea unor indicatori pentru măsurarea performanţei programatorilor permit reducerea la minimum a acestui risc.

15. Organizare Scrum
Metodologia SCRUM implică intervenţia a trei protagonişti :
Product owner: responsabilul de produs şi coordonatorul echipei clientului. El este cel care defineşte şi stabileşte funcţionalităţile prioritare şi alege data şi conţinutul fiecărui sprint pe baza volumelor de lucru comunicate de echipă.
ScrumMaster: acesta facilitează buna desfăşurare a proiectului, are grijă ca fiecare membru să poată lucra la capacitate maximă eliminând impedimentele şi protejând echipa de perturbările exterioare. De asemenea, acordă o atenţie specială respectării diferitelor faze SCRUM.
Echipa: fiind de regulă alcătuită din circa 4-10 persoane, echipa adună la un loc specialiştii necesari în cadrul unui proiect, şi anume: arhitectul, designerul, programatorul, testerul etc. Echipa se organizează singură şi rămâne neschimbată pe toată durata sprintului.

16. Tabla Scrum

17. Tabla Scrum în LTIC

18. Comunicare Programator&Tester

19. Tabla LTIC restructurată

20. Motivare Scrum

21. Restricţii şi recomandări pentru tabla Scrum
Cît mai puţine sarcini mici în Sprint per persoană cu atît mai bine;
Modificaţi tabla Scrum conform necesităţilor echipei şi a proiectului;
Sarcini curente în realizare maxim 2;
Numărul de sarcini plasate pe tabla trebuie să fie realizate la finisarea Sprint-ului;
Nu se acceptă sarcini noi în Sprint-ul care este în proces de realizare.
Soluţie: Înlocuirea sarcinilor;

22. Sprint Software

23. Cui se adresează acest tip de organizare?
Acest tip de organizare poate fi utilizat în majoritatea proiectelor;
Metodologia Agile – SCRUM este destinată în special proiectelor care nu au un cadru bine conturat;
E nevoie o echipă cu iniţiativă care cuprinde oameni cărora le place să experimenteze, să schimbe şi să se adapteze cerinţelor;
Echipe care stiu sa se organizeze;

24. Este IDSI o echipa Agile-Scrum?

25. Este IDSI o echipa Agile-Scrum?
Numărul foarte mare de studenţi (70%) cu un orar de lucru part-time;
Cele 4 tipuri de şedinţe Scrum nu pot fi organizate;
Categorii de vîrstă şi mod de percepere diferit a procesului de lucru;
Nu toţi membrii echipei vor să fie Agile;
Dimensiunea echipei este mare şi nu se regasesc în ea posturile necesare unei echipe Scrum;
Numărul mare de proiecte la mentenanţă;
Fiecare membru al echipei este implicat în mai mult de 1 proiect în Sprint;
Nu pot fi planificate şi estimate corect sarcinile pentru Sprint;
Sarcini neplanificate se soluţionează în timpul Sprint-ului;
Nu este posibil de estimat corect timpul la sarcini de către echipă;
Nu se face livrarea proiectului la finisarea fiecărui Sprint;
etc

26. Soluţia?

27. Link-uri utile

28. Întrebări ?