Dezvoltarea Unui Proiect Folosind Metodologia Agila Scrum

Academia de Studii Economice, Bucuresti

Facultatea de Cibernetica, Statistica si Informatica Economica

Dezvoltarea unui proiect folosind metodologia agila SCRUM

Studenti: Dragnea Costin Daniel

Grigore Adrian

Iacob Mihaela

Ivan Paula

Miron Diana

Profesori Coordonatori: Mircea Marinela

Stoica Marian

Bucuresti

2015

Prezentarea generala a proiectului

Proiectul consta in realizarea unui website de prezentare a cartilor, care sa includa posibilitatea de a realiza cautari de articole, abonarea la un newsletter, postarea recenziilor despre carti si purtarea unor discutii prin intermediul unui forum. Solutia oferita cuprinde urmatoarele :

Pagina de index a website-ului ce va cuprinde cateva informatii despre administratorii pagini, meniul principal al paginii web, recenziile de top si informatii cu privire la scopul site-ului;

Posibilitatea de introducere in baza de date a aplicatiei noi carti, descrierea acestora si recenzii postate de catre utilizatori;

Posibilitatea de abonare pentru a primi informatii cu privire la aparitia unor noi recenzii;

Posiblitatea de cautare a articolelor in cadrul website-ului;

Posibilitatea de inregistrare/autentificare;

Purtarea dicutiilor in cadrul unui forum;

Printre beneficiile unei astfel de pagini web numaram:

Posibilitatea informarii celor pasionati de citit despre diferite categorii de carti

Schimbarea cat mai usoara a parerilor si dezbaterea diferitelor subiecte legate de carti.

Obiectivele proiectului:

Crearea unui website usor de utilizat de catre toate categoriile de persoane

Oferirea unei experiente de comunicare mult mai accesibila;

Necesitatea implementarii SCRUM:

cerintele de proiect sunt dezvoltate in cadrul iteratiilor numite sprinturi, iar la sfarsitul fiecarei iteratii este livrata o versiune functionala de proiect, testata si stabila din punct de vedere al utilizarii, asadar proiectul poate fi folosit de catre utilizatori chiar dupa prima iteratie;

Scrum gestioneaza bine timpul de dezvoltare al unui proiect, deoarece permite demararea fazei de dezvoltare fara a avea specificatiile functionale complete;

Flexibilitate si usurinta de adaptare la schimbarile cerintelor clientului, chiar daca proiectul este intr-o stare avansata, eventualele schimbari se pot efectua relativ usor;

Utilizarea SCRUM in cadrul unui proiect software (+ utilizarea instrumentului Sprintometer pentru managementul proiectului)

Se va utiliza un instrument de management de proiect care foloseste SCRUM. Sprintometer-ul este un software simplu dar folositor, utilizat pentru managementul proiectelor Agile de tip Scrum sau XP (Extreme Programming). Programul a fost dezvoltat initial de persoane care lucrau la proiecte. Pentru a simplifica transferul de date dintre sprintometer si alte programe externe, toate datele stocate pot fi exportate intr-un fisier Excel sau intr-un XML.

Principalele caracteristici ale Sprintometer-ului sunt:

administrarea proiectelor Scrum si XP;

diagrama Burn Down detaliata si alte diagrame folositoare;

compozitia unei echipe poate varia de la un sprint la altul fara a afecta modul de management al proiectului;

posibilitatea de a inregistra schimbarile unui task;

ofera o predictie a deviatiei de la planul initial;

calculeaza permanent numarul de puncte asignat unui membru al echipei;

datele pot fi stocate local sau pe un server remote;

conexiuni https securizate cu serverul;

task-urile si story-urile pot fi asignate membrilor echipei.

Facilitatile oferite de acest program usureaza mentinerea Sprint Backlog-ului actualizat, oferind in acelasi timp o viziune mai buna asupra progresului echipei.

Faza de planificare

In cadrul aceste faze este surprinsa stabilirea concreta a cerintelor la momentul actual al produsului ce va urma sa fie dezvoltat.

Conform proiectului nostru, website-ul destinat prezentarii cartilor va cuprinde atat pagini de informare precum cea de home sau contact, paginile cu recenzii, cat si pagini ce presupun autentificarea sau inregistrarea pe site precum si postarea de comentarii sau recenzii.

Product Backlog-ul a fost format pe baza secțiunilor ce urmau să intre în dezvoltare, materializându-se într-un document Excel. Story-urile trecute în document conțineau doar titlul secțiunii, specificațiile trebuind să fie formulate înainte de prima ședință de planificare sub forma minimalista de wireframe.

Product Backlog-ul este un document de nivel înalt pentru întreg proiectul. El conține specificațiile detaliate pentru toate funcționalitățile cerute și lucruri care vor fi dezvoltate în viitor, prioritizate în funcție de valoarea business pe care o dețin. În principiu conține ceea ce urmează a fi dezvoltat. Product Backlog-ul este proprietatea Product Owner-ului, acesta determinând valoarea business în timp de echipa determină necesarul de efort pentru fiecare element din document.

Backlog-ul produsului:

Figura 1 – Backlog-ul produsului

Dupa cum se poate observa, avem mai multe cerinte in realizarea website-ului precum proiectarea bazei de date, crearea arhitecturii website-ului, adaugarea articolelor si comentariilor, pagina de cautare, pagina de contact, listarea articolelor precum autentificarea/inregistrarea pe site.

Fiecare componenta a proiectului cuprinde mai multe task-uri ce trebuie realizate pentru a atinge obiectivul respectiv.

Tot in cadrul acestei faze se mai stabilesc si urmatoarele aspecte :

Proiectul va fi realizat pe durata a 5 sprint-uri. Acestea vor avea fiecare cate 2 saptamani (10 zile lucratoare). Data de start a proiectului este 2 Noiembrie 2015.

Data la care va fi livrat produsul : 8 ianuarie 2016

echipa este formata din: Scrum master, doi programatori si doi testeri

echipamente necesare: pentru fiecare membru al echipei va fi nevoie de cate un echipament de calcul. Toti membrii echipei vor necesita calculatoare desktop pentru a avea o mai mare eficienta in testare si programare a produsului.

Timpul ce va fi alocat fiecarui sprint va fi corelat cu volumul de munca necesar pentru indeplinirea obiectivelor

Arhitectura website-ului va cuprinde pagina de index, pagina de contact, pagina de afisare a articolelor, pagina de adaugare a unui articol/comentariu, pagina de autenbtificare/inregistrare, crearea bazei de date si conectarea ei la pagina de recenzii precum si implementarea efectiva a acestora in cod.

Faza de dezvoltare

Aceasta faza reprezinta partea agila a abordarii Scrum. Aceasta faza este tratata ca o cutie neagra unde unele elemente sunt imprevizibile. Variabilele identificate ce tin de mediul de devoltare, care se pot schimba de-a lungul timpului, sunt observate si controlate prin diverse practici Scrum. Scrum ia in considerare aceste variabile nu doar la inceput (in faza de pre-joc), ci pe tot parcursul procesului de dezvoltare pentru a se putea adapta usor la schimbari. In aceasta faza proiectul este realizat prin intermediul sprint-urilor.

La inceputul fiecarui sprint are loc o intalnire denumita Sprint Planning Meeting. In prima parte a acestei intalniri, proprietarul produsului si echipa fac o recenzie asupra listei ”Product Backlog”, discuta despre obiectivele si contextul fiecarui item si este asigurata corespondenta dintre gandirea echipei si a proprietarului.

In cea de-a doua parte a intalnirii, echipa selecteaza din lista prioritizata item-urile pe care le va finaliza pana la sfarsitul sprintului. Aici este si ideea practicilor SCRUM: echipa decide cat de mult va munci pana ce va finaliza proiectul, spre deosebire de abordarea clasica in care munca echipei este hotarata de superiori. Acest lucru face ca angajamentul membrilor sa fie mult mai intens, deoarece echipa il hotaraste si tot ea il realizeaza.

In final va fi hotarat numarul de ore necesare pentru efectuarea cu succes a cerintelor. Odata ce aceste probleme sunt rezolvate, echipa va incepe sa lucreze la primul item din lista si membrii vor lucra impreuna, impartind sarcinile intre ei, sarcini care vor fi inregistrate in documentul numit sprint backlog . Odata ce sarcinile sunt identificate, membrii echipei se vor oferi sa le rezolve, stabilind timpul pentru fiecare in parte si asigurandu-se ca volumul de munca este rezonabil pentru fiecare.

Pe parcursul sprintului in fiecare zi are loc sedinta zilnica Scrum. Aceasta intalnire are orientari specifice:

Reuniunea incepe la o ora exacta, la ora 10:30 dimineata.

Reuniunea este de 20-30 minute (durata ei este foarte importanta, este imperativ ca sedinta sa nu dureze mai mult) .

Reuniunea se desfasoara in acelasi loc si la aceeasi ora in fiecare zi.

In timpul intalnirii, fiecare membru al echipei raspunde la trei intrebari: Ce ai facut ieri? Ce ai de gand sa faci azi? Ce probleme ai intampinat ?

De rezolvarea diferitelor impedimente se ocupa maestr-ul scrum. Rezolvarea insa are loc in afara contextului sedintei zilnice scrum, pentru a nu plictisi ceilalti participanti si pentru a pastra durata sedintei de 20 minute.

ScrumMaster-ul se asigura ca echipa sustine sedinta. Echipa este responsabila de efectuarea sedintei Scrum zilnice. Scrum Master-ul invata echipa sa pastreze sedinta Scrum zilnica scurta prin aplicarea regulilor si asigurandu-se ca oamenii vorbesc pe scurt. Sedinata Scrum zilnica nu este o reuniune de stare. Nu este pentru oricine, ci numai pentru oamenii ce transforma backlog-ul produsului intr-o incrementare, adica echipa.

Echipa s-a angajat sa atinga obiectivul unui sprint si sa implementeze elementele ce fac parte din backlog-ul produsului. Sedinta Scrum zilnica este o inspectie a progresului fata de obiectivul sprint-ului (cele trei intrebari). Sedintele de urmarire sunt sustinute de obicei pentru a adapta din mers munca ce trebuie efectuata in sprint. Intentia este de a mari probabilitatea ca echipa isi va indeplini obiectivul. Aceasta este o sedinta cheie pentru inspectie si adaptare in cadrul procesului empiric Scrum.

Dupa ce un sprint este finalizat, are loc o analiza a sprintului in care echipa prezinta ce a reusit sa faca pana la momentul respectiv. La aceasta intalnire sunt prezente toate persoanele implicate in proiect, plus reprezentanti ai clientilor, stakeholderi, experti, membri ai forului executiv si orice alta persoana interesata. Aceasta nu este o prezentare in adevaratul sens al cuvantului si de obicei nu se pierd mai mult de 30 de minute cu pregatirea acesteia. Are loc expunerea unui demo a ceea ce s-a lucrat pana la acel moment si poate dura de la 10 minute pana la 2 ore. Orice persoana prezenta poate sa adreseze intrebari sau sa isi exprime parerea legata de ceea ce a vazut.

Dupa analiza are loc retrospectiva a ceea ce s-a facut. Este o oportunitate pentru echipa sa discute ce a functionat si ce nu a functionat. Echipa scrum, proprietarul produsului si scrum master vor fi prezenti la aceasta intalnire. O modalitate simpla de a structura retrospectiva este aceea de a pune in doua coloane separate elementele pozitive si cele negative. Dupa ce au fost identificate anumite probleme, cei prezenti se pun de acord asupra anumitor modificari care sa aduca o serie de imbunatatiri.

O practica pe care echipele o gasesc utila este organizarea unei discutii la sfarsitul fiecarui sprint, discutie in care sunt revazute elementele de pe backlog-ul produsului si este o oportunitate pentru identificarea item-urilor care nu pot fi realizate datorita diverselor probleme tehnice.

2.2.1 Sprint 1 (Design aplicatie)

Durata unui Sprint este fixată la două săptămâni. Deoarece Project Managerul nu a dorit initial redactarea anterioara a specificatiilor tehnice, fiecare story ce intra in sprintul respectiv era dezbatut amanuntit in sedinta de planificare. Detaliile erau notate in proiectul creat in sprintometru. Story-urile aveau intotdeauna specificata prioritatea.

Toate story-urile care au fost incluse in primul sprint au fost trecute in sprintometru, impreuna cu estimarea timpului pentru fiecare si developerul care si-a asumat taskul respectiv. Cu toate ca metodologia spune ca taskurile nu se asigneaza la inceputul sprintului, echipa a vrut ca fiecare developer sa stie ce are de facut in perioada sprintului.

Sprint Backlog-ul este un document care contine informatii despre modul in care echipa o sa implementeze functionalitatile care trebuie realizate in sprintul urmator. Elementele mari sunt impartite in task-uri. Aceste task-uri primesc un numar de puncte care reflecta timpul necesar realizarii.

Prin intermediul acestui nivel de detaliere, toata echipa intelege ce are de facut si oricine pooate sa aleaga un task din lista pentru a-l realiza. Conform metodologiei, task-urile din backlog nu sunt niciodata atribuite de altcineva, acestea fiind preluate de membrii echipei pe masura ce trebuie indeplinite, conform cu prioritatea acestora si cu nivelul de pregatire al persoanei care realizeaza task-ul respectiv. Sprint Backlog-ul este proprietatea echipei, estimarile task-urilor realizandu-se tot de catre echipa.

Pentru primul sprint al prezentului studiu de caz, sprint backlog-ul este prezentat in figura urmatoare :

Figura 3 – Sprintul 1

Primul sprint se va concentra asupra arhitecturii website-ului de recenzii pentru carti pe care il vom crea si asupra crearii bazei de date.

Acesta se va desfasura pe perioada 2 Noiembrie 2015 – 13 Noiembrie 2015. Perioadele nelucratoare sunt reprezentate de zilele de sambata si duminica.

Sprint-ul 1 cuprinde cinci story-uri cu mai multe task-uri fiecare. Primul story, Crearea bazei de date, are un singur subtask, si anume cel de proiectare si implementare a bazei de date.

Cel de-al doilea story al primului sprint, Pagina home, cuprinde trei subtaskuri ce au in prim plan:

Crearea interfetei paginii de home

Crearea backoffice-ului corespunzator paginii de home

Testarea functionalitatilor implementate

Cel de-al treilea story al primului sprint se concentreaza pe crearea paginii de contact. Acesta are ca task-uri:

Crearea interfetei paginii de contact si a backoffice-ului corespunzator

Crearea UI-ului si a backoffice-ului corespunzator formularului de contact

Incorporarea functionalitatii de google maps

Testarea functionalitatilor implementate

Cel de-al patrulea story al sprintului, Pagina de search, cuprinde 3 taskuri:

Crearea interfetei si backoffice-ului paginii de search

Codarea motorului de cautare

Testarea functionalitatilor implementate

Cel din urma story, Pagina top review-uri, cuprinde si acesta 3 taskuri:

Crearea interfetei si backoffice-ului paginii de search

Crearea sistemului de clasare al cartilor

Testarea functionalitatilor implementate

Figura 4 – Storyuri Sprint 1

Pe parcursul sprintului in fiecare zi are loc sedinta zilnica. Aceasta intalnire a avut orientari specifice:

Reuniunea incepe la o ora exacta, la ora 10:30 dimineata.

Reuniunea este de 20-30 minute (durata ei este foarte importanta, este imperativ ca sedinta sa nu dureze mai mult) .

Reuniune se desfasoara in acelasi loc si la aceeasi ora in fiecare zi.

In timpul intalnirii, fiecare membru al echipei raspunde la trei intrebari: Ce ai facut ieri? Ce ai de gand sa faci azi? Ce probleme ai intampinat ?

Sedintele de pe parcursul sprint-ului s-au desfasurat in bune conditii, fiecare membru al echipei stiind exact ceea ce are de facut. Au fost intrebari legate de modul in care se vor folosi toate instrumetele si de procurarea unui manual pentru acestea. S-a rezolvat aceasta problema cu ajutorul documentatiei aferente fiecarui instrument folosit (printre care si Sharepoint).

Resursele umane care vor fi folosite sunt reprezentate de personalul ce se va ocupa de dezvoltarea proiectului si anume: Scrum master-ul, programatorii si tester-ii.

Fiecare task de dezvoltare a fost asignat cate unui dezvoltator, exceptie facand proiectarea bazei de date, ce a fost asignata celor doi dezvoltatori, fiind un task de o amploare mai crescuta. Taskurile de testare sunt impartite intre cei doi testeri aflati pe proiect.

Dupa incheierea primului sprint, are loc o sedinta de retrospectiva in care echipa prezinta ce a reusit sa faca pana la momentul respectiv. La sfarsitul sprintului, scopul lui a fost atins in procent de 100%:

Figura 5. Sedinta de retrospectiva – Sprint 1

Mai jos sunt capturi facute in tool-ul sprintometer pentru graficul ce ilustreaza volumul de munca al membrilor echipei.

Figura 6 – Volumul de munca al anagajatilor in cadrul primului sprint

Atat volumul de munca, cat si tipul acesteia a fost distribuit egal printre membrii echipei. Dat fiind faptului ca s-a dezvoltat un volum foarte mare de functionalitati, activitatea testerilor a fost destul de mare, pentru a putea comunica dezvoltatorilor eventualele probleme aparute.

La sedinta de retrospectiva, s-au analizat taskurile finalizate si au fost lansate in environmentul de productie, s-au prezentat Product Ownerului si s-au discutat impresiile despre metodologie, iar fiecare membru al echipei si-a exprimat parerea in legatura cu Scrum.

Product Ownerul a fost de acord ca pentru al doilea sprint sa realizeze specificatiile in avans si sa le furnizeze echipei de dezvoltare in ziua planificarii sprintului. De asemenea, a fost de acord cu pastrarea specificatiilor neschimbate in perioada sprintului.

Membrii echipei au apreciat ca noul mod de lucru a consolidat comunicarea in echipa, fiecare membru fiind nevoi sa participle la sedintele zilnice, la sedinta de planificare, intelegand astfel toate taskurile in ansamblu si participand cu idei la realizarea lor.

De asemenea, membrii echipei au hotarat ca toate ideile despre imbunatatirea procedului sa fie adaugate pe tabla din biroul echipei de dezvoltare si dezbatute in cadrul sedintei de retrospectiva.

2.2.2 Sprint 2 (NewsLetter)

Cel de-al doilea sprint al proiectului se concentreaza pe adaugarea functionalitatii de stiri si newsletter, implementand functionalitati de abonare/dezabonare si crearea sabloanelor de email-uri ce vor fi folosite la instiintarea utilizatorilor website-ului.

Pentru primul sprint al prezentului studiu de caz, sprint backlog-ul este prezentat in figura urmatoare :

Figura 7 – Sprintul 2

Acest sprint se va desfasura pe perioada 16 Noiembrie 2015 – 27 Noiembrie 2015. Perioadele nelucratoare sunt reprezentate de zilele de sambata si duminica.

Sprint-ul 2 cuprinde trei story-uri a cate trei task-uri fiecare. Primul story, Formularul de abonare, cuprinde urmatoarele taskuri:

Crearea capurilor de introducere a datelor de inscriere

Corelarea informatiilor preluate din formular cu baza de date

Testarea functionalitatilor implementate

Cel de-al doilea story al celui de-al doilea sprint, Dezabonarea, cuprinde trei subtaskuri ce au in prim plan:

Crearea sablonului de email si a linkului de dezabonare

Stergerea utilizatorului abonat din baza de date si introducerea acestuia in istoric

Testarea functionalitatilor implementate

Cel de-al treilea story al sprintului se concentreaza pe crearea sabloanelor. Acesta are ca task-uri:

Crearea sablonului prin intermediul backoffice-ului

Crearea sistemului de colectare a articolelor noi si afisarea lor in sablon

Testarea functionalitatilor implementate

Figura 8 – Storyuri Sprint 2

Pe parcursul sprintului in fiecare zi are loc sedinta zilnica. Aceasta intalnire a avut orientari specifice:

Reuniunea incepe la o ora exacta, la ora 10:30 dimineata.

Reuniunea este de 20-30 minute (durata ei este foarte importanta, este imperativ ca sedinta sa nu dureze mai mult) .

Reuniune se desfasoara in acelasi loc si la aceeasi ora in fiecare zi.

In timpul intalnirii, fiecare membru al echipei raspunde la trei intrebari: Ce ai facut ieri? Ce ai de gand sa faci azi? Ce probleme ai intampinat ?

Sedintele de pe parcursul sprint-ului s-au desfasurat in bune conditii, fiecare membru al echipei stiind exact ceea ce are de facut. Au fost intrebari legate de modul in care se vor folosi toate instrumetele si de procurarea unui manual pentru acestea. S-a rezolvat aceasta problema cu ajutorul documentatiei aferente fiecarui instrument folosit (printre care si Sharepoint).

Resursele umane care vor fi folosite sunt reprezentate de personalul ce se va ocupa de dezvoltarea proiectului si anume: Scrum master-ul, programatorii si tester-ii.

Fiecare task de dezvoltare a fost asignat cate unui dezvoltator ia taskurile de testare sunt impartite intre cei doi testeri aflati pe proiect.

Dupa incheierea primului sprint, are loc o sedinta de retrospectiva in care echipa prezinta ce a reusit sa faca pana la momentul respectiv. Si la sfarsitul acestui sprint, scopul lui a fost atins in procent de 100%:

Figura 9. Sedinta de retrospectiva – Sprint 2

Mai jos sunt capturi facute in tool-ul sprintometer pentru graficul ce ilustreaza volumul de munca al membrilor echipei.

Figura 10 – Volumul de munca al anagajatilor in cadrul celui de-al doilea sprint

Atat din volumul de munca, cat si din tipul acestuia se poate observa ca in cadrul acestui sprint, activitatea de dezvoltare de noi functionalitati nu a fost atat de intensa, deci nici testarea nu a necesitat foarte mult efort. Tocmai din acest motiv, toate taskurile s-au realizat cu succes. Desi testerii au avut activitate scazuta, acestia au asistat procesul de dezvoltare.

Dupa incheierea acestui sprint, are loc o analiza a sprintului in care echipa prezinta ce a reusit sa faca pana la momentul respectiv. La aceasta intalnire au fost prezente toate persoanele implicate in proiect, plus reprezentanti ai clientilor, stakeholderi, experti, membri ai forului executiv si orice alta persoana interesata. Durata pregatirii sedintei nu a fost mai mare de 30 de minute.

A avut loc expunerea unui demo a ceea ce s-a lucrat pana la acel moment si a durat 1 ora si 30 de minute. Au fost adresate intrebari de catre beneficiarul aplicatiei si toate aspectele neclare au fost lamurite.

Figura 11 – Diagrama burndown pentru Sprint-ul 2

In figura de mai sus este prezentata diagrama de burndown a backlog-ului sprintului care reprezinta un grafic al muncii ramase intr-un sprint fata de durata lui. Durata acestui sprint este de 10 zile, iar sprintul este impartit in 3 story-uri, fiecare fiind impartite in task-uri a caror evolutie in timp poate fi mult mai usor urmarita. Din aceasta diagrama se poate observa ca activitatea de testare a avut loc la finalul sprintului, lucru care nu a fost tocmai optim, intrucat eventualele erori si probleme aparute, nu au putut fi reparate in cadrul acestui sprint.

Conform metodologiei Scrum, echipa trebuie să dezvolte o funcționalitate a produsului în fiecare Sprint. Aceasta funcționalitate trebuie să fie livrabilă, Product Owner-ul având posibilitatea de a solicita lansarea ei imediată. Pentru a putea realiza acest lucru, acest element trebuie să reprezinte o parte integrabilă a produsului. Trebuie să fie “done”. Fiecare funcționalitate lansată trebuie să fie compatibilă toate elementele produsului și să fie testată în detaliu, asigurând astfel buna funcționare a software-ului.

Defintia de “done” trebuie percepută în același fel de toți membrii echipei. De cele mai multe ori, un element din Product Backlog este “done” după ce a fost dezvoltat, testat de dezvoltatori, compilat și acceptat pentru lansare.

După încheierea ședinței de review urmează ședința de retrospectiva. Deși nu este în concordanță cu metodologia Scrum, la această ședință participa și Product Owner-ul. Membrii echipei își exprima punctul de vedere cu privire la ce a mers bine și ce a mers prost în timpul ultimului Sprint și încearcă să găsească o soluție pentru a îmbunătăți derularea Sprint-ului următor.

Sprint 3

2.2.4 Sprint 4

2.2.5 Sprint 5

2.3 Faza de finalizare a proiectului

In cadrul acestei faze toate cerintele stabilite sunt indeplinite. In acest stadiu nu mai sunt elemente sau probleme (in produsul nerezolvat) care trebuie adresate si nici nu se mai pot gasi altele noi. Produsul este gata pentru a fi livrat si se pregateste aceasta actiune (prin integrare, testare, documentare).

Proiectul s-a incheiat cu succes, a fost livrat la timp, iar beneficiarul s-a declarat multumit de aplicatia care ii serveste in intregime. Cel mai mare avantaj al folosirii metodologiei Scrum a fost faptul ca dupa fiecare sprint echipa a prezentat o versiune functionala a aplicatiei, iar clientul a putut urmari evolutia proiectului de la primele functionalitati dezvoltate in primul sprint, pana la produsul final livrat la ultimul sprint.

Analiza rezultatelor obtinute in urma adoptarii metodologiei SCRUM

In urma discutiilor cu membrii echipei proiectului au fost extrase cateva concluzii atat positive cat si negative legate de utilizarea metodologiei scrum :

se pune accent pe factorul uman in mod special – fiecare membru al echipei este invitat sa isi exprime parerea si poate contribui la toate deciziile luate in cadrul proiectului, fiind deci mai implicat si mai motivat.

echipe lasate sa se organizeze singure

problema este planificarea financiara; este foarte dificil sa estimezi un cost si un timp de dezvoltare cand tu nu stii cate iteratii vor fi necesare si nu ai o planificare foarte clara a intregului ciclu de dezvoltare;

abordarea clientior : “arata-mi ceva si apoi iti spun ce sa schimbi” este de multe ori una greu de realizat;

comunicarea zilnica dintre client si echipa face posibila o colaborare mai stransa intre cele doua parti.

implementarea mai intai a functionalitatilor cele mai importante pentru client;

evitarea implementarii functionalitatilor ce nu vor fi utilizate;

un bun control al proceselor foarte complexe de dezvoltare a softului;

pretinde stabilirea priroritatii functionalitatilor sistemului;

capacitatea de a raspunde la cerintele imprevizibile sau nedefinite clar

reducerea documentatiei la minimul necesar in vederea sporirii productivitatii