Introducere … … … … – 7 – [617458]

– 5 –

Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………. – 7 –
1. Introducere în Agile ………………………….. ………………………….. ………………………….. ……. – 8 –
1.1 Waterfall (metodologia în cascadă sau tradițională) ………………………….. ………………. – 8 –
1.2 Prototipul ………………………….. ………………………….. ………………………….. ………….. – 10 –
1.3 Modelul în spirală ………………………….. ………………………….. ………………………….. . – 10 –
1.4 Agile ………………………….. ………………………….. ………………………….. ………………… – 12 –
1.5 Agile vs W aterfall – pro și contra ………………………….. ………………………….. …….. – 14 –
1.6 Ce alegem ………………………….. ………………………….. ………………………….. …………. – 15 –
2. Metode încadrate în categoria Agile ………………………….. ………………………….. ………… – 17 –
2.1 Scrum ………………………….. ………………………….. ………………………….. …………………… – 18 –
2.1.1 Roluri în Scrum ………………………….. ………………………….. ……………………….. – 19 –
2.2 Extreme programming (XP) ………………………….. ………………………….. …………….. – 21 –
2.2.1 Termeni folosiți în Extreme Programming ………………………….. ……………………. – 21 –
2.2.2 Avantaje și dezavantaje ………………………….. ………………………….. …………………. – 23 –
2.3 Test Driven Development ………………………….. ………………………….. ……………….. – 24 –
a. Adaugarea unui nou test ………………………….. ………………………….. ………………….. – 24 –
b. Rularea testelor scrise anterior ………………………….. ………………………….. …………. – 25 –
c. Implementarea funcționalității ………………………….. ………………………….. …………. – 25 –
d. Rularea testelor scrise la primul pas ………………………….. ………………………….. ….. – 25 –
e. Refactorizarea codului ………………………….. ………………………….. …………………….. – 25 –
2.4 Continuos Integration ………………………….. ………………………….. ……………………… – 27 –
a. Integrarea trebuie făcută măcar zilnic ………………………….. ………………………….. .. – 27 –
b. Trebuie să existe un singur server de control al versiunilor ………………………….. . – 27 –

– 6 –

c. Build -ul să fie testabil automat ………………………….. ………………………….. …………. – 27 –
d. Existența unei mașini de integrare ………………………….. ………………………….. ……. – 27 –
e. Testele să se facă pe o copie identică a mașinilor de producție ……………………… – 28 –
f. Deploymentul automat ………………………….. ………………………….. ……………………. – 28 –
2.5 Kanban ………………………….. ………………………….. ………………………….. …………….. – 30 –
3. Estimarea în Agile ………………………….. ………………………….. ………………………….. ……. – 32 –
2.1 Estimarea pe zile ………………………….. ………………………….. ………………………….. ……. – 33 –
2.2 Estimarea folosind puncte ………………………….. ………………………….. ……………………. – 34 –
4. Aplicația Scrum Planner pentru managementul estimărilor ………………………….. …….. – 36 –
4.1 Problema ………………………….. ………………………….. ………………………….. ……………….. – 37 –
4.2 Soluția propusă ………………………….. ………………………….. ………………………….. ….. – 38 –
4.3 Aplicația Scrum Planner ………………………….. ………………………….. ………………………. – 39 –
4.3.1 Termeni folosiți ………………………….. ………………………….. ………………………….. .. – 39 –
4.3.2 Skills – calitățile dezvoltatorului software ………………………….. ……………….. – 40 –
4.3.3 Productivity index (indexul de productivitate) ………………………….. …………. – 41 –
4.3.4 Estimated Hours și Real Hours ………………………….. ………………………….. ….. – 42 –
4.3.5 Auto -atribuirea ………………………….. ………………………….. ………………………… – 43 –
4.3.6 Tehnologii folosite ………………………….. ………………………….. …………………… – 48 –
4.3.7 Dezvoltări viitoare ………………………….. ………………………….. …………………… – 48 –
Concluzie ………………………….. ………………………….. ………………………….. ………………………. – 49 –
Bibliografie ………………………….. ………………………….. ………………………….. ……………………. – 50 –

– 7 –

Introducere
Această lucrare își propun e 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 met odologii î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 ac estor
metodologii și recomandă alegerea uneia sau 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 apli caț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 difer it 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, deoare ce aceleași diferențe
între un junior și senior, de exemplu, vor exista și în echipele de testare.

– 8 –

1. 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 avan sată. În care acesta
descria procesul folosit pentru dez voltarea 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, într –
un 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.

– 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 compo nente î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

– 10 –

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 m odelul de dezvoltare implică definirea inițială a unui mod el 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]:

– 11 –

Figura 2: Cadranele modelului în spirală
Această metodologie a fost descrisă pentru prima oară de către Barr y Boehm în 1986 .
Este folosită în g eneral î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 dat orate
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 softw are ș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.

– 12 –

1.4 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 .
Terme nul „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 fun cț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 pri ncipii [1] ale Agile sunt:
1. Satisfacerea d orințelor clientului încă de la inceputurile proiectului si livrarea
continuă de muncă de calitate
2. Împărțirea sarcin ilor 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

– 13 –

12. 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

– 14 –

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 Waterf all – 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 m ult 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,

– 15 –

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 est imă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 între gului 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 ca drul 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 gen eral, 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 proiect elor
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.

– 16 –

Agile tinde să f ie 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.

– 17 –

2. Metode încadrate în categoria Agile
Există multe metod e 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 met odelor 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 ant erioară, 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 pen tru
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 conf irma 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 desc rise în continuare nu sse folosesc independent, ci împreună, pentru a
asigura calitatea unui proiect dezvoltat Agile.

– 18 –

2.1 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 posib ilitatea 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 s ine 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 impreu nă 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, progr esul si pro bleme 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 ech ipa 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.

– 19 –

De asemenea tot la sfârșitul sprintului, se face un o retrospectivă cu toți membri
echipei, pen tru 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]
2.1.1 Roluri în Scrum
Există 3 rolur i fundamentale în Scrum (Product Owner, Scru m 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 prioritiz area lor

– 20 –

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 c u 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 .

– 21 –

2.2 Extreme programming (XP)
Această met odologie se b azează 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. Com unicarea î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ți ile 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 ti mpul sprintului, interschimbări ale unor t askuri
cu altele care ar avea ace eaș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 real izează prioritizarea in cadrul sprintului; în XP, clientul este cel care
prioritizează orice task din cadrul sprintulu i, 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.

2.2.1 Termeni fol osiț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

– 22 –

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ă i ntreaga 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 dezv oltatorii 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 ședi nță 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 exper imentat
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)

– 23 –

Figura 6 – Termenii de bază în Extreme Programming [20]

2.2.2 Avantaje și dezavantaje
Avantajele acestei metode Agile sunt clare: produsul livrat este de o calitate
superioară, bug urile 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. Ec hipa 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].

– 24 –

2.3 Test Driven Development
Test Driven Development (TDD) este o tehnică de programare baza tă 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 teste le 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ându –
se 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

– 25 –

să cunoască foarte bine cerințele în aintea 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ă s unt î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 c are 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 p as 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 codulu i
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 realize ază
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

– 26 –

adesea major, și anume faptu l 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 superioa re 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 în tre 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

– 27 –

2.4 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 c odului 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 comi t 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ă p e 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 s erver de control al versiunilor
Chiar și în cazul frecvent în care se lucrează cu diver se 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 exist entă 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 rezolvat e apoi

– 28 –

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șin ile 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 pun ct este esențial, deoarece se dorește reproducerea d efectelor din producție cu
cât mai multă acuratețe . Acest lucru în seamnă 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ă d eployment 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ă me reu 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 ce rințele
clientului.

– 29 –

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

– 30 –

2.5 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 or ice 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 t rebuie 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, testeri i 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 proce sul 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]

– 31 –

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ăru l
aferent. Oricare dintre coloane poate conține itemi în curs și terminați, figura exemplifică
acest lucru doar pe două dintre coloane.

– 32 –

3. 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 f olosesc î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. Dezvol tatorii 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.

– 33 –

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 -story –
uri), apoi fiecar ui 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 u n
singur dezvoltator. Este o estimare simplă și nu necesită găsirea de legături între user –
story -urile dintr -un sprint.
Uneori se folosește în acest caz estimarea în 3 puncte, care se realizează precum
urmează:

– 34 –

– 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ă
–
2.2 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 co mparate 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 (man –
hours, 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 deoseb ire de estimarea
simplă pe zile.
O variantă a estimării folosind punc te 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 es te 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 di ferenț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]:

– 35 –

Figura 10 – Cărți specifice estimării Poker [18]

– 36 –

4. 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 stad iu 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 d in 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 industri a
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 afe ctat, 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 ac eleaș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

– 37 –

4.1 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 p e 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. Res pectivul 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 sun t 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 d e 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 e xemplu, limbaj pe care

– 38 –

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 tasku rile 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.

– 39 –

4.3 Aplicația Scrum Planner
4.3.1 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 sin gur 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 ca re
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 produc tivitatea 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 Productivit y Index

– 40 –

Figura 1 1: lista de taskuri ale sprintului curent, împreună cu informații despre ele

4.3.2 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. Ponderil e 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 s arcinilor 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 sed ință 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 .

– 41 –

Figura 1 2: Pagina de detalii a unui dezvoltator, conținând detalii despre skilluri,
productivity index, taskuri atribuite

4.3.3 Productivity index (indexul de productivitate)
Acest index este specific fiecărui dezvoltator în parte, ținandu -se cont de skillu rile
anterioare (ponderea și valoarea). Se calculează conform formulei următoare:
∑(
)

Unde simbolurile sunt:
Pi = Ponderea Skillului cu indexul i

– 42 –

Vi = Valo area 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 ).

4.3.4 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 dezv oltatorul 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 tas kul T
PIR – Indexul de productivitate al dezvoltatorului D
Formula folosește o diferență între 100 și Productivit y Index, deoarece, cu cât acesta
este mai mare, cu atât a cel 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.

– 43 –

Figura 12: pagina de editare a unui task sugerează numele unui alt dezvoltator, care
ar putea rezolva taskul în mai puțin timp

4.3.5 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
atribu ie în funcție de experiență, cunoașterea tehnologiilor etc. În Scrum, dezvoltatorii

– 44 –

decid singuri cum iși vor atribui taskurile , de aceea este important ca aplicația să per mită
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 înc epâ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ă ce rtitudinea 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, înain te 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:

– 45 –

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:

– 46 –

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

– 47 –

Oscar Wilde, cu un index de 77.60, iar cel cu indexul de productivitate cel mai mic
este Dan Brown, cu un index de 39.23.
În figura de mai jos s e 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 pu tem observa noile valori per user -story:

– 48 –

Durata totală posibilă s -a redus la 107 ore, iar întârzierea totală posibilă este acum de
doar 27 de ore. Acest algoritm a redus intârzierea posibilă de la 42% la 33% din perioada
estimată.

4.3.6 Tehnologii folosite
Aplicația folosește tehnologiile .NET 4.5, ca platformă generală de dezvoltare.
Limbajul de back -end este C# 4.5, iar pentru front se folosește ASP.MVC 4, rezultând
o arhitectură Model View Controller.
Baza de date folosită este SQL Server Expres s 2008, iar ca Object Relational
Mapping (ORM) se folosește Entity Framework 5, disponibil în regim open -source.
Pentru limbajul de scripting pe partea de client se foloseșste JavaScript și librăria
jQuery.

4.3.7 Dezvoltări viitoare
Aplicația poate fi cu ușurin ță extinsă pe viitor, prin adăugarea de noi module sau
îmbunătățirea celor existente. Printre aceste planuri de extindere se pot include:
o adăugarea de funcționalități pentru a realiza review -uri pentru membrii echipei, în
funcție de productivitatea lor în timp
o realizarea de grafice pentru a se observa estimările, timpul petrecut pe taskuri, timpul
rămas etc.
o adăugarea de tipuri noi de resurse (ex: testeri), care să aibă seturi diferite de skill -uri,
pentru a extinde funcționalitatea existentă și la alte tip uri de echipe
o adăugarea unui modul de pontaj, prin care membrii echipei pot raporta timpul petrecut
pe diverse taskuri, și a unei funcționalități care calculează diferențele dintre estimări și
timpul real, prin care se pot observa mai ușor capacitățile mem brilor echipei

– 49 –

Concluzie
Aplicația Scrum Planner oferă o imagine nouă estimărilor clasice, punând accent pe
om în locul taskului. Programatorul, respectiv cel ce realizează taskul este cel de care
trebuie să ținem seama atunci când estimăm.
Aplicația poate fi extinsă pentru a urmări și evoluția în timp a estimărilor și de a oferi
rapoarte bazate pe diverse sprinturi. Un project manager poate observa și evoluția unui
programator, care poate de exemplu să își îmbunătățească performanțele, să învețe
tehno logii noi și să capete experiență. Folosind indexul de productivitate, se pot face
evaluările programatorilor etc.
Aplicația poate fi extinsă pentru echipele de testare, suport, sau chiar pentru echipe
din afara sferei IT, pentru un mai bun management al t impului, respectiv al riscului de
întârziere.
Agile este o mulțime de metodologii care, pentru a avea rezultate cât mai bune,
trebuie folosite împreună. Importantă este cunoașterea proprietăților specifice fiecarei
metodologii și mularea pe proiectul care urmează a fi dezvoltat, precum și pe echipa de
dezvoltatori, testeri, business analiști, project manageri care vor lucra împreună la proiect.
Nu există nici o metodologie potrivită perfect oricărui tip de proiect și oricărei echipe.
Decizia de a folosi Agi le nu poate fi luată peste noapte, este nevoie de studiu și
consultarea tuturor membrilor echipei, dar este o decizie care, conform susținătorilor săi,
va îmbunătăți considerabil procesul de dezvoltare software. În ziua de astăzi, multe
companii IT și mulț i clienți ai acestora se orientează spre aceste metodologii moderne,
deoarece au incredere în rezultatele obținute.
Agile este o direcție care câștigă teren, iar în viitor probabil că vom vedea toate
proiectele IT conținând, măcar intr -o mică parte, idei p reluate din metodologia Agile.

– 50 –

Bibliografie

[1] Agile Manifesto – http://agilemanifesto.org/
[2] Agile Alliance – http://www.agilealliance.org/
[4] Mikolouk , Kasia – Agile Vs. Waterfall: Evaluating The Pros And Cons (2013)
[5] Fowler , Martin – The New Methodology (2005)
[6] Forsyth , Aaron – Waterfall vs Agile Models in Software Development (2013)
[7] Boehm, Barry – A Spiral Model of Software Development and Enhancement (1986)
[8] Scrum and Agile Training and Consulting – http://www.mountaingoatsoftware.com
[9] Sims, Chris – Scrum: A Breathtakingly Brief and Agile Introduction
[10] Mar, Kane; Schwaber, Ken – Scrum with XP (2010)
[11] Zuiderveld, Nicholas – eXtreme Programming and Scrum: A comparison of Agile
methods
[12] http://www.kanbanblog.com/
[13] http://www.learnaccessvba.com/application_development/waterfall_method.htm
[14] http://ultimatesdlc.com/spiral -model/
[15]http://www.codeproject.com/Articles/320791/Developing -Factorial -Application –
Using -Test-Driven
[16] Cohn, Michael – Agile Estimation and Planning
[17] Martini, Arialdo – 8 practical rules for producing decent estimates (2012)
[18] http: //www.codeproject.co m
[19] http: //www.cprime.com

– 51 –

[20] http: //www.xpprogramming.com
[21] http://grouper.ieee.org/