Dezavantajele metodelor clasice de management a proiectelor Fore uriae n timpul etapei de planificare; Resurse enorme pentru modificarea cerinele tehnice ntr-un mediu ce se schimb rapid; Tratarea personalului ca factor de producie; Rezultatul metodelor clasice implementate n IDSI* Haos datorit schimbrii cerinelor - cerinele unui proiect pot s se schimbe n faza de design, implementare i chiar lansare. n mai toate metodologiile de dezvoltare, analiza este fcut n partea de nceput a proiectului, i nici o schimbare nu mai este permis pn spre final. Estimri nerealiste de timp, cost i calitate a proiectelor - managerul de proiect i dezvoltatorii tind s subestimeze ct timp i resurse sunt necesare pentru un proiect, i cte funcionaliti pot fi livrate. Acestea nu pot fi niciodat prevazute 100% n faza de nceput a ciclului de dezvoltare.
Soluia? Agile Software Development nume preluat de la sportul de Rugby unde toat echipa acioneaz mpreun - analogie se face la dezvoltarea software unde echipa lucreaz mpreun pentru a dezvolta cu succes produse de calitate.
Ce este Agile? Metodologie de management a proiectelor ce ncearc s micoreze riscurile de dezvoltare i timpul de execuie prin implementarea proiectelor n form foarte flexibil i interactiv.
Caracteristicile Agile Este iterativ: o iteraie are ntre 1-4 saptmni,n rezultat sunt livrate anumite funcionaliti ale proiectului. Este bazat pe timp:durata iteraiei e fix i nu poate fi modificat pe parcursul proiectului. n acest fel exist ntotdeauna un rezultat productiv la finalul iteraiei. Deschis ctre client:la finalul fiecrei iteraii exist un rezultat care poate fi prezentat clientului. Bazat pe livrarea de versiuni intermediare ale produsului: fiecare iteraie va implementa complet toate task-urile cuprinse n acea iteraie
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. 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 dezvoltrii; Livrm frecvent soft funcional, cu o frecven sptmnal spre lunar, cu preferin pentru termenii mai scuri; Principiul Agile:YAGNI "You Aren't Going To Need It... unless the business says so!".
Prin acest principiu suntem ncurajai s implementm doar acele elemente pe care le solicit clientul i nimic mai mult! Scrum Principiul metodologiei SCRUM dezvoltarea incremental a aplicaiei software; livrri frecvente - de regul au loc o dat la 4 sptmni; clientul primete de fiecare dat o aplicaie ce conine un numr tot mai mare de funcionaliti i care se afl n perfect stare de funcionare.
Reguli n Scrum Aceast metod necesit patru tipuri de edine : edinele zilnice: echipa se reunete n fiecare zi i petrece circa 15 minute, n picioare, pentru a rspunde la urmtoarele trei ntrebri: ce am fcut ieri? Ce voi face azi? Cu ce obstacole m confrunt azi? edinele de planificare: ntreaga echip se adun pentru a decide care sunt funcionalitile care vor alctui urmtorul sprint, i pentru a actualiza lista general. edinele de revizuire a activitii: n timpul acestei edine, fiecare membru prezint ceea ce a fcut pe durata sprintului. Se organizeaz o demonstraie a noilor funcionaliti i o prezentare a arhitecturii. Aceasta este o edin informal, de dou ore, la care particip toat echipa. edinele retrospective: la finalul fiecrui sprint, echipa analizeaz aspectele care au funcionat bine, precum i pe cele care au funcionat mai puin bine. n timpul acestei edine de 1530 de minute, se organizeaz un vot de ncredere pentru a decide ce mbuntiri trebuie implementate.
Avantaje reducerea documentaiei la minimul cu scopul sporirii productivitii; evitarea efectului de tunel", adic faptul de a obine rezultatul abia la livrarea final i de a nu ntrezri nimic concret pe durata ntregii faze de dezvoltare; compunerea secvenial a coninutului sprint-urilor permite efectuarea unei modificri sau adugarea unei funcionaliti care nu era prevzut iniial. Acesta este principalul aspect care face ca aceast metod s fie agil; metod participativ: fiecare membru al echipei este invitat s i exprime prerea i poate contribui la toate deciziile luate n cadrul proiectului, fiind astfel mai implicat i mai motivat; facilitarea comunicrii: lucrnd n aceeai sal de dezvoltare sau fiind conectat prin intermediul diferitelor mijloace de comunicare, echipa poate comunica uor i poate schimba informaii despre impedimentele ntlnite n scopul eliminrii ct mai rapide a acestora; ameliorarea cooperrii: comunicarea zilnic dintre client i echipa face posibil o colaborare mai strns ntre cele dou pri; creterea productivitii: prin eliminarea anumitor exigene" specifice metodelor clasice, precum documentaia; timpul de livrare a produsului final se reduce semnificativ.
Riscuri i soluii Dimensiunea echipei: fiind limitat la 7 -10 persoane, dimensiunea echipei se poate transforma ntr-un obstacol dac se depete numrul de membri recomandat. n acest caz, organizarea de edine devine imposibil. Soluia const n realizarea unui Scrum of Scrums - mprirea proiectului n echipe de dimensiuni standard i adugarea unei instane superioare care s grupeze ScrumMasterii fiecrui 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 aplicaie de gestiune a cererilor; Calitatea produsului realizat: cu ct numrul echipelor este mai mare, cu att 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 msurarea performanei programatorilor permit reducerea la minimum a acestui risc.
Organizare Scrum
Metodologia SCRUM implic intervenia a trei protagoniti : Product owner: responsabilul de produs i coordonatorul echipei clientului. El este cel care definete i stabilete funcionalitile prioritare i alege data i coninutul fiecrui sprint pe baza volumelor de lucru comunicate de echip. ScrumMaster: acesta faciliteaz buna desfurare a proiectului, are grij ca fiecare membru s poat lucra la capacitate maxim eliminnd impedimentele i protejnd echipa de perturbrile exterioare. De asemenea, acord o atenie special respectrii diferitelor faze SCRUM. Echipa: fiind de regul alctuit din circa 4-10 persoane, echipa adun la un loc specialitii necesari n cadrul unui proiect, i anume: arhitectul, designerul, programatorul, testerul etc. Echipa se organizeaz singur i rmne neschimbat pe toat durata sprintului.
Tabla Scrum
Tabla Scrum n LTIC
Comunicare Programator&Tester
Tabla LTIC restructurat
Motivare Scrum
Restricii i recomandri pentru tabla Scrum Ct mai puine sarcini mici n Sprint per persoan cu att mai bine; Modificai tabla Scrum conform necesitilor echipei i a proiectului; Sarcini curente n realizare maxim 2; Numrul 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. Soluie: nlocuirea sarcinilor; Sprint Software
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 iniiativ care cuprinde oameni crora le place s experimenteze, s schimbe i s se adapteze cerinelor; Echipe care stiu sa se organizeze;
Este IDSI o echipa Agile- Scrum? Este IDSI o echipa Agile- Scrum? Numrul foarte mare de studeni (70%) cu un orar de lucru part- time; Cele 4 tipuri de edine Scrum nu pot fi organizate; Categorii de vrst i mod de percepere diferit a procesului de lucru; Nu toi membrii echipei vor s fie Agile; Dimensiunea echipei este mare i nu se regasesc n ea posturile necesare unei echipe Scrum; Numrul 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 soluioneaz n timpul Sprint-ului; Nu este posibil de estimat corect timpul la sarcini de ctre echip; Nu se face livrarea proiectului la finisarea fiecrui Sprint; etc Soluia?