- 5 - Introducere Introducere în Agile Waterfall (metodologia în cascadă sau tradiţională) Prototipul...

Transcription

1 - 5 - Cuprins Introducere Introducere în Agile Waterfall (metodologia în cascadă sau tradiţională) Prototipul Modelul în spirală Agile Agile vs Waterfall pro şi contra Ce alegem Metode încadrate în categoria Agile Scrum Roluri în Scrum Extreme programming (XP) Termeni folosiţi în Extreme Programming Avantaje şi dezavantaje Test Driven Development a. Adaugarea unui nou test b. Rularea testelor scrise anterior c. Implementarea funcţionalităţii d. Rularea testelor scrise la primul pas e. Refactorizarea codului Continuos Integration a. Integrarea trebuie făcută măcar zilnic b. Trebuie să existe un singur server de control al versiunilor

2 - 6 - c. Build-ul să fie testabil automat d. Existenţa unei maşini de integrare e. Testele să se facă pe o copie identică a maşinilor de producţie f. Deploymentul automat Kanban Estimarea în Agile Estimarea pe zile Estimarea folosind puncte Aplicaţia Scrum Planner pentru managementul estimărilor Problema Soluţia propusă Aplicaţia Scrum Planner Termeni folosiţi Skills calităţile dezvoltatorului software Productivity index (indexul de productivitate) Estimated Hours şi Real Hours Auto-atribuirea Tehnologii folosite Dezvoltări viitoare Concluzie Bibliografie

3 - 7 - Introducere Această lucrare îşi propune să sintetizeze metodologiile de dezvoltare software încadrate în categoria Agile, care se bucură în ziua de astăzi de o creştere continuă în popularitate în rândul companiilor de pe piaţa IT. Lucrarea descrie punctele comune şi punctele diferite ale fiecărei metodologii în parte, precum şi recomandări pro şi contra folosirii lor în diverse proiecte, în procesul de dezvoltare software. Prin lucrare nu se doreşte incurajarea unui anumit tip de metodologie în detrimentul celorlalte, ci sublinierea faptului că ele pot fi folosite împreună pentru a obţine cele mai bune rezultate în procesul de dezvoltare. Lucrarea incurajează cunoaşterea acestor metodologii şi recomandă alegerea uneiasau mai multe în funcţie de proiectul care va fi dezvoltat, luând în calcul recomandările prezentate. În lucrare se propune un nou mod de abordare a estimărilor în echipele Agile, contrar frameworkurilor şi aplicaţiilor de estimare care există pe piaţă în ziua de azi, respectiv estimarea relativă la resursele folosite, şi anume programatorii. Deoarece fiecare programator, în funcţie de experienţă şi alti factori, va rezolva anumite taskuri într-un interval diferit de timp faţă de un alt programator, cu un alt nivel de experienţă şi cunoaţtere a tehnologiilor, aplicaţia propusă, Scrum Planner, oferă o imagine diferită estimărilor, în funcţie de programatorul care va rezolva taskul. De asemenea propune un algoritm de atribuire automată a taskurilor, astfel ca întârzierile intr-un proiect să fie minimizate. Ideea poate fi extinsă şi la altfel de echipe IT, pretându-se foarte bine şi echipelor de testare, care lucrează în acelaşi timp cu echipele de dezvoltare, deoarece aceleaşi diferenţe între un junior şi senior, de exemplu, vor exista şi în echipele de testare.

4 Introducere în Agile Una dintre primele probleme care apar la inceputurile unui nou proiect software este discuţia despre ce metodologie de dezvoltare se va folosi. Acest aspect este o decizie suficient de importantă si va genera discuţii si dispute aprinse, întrucât este foarte dificil sau chiar imposibil sa fie schimbată în decursul proiectului, fără a afecta planificarea iniţială. Astfel, se remarcă mai multe categorii mari de metodologii de dezvoltare software: a. Waterfall b. Prototipul c. În spirală d. Agile Dintre acestea, cele mai folosite în ziua de astăzi ar fi Waterfall şi Agile, cu tendinţa metodologiei Agile de a câştiga teren faţă de clasicul Waterfall, celelalte reprezentând o pondere mai mică în ingineria software, fiind în schimb folosite în alte domenii. 1.1 Waterfall (metodologia în cascadă sau tradiţională) Se remarcă printr-un proces iterativ linear, cu un număr fixat de etape, în care startul unei etape are loc numai dupa terminarea etapei anterioare si nici una din etape nu va fi repetată ulterior. Prima prezentare conţinând etape similare a fost ţinută in 1956 de către Herbert Benington, în cadrul Simpozionului pentru metode de programare avansată. În care acesta descria procesul folosit pentru dezvoltarea proiectului SAGE (Semi Automated Ground Environment), proiect pentru apărarea aeriană automata a Americii de Nord. Prima prezentare formală a procesului a avut loc de fapt mult mai târziu, în 1970, întrun articol al cărui autor a fost Winston Royce, acesta nefolosind termenul waterfall în prezentarea sa. Royce l-a prezentat ca pe un model intens folosit, care este greşit si nefuncţional.

5 - 9 - Termenul de waterfall sau cascadă a apărut mai târziu, datorită definiţiei etapelor, în stil top-down, fără elemente repetitive, ca o cascadă care mereu merge în jos, iterativ, niciodată nu urcă şi nu repetă etapele anterioare. În general, etapele sunt mai multe sau toate din lista următoare, ca în Figura 1 de mai jos [13]: - Analiza cerinţelor împreună cu clientul - Designul sau arhitectura sistemului - Implementarea proiectului, alcătuită din 2 subetape: o Scrierea codului de către dezvoltatori, din care rezultă proiectul software o Integrarea părţilor componente în sistemul nou sau existent - Verificarea sistemului, care include testarea si rezolvarea eventualelor defecte - Instalarea proiectului software pentru client - Mentenanţa Figura 1: Etapele metodologiei Waterfall

6 Acestui tradiţional model de dezvoltare i s-au adăugat modele modificate de-a lungul anilor, în funcţie de necesităţile de moment, păstrând totuşi neschimbate conceptele de bază. 1.2 Prototipul Acest modelul de dezvoltare implică definirea iniţială a unui model sau tipar, numit prototip, după care se va ghida întreg procesul de dezvoltare software, şi care poate fi folosit în testare sau ca demonstraţie pentru client [8]. Modelul acesta a fost derivat din Waterfall, în acele cazuri când cerinţele iniţiale nu sunt foarte clare. În timpul procesului de construire a acestui model, clientul va oferi feedback din când în când, acest fapt conducând la obţinerea acestui prototip. Având confirmarea de la client la terminarea construcţiei acestui prototip, este posibilă editarea unui document de specificaţii. Folosind acesta, se poate începe dezvoltarea software a produsului final, folosind în general Waterfall. 1.3 Modelul în spirală Modelul spirală combină aspecte ale modelului Waterfall şi Prototip. De unde îi vine şi numele, în acest tip de metodologie software procesele vor fi aşezate în formă de spirală, ca în Figura 2 [14]:

7 Figura 2: Cadranele modelului în spirală Această metodologie a fost descrisă pentru prima oară de către Barry Boehm în Este folosită în general în sistemele cu grad ridicat de risc. În general, fiecare buclă a spiralei reprezintă o fază a dezvoltării, iar fiecare fază va fi alcătuită din 4 paşi [7], descrişi mai jos: 1. Se determină obiectivele (unde trebuie să se ajungă) şi constrângerile datorate costurilor, tehnologiei disponibile etc. 2. Se analizează riscurile şi alternativele. Orice problemă legată de tehnologie se va soluţiona pe parcursul acestei faze. Scopul principal este minimizarea riscurilor ulterioare. 3. Se realizează dezvoltarea software şi testarea, dacă este cazul. În acest pas este posibilă folosirea unei alte metodologii de dezvolate, cum ar fi Waterfall. 4. Se planifică faza următoare.

8 Agile Datorită greutăţilor întâmpinate în timpul dezvotării proiectelor folosind waterfall, a fost prezentată in 2001 o metodologie numită generic Agilă, bazată pe etape incrementale si repetitive, în care cerinţele se dezvoltă pe parcurs, având suportul întregii echipe şi de asemenea axându-se pe colaborarea intensă între membrii echipei. Termenul agile a fost prezentat în 2001 de către autorii Agile Manifesto [1], o proclamaţie a unor valori cheie si principii de dezvoltare, care are 17 semnatari. Cele 4 valori [1] cheie prezente în Manifesto încurajează: 1. Indivizii si interacţiunea dintre ei faţă de unelte si procese 2. Software funcţional peste documentaţie foarte completă si complexă 3. Colaborarea cu clientul peste negocierea de contracte 4. Reacţie la schimbare în schimbul urmăririi unui plan Cele 12 principii [1] ale Agile sunt: 1. Satisfacerea dorinţelor clientului încă de la inceputurile proiectului si livrarea continuă de muncă de calitate 2. Împărţirea sarcinilor mari în componente mici care se pot rezolva rapid 3. Recunoaşterea faptului că munca de calitate rezultă din echipe independent organizate 4. Alocarea de mediu şi suport necesar indivizilor motivaţi si increderea că aceştia işi pot duce munca la bun sfârşit 5. Crearea de procese care promovează efortul susţinut 6. Menţinerea unui ritm constant al muncii 7. Adaptarea rapidă la cerinţe care se schimbă, chiar şi spre sfârşitul proiectului 8. Realizarea unor şedinţe zilnice a membrilor echipei împreuna cu cei responsabili de business pe tot parcursul proiectului 9. La intervale regulate, nevoia echipei de a reflecta cum pot deveni mai buni în ceea ce fac şi schimbarea comportamentului pentru realizarea acestuil lucru 10. Măsurarea progresului prin cantitatea terminată din proiect 11. Incercarea constantă de a atinge perfecţiunea

9 Valorificarea schimbărilor pentru avantaje competitive Figura 3: Agile Manifesto pagina principală [1] După cum se poate observa, aceste principii sunt foarte generale si se pot folosi practic în mult mai multe domenii, nu doar în dezvoltarea de software, iar autorii acestui manifest doresc introducerea si familiarizarea mai multor industrii cu aceste concepte utile si principii. O parte din aceşti autori au decis formarea alianţei Agile [2], o organizaţie non profit care promovează şi astăzi devoltarea Agile, conform principiilor si regulilor de mai sus. Deşi iniţial nu foarte cunoscută, metodologia a inceput să prindă contur pe parcursul ultimilor ani, în 2005 fiind publicat un addendum la Agile Manifesto, numit Declaraţia de Independenţă, un set de 6 principii de management în dezvoltarea agilă de software, iar în 2009 a fost publicat Software Craftmanship Manifesto, un ghid extins pentru

10 dezvoltare agilă, care se concentrează pe calităţile codului şi proiectului final, decât pe partea financiară rezultată din proiectele software. Figura 4: Agile Alliance logo [2] 1.5 Agile vs Waterfall pro şi contra Deşi încep sa fie din ce in ce mai populare, metodologiile Agile nu au luat total locul metodologiilor tradiţionale si cel mai probabil pe viitor vor fi folosite ambele în proporţii variabile. Printre calităţile Agile putem număra în primul rând flexbilitatea şi capacitatea de schimbare, chiar foarte târziu în procesul de dezvoltare [6]. Modelul este extrem de flexibil, inginerii software lucrând la module mici, discutând continuu cu clientul, şi cu certitudinea că acele module vor fi de calitate şi asa cum se asteaptă clientul în momentul în care sunt livrate. Benficiile cele mai mari ale Agile se pot vedea atunci când imaginea de final nu este foarte bine definitiă şi clientul vede pe parcurs ce anume doreşte, clarificându-se foarte mult cerinţele cu cât proiectul se apropie de sfârşit. În acelaşi timp, acest model încurajează foarte mult comunicarea, atat client-dezvoltator, cât şi in cadrul echipei de dezvoltare, mici module fiind lucrate de programatori simultan şi integrate la sfârşit. Dezavantajele acestei metologii ar fi dificultatea estimării atat a timpului, cât şi a bugetului final, datorită lipsei unui plan concret total al proiectului. De asemenea,

11 comunicarea intensivă descrisă mai sus poate consuma suficient de mult timp, probabil mai mult decât în metoda Waterfall [4], dar în acest caz avantajele sunt mai importante decat dezavantajele. Waterfall vine şi ea cu o serie de avantaje, printre care numărăm un plan clar de lucru la inceputul proiectului şi posibilitatea unei estimări mai acurate [4]. Timpul de lucru si bugetul sunt mult mai bine planificate, ceea ce este de obicei pe placul clienţilor. Deoarece se pune accent pe documentare si planificare, înlocuirea unui individ în timpul procesului de dezvoltare nu este foarte dificilă, o persoană nouă putând cu uşurinţă să ia locul altcuiva în timpul procesului de dezvoltare. Pe de altă parte, dezavantajele acestei metode numără rigiditatea si lipsa de flexibilitate pe parcursul întregului proces. Etapele sunt bine fixate de la inceput, estimate destul de exact, iar schimbările în timpul procesului pot fi foarte dificile şi necesită eforturi considerabile. De asemenea, în cazul metodologiei clasice tradiţionale de tip cascadă, testarea de orice fel are loc destul de târziu în cadrul proiectului, ceea ce face ca soluţionarea problemelor majore găsite să necesite timp şi buget, de multe ori în afara celor planificate iniţial. 1.6 Ce alegem Alegerea unei metodologii la începutul proiectului poate fi dificil, întrucât este clar că nici una nu este potrivită pentru toate cazurile şi toate tipurile de proiecte. Susţinătorii ambelor metodologii vor exista mereu şi asta deoarece fiecare are avatanje considerabile şi se poate plia pe anumite tipuri de proiecte mai bine decât opusa ei. În general, Waterfall tinde să fie mai utilă atunci când se estimează multe schimbări pe parcursul proiectului, când se cunoaşte bugetul clientului de la început şi ceea ce se doreşte a se obţine prin proiect este foarte clar. Este mai potrivită în cazul proiectelor foarte mari, care se întind pe o durată mare de timp şi implică echipe mari, în care multă interacţiune cu clientul ar încetini foarte mult procesul, sau echipe distribuite în mai multe ţări, eventual cu fuse orare foarte diferite.

12 Agile tinde să fie potrivită pentru proiecte mai mici, cu tendinţe de schimbare pe parcurs, echipe mai mici şi independente, de obicei localizate în acelaşi loc. În multe cazuri, procesul de dezvoltare începe Waterfall, ca imagine de ansamblu, şi continuă Agile pe diverse module mai mici, în momentul când apare nevoia de detalii insuficient descrise de cerinţe sau omise. Nu există vreo abordare lege, ci se alege în funcţie de proiect, echipă şi experienţa pe aceste metodologii a membrilor ei.

13 Metode încadrate în categoria Agile Există multe metode de dezvoltare clasificate ca fiind Agile, majoritatea fiind bazate pe interacţiune intensă între membrii echipei şi adaptabilitate crescută la schimbările ce au loc pe parcursul dezvoltării proiectului. Majoritatea metodelor se bazează pe împărţirea proiectului în mici module, uşor de dezvoltat şi gestionat fără planificarea lor intensivă. Modulele se dezvoltă în iteraţii, uneori numite sprinturi, care pot dura de la o săptămână până la două luni, dar preferabil cât mai puţin pentru a avea certitudinea livrării unui produs calitativ, precum şi a lăsa loc shimbărilor rapide ce pot avea loc. În timpul acestor iteraţii, este esenţială colaborarea între membrii echipei, pentru a fi siguri că se realizează în mod corect toate etapele dezvoltării: planificarea, analiza cerinţelor, arhitectura modulului, implementarea, testarea. O caracteristică destul de comună a metodelor Agile este prezenţa unor şedinţe zilnice, în care fiecare membru al echipei descrie ce a făcut în ziua anterioară, ce are de făcut în continuare şi ce probleme întâmpină, pentru ca ceilalţi mebri al echipei să îl poată eventual ajuta şi ghida spre soluţionarea problemelor. Este necesar ca echipele să fie alcătuite din indivizi cu diferite responsabilităţi pentru a putea fi atinse toate punctele anterioare. De asemenea este necesară prezenţa în permanenţă a unui reprezentant al clientului la şedinţele ce au loc în cadrul echipei de dezvoltatori sau posibilitatea contactării acestuia în permanenţă, pentru a confirma cu aceştia cerinţele necesare şi a clarifica problemele decizionale care s-ar putea ivi. Sfârşitul unui sprint nu are ca scop livrarea unui produs final, ci mai degrabă livrarea unor funcţionalităţi cu un număr redus de defecte (buguri). Metodele descrise în continuare nu sse folosesc independent, ci împreună, pentru a asigura calitatea unui proiect dezvoltat Agile.

14 Scrum Scrum este o metodă de dezvoltare Agile si management de proiect bazată pe flexibilitate la schimbări si planificare iniţială minimală. Procesul Scrum se realizează în scurte iteraţii numite sprinturi, care durează până la patru săptămâni. Fiecare sprint începe cu o sedinţă scurtă de planificare şi se finalizează cu un review. Ideea principală este de a lăsa dezvoltatorilor posibilitatea de a se auto planifica, întrucât ei sunt cei mai in măsură să estimeze si să realizeze corect livrarea şi de asemenea de a rezolva problemele pe măsură ce acestea apar. În momentul de faţă este cea mai des folosită metodă din categoria Agile, de sine stătătoare sau în combinaţie cu altele. Scrum se bazează pe echipe complexe, independente si care se pot organiza singure [9]. În loc să existe un team-leader care să ia decizii singur, deciziile sunt lăsate la latitudinea echipei. Ei vor decide impreună sarcinile ce le va realiza fiecare membru în parte şi cum se rezolvă problemele apărute pe parcurs. Toţi sunt responsabili în aceeaşi măsură de progresul sprintului şi rezultatul final. La inceputul sprintului, membri echipei fac o listă cu user-story-urile care se pot realiza şi livra la sfarşit (aşa numitul sprint-backlog, care reprezintă o parte componentă din product-backlog, totalul user story-urilor care se vor livra la final), apoi, de comun acord, acestea se împart. Zilnic au loc alte şedinţe (scrum zilnic), în care fiecare membru va lua cuvântul pentru a prezenta ce a realizat în ziua anterioară, ce mai are de făcut şi ce eventuale probleme întâmpină. Taskurile se pot reîmpărţi în cazul în care unele durează mai mult şi altele mai puţin decât estimate, pentru a realiza terminarea lor până la sfârşitul sprintului. Aceste şedinţe sunt foarte importante în Scrum şi ar trebui realizate cu regularitate, deoarece astfel toţi membri echipei vor fi puşi la curent cu statusul proiectului, progresul si probleme ivite, dar se realizează şi sincronizarea taskurilor membrilor. Aceste şedinţe nu ar trebui să dureze mai mult de 15 minute. La sfârşitul unui sprint se va realiza o demonstraţie a livrării împreună cu un reprezentant al clientului şi echipa de dezvoltatori. Astfel se poate primi feedback de către client şi rezolva problemele apărute, precum şi schimbarea anumitor specificaţii dacă este necesar.

15 De asemenea tot la sfârşitul sprintului, se face un o retrospectivă cu toţi membri echipei, pentru a se observa ce a mers bine, ce a mers prost si cum se poate îmbunătăţi modul de lucru în sprintul viitor. Figura 5 Procesul Scrum împreună cu rolurile aferente [19] Roluri în Scrum Există 3 roluri fundamentale în Scrum (Product Owner, Scrum Master, Membru al echipei), care asigură realizarea corectă şi completă a ciclului Scrum, şi câteva roluri secundare [9]: a. Product Owner Product Ownerul lucrează în strânsă legătură cu clientul şi este responsabil de comunicarea cu echipa de dezvoltatori si explicarea acestora viziunea clientului asupra proiectului. El reprezintă interesele clientului prin descrierea cerinţelor şi prioritizarea lor

16 corectă. În general, în marile companii, acest rol are şi responsabilităţile unui Project Manager, acest lucru neafectând responsabilităţile lui principale în dezvoltarea Scrum b. Scrum Master Scrum Masterul se asigură că procesul Scrum este urmat cu stricteţe si nu există impedimente care ar putea afecta livrarea la sfârşitul sprintului. El este cel care motivează în permanenţă echipa de dezvoltatori şi se asigură că problemele sunt rezolvate rapid şi eficient. Este oarecum similar cu un team-leader şi se află ca mediator între echipa de dezvoltatori şi Product Owner. c. Membru al echipei Echipa este responsabilă de livrarea la timp şi calitativă a produsului software. În scrum, echipele sunt mixte, adică sunt alcătuite din ingineri software, analişti, arhitecţi, programatori, testeri, designeri. Fiecare dintre aceşti membri particpă la sedinţele zilnice şi ia parte la luarea de decizii. Echipa este autonomă, fără a fi nevoie de prezenţa unui team-leader. d. Roluri secundare Printre rolurile secundare se numără Stakeholders (părţile interesate) clienţii, care au interes în finalizarea produsului, reprezentaţi de către Product Owner, şi utilizatorii finali, care sunt cei cărora li se adresează produsul.

17 Extreme programming (XP) Această metodologie se bazează pe livrări rapide în cicluri scurte, orientată foarte mult pe codul scris. Din acest motiv foloseşte tehnici ca pair-programming, unit testing pe tot codul, code review în mod extensiv, şi se asează pe păstrarea clarităţii si simplităţii în cod. Comunicarea între membrii echipei şi client este incurajată foarte mult. Deşi la prima vedere pare foarte similară ca metodologie cu Scrum, între cele doua există şi diferenţe notabile [10]: o Sprinturile Scrum sunt până la 4 săptămâni, în XP se preferă iteraţiile mai scurte, de până la 2 săptămâni o În Scrum nu se permit modificări în timpul sprintului, iar şedinţa de sprint planning este făcută pentru a se decide asupra unei liste de taskuri ce trebuie livrată la sfârşitul sprintului; XP permite modificări în timpul sprintului, interschimbări ale unor taskuri cu altele care ar avea aceeaşi durată, atâta timp cat taskurile care se vor scoate nu au fost începute deja o În Scrum, prioritizarea sprinturilor este făcută în general de căter Product Owner, dar echipa realizează prioritizarea in cadrul sprintului; în XP, clientul este cel care prioritizează orice task din cadrul sprintului, echipa nu poate lua decizii în acest caz o Scrum este o metodologie mai generală, nu încurajează nici un fel de tehnică de programare; XP în schimb este bazată pe folosirea diverselor tehnici care ajută la obţinerea unei calităţi superioară a codului, cum ar fi unit-testing şi testarea automată, şabloane de proiectare, refactorizare, pari programming, standarde de coding Termeni folosiţi în Extreme Programming Extreme programming conţine o listă de termeni, mai precis de bune practici, pentru ca metolodogia de dezvoltare să poată fi considerată ca făcând parte din această categorie, printre care se numără: o Test Driven Development, explicat pe larg în capitolul următor o Continuous integration, explicat într-un capitol viitor

18 o Standarde de coding, printre care se numără respectarea notaţiilor, regulilor de coding, Clean coding şi principiile SOLID o Ritm sustenabil, cea ce înseamnă că intreaga echipă trebuie să muncească în acelaşi ritm, care este de obicei unul alert o Refactoring, adică fiecare dezvoltator are obligaţia îmbunătăţirii codului existent în momentul când lucrează la un task o Codul ca proprietate colectivă, respectiv toţi dezvoltatorii trebuie să cunoască toate parţile din proiect, nu se împart pe module o Planning game, care este o sedinţă de planificare, făcută la inceputul sprintului. Nu se fac şedinţe zilnice, dar, dat fiind faptul că sprinturile sunt scurte, o astfel de şedinţă va avea loc o data la 1-2 săptămâni. Uneori, în această şedinţă se foloseşte planificare de tip poker, descrisă în capitolul următor o Pair-programming, concept cheie care de obicei diferenţiază extreme programming de alte metodologii, reprezintă munca în grupuri de căte doi, în cazul întâmpinării unor probleme mai complexe. În alte metodologii de dezvoltare, acest tip de programare se foloseşte pentru ca un membru nou al echipei să fie familiaizat mai uşor cu proiectul, învăţănd de la un membru mai experimentat o Metafora sistemului, care reprezintă viziunea comună iniţială a echipei faţă de cum trebuie proiectul să arate şi să se comporte o Design simplu, pentru ca sistemul să poată fi extins cu uşurinţă o Testarea la nivel de client, pentru a-i oferi acestuia produsul conform cerinţelor sale o Livrări scurte şi dese (1-2 săptămâni)

19 Figura 6 Termenii de bază în Extreme Programming [20] Avantaje şi dezavantaje Avantajele acestei metode Agile sunt clare: produsul livrat este de o calitate superioară, bugurile sunt puţine, schimbările în proiect sunt făcute exact atunci când este nevoie şi clientul supervizează evoluţia prin prioritizarea taskurilor. Dezavantajele ar număra faptul ca nu fiecare echipă se pretează la acest tip de metodologie, deoarece este nevoie de programatori care să fie bine pregătiţi şi cu o experienţă clară în spate. Este dificil pentru programatorii juniori sau pentru inidivizii noi veniţi să se integreze cu toate tehnicile de dezvoltare folosite în XP şi să ţină pasul cu ceilalţi. Echipa trebuie să fie în acest caz cât mai stabilă, deoarece este dificilă inlocuirea oamenilor. De asemenea, este complicat de implementat XP în echipe foarte mari [11].

20 Test Driven Development Test Driven Development (TDD) este o tehnică de programare bazată pe scrierea de teste automate, pentru a avea siguranţa unui cod lipsit de defecte în procent cât mai mare, acest lucru favorizând o mentenaţă uşoară şi lipsită de probleme majore. Faţă de metodele trasiţionale de programare, în TDD este necesar ca testele să fie scrise înaintea codului, iar codul să fie scris în asa fel încât la sfârşit toate testele se vor finaliza cu succes. TDD este înrudit cu Extreme Programming, fiind folosit uneori ca tehnică de programare în cadrul unei echipe XP. În general, Test Driven Development este alcătuit din mai multe faze, ca în figura de mai jos [15]: a. Adaugarea unui nou test Fiecare funcţionalitate nouă începe cu scrierea a unuia sau mai multor teste. Bazânduse pe cerinţe şi cunoscând foarte bine use-case-urile, un developer va scrie teste ca să acopere întreaga funcţionalitate, aşa cum va fi ea văzută de către utilzatorul final. Acest detaliu, de a scrie testele înaintea implementării noi funcţionalităţi va face dezvoltatorul

21 să cunoască foarte bine cerinţele înaintea scrierii codului, ceea ce va ridica considerabil calitatea codului şi va îmbunătăţi aria de acoperire a sa. b. Rularea testelor scrise anterior În acest pas este extrem de omportant ca testele noi scrise să eşueze. Astfel, dezvoltatorul se asigură că sunt îndeplinite următoarele condiţii: - Funcţionalitatea nouă nu există deja - Testul este valid În caz contrar, se va repeta primul pas şi se va investiga ce anume a fost greşit. c. Implementarea funcţionalităţii În aces pas, singurul scop este scrierea de cod care va face testele să fie terminate cu succes. Nu este esenţială atenţia la calitatea codului, este importantă viteza cu care noua funcţionalitate este scrisă. Acest pas trebuie să dureze cât mai puţin. d. Rularea testelor scrise la primul pas În acest pas, spre deosebire de pasul al II-lea, testele trebuie să treacă. În caz contrar, până cand nu trec toate testele, dezvoltarul se va întoarce la pasul anterior, repetându-l împreună cu pasul curent, în ciclu, până când toate testele trec. e. Refactorizarea codului Având certitudinea faptului că noua funcţionalitate este complet implementată şi în conformitate cu cerinţele, aces pas se asigură de calitatea codului. Codul va fi refactorizat, respectând tehnicile moderne de ingineria programării. Acest pas se realizează conconmitent cu pasul anterior, pentru a avea certitudinea că refactorizarea nu cauzează defecte în funcţionalitatea existentă. Toate etapele de mai sus se vor repeta ori de câte ori este necesar, până la sfârşitul proiectului. Acest tip de dezvoltare determină o mare calitate a codului scris şi se asigură că defectele sunt descoperite şi reparate cât mai devreme în procesul de dezvoltare. Venind cu aceste beneficii, acest model de dezvoltare vine şi cu un defect considerat

22 adesea major, şi anume faptul că procesul este îndelungat şi costisitor, fiind mai potrivit uneori pentru proiectele de mică anvergură şi cu module slab cuplate între ele. În acest tip de dezvoltare, există câteva reguli best-practice, care ajută la obţinerea unei calităţi superioare a TDD şi implicit, a proiectului final. Printre ele se numără: o Testele şi codul sursă trebuie să fie separate în proiect şi pe disc, pentru a nu se incurca şi a crea claritate în cod o Este esenţial ca testele să pice prima oară cand sunt scrise, în mod contrar fiind nefolositoare pentru cazul dat o Numele testelor trebuie să fie clare şi să reflecte întocmai asteptările o Codul duplicat trebuie şters la fiecare refactoizare o Orice refactorizare, oricăt de mică, trebuie să fie urmată de rularea suitei de teste o Codul nou trebuie scris doar atunci cănd un test pică; în caz contrar, ceea ce trebuie făcut este o refactorizare o În primă fază, codul care trebuie scris pentru ca testul să treacă trebuie să fie cât de simplu posibil o Trebuie sa se elimine dependeţele între teste: în orice ordine ar rula, testele trebuie să aibă aceelaşi comportament o Testele trebuie să fie rapide, în caz contrar există riscul să se treacă cu vederea testele lente şi astfel va exista funcţionalitate netestată sau testată insuficient

23 Continuos Integration Integrarea continuă este un proces de dezvoltare software prin care codul comis de către dezvoltatori pe un server de control al versiunilor trece prin diverse etape, pentru a asigura calitatea integrării în mod constant. Integrarea codului se poate face prin mai multe metode, iar în Continuos Integration este necesar ca acest lucru să fie făcut de mai multe ori pe zi. Printre principiile acestui proces se numără: a. Integrarea trebuie făcută măcar zilnic Atunci cand dezvoltatorii comit codul pe serverul de control al versiunilor, este preferabil să existe taskuri care rulează un build automat după fiecare check-in al fiecărui dezvoltator, dar, dacă acest lucru nu este posibil, se recomandă ca această procedura să se facă măcar o dată pe zi. În acest mod erorile de integrare pot fi detectate şi corectate rapid, înainte ca acestea să se adune şi să creeze probleme în lanţ. b. Trebuie să existe un singur server de control al versiunilor Chiar şi în cazul frecvent în care se lucrează cu diverse versiuni ale aceluiaşi proiect, este esenţial să existe o versiune principală şi taskuri automate care să faca eventualele merge-uri între versiuni, pentru a le aduce la nivel similar. Existenţa mai multor copii ale aceluiaţi proiect, nelegate între ele, lasă loc de multe erori umane, care sunt greu de depistat şi rezolvat ulterior. c. Build-ul să fie testabil automat Este foarte util ca, după ce buildul a fost realizat în urma unui check-in al unui dezvoltator, să fie rulate toate testele automate care existau dinainte, pentru a asigura calitatea codului noi introdus, cât şi pentru a fi siguri că funcţionalitatea existentă nu a fost afectată în vreun fel de către noul cod. d. Existenţa unei maşini de integrare Este preferabil ca fiecare build automat să beneficieze de o maşină separată pentru integrare, în care eventualele probleme ale integrării automate să fie rezolvate apoi

24 manual, înainte să se facă un deployment pe maşinile de test. În acest caz se evită diversele neconcordanţe între maşinile de development şi maşinile de test, dar în acelaşi timp se optimizează timpul pierdut pentru refacerea deploymentului pe maşinile de test, în cazul în care acesta nu a reuşit de prima oară. e. Testele să se facă pe o copie identică a maşinilor de producţie Acest punct este esenţial, deoarece se doreşte reproducerea defectelor din producţie cu cât mai multă acurateţe. Acest lucru înseamnă copierea bazelor de date si serviciilor din producţie cât mai des, recomandabil zilnic, de către taskuri automate. f. Deploymentul automat Deploymentul automat uşurează foarte mult munca dezvoltatorilor. Ideal ar fi să existe taskuri care realizează deployment automat pe toate maşinile de integrare şi testare, eventual şi în producţie. Eventualele greşeli de integrare pot fi apoi rezolvate manual, dar un proces automat minimizează existenţa erorilor umane. Continuous Deployment este un concept similar cu Continuous Integration, diferenţa fiind scopul acestuia. Continuos Deployment se referă la livrarea în producţie a acelor părţi din proiect care au respectat o parte din paşii de mai sus: au trecut buildul şi testele automate. Aces lucru înseamnă că mereu se va livra software calitativ, fără a fi afectate funţionalităţile deja existente, iar livrările se vor face foarte frecvent. De asemenea, livrarile vor avea un grad scăzut de risc şi vor putea fi adaptate foarte rapid la cerinţele clientului.

25 Figura 7 Proces ciclic complex de Continuos Integration [18]

26 Kanban Metodologia Kanban provine de la Toyota sistemul JIT (just-in-time), şi se axează pe eliminarea efectului de dop de sticlă (bottleneck), prin optimizarea procesului de producţie în orice domeniu. Deşi tehnologia construcţiilor de maşini nu are foarte multe similarităţi cu ingineria software, procesul Kanban a fost bine primit în ultima vreme şi se regăseşte printre metodologiile Agile. Se presupune că un proces de dezvoltare software trebuie să meargă continuu şi uniform. Dar frecvent vor apărea acele blocaje numite bottleneck, ca de exemplu: testerii au capacitatea de a testa 5 bug-uri pe săptămână, dar dezvoltatorii sunt capabili să fixeze 10 buguri pe săptămână. În acest caz, testerii vor fi cei care creează blocajul [12]. Testerilor li se vor acumula volume imense de muncă şi inevitabil, produţia va fi încetinită, clientul va fi nemulţumit etc. Din păcate, blocaje similare se pot întâmpla la momente diferite oricăror roluri din procesul de dezvoltare, problemele nefiind vizibile la timp. Kanban îşi propune să rezolve această problemă, limitând dinamic volumul de muncă al fiecărui rol, folosind aşa numita tablă Kanban, ca in figura de mai jos [11]: Figura 8 Tabelă Kanban [18]

27 Cifrele de deasupra fiecărui pas reprezintă numărul maxim de itemi care pot fi la un moment dat în curs în pasul respectiv. Dacă acest număr este depăşit pe vreuna dintre coloane, aceasta devine blocaj şi trebuie găsite rapid soluţii pentru a scădea numărul aferent. Oricare dintre coloane poate conţine itemi în curs şi terminaţi, figura exemplifică acest lucru doar pe două dintre coloane.

28 Estimarea în Agile Estimarea este una dintre problemele cele mai dificile cu care se confruntă toate părţile implicate într-un proiect software. Pornind de la calcule simple şi până la algoritmi complecşi, estimările pot fi foarte dificil de realizat în industria IT, datorită lipsei constantelor din tehnologia actuală. Spre deosebire de alte industrii, nu se poate calcula cu precizie cât va dura un task, deoarece există prea mulţi factori de luat în considerare, factori care includ tehnologiile folosite, experienţa pe proiect, resursele fizice pe care va rula proiectul etc. În Agile există două tipuri de estimări care se folosesc în mod frecvent, şi anume estimarea bazată pe puncte (story point) şi estimarea bazată pe zile de dezvoltare (ideal developer days) [16]. Deşi în trecut estimarea pe zile a fost mai des folosită, metodologiile tradiţionale având nevoie de estimări stricte pe perioade lungi de timp, odată cu apariţia Agile a inceput să prindă contur estimarea bazată pe puncte [17]. În ambele cazuri, estimarea are loc în 4 paşi standard, care se pot vedea în figura de mai jos: 1. Clientul descrie user-story-urile 2. Dezvoltatorii estimează individual 3. Are loc o discuţie pe baza estimărilor, ăn care se aduc argumente de ce s-a estimat astfel 4. Dezvoltatorii estimează din nou individual Dacă este nevoie, ultimii 2 paşi se pot repeta până când se ajunge la un consens.

29 Figura 9 Paşii în estimarea Agile [18] 2.1 Estimarea pe zile Acest tip de estimare are o istorie lungă, fiind folosit de foarte multă vreme si continuă să fie folosit frecvent. Întreaga echipă se reuneşte în sedinţa de Sprint planning, se decide ce se va livra în cadrul sprintului (acel Sprint backlog, alcătuit din user-storyuri), apoi fiecarui user-story i se va ataşa un număr de zile în care trebuie să fie terminat. Aceste zile reprezintă de fapt numărul de zile în care va putea fi rezolvat de către un singur dezvoltator. Este o estimare simplă şi nu necesită găsirea de legături între userstory-urile dintr-un sprint. Uneori se foloseşte în acest caz estimarea în 3 puncte, care se realizează precum urmează:

30 se decide cam cât ar dura realizarea taskului - se decide cât va dura în cel mai bun caz şi în cel mai rău caz - se face media celor 3 estimări, rezultând estimarea finală Estimarea folosind puncte Acest tip de estimare presupune compararea user-story-urilor între ele. Se începe prin a se alege cel mai simplu user-story (cel a cărui durată se presupune a fi cea mai mică) şi i se asignează un punctaj de 1. Apoi toate celelalte user-story-uri vor fi comparate cu primul şi apoi între ele, asignându-li-se numere din şirul lui Fibonacci (1, 2, 3, 5, 8 etc.). Apoi user-story-urilor cele mai simple li se va asigna un număr de ore sau zile (manhours, man-days), iar celorlalte li se vor asigna estimări egale cu estimarea celei mai simple înmulţită cu numărul din şirul lui Fibonacci aferent. Astfel se pot lua în calcul şi eventualele întârzieri (similar cu un worst-case-scenario), spre deosebire de estimarea simplă pe zile. O variantă a estimării folosind puncte este planificarea poker, denumită astfel deoarece se folosesc cărţi de joc sau cartonaşe conţinând numerele din şirul lui Fibonacci. Fiecare membru al echipei primeşte un set de astfel de cartonaşe şi estimează, pe rând, câte un user-story. Important este la acest tip de estimare ca toţi membrii echipei să arate cartonaşele pentru acelaşi user-story în acelaşi timp, pentru a nu fi influenţati între ei. Se presupune că toţi vor da aceeaşi estimare sau foarte asemănătoare. Dacă se întâmplă totuşi să fie diferenţe foarte mari, cei care au estimarea diferită de medie vor trebui să explice de ce au ales această soluţie şi apoi se va vota din nou. Detalii în figura următoare [18]:

31 Figura 10 Cărţi specifice estimării Poker [18]

32 Aplicaţia Scrum Planner pentru managementul estimărilor În ziua de astăzi există numeroase aplicaţii independente sau de tip plug-in la diverse medii de dezvoltare care au ca scop principal managementul proiectelor, mai precis al diverselor etape în procesul de dezvoltare software. Aplicaţiile sunt capabile să ajute utilizatorii să aibă o evidenţă cat mai clara a taskurilor, a membrilor echipei care se ocupă de aceste taskuri, precum şi raportele zilnice referitoare la aplicaţie (fiecare mebru al echipei la ce a lucrat şi in ce stadiu este fiecare task al proiectului). Unele dintre aceste aplicaţii de management au fost îmbunătăţite şi pot oferi soluţii de management în dezvoltarea de tip Agile, permiţând de exemplu realizarea unor tabele de tip Kanban, grafice, evidenţa şedinţelor din Scrum etc. Printre aceste aplicaţii se numără: - Jira, VersionOne aplicaţii independente, de sine stătătoare - Visual Studio Scrum pentru Visual Studio - Agile for Oracle - pentru Oracle Aceste aplicaţii au foarte multe întrebuinţări şi sunt folosite la scară largă în industria software. Ele pot avea use-case-uri de tipul: o un dezvoltator poate vedea taskurile care i-au fost atribuite, le poate sorta în funcţie de prioritate, de modulul afectat, de gravitate etc. o un dezvoltator îşi poate loga orele lucrate la diverse sarcini o un utilizator (team leader, project manager) poate estima diverse taskuri şi le poate atribui priorităţi, le poate atribui dezvoltatorilor etc o un tester poate realiza aceleaşi acţiuni pe un test plan ca şi dezvoltatorii pe taskuri o un project manager poate observa planificările, poate schimba diverse informaţii la nivel de proiect o un project manager poate crea rapoarte despre taskurile terminate, în lucru sau neîncepute, şi poate avea o imagine de ansamblu a muncii fiecărui membru al echipei de dezvoltatori sau testeri

33 Problema Deşi aplicaţiile sunt făcute în aşa fel încât să ofere foarte multe funcţionalităţi, ele sunt organizate în aşa fel încât să fie concentrate pe proiect şi pe taskurile componente. Un task poate fi estimat la începutul proiectului la un număr de ore sau zile şi eventual reestimat pe parcurs, în funcţie de diverse module care l-ar putea afecta. Apoi unui dezvoltator îi este atribuit acel task. Respectivul dezvoltator trebuie să încerce pe cât posibil să se incradreze în acea estimare, cu toate că acest lucru îi este uneori imposibil, datorită factorilor externi sau interni: o Factori externi: meetinguri lungi o dată sau de mai multe ori pe zi, colegi care trebuie ajutaţi, probleme administrative în cadrul companiei, traininguri etc. o Factori interni: capacitatea dezvoltatorului de a rezolva taskul, în funcţie de experienţa sa, cunoasterea tehnologiilor necesare, talentului său de programator etc. Aceşti factori ne duc cu gândul la nevoia unei funcţionalităţi într-o aplicaţie de management care să ia în calcul aceşti factori descrişi mai sus. Funcţionalitatea ar trebui orientată asupra dezvoltatorului şi capacităţii sale de a rezolva diverse taskuri, cu referire atât la factorii care îi pot îmbunătăţi munca, cât şi la factorii perturbanţi, care pot lungi perioada petrecută lucrănd la task. Exemplu: Taskul T a fost estimat de o echipă de tip Scrum la o zi (8 ore de muncă). Estimarile de acest tip sunt pesimiste iniţial, pornind de la dezvoltatori, dar, trecând prin mâinile mai multor persoane, inclusiv project managerul, ele se pot scurta, deoarece se doreşte livrarea cât mai rapidă. Acest task i-a fost atribuit dezvoltatorului D, cu un nivel mediu de experienţă, dar cu vechime pe proiect. Putem presupune astfel că taskul nu va fi greu de integrat de către dezvoltator, datorită cunoştinţelor acestuia despre proiect şi modulele sale, dar că i-ar putea crea anumite întârzieri datorită limbajului L, de exemplu, limbaj pe care

34 dezvoltatorul D în cunoaşte la nivel mediu. De asemenea, în ziua în care dezvoltatorul îşi propusese să rezolve respectivul task, a venit un angajat nou, căruia D a trebuit să îi faca o introducere în companie şi proiect, fapt ce i-a răpit câteva ore din munca la task. În aceeaşi zi a avut loc şi o şedinţă neasteptată, care de asemenea a facut imposibil lucrul la task. Din exemplu de mai sus putem deduce că taskul T poate avea întârzieri mari, iar timpul real în care taskul a fost terminat poate fi şi dublu faţă de estimarea iniţială. Şi cu toate că în unele companii este posibilă şi raportarea timpului petrecut în sedinţe, multe aplicaţii nu permit decîr raportarea muncii la taskuri, deci este necesar să se raporteze 8 ore pe zi. Este simplu de dedus că, impreună cu diverse pauze scurte din timpul zilei, cu prezentarea proiectului către noul coleg, cu şedinţa si cu alte eventuale modalităţi de distragere a atenţiei, nu este posibil să se fi lucrat 100 % din zi la task, deci vor apărea întărzieri. Sub un deadline strâns, multi dezvoltatori sunt nevoiţi să petreacă foarte multe ore în plus la servici, pentru a rezolva taskurile prost estimate in iniţial. În urma multor ore de muncă în plus, productivitatea va scădea, nemulţumirile personale vor creşte, fapt care nu este benefic nici pentru angajat, nici pentru proiect şi nici pentru companie, pe termen lung. 4.2 Soluţia propusă Conform exemplului de mai sus, este clar că există o variabilă în procesul estimării de care aplicaţiile deja existente nu ţin cont. Această variabilă este chiar dezvoltatorul căruia îi este atribuit taskul, respectiv o măsură a diverşilor factori care pot contribui la accelerarea sau dimpotrivă, la încetinirea procesului de rezolvare a taskului. El poate avea o mulţime personală de variabile, din care se pot calcula intârzierile care pot apărea în munca sa, astfel ca project managerul să poată să aibă o imagine de ansamblu şi eventual să discute cu clientul in cazul intârzierilor foarte mari.

35 Aplicaţia Scrum Planner Termeni folosiţi Sprint se referă la un sprint din modelul de dezvoltare Agile. Este important să fie cât mai scurt, dar nu mai mult de 4 săptămâni. User story modulele care vor intra în sprintul curent. Mai multe persoane pot lucra concomintent la acelaşi user story. Task - unitate de muncă, sarcină mică care intră în componenţa unui user story. Un task este rezolvat de un singur dezvoltator. Resource un dezvoltator care poate lucra la taskurile ce îi sunt atribuite. Are un număr maxim de ore de muncă care îi pot fi atribuite într-un sprint. Skill calităţile, abilităţile şi factorii externi care ţin strict de Resource şi care influenţează estimarea taskurilor. Acestea au fiecare un Skill Weight (pondere): unele sunt mai importante ca altele, în sensul că vor influenţa mai mult estimarea. Productivity index număr repezentând productivitatea dezvoltatorului, calculată în funcţie de mulţimea de Skilluri, valorile şi ponderile acestora Estimated Hours orele estimate de către echipă ale unui task Real Hours orele calculate de către aplicaţie, conţinând întârzierea datorată dezvoltatorului, conform Productivity Index

36 Figura 11: lista de taskuri ale sprintului curent, împreună cu informaţii despre ele Skills calităţile dezvoltatorului software Aceste skill-uri se pot defini dinamic, în funcţie de necesităţile proiectului, pentru a exprima cu cât mai multă acurateţe nivelul programatorului, lucru care va avea ca urmare calcularea mai precisă a indexului de productivitate. Fiecare skill va avea o pondere si o valoare. Ponderile pot lua valori în intervalul 1-5, în timp ce valorile skillurilor pot fi între -5 şi 5. Cele pozitive reflectă calităţi ale dezvoltatorului (cunoaşterea diverselor tehnologii, experienţa în profesie sau experienţa pe proiect), calităţi care il vor ajuta în realizarea mai rapidă a taskurilor, iar cele negative reprezintă diversele evenimente perturbatoare, care îl impiedică în muncă (sedinţe, trainiguri etc). Exemplu: un dezvoltator senior poate termina un task estimat la 8 ore în mai puţin de atâta, dacă lucrează neîntrerupt. Dar tot acelaşi programator senior mai are si alte atribuţii în afara sarcinilor ce ţin strict de proiect, cum ar fi realizarea de diverse trainiguri la interni şi juniori (inclusiv pregătirea prezentărilor respective), şedinţe, ajutarea diverşilor colegi cu diverse probleme etc. Presupunând munca la task de 7 ore, plus o sedinţă de o ora, un training de o oră şi explicarea problemelor unor colegi care au nevoie de ajutor încă o oră, estimarea este uşor depăşită. Adăugând mai multe taskuri similare, într-un user story este foarte uşor să nu se respecte acel estimările iniţiale.

37 Figura 12: Pagina de detalii a unui dezvoltator, conţinând detalii despre skilluri, productivity index, taskuri atribuite Productivity index (indexul de productivitate) Acest index este specific fiecărui dezvoltator în parte, ţinandu-se cont de skillurile anterioare (ponderea şi valoarea). Se calculează conform formulei următoare: ( ) Unde simbolurile sunt: Pi = Ponderea Skillului cu indexul i

38 Vi = Valoarea Skillului cu indexul i n = numărul de skilluri ale dezvoltatorului În cadrul aplicaţiei, acest ProdIndex va fi rotunjit până la 2 zecimale, conform standardului IEEE 754 [21], (rotunjirea bancherului sau rotunjirea la cel mai apropiat număr) Estimated Hours şi Real Hours Orele estimate sunt rezultatul şedinţei de Sprint planning, realizată de către intreaga echipă, pentru fiecare task. După estimare se poate calcula estimarea totală pentru un user story. Orele reale pentru un task se calculează din orele estimate, folosind Productivity Index pentru dezvoltatorul atribuit. Atribuirea taskului altui dezvoltator modifică orele reale. Acestea se calculeazo conform formulei: ( ) Unde simbolurile au următoarea semnificaţie: RH T Orele reale ale taskului T EH T Orele estimate pentru taskul T PI R Indexul de productivitate al dezvoltatorului D Formula foloseşte o diferenţă între 100 şi Productivity Index, deoarece, cu cât acesta este mai mare, cu atât acel dezvoltator este mai bine pregătit şi va putea rezolva mai rapid taskul. Diferenţa de la 100 provine de la faptul că Productivity Index se calculează ca un procent.

39 Figura 12: pagina de editare a unui task sugerează numele unui alt dezvoltator, care ar putea rezolva taskul în mai puţin timp Auto-atribuirea În unele cazuri, project managerul poate dori ca aplicaţia să atribuie automat taskurile pentru a minimiza timpul de întârziere. Aplicaţia permite acest lucru prin folosirea unui buton de Auto-assign, care va declanşa algoritmul de auto-atribuire a taskurilor. Nu este obligatorie folosirea acestui algoritm, deoarece, de obicei, într-un proiect taskurile se atribuie în funcţie de experienţă, cunoaşterea tehnologiilor etc. În Scrum, dezvoltatorii

40 decid singuri cum işi vor atribui taskurile, de aceea este important ca aplicaţia să permită auto atribuirea, cât şi atribuirea manuală. Algoritmul de auto-atribuire este euristic, care va sorta taskurile descrescător după numărul de ore estimate, apoi programatorii tot descrescător după indexul de productivitate. Apoi va asigna taskurile începând cu programatorul cu indexul de productivitate cel mai mare, până la numărul maxim de ore ce îi pot fi asignate, continuând în jos. Algoritmul este descris în pseudocod mai jos: max_possible_hours=constant sort list_of_tasks sort list_of_programmers for task in list_of_tasks for programmer in list_of_programmers if task.estimated_hours + programmer.total_assigned_hours <= max_possible_hours assign task to programmer break Acest algoritm asigură certitudinea că taskurile cele mai lungi, la care pot apărea cele mai mari întârzieri, sunt atribuite întâi programatorilor cei mai buni. De asemenea se asigură că, în procesul de atribuire de taskuri, programatorii cei mai buni vor fi luaţi în calcul, înainte de a atribui taskuri celorlalţi. Algoritmul funcţionează doar cu menţiunea că orele totale estimate ale taskurilor nu trebuie să depăşească totalul orelor maxime care pot fi atribuite programatorilor, plus o marjă de eroare de 20%. Studiu de caz auto-atribuire: Pornim de la situaţia user-story-urilor ca mai jos:

41 Figura 13: User-story-urile şi orele estimate, reale, precum şi posibila întârziere Observăm posibilitatea unor întârzieri în proiect de 34 de ore, cu 43% mai mult decât perioada estimată. Taskurile sunt asignate astfel: Figura 14: Taskurile sprintului curent şi atribuirea resurselor Această atribuire s-a făcut manual, în timpul şedinţei de sprint planning. Echipa este alcătuită din juniori şi seniori. Aceştia au totalul de ore atribuite, precum şi productivity index ca în figura mai jos:

42 Figura 15: Indexul de productivitate şi orele atribuite fiecărui dezvoltator Folosind butonul de Auto-assign din pagina cu lista de taskuri, putem declanşa algoritmul de auto atribuire. Acesta va genera un dialog, iar dacă se confirmă, algoritmul va suprascrie valorile atribuite momentan, ca în figura de mai jos: Figura 16: Declanşarea algoritmului de atribuite automată Algoritmul rulează rapid, datorită mulţimii reduse de date de procesat, apoi putem urmări noua atribuite a taskurilor. Deoarece algoritmul lucrează cu constanta MAX-HOURS, în cazul aplicaţiei definită la 20 de ore, s-au putut atribui taskurile majore celor mai buni programatori, taskurile mai simple fiind redistribuite celorlalţi, tot în ordine descrescătoare a indexului propriu de productivitate. În cazul nostru, programatorul cel mai bun ar fi

43 Oscar Wilde, cu un index de 77.60, iar cel cu indexul de productivitate cel mai mic este Dan Brown, cu un index de În figura de mai jos se observă noua atribuire: Observăm că taskul cel mai lung i-a fost atribuit lui Oscar Wilde, astfel fiindu-i atribuite un total de 20 de ore, apoi programatorul cu indexul imediat următor, respectiv Umberto Eco, are atribuite 2 taskuri care totalizează 20 de ore. Dan Brown din contră, având indexul de productivitate cel mai mic, are cele mai puţine ore atribuite, respectiv 10 ore ale unui singur task, dar care, datorită productivităţii reduse, vor putea avea o întârziere de 6 ore. În figura de mai jos putem observa noile valori per user-story: