-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 Waterfall – 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 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.
 -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 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, î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 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

 - 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 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]:
 - 11 -

Figura 2: Cadranele modelului în spirală

Această metodologie a fost descrisă pentru prima oară de către Barry Boehm în 1986.
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.
 - 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.

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
 - 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 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,
 - 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 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.
 - 16 -

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

2. 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.
 - 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 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.
 - 19 -

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]

2.1.1 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
 - 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 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.
 - 21 -

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

2.2.1 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
 - 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ă 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)
 - 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ă, 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].
 - 24 -

2.3 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â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 î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
 - 26 -

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
 - 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 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
 - 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ş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.
 - 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 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]

 - 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ărul
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 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.
 - 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 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 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 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 (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 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]:
 - 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 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
 - 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 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
 - 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 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.
 - 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 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
 - 40 -

Figura 11: 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. 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.
 - 41 -

Figura 12: 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 skillurile
anterioare (ponderea şi valoarea). Se calculează conform formulei următoare:

∑ ( )

Unde simbolurile sunt:

Pi = Ponderea Skillului cu indexul i

 - 42 -

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

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 dezvoltatorul atribuit. Atribuirea taskului altui dezvoltator modifică orele
reale. Acestea se calculeazo conform formulei:

( )
Unde simbolurile au următoarea semnificaţie:

RHT – Orele reale ale taskului T

EHT – Orele estimate pentru taskul T

PIR – 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.
 - 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
atribuie î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ă 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:

 - 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 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:

 - 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 Express 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 tipuri 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 membrilor 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
tehnologii 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 timpului, 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 Agile 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 preluate 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.com

[19] http: //www.cprime.com

 - 51 -

[20] http: //www.xpprogramming.com

[21] http://grouper.ieee.org/