ACADEMIA DE STUDII ECONOMICE BUCURETI FACULTATEA DE MANAGEMENT ECONOMIC

Implementarea metodologiilor waterfall si agile in companii si servicii

Proiect -Managementul Calitatii Proceselor

Realizatori : Dinu Catalina-Cristina Dobrinoiu Denisa Dragusin Andreea Van Gulik Radu

Bucuresti -2012-

Implementarea metodologiilor waterfall si agile in companii si servicii

MODELUL CASCADA Fiind cel mai vechi dintre modele, elaborat la nceputul anilor 70 de W.W. Royce, modelul cascad corespunde ciclului de viat clasic. Modelul cascad este unul de referint, asigurnd trecerea de la o etap la alta,ce-i drept, mai mult teoretic, n ordine secvential. Realitatea a demonstrat c parcurgerea etapelor/fazelor ntr-o astfel de ordine nu este o regul, deoarece, de cele mai multe ori, se nregistreaz reveniri la etapele anterioare sau parcurgerea n paralel a unora dintre ele. Modeleul const ntr-o descompunere a ciclului de viat n faze secventiale. La rndul lor, fazele sunt structurate pe activitti i subactivitti. Trecerea de la o etap la alte se realizeaz dup ce precedenta a fost parcurs n ntregime. Modelul se aplic la nivel de sistem tocmai aici este punctul slab, deoarece sistemele complexe, cu un numr mare de aplicatii ce interacioneaz ntre ele sunt greu de controlat.

In prima sa versiune, modelul avea numai sgei descendente, care materializeaz nlnuirea etapelor; el nu prevedea iteraii. Sgeile ascendente au fost adugate mai trziu pentru a ilustra principiul c o etap repune n discuie numai etapa precedent.

Limitele modelului n cascad Modelul n cascad se bazeaz pe o secven de faze bine delimitate. Documentele produse de fiecare faz sunt evaluate n cadrul reviziilor care valideaz trecerea de la o faz la alta. Din pcate, proba efectiv a bunei sau a proastei functionri a sistemului este realizat numai n cadrul fazei de integrare, cnd este posibil evaluarea concret a programului. Inaintea acestei faze au fost produse numai documente. Abordarea n cascad d rezultate satisfctoare numai n cazul n care este efectiv posibil nlnuirea fazelor fr prea multe probleme. Aceasta presupune ca ansamblul cerinelor s fie perfect cunoscut i problema complet nteleas de analiti. Trebuie de asemenea ca soluia s fie uor de determinat de proiectani i codificarea simpl - redus ideal la generarea automat a codului plecnd de la documentele de proiectare. In realitate se constat c partea de necunoscut poate fi nsemnat n anumite dezvoltri, n special datorit: - nenelegerii cerinelor de ctre client sau analist; - instabilitii cerinelor; -alegerilor tehnologice; -schimbrilor de personal. Din toate aceste motive sunt necesare reveniri n etape anterioare ale procesului de dezvoltare. Aceste reveniri sunt de fapt o reflectare a realitii. Dac aceste reveniri sunt ocazionale i limitate la faze adiacente, modelul n cascad este pertinent. In caz contrar, modelul n cascad nu corespunde realitii.

Avantaje: 1. Sistemul este bine documentat 2. Permite un bun management al proiectului: planificarea resurselor umane pe etape estimari de cost mai exacte

Dezavantaje: 1. Un produs executabil, care sa demonstreze functionarea sistemului este disponibil destul de tarziu, dupa integrare. Pana atunci s-au produs numai documente. 2. Deoarece modelul este secvential, exista numai uhn feedback local, la tranzitiile intre faze. 3. Multe erori sunt descoperite tarziu cost crescut 4. Toate riscurile sunt incluse intr-un singur ciclu de dezvoltare

Adecvat pentru proiectele in care cerintele sunt bine intelese de la inceput si nu se modifica pe parcursul procesului de dezvoltare. Experienta ultimelor decenii a demonstrat ca modelul este valoros. Este utilizat si in prezent de multe organizatii mari. O variant mbunttit a acestui model este modelul cascad cu revenire(waterfall model with back flow), prezentat n figura de mai jos.

AGILE SOFTWARE DEVELOPMENT n februarie 2001, un grup de programatori care mpreau aceleai probleme legate de procesul greoi de dezvoltare software s-a reunit n Utah, SUA pentru a discuta tehnicile noi numite procese uoare. n urma acestor discuii s-a adoptat termenul agile, ce desemna o noua abordare, presupunnd revizuirea metodologiilor tradiionale de dezvoltare software prin prioritizarea activitilor, concentrarea asupra oamenilor, mediului colaborativ, scopurilor concrete, precum i asupra elaborrii unor aplicaii care sunt cu adevrat utile. Toate aceste idei au fost ncadrate n Agile Manifesto [1], care sta la baza noiunii din industria software cunoscuta sub numele de Tehnici Agile de dezvoltare software. Dezvoltarea Agile folosete feedback-ul pentru efectuarea ntr-o manier colaborativ a unor ajustri periodice ale procesului de producie. Aceasta nseamn s nu amnm procesul de testare a aplicaiei pentru finalul proiectului, s-au s integrm schimbrile din codul aplicaiei doar la sfritul fiecrei luni, sau sa ne oprim din obinerea noilor cerine imediat ce ncepem procesul de producie. Din contra, aceste activiti se vor efectua pe tot ciclul de viaa al proiectului. Cum un proiect software nu poate fi considerat ca i finalizat, att timp ct mai sunt persoane care l folosesc, se impune un feedback continuu de la utilizatori precum i o dezvoltare continua a produsului. Nu e nevoie sa a tepi ase luni ca sai dai seama ca ceva merge prost, care e relativ simplu de reparat, l repari imediat. Ideea de dezvoltare continu este preponderenta in toate metodele agile. Aceasta se aplica la ciclul de producie n sine dar i asimilarea noilor tehnologii, obinerea cerinelor, deployment-ul aplicaiei precum i antrenamentul utilizatorilor. Principiul este valabil pentru toate fazele de dezvoltare ale unui proiect deoarece elaborarea unei aplicaii software reprezint o activitate foarte complex. Orice detaliu substanial amnat va fi implementat mai trziu prost, sau deloc , sau va evolua n ceva foarte dificil de controlat. Este un cadru conceptual pentru proiectele software. Exista mai multe metode de dezvoltare agila, cum sunt cele expuse de Agile Alliance, o organizatie non-profit. Pentru orice proiect software exista o serie de factori de risc care pot periclita finalizarea cu succes a proiectului, cum ar fi: factori de experienta ( conducatorului de proiect, a echipei), factori de planificare, factori tehnologici, factori externi (modificarea cerintelor, modificarea interfetelor externe). Cele mai multe metode de dezvoltare agila incearca sa minimizeze riscul dezvoltand software-ul in intervale scurte de timp, numite timeboxes, constand din 1-4 saptamani. Data de sfarsit a unui timebox nu poate fi modificata. Daca echipa depaseste data, iteratia este anulata si replanificata.

Fiecare iteratie este un proiect software in miniatura si include toate activitatile necesare livrarii mini-incrementului unei noi functionalitati: planificare, analiza cerintelor, proiectare, codificare, testare, documentare. Fiecare noua iteratie trebuie sa livreze un nou produs. La sfarsitul fiecarei iteratii echipa reevalueaza prioritatile proiectului.

Timebox-urile sunt utilizate in ,metodele de dezvoltare agila ca o forma de management al riscului in dezvoltarea unui software. Metodele agile pun in evidenta comunicarea directa intre participantii la elaborarea unei iteratii, in locul documentelor scrise. Acestia lucreaza in aceeasi locatie, intre ei fiind cel putin programatorii si clientii lor (cei care definesc produsul). Echipa poate include testori, proiectanti de interactiune, echipe de documentare tehnica si manageri.
Principala masura a progresului este considerata software-ul functional. Se produce foarte putina do

Cteva dintre principiile enumerate n acest manifest sunt: Satisfacia clientului prin livrarea rapid i continu de soluii software utile. Sunt lansate frecvent versiuni funcionale ale aplicaiei (sptmni mai degrab dect luni) Unitatea de msura a progresului este dat de ctre funcionalitatea aplicaiei. Chiar si schimbrile trzii ale cerinelor aplicaiei sunt binevenite. Colaborarea strns dintre dezvoltatori si clieni, pe baz zilnic. Convorbirile faa n fa sunt cea mai buna modalitate de comunicare. Proiectele sunt construite de ctre indivizi motivai, care merit ncredere. o atenie deosebit asupra arhitecturii aplicaiei i asupra perfecionrii tehnicilor de programare. Simplitatea Echipe dinamice bine organizate. Adaptarea periodica la circumstanele noi. cumentatie, motiv pentru care metodele sunt criticate.

PRACTICI AGILE-ANALIZA

Lucrul n echip Dezvoltarea aplicaiilor nu are loc ntr-o diagram, un mediu de dezvoltare sau ntr-un utilitar de modelare, totul se ntmpl n capul nostru, concomitent cu alte lucruri cum ar fi emoiile, politica companiei ,orgoliul profesional, memoriile . Deoarece acestea mpreuna ne influeneaz direct productivitatea noastr, dispoziia i atitudinea adecvata pot face diferena. Este important

sa atragem atenia asupra acestor lucruri efemere nu doar personal ci i n cadrul echipei. O atitudine profesionala se concentreaz asupra rezultatelor pozitive din cadrul proiectului, precum i asupra creterii personale si a echipei. Metodele agile dau roade numai in cazul in care se adopt o atitudine profesional n ce privete proiectul, jobul, cariera . Cu o atitudine adecvat se pot obine rezultate maxime, in caz contrar aceste practici nu vor mbunti substanial procesul de dezvoltare.

nelegerea metodologiei

Pentru a efectua unele schimbri ale codului, mai nti depunem un efort necesar pentru nelegerea funcionalitii acestuia, acelai principiu se aplica i la nivel de echip. Este important sa nelegem cum funcioneaz metodologia noua, de ce este necesar schimbarea metodologiei i cum s-a ajuns n acest punct. Trecerea spre schimbarea efectiva a metodologiei se poate face doar avnd aceast imagine clara. Critica

Se ntlnesc des situaiile n care discuiile asupra arhitecturii aplicaiei deriva n discuii contradictorii ncrcate emoional. Se pot lua decizii pripite bazndu-se pe autoritatea persoanei care propune o idee i nu pe baza fezabilitii acesteia. O critica constructiva impune prevenirea acestor situaii prin remarci profesionale i nu personale. Doza de politee omniprezenta in discuiile echipei are rolul de a pstra atenia echipei asupra ideii in cauza evitnd astfel problemele personale. Cu toi suntem capabili sa livram nite idei excelente i inovative n acelai timp, fiecare din noi poate grei oricnd. Exista un risc substanial n cazul n care idea propusa este ridiculizat , sau se pierde din imaginea profesionala prin ntrebri relative simple, ca angajatul sa nu mai fie dispus sa propun ceva, vreodat. Aceasta poate fi o problema adevrat, deoarece elaborarea unei aplicaii reuite adeseori necesita ingeniozitatea si creativitatea ntregii echipe. Proiectul are succes atunci cnd angajaii cu diferite idei i obligaii mpart aceste idei i le unifica ntr-o contribuie care nu va fi niciodat egalata de ctre efortul individual. Concentrarea asupra rezultatului

ntr-o echipa agile lucrurile ar trebui s fie n felul urmtor: n momentul cnd un coleg i cere ajutorul sau se plnge de o problema, nu ncerci sa generezi noi probleme ci ii concentrezi efortul asupra gsirii soluiei. Motivarea e clara rezultatul final e cel care conteaz i nu meritul

,vina sau concurenta intelectuala. Aceasta atitudine da de neles ca vrei sa faci parte din soluia problemei, i nu invers. n timp atitudinea colegilor se va schimba, acestea vor apela la tine cnd vor vrea cu adevrat sa rezolve problemele, iar pentru plngeri se vor merge n alta parte. n cazul n care primeti un rspuns ntr-o maniera mai puin profesionala, ncearc sa fii mai explicit n ceea ce doreti sa realizezi, accentueaz ca scopul tu este rezolvarea problemei i nu incriminarea sau concurenta. nvinuirea celorlali nu rezolva problemele, in loc sa ne pierdem timpul cutnd vinovaii, ar trebui sa ne concentram eforturile la gsirea unei soluii. Pana la urma rezultatul este cel care face diferena.

Adaptare Sa tim cnd s dezvm Unul din principiile agile presupune adaptarea la schimbarea continua a mediului de dezvoltare. innd cont ca tehnologiile se schimba i evolueaz constant, nu se merita sa ne limitam la utilizarea acelorai tehnologii i utilitare cu care suntem deja familiarizai. Pe lng nevoia de nvare continua, trebuie sa ne obligam sa uitam cteva din ele. Cu ct tehnologia avanseaz mai tare, lucrurile care erau cele mai importante devin prioriti secundare. Pe lng faptul ca nu ne mai sunt de folos acestea pot afecta grav productivitatea. Cnd nv am o tehnologie noua trebuie sa ne ntrebam dac nu proiectam prea multe din atitudinile nvechite n noua abordare. nvarea programrii ntr-un limbaj orientat pe obiecte este diferita fundamental de nvarea programrii ntr-un limbaj procedural. Se pot distinge uor secvenele de cod n care cineva ncearc sa scrie cod C n Java. Cnd se ntmpla acest lucru se pierde avantajul obinut prin trecerea la noua tehnologie. Evitarea soluiilor de moment

Adeseori ,sub presiunea timpului, facem schimbri n cod fr sa-i nelegem n totalitate funcionalitatea, nefiind n stare sa apreciem consecinele posibile. Este uor sa cazi prada unei asemenea tentaii - soluia de moment, care pare sa funcioneaz perfect la prima vedere. Utilizarea acestor scurtturi pentru o perioada ndelungata de timp, e ca i cum ai decl ana mecanismul unei bombe cu reacie ntrziata. Imediat ce acceptam acest gen de soluie scade claritatea codului. Odat cu acumularea lor codul devine opac i greu de ntreinut i la fel de greu de neles. Respectarea principiile agile devine mult mai dificila cu acest gen de bagaj n spate. Refactoring

Deseori n timp ce scriem cod, cutam mici modalitatea de mbuntire a acestuia. Se poate mbunti lizibilitatea, sau se descoper ca acel cod devine mai uor de testat dac l mprim

n mai multe metode. Majoritatea acestora sunt mbuntiri minore. Abordarea agile presupune sa facem ceva mic i util mai degrab,dect sa amnam totul pentru o singura sesiune de rearanjare a codului. Dezvoltarea incremental este mai potrivit dect dezvoltarea pentru o perioada extins de timp, pentru scrierea unui cod curat, simplu i care este uor de ntreinut. Putem sa mbuntim mereu codul prin utilizarea diverselor abloane de proiectare, principii sau tehnologii noi doar dac avem un motiv ntemeiat pentru utilizarea acestora. O bucata de program poate fi mereu schimbata, pana la un anumit punct cnd nu se mai obin beneficii reale din mbuntirile efectuate. E bine sa evitam atingerea acestui punct, i sa mergem mai departe atunci cnd e cazul.

Utilizeaz nainte s construieti

Folosind tehnica Test Driven Development (TDD), se scrie codul numai dup ce sunt scrise unitile de testare automata corespunztoare. De obicei testarea eueaz deoarece codul testat nc nu exist sau nc nu conine logica c ar permite trecerea testului. Atunci cnd scriem testele, privim codul din perspectiva utilizatorului i nu a celui care implementeaz funcionalitatea. Acest factor poate face diferena deoarece permite elaborarea unor interfee mult mai utile i consistente, acestea fiind utilizate de programator n primul rnd. TDD trebuie privit ca un accesoriu implicit n procesul de proiectare a aplicaiei, ducnd la un model mult mai simplu i pragmatic. Unitile de testare n parte nu garanteaz o arhitectura reuita, dar ajut la crearea acesteia. Decizie Dezvoltare incremental

Metodele agile recomand dezvoltarea incremental i iterativ. Prin dezvoltarea iterativ nelegem adugarea funcionalitilor aplicaiei n grupuri mici ,ntr-un interval de timp stabilit. Fiecare rund de mbuntiri se bazeaz pe funcionalitile precedente adugnd altele noi mrind astfel valoarea aplicaiei. O iteraie reprezint un ciclu de dezvoltare ce poate dura intre una si patru sptmni. Echipa i propune un scop realizabil prin care creeaz o bucata mic dar completa a aplicaiei. Complet nseamn testat,documentat, iar codul integrat in produs. La sfritul fiecrei iteraii se stabilete un nou milestone, aceasta nu nseamn neaprat ca produsul poate fi cu adevrat in acel moment. Dup ce codul construit iteraie cu iteraie este gata sa fie folosit de ali oameni are loc o incrementare, release. De regul un release este alctuit din mai multe iteraii, putnd fi si limitat doar la un grup specializat de testare din interiorul companiei, sau la un grup de beta testeri. Un proiect poate presupune unul sau mai multe release-uri. Sfritul unui proiect de obicei marcheaz ncetarea finanrii sau desfiinarea echipei.

Ideea abordrii unui proiect mare pas cu pas este caracteristica stilului agile. Paii mari cresc riscurile, paii mici ajuta la pstrarea echilibrului. Demo

Clienii nu vor nceta sa caute diferite modaliti de mbuntire a aplicaiei, chiar si dup ce specificaiile iniiale au fost livrate, iar aplicaia intrat n producie. Dac se neglijeaz acest aspect, i se implementeaz aplicaia dup cerinele iniiale, nu vom fi nici pe aproape de punctul n care clienii vor fi mulumii de aplicaie n momentul livrrii acesteia cerinele fiind deja schimbate. Astfel suntem expui la unul dintre cele mai mari riscuri din domeniul dezvoltrii software: am produs o aplicaie pe care au vrut-o clienii , dar care nu corespunde cu cerinele lor actuale. Este destul de uor de observat ca cu ct mai mult amnam prezentarea rezultatelor la clieni cu att va fi mai mare discrepanta dintre cerine, i cu att va fi mai greu sa remodelam aplicaia. Se recomanda organizarea unei ntlniri cu clientul (Demo) la intervale constante de timp stabilite anterior, de exemplu sfritul unei iteraii, ca sa demonstram noile mbuntiri si funcionalitile adugate. Prin consultarea periodica cu clienii, toi nu vor avea dect de ctigat. Clienii sunt contieni de progresul pe care l nregistreaz produsul. Ca rezultat ei sunt capabili sa reformuleze cerinele prin oferirea feedback-ului echipei de dezvoltare. Ei sunt capabili sa ne ghideze bazndu-se pe ateptrile i cunotinele lor in evoluie despre proiect, astfel putem scrie cod potrivit pentru necesitile clienilor. Clienii pot prioritiza cerinele n funcie de progresul efectuat, timpul rmas i bugetul disponibil. Trusa de instrumente Agile Majoritatea proiectelor agile au n comun un set de utilitare de baz. Printre acestea se numra: Wiki. O pagina Wiki (scurttura de la WikiWikiWeb) este o pagina web ce permite utilizatorilor sa editeze coninut i sa creeze legturi ctre alte pagini prin intermediul unui simplu browser web. Wiki reprezint o modalitate pentru ncurajarea colaborrii, deoarece fiecare din echip poate rearanja coninutul dinamic n funcie de necesiti. Version control. Sistemul de control al versiunilor are grija de toate componentele care intra in structura produsului: cod sursa, documentaie, imagini, scripturi etc. Acesta ne permit sa avem la toate versiunile prin care a trece produsul, avnd astfel o copie de rezerva pentru orice eventualitate.

Unit testing. Un proiect mare nu poate fi conceput fr unitile de testare automata, care garanteaz stabilitatea produsului cnd trecem la o noua versiune. Rularea lor este obligatorie nainte de salvarea (submit) schimbrilor in codul de baza.

Build automation. Build-ul(elaborarea unei versiuni a aplicaiei) de pe calculatorul local, la fel ca i build-ul principal destinat ntregii echipe trebuie sa fie in totalitate automat i reproductibil. Rularea permanent a build-urilor este cunoscut sub numele de integrare continua. mparte Cod partajat Orice aplicaie care nu este banal necesit un efort colaborativ pentru dezvoltarea sa. Pornind de la aceasta nu exista nici un motiv pentru care cineva sa i asume proprietatea asupra unei buci de cod, modul. Oricine care este capabil sa neleag acel cod are dreptul sa-l i modifice n funcie de cerine. Riscurile cresc atunci cnd o bucata de cod este deinuta doar de un singur programator. Rezolvarea problemelor si modificarea aplicaiei n conformitate cu ateptrile utilizatorilor conteaz mai mult dect deciderea a cui idee a fost mai strlucita, i cine nu a fost la fel de bun. Cnd asupra unui fragment de cod lucreaz mai muli oameni acesta este mereu rearanjat, verificat i testat. Dac este nevoie de o modificare oricare dintre programatori poate sa o fac. Proiectarea orarului devine mult mai facila deoarece fiecare programator poate lucra cu mai multe buci de cod. Se va constata ca per total cunotinele oamenilor se mbuntesc cnd acestea lucreaz in rotaii, dndu-le posibilitatea sa lucreze cu diferite pri ale aplicaiei. Investete n echipa ta

Fiecare membru al echipei are capaciti, experien si ndemnri diferite, avnd att puncte tari ct i puncte slabe. Un astfel de amestec de talente i priceperi creeaz un mediu perfect pent ru nvare. ntr-o echip nu e destul ca doar un programator sa fie foarte bun. Dac ceilali membrii sunt mai slabi echipa nu mai este la fel efectiv . O echip valoroas este una educat. Trebuie gsite domeniile n care unul dintre membrii echipei este mai avansat dect ceilali, care s-i ajute i pe ceilali sa progreseze. n plus se pot discuta cum lucrurile noi nvate pot fi aplicate n cadrul aplicaiei. Se recomanda stabilirea unei ntlniri sptmnale (chit-chat)cu echipa, intru-un cadru familiar, la care un membru desemnat poate expune o idee noua, noi concepte sau sa prezinte un nou utilitar, sau se poate discuta despre orice altceva ce intereseaz echipa.

COMPARATIE CU ALTE METODE Considerand ca metodele de dezvoltare pot fi plasate pe o scara continua de la cele adaptive la cele predictice, metodele agile se situeaza la extremitatea celor adaptive. <--Agile--> <--Iterative/Incrementale--> <--Cascada--> <-------------|------------------------------------|----------------|-> Adaptive Predictive Metodele adaptive sunt focalizate pe adaptarea rapida la schimbari. Nu se au in vedere cu exactitate ce se va intampla in viitor. O echipa adaptiva poate raporta exact ce sarcini vor fi realizate saptamana urmatoare si ce este planificat pentru luna urmatoare. Metodele predictive sunt focalizate pe planificarea in detaliu a activitatilor, in timp. O echipa predictiva poate raporta exact ce este planificat pentru intreagul proces de dezvoltare. Echipa predictiva are dificultati in schimbarea directiei. Planul este optimizat pentru desinatia originala iar schimbarea directiei poate necesita renuntarea la rezultatele curente si replanificarea activitatilor. Numai schimbarile considerate importante sunt luate in considerare. In comparatie cu metodele incrementale: asemanare- creaza produse livrabil in perioade de timp scurte deosebiri: perioadele de timp sunt masurate in saptamani si nu luni perioadele de timp sunt stricte (time-box-uri) in metodele incrementale procesul este ghidat de analiza si masurare a caracteristicilor produsului. Ele sunt suportul pentru determinarea eficientei procesului si a calitatii produsului

In comparatie cu modelul cascada Dezvoltarea agila are foarte putine in comun cu dezvoltarea cascada. Modelul cascada are si in prezent o utilizare larga.. Modelul cascada este cel mai predictiv, activitatile sunt pre-planificate intr-o secventa. Progresul este masurat prin produse intermediare (specificatii, doc de proiectare, planuri de testare, revizii ale codului, etc). Efortul de integrare si testare poate fi foarte mare (cateva luni cativa anui!), fiind una dintre cauzele de esec ale unei dezvoltari cascada. Prin dezv agila se produc produse executabile intervale de cateva saptamani sau luni. Se pune accentul pe obtinerea de executabile cat mai repede apoi imbunatatirea lor continua!

Extreme Programming, este o metoda de dezvoltare agila care a crescut popularitatea metodelor agile. Extreme Programming (XP) este un model incremental bazat pe iteratii scurte, testare intensiva si simplitate. Este adecvata pentru echipe mici si proiecte caracterizate prin schimbari rapide ale cerintelor. Dezvoltarea agil de programe este o familie de metodologii de project management n ingineria software, bazat pe dezvoltarea incremental i care mbrieaz i promoveaz schimbrile ce evolueaz de-a lungul ntregului ciclu de via al unui proiect. Aceste metodologii se caracterizeaz prin divizarea problemei n subprobleme mici i planificarea lor pe durate scurte. Se evit planificarea n detaliu pe termen lung, deoarece inerent n dezvoltarea de software apar ntrzieri frecvente din cauza schimbrilor i detalierii cerinelor clientului. Scopul principal este ca, la terminarea fiecrui ciclu de dezvoltare (denumit iteraie, i a crui durat este de obicei ordinul ctorva sptmni) s existe o versiune ct de ct funcional (dei incomplet) a software-ului dezvoltat (cu numr minim de buguri). O alt caracteristic important este comunicarea frecvent ntre membrii echipei, care, n multe cazuri, se ntlnesc ntr-o scurt edin zilnic, denumit stand-up sau scrum (pronunat /scrm/) n care fiecare prezint pe scurt progresul su n ultima zi de lucru i problemele cu care s-a confruntat. Acestora li se altur i un reprezentant al clientului, care trebuie s fie informat de aspectele dezvoltrii, pentru a ti ce modificri este realist s cear i ct de mult ar putea costa ele. Astfel, toat lumea are cunotine despre fiecare aspect al dezvoltrii aplicaiei i poate prelua munca altuia sau ajuta pe altcineva. n prezent, majoritatea dezvoltatorilor de produse software opteaz pentru metodologia Agile n defavoarea abordrilor traditionale. La baza acesteia se afl satisfactia clientului, livrarea rapid si continu de rezultate, simplificarea integrrii modificrilor aduse cerintelor pe parcursul dezvoltrii si permanenta comunicare ntre dezvoltatori si clienti. Acestea au condus la obtinerea unei metodologii simple, flexibile si eficiente Dezavantajele metodelor clasice de management a proiectelor Forte 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 Solutia este Agile Software Development

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.

TEHNICI ALE METODOLOGIEI AGILE Metodologia Agile exista in mai multe variante: XP(eXtreme Programming), SCRUM,DSDM, Crystal, Feature Driven Development, Lean Software Development. Toate aceste variante folosesc principiul de baza ale filozofiei Agile, dar o implementeaza in moduri diferite. Tehnica sugerata este SCRUM. Aceasta nu este un acronym, este doar un process wrapper, general si scalabil, gandit sa resolve unele din cele mai des intalnite problem in dezvoltarea de proiecte software,cum ar fi : haos datorita schimbarii cerintelor-cerintele reale sau percepute ale unui proiect se schimba dramatic din momentul in care produsul este in faza de design pana la faza de lansare.In mai toate metodologiile de dezvoltare , analiza este facuta in partea de inceput a proiectului si nici o schimbare nu mai e permisa pana spre final.Estimari nerealiste de timp , cost si calitate a produselor-managerul de proiect si dezvoltarii tind sa subestimeze cat timp si resurse sunt necesare pentru un proiect , sic ate functionalitati pot fi livrate in aceste constrangeri.Acestea nu pot fi niciodata prevazute 100 % in faza de inceput a ciclului de dezvoltare .Dezvoltatorii trebuie sa minta cand se discuta progresul proiectului-cand managementul subestimeaza timpul si costul necesar atingerii unui anumit nivel de calitate , dezvoltatorii fie vor altera realitatea referitoare la progresul dezvoltarii produsului, fie vor fi nevoiti sa faca fata indignarii managerului de proiect. Valorile SCRUM sunt derivate din cele ale metodologiei AGILE de software development: Indivizii si interactiunea primeaza procesele si instrumentelor de dezvoltare-desi acestea din urma sunt de folos, nu vor adduce nici un plus in progresul dezvoltarii daca echipa nu invata sa comunice sis a colaboreze intr-o maniera constructiva . Software-ul functional livrat primeaza unei documentatii stufoase-documentarea progresului este importanta , dar este mult mai important ca rezultatul final sa functionez conform nevoilor clientului.Colaborarea cu clientul primeaza negocierii de contracte-ideea de baza este ca nu trebuie sa se urmareasca contractarea unui proiect pentru a primi bani, ci pentru a rezolva problema ridicata de client.Raspunde schimbarilor conform planului-daca cerintele se schimba si planul de proiect si design-ul trebuie actualizate.Metodologia de Management a Proiectelor Software SCRUM se bazeaza pe SPRINT-uri.Asa cum un alergator de marathon incearca sa obtina un ritm constant pentru a ajunge linia de finish,echipele SCRUM trebuie sa dezvolte produse cu o anumita viteza pentru a reusi livrarea in timpul alocat proiectului. Un SPRINT are o data de start si una de incheiere.Sunt evenimente fixate in timp,in care nici o modificare nu este permisa.Termiare unui SPRINT poate fi considerata milestone pentru proiect,deoarece livreaza rezultatele muncii depuse pe durata,pentru a putea usura munca de masurare a progresului proiectului.Acestea ar trebui sa nu fie mai lungi de 3 saptamani ,nici mai scurte de o saptamana.Dimensiunea unui sprint variaza de la proiect la proiect,in functie de numarul de pachete de lucru incluse.

Pentru a defini sprinturile se imparte timpul total de executie al proiectului in ferestre egale folosind regula de mai sus si pastrand in atentie toate pachetele de lucru definite in planul de dezvoltare.De exemplu,pentru o versiune de aplicatie care trebuie livrata in 3 luni,se recomanda 10 sprint-uri (de 7 zile lucratoare) si unul final(ultimele 5 zile ) pentru a pregati versiunea de release si documentatia aferenta.Project Managerul ar trebui sa pastreze ultimul sprint atat de scurt cat sa se simta comfortabil in a-si rezolva sarcinile legate de inchiderea proiectului,si este si ultima sansa de a asigura un release bug-free,documentat,etc.In aceasta ultima etapa,in cazul in care mai exista problem,doar cele majore se mai pot rezolva. Primul sprint ar tebui intotdeauna consacrat etapei de analiza.In aceasta faza SCRUM Masteul si Product Owner-ul ar trebui sa se intalneasca sa discute despre ce trebuie executat,care sunt prioritatile si ce resurse se pot aloca.Principalul scop este livrarea unui Project Development Plan coherent, pe care dezvoltatorii sa-l poata urmari. Numarul de pachete de lucru sau continutul acestora nu se mai modifica odata ce un SPRINT a fost demarat.In cazul in care se descopera problem sau apar cereri de schimbare pe pachetele existente,acestea vor fi incluse in planul de dezvoltare pentru SPRINT-urile urmatoare,astfel incat sa nu existe interferente in planul current de lucru. 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 si solutii: 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.

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? 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;

n prezent, majoritatea dezvoltatorilor de produse software opteaz pentru metodologia Agile n defavoarea abordrilor traditionale. La baza acesteia se afl satisfactia clientului, livrarea rapid si continu de rezultate, simplificarea integrrii modificrilor aduse cerintelor pe parcursul dezvoltrii si permanenta comunicare ntre dezvoltatori si clienti. Acestea au condus la obtinerea unei metodologii simple, flexibile si eficiente. Popularitatea metodologiei Agile La sporirea aplicabilittii si eficientei acesteia au contribuit n ultimii ani o serie de factori, dintre care poate cel mai important este disponibilitatea mai mare de unelte si solutii software specializate n gestiunea dezvoltrii, testrii, publicrii si livrrii proiectelor. Posibilitatea de a face estimri si predictii asupra evolutiei proiectului are un rol semnificativ nc de la aparitia principiilor Agile stipulate n manifestul Agile (februarie, 2001). Astfel, metodele Agile pot fi privite ca fiind rezultatul maturizrii, standardizrii si automatizrii managementului de proiecte n general si designului arhitecturilor software n particular. Fundamentul l constituie experienta dezvoltatorilor si cunoasterea obtinut prin explorarea ampl si documentat a unei game variate de proiecte n trecut. Acesta este probabil motivul pentru care metodologia Agile nu s-a dovedit productiv pentru sisteme complexe, unde evolutia proiectului este influentat de multi factori. De aceea se prefer utilizarea ei predominant pentru proiecte de dimensiuni mici. Design incremental Un proiect dezvoltat cu metode Agile se va desfsura n iteratii de scurt durat, de aproximativ dou sptmni, spre deosebire de perioadele lungi de timp tipice predecesorilor acesteia. Numite si timeboxes, aceste iteratii cuprind toate fazelele obisnuite de dezvoltare a proiectelor: planificarea, dezvoltarea, testarea. Decizia privind componentele ce vor fi realizate n iteratia initial se face prin alegerea acelor caracteristici ale produsului ce sunt (absolut) necesare pentru a putea livra un rezultat. n iteratiile urmtoare, dezvoltarea se face n mod incremental, adugnd componente, care desi nu justific neaprat o versiune nou a produsului, reprezint o solutie unitar si functional. n cadrul unei iteratii, planificarea este minimal si pe termen scurt. Dezvolatorii agile nu se bazeaz pe documentatii ample ale cerintelor clientului si arhitecturii proiectului, ci pe predictii si sabloane care s-au dovedit a fi de ncredere. Testarea se ncepe devreme, aceasta influentnd ntr-o mare msur dezvoltarea. Acest stil de lucru are ca scop mentinerea unei echipe motivate prin reducerea timpului ntre planificarea proiectului si obtinerea de rezultate. n acelasi timp, sunt minimizasi factorii de risc si rata defectelor din produs. Desi dezvoltarea n iteratii a proiectului nu poate elimina esecurile, acestea sunt identificate rapid, putnd fi luate n considerare mai devreme.

Colaborare si comunicare Cu sigurant cea mai reprezentativ caracteristic a dezvoltrii agile este accentul pus pe comunicarea din cadrul echipei. Organizarea echipei se face din interiorul ei si nu trebuie s corespund unei ierarhii. Colaborarea nu se face doar ntre membrii cu aceeasi specialitate, ci ntre dezvoltatori, client, manageri si testeri deopotriv. Aceast prezent a clientului sau a unui reprezentant al acestuia n echip are consecinte benefice asupra dezvoltrii, deoarece cunoasterea sa si colaborarea cu acesta permite o mai bun prevedere si integrare a modificrilor aduse pe parcurs cerintelor initiale. Satisfactia clientului este prioritatea oricrei echipe agile. Cu evidente consecinte favorabile din punct de vedere comercial pentru client, dezvoltatorii iau n considerare feedback-ul primit de la utilizatori. Spre deosebire de situatiile n care produsul este livrat complet la final, n acest caz, cum dezvoltarea este incremental, ea poate fi puternic influentat de utilizatori. Adaptabilitate Agile nu se potriveste tuturora. Foarte multi dezvoltatori opun rezistent la abordri noi. Unei echipe nu i se poate impune s fie agile, ci trebuie antrenat pentru a deveni agile. Absenta unor specificatii care s trateze exhaustiv subiectul si care s ofere rspunsuri concrete dezvoltatorilor poate crea confuzie. Disciplinele si dogmele unei organizatii, cerintele guvernamentale, complexitatea aplicatiei pot toate s mpiedice utilizarea metodologiei Agile si reprezint unele dintre cele mai mari probleme ntmpinate de dezvoltatori. Ceea ce nu trebuie nteles gresit este c metodologia Agile reprezint un set de principii care pot fi aplicate n variate moduri. Agile ofer un cadru n care o echip nu este obligat s adopte o metod Agile pur (Scrum, XP), ci s mbine principiile Agile cu principiile organizatiei, iar rezultatul s reflecte factorii de mediu existenti. Un dezvoltator agile nu actioneaz pornind de la indicatii clare, ci de la principii. Implicarea clientului, alaturi de accentul pus pe livrarea frecventa a deliverable-urilor, asigura feedback-uri dese si sincronizarea perspectivelor partilor implicate. De asemenea, efectuarea frecventa de teste asigura informarea membrilor ce se ocupa de managementul proiectului. In metodologia XP, a fost introdus termenul de pair programming (programare in perechi). In paradigma Agile Testing, se poate vorbi de pair testing[A2] . Desi prezinta nenumarate avantaje, in special cand vorbim de proiecte la care lucreaza un numar mic de dezvoltatori si de echipe de dezvoltare, metodologiile Agile nu reprezinta singura cale catre programarea de software de calitate. Cei implicati in proiect pot utiliza diverse procedee, metodologii si tehnici pentru a eficientiza procesul. Acestea trebuiesc adaptate situatiei, astfel incat randamentul sa fie maxim

Beneficiile Agile: Satisfacerea nevolilor de business ale clientului prin insusirea unei capacitati de reactie rapida la cereri in coditii de calitate, ramanand in acelasi timp competitive din punct de vedere costuri Rezolvarea problemelor istorice din dezvoltarea de software Beneficiile Scrum: Ofera un cadru simplu de proces pentru dezvoltarea si mentenanta produselor complexe si, in general, pentru rezolvarea problemelor complexe adaptive. Ofera o solutie pentru problemele aparute in abordarea Waterfall, prin Praticarea artei posibilului, rezultat al unui control empiric si iterative al procesului METODOLOGIA AGILE - SCRUM

Metodele de dezvoltare Agile, sau dezvoltare adaptiv, se adreseaz persoanelor care urmresc atingerea satisfaciei clientului prin realizarea unei aplicaii software care s fie pe deplin funcional de-a lungul ntregului proces de fabricaie.

PRINCIPIU DE FUNCIONARE I FAZE CONSTITUTIVE Principiul metodologiei SCRUM const n dezvoltarea incremental a unei aplicaii software, implicnd totodat pstrarea unei liste transparente cu cererile de upgradare sau de corectare care trebuie implementate (backlog). Datorit livrrilor frecvente, care de regul au loc o dat la patru sptmni, clientul primete de fiecare dat o aplicaie care conine un numr tot mai mare de funcionaliti i care se afl n perfect stare de funcionare. Astfel, metoda se bazeaz pe o dezvoltare iterativ cu frecven regulat, cuprins ntre dou i patru sptmni. Prin urmare, upgradrile pot fi integrate cu mai mult uurin atunci cnd se utilizeaz ciclul n V. Aceast metod necesit patru tipuri de edine:

edinele zilnice: echipa se reunete n fiecare zi i petrece circa 15 minute, n general 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 n care fiecare membru vorbete n nume propriu, se organizeaz un vot de ncredere pentru a decide ce mbuntiri trebuie adese. Avantajul acestei metode const n reducerea documentaiei la minimul necesar n vederea sporirii productivitii. Scopul este acela de a ntocmi doar documentaia strict necesar care permite salvarea istoricului deciziilor luate n cadrul proiectului i de a putea efectua cu uurin intervenii pe aplicaia software dup intrarea acesteia n faza de mentenan.

ORGANIZARE Metodologia SCRUM implic intervenia a trei protagoniti:

Product owner: n majoritatea proiectelor, responsabilul de produs (product owner) este coordonatorul echipei clientului. El este cel care definete i stabilete funcionalitile prioritare i alege data i coninutul fiecrui sprint pe baza valorilor (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.

AVANTAJE Scrum se difereniaz de alte metode de dezvoltare prin avantajele sale care fac ca acest procedeu s fie un rspuns pragmatic la exigenele cu care se confrunt n prezent responsabilii de produs:

Metod iterativ i incremental: aceasta permite evitarea efectului de tunel", adic faptul de a obine rezultatul abia la livrarea final i de a nu ntrezri nimic sau aproape nimic concret pe durata ntregii faze de dezvoltare, situaie frecvent ntlnit n cadrul proiectelor bazate pe ciclul n V.

Adaptabilitate maxim pentru realizarea de produse i aplicaii: compunerea secvenial a coninutului sprinturilor 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 deci 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 n mod facil i poate schimba informaii despre impedimentele ntlnite n scopul eliminrii ct mai rapide a acestora. Ameliorarea cooperrii: comunicarea zilnic dintre client i echipa Pentalog face posibil o colaborare mai strns ntre cele dou pri. Creterea productivitii: prin eliminarea anumitor exigene" specifice metodelor clasice, precum documentaia sau formalizarea excesiv, SCRUM faciliteaz creterea productivitii echipei. n plus, fiecare modul poate fi supus evalurii, ceea ce permite efectuarea de estimri n cifre. Astfel, fiecare membru i poate evalua performana n raport cu productivitatea medie a echipei. RISCURI I SOLUII Metodologia SCRUM nu reprezint un rspuns miraculos la toate problemele specifice dezvoltrii de aplicaii software. Trebuie acordat atenie riscurilor enumerate mai jos, care ofer totui un rspuns sistematic bazat pe extrapolarea metodei:

Dimensiunea echipei: fiind de regul limitat la 7 sau 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, iar bazele nsei ale metodelor sunt afectate. Soluia const n realizarea unui Scrum of Scrums". Aceasta presupune 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. n ceea ce privete validarea livrrilor, aceste contradicii pot duce la ncetinirea procesului de validare. Pentru a remedia aceast problem, trebuie s se utilizeze n mod obligatoriu o aplicaie de gestiune a cererilor, care la Pentalog este inclus n oferta standard. Calitatea produsului realizat: cu ct numrul echipelor este mai mare, cu att calitatea este mai greu de controlat. Aceast regul este cu att mai valabil cu ct proiectul este mprit pe mai multe centre. Riscurile sunt legate n special de calitatea codului i de numrul defectelor sesizate n momentul integrrii. Pentru aceasta, este important s existe o politic de calitate riguroas i un plan de calitate a proiectului care s ofere o definiie clar a regulilor proiectului. Verificarea frecvent a codului i introducerea unor indicatori pentru msurarea performanei programatorilor permit reducerea la minimum a acestui risc.

CUI SE ADRESEAZ ACEST TIP DE ORGANIZARE? Acest tip de organizare poate fi utilizat n majoritatea proiectelor. Cu toate acestea, metodologia Agile SCRUM este destinat n special proiectelor care nu au un cadru bine conturat i pentru care clientul solicit un sistem de monitorizare. Cu alte cuvinte, acesta dorete o implicare din partea furnizorului, lucru foarte important ntr-un ciclu de dezvoltare. Disponibilitatea clientului este un criteriu determinant n alegerea acestei metode de dezvoltare. Noi estimm un ETP (echivalent norm ntreag) aproape de 1 n ceea ce privete timpul necesar product owner-ului s rspund exigenelor acestei metode: transferarea anumitor aciuni ale efului de proiect ctre product owner printr-o metod clasic (distana dintre echip i necesiti).

CONCLUZIE

Indiferent de poziia ocupata in cadrul unui proiect software, fiecare poate aplica aceste practici personal, sau mpreun cu toata echipa ncepnd sa produc aplicaii stabile uor de realizat ntrun ritm dinamic. Ron Jeffreys : Nu iei nici un premiu dac eti agile, adevratul beneficiu este alegerea corecta a combinaiei de metodologii care te vor duce la succes. Trebuie sa ne concentram asupra rezultatelor, in loc sa urmam orbete metodologiile fie ele i agile.

BIBLIOGRAFIE

www.wikipedia.ro http://www.cristianolaru.com http://www.slideshare.net http://www.bobyte.ro http://www.pentalog.ro