-5-

Cuprins
Introducere ............................................................................................................................ - 7 -

1. Introducere n Agile ....................................................................................................... - 8 -

1.1 Waterfall (metodologia n cascad sau tradiional) ................................................... - 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 folosii 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 funcionalitii ............................................................................. - 25 -

d. Rularea testelor scrise la primul pas ..................................................................... - 25 -

e. Refactorizarea codului.......................................................................................... - 25 -

2.4 Continuos Integration ........................................................................................... - 27 -

a. Integrarea trebuie fcut mcar zilnic .................................................................. - 27 -

b. Trebuie s existe un singur server de control al versiunilor ................................. - 27 -

 -6-

c. Build-ul s fie testabil automat............................................................................. - 27 -

d. Existena unei maini de integrare ....................................................................... - 27 -

e. Testele s se fac pe o copie identic a mainilor de producie ........................... - 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. Aplicaia Scrum Planner pentru managementul estimrilor ........................................ - 36 -

4.1 Problema.................................................................................................................... - 37 -

4.2 Soluia propus ..................................................................................................... - 38 -

4.3 Aplicaia Scrum Planner............................................................................................ - 39 -

4.3.1 Termeni folosii .................................................................................................. - 39 -

4.3.2 Skills calitile 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 Dezvoltri 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 astzi de o cretere continu n
popularitate n rndul companiilor de pe piaa IT. Lucrarea descrie punctele comune i
punctele diferite ale fiecrei metodologii n parte, precum i recomandri pro i contra
folosirii lor n diverse proiecte, n procesul de dezvoltare software.

Prin lucrare nu se dorete incurajarea unui anumit tip de metodologie n detrimentul

celorlalte, ci sublinierea faptului c ele pot fi folosite mpreun pentru a obine cele mai
bune rezultate n procesul de dezvoltare. Lucrarea incurajeaz cunoaterea acestor
metodologii i recomand alegerea uneiasau mai multe n funcie de proiectul care va fi
dezvoltat, lund n calcul recomandrile prezentate.

n lucrare se propune un nou mod de abordare a estimrilor n echipele Agile, contrar

frameworkurilor i aplicaiilor de estimare care exist pe pia n ziua de azi, respectiv
estimarea relativ la resursele folosite, i anume programatorii.

Deoarece fiecare programator, n funcie 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 cunoatere a tehnologiilor, aplicaia propus, Scrum Planner, ofer o
imagine diferit estimrilor, n funcie de programatorul care va rezolva taskul. De
asemenea propune un algoritm de atribuire automat a taskurilor, astfel ca ntrzierile
intr-un proiect s fie minimizate.

Ideea poate fi extins i la altfel de echipe IT, pretndu-se foarte bine i echipelor de
testare, care lucreaz n acelai timp cu echipele de dezvoltare, deoarece aceleai diferene
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
discuia despre ce metodologie de dezvoltare se va folosi. Acest aspect este o decizie
suficient de important si va genera discuii si dispute aprinse, ntruct este foarte dificil
sau chiar imposibil sa fie schimbat n decursul proiectului, fr a afecta planificarea
iniial. 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 astzi ar fi Waterfall i Agile, cu tendina
metodologiei Agile de a ctiga teren fa de clasicul Waterfall, celelalte reprezentnd o
pondere mai mic n ingineria software, fiind n schimb folosite n alte domenii.

1.1 Waterfall (metodologia n cascad sau tradiional)

Se remarc printr-un proces iterativ linear, cu un numr 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 coninnd etape similare a fost inut in 1956 de ctre 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 aprarea aerian automata a Americii de Nord.

Prima prezentare formal a procesului a avut loc de fapt mult mai trziu, n 1970, ntr-
un articol al crui autor a fost Winston Royce, acesta nefolosind termenul waterfall n
prezentarea sa. Royce l-a prezentat ca pe un model intens folosit, care este greit si
nefuncional.
 -9-

Termenul de waterfall sau cascad a aprut mai trziu, datorit definiiei etapelor,
n stil top-down, fr 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 urmtoare, ca n Figura 1 de mai
jos [13]:

- Analiza cerinelor mpreun cu clientul

- Designul sau arhitectura sistemului
- Implementarea proiectului, alctuit din 2 subetape:
o Scrierea codului de ctre dezvoltatori, din care rezult proiectul software
o Integrarea prilor componente n sistemul nou sau existent
- Verificarea sistemului, care include testarea si rezolvarea eventualelor defecte
- Instalarea proiectului software pentru client
- Mentenana

Figura 1: Etapele metodologiei Waterfall

 - 10 -

Acestui tradiional model de dezvoltare i s-au adugat modele modificate de-a lungul
anilor, n funcie de necesitile de moment, pstrnd totui neschimbate conceptele de
baz.

1.2 Prototipul
Acest modelul de dezvoltare implic definirea iniial 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 demonstraie pentru client [8].

Modelul acesta a fost derivat din Waterfall, n acele cazuri cnd cerinele iniiale nu
sunt foarte clare. n timpul procesului de construire a acestui model, clientul va oferi
feedback din cnd n cnd, acest fapt conducnd la obinerea acestui prototip. Avnd
confirmarea de la client la terminarea construciei acestui prototip, este posibil editarea
unui document de specificaii. 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 aezate 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 ctre 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 dezvoltrii, iar fiecare faz va fi alctuit din 4 pai [7],
descrii mai jos:

1. Se determin obiectivele (unde trebuie s se ajung) i constrngerile datorate

costurilor, tehnologiei disponibile etc.
2. Se analizeaz riscurile i alternativele. Orice problem legat de tehnologie se va
soluiona 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 urmtoare.
 - 12 -

1.4 Agile
Datorit greutilor ntmpinate n timpul dezvotrii proiectelor folosind waterfall, a
fost prezentat in 2001 o metodologie numit generic Agil, bazat pe etape
incrementale si repetitive, n care cerinele se dezvolt pe parcurs, avnd suportul ntregii
echipe i de asemenea axndu-se pe colaborarea intens ntre membrii echipei.

Termenul agile a fost prezentat n 2001 de ctre autorii Agile Manifesto [1], o
proclamaie a unor valori cheie si principii de dezvoltare, care are 17 semnatari.

Cele 4 valori [1] cheie prezente n Manifesto ncurajeaz:

1. Indivizii si interaciunea dintre ei fa de unelte si procese

2. Software funcional peste documentaie foarte complet si complex
3. Colaborarea cu clientul peste negocierea de contracte
4. Reacie la schimbare n schimbul urmririi unui plan

Cele 12 principii [1] ale Agile sunt:

1. Satisfacerea dorinelor clientului nc de la inceputurile proiectului si livrarea
continu de munc de calitate
2. mprirea sarcinilor mari n componente mici care se pot rezolva rapid
3. Recunoaterea faptului c munca de calitate rezult din echipe independent organizate
4. Alocarea de mediu i suport necesar indivizilor motivai si increderea c acetia ii
pot duce munca la bun sfrit
5. Crearea de procese care promoveaz efortul susinut
6. Meninerea unui ritm constant al muncii
7. Adaptarea rapid la cerine care se schimb, chiar i spre sfritul proiectului
8. Realizarea unor edine 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. Msurarea progresului prin cantitatea terminat din proiect
11. Incercarea constant de a atinge perfeciunea
 - 13 -

12. Valorificarea schimbrilor 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 aceti autori au decis formarea alianei Agile [2], o organizaie non
profit care promoveaz i astzi devoltarea Agile, conform principiilor si regulilor de mai
sus. Dei iniial nu foarte cunoscut, metodologia a inceput s prind contur pe parcursul
ultimilor ani, n 2005 fiind publicat un addendum la Agile Manifesto, numit Declaraia
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 calitile codului i proiectului final, dect pe

partea financiar rezultat din proiectele software.

Figura 4: Agile Alliance logo [2]

1.5 Agile vs Waterfall pro i contra

Dei ncep sa fie din ce in ce mai populare, metodologiile Agile nu au luat total locul
metodologiilor tradiionale si cel mai probabil pe viitor vor fi folosite ambele n proporii
variabile.

Printre calitile Agile putem numra n primul rnd flexbilitatea i capacitatea de

schimbare, chiar foarte trziu n procesul de dezvoltare [6]. Modelul este extrem de
flexibil, inginerii software lucrnd la module mici, discutnd 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 cnd imaginea
de final nu este foarte bine definiti i clientul vede pe parcurs ce anume dorete,
clarificndu-se foarte mult cerinele cu ct proiectul se apropie de sfrit. n acelai timp,
acest model ncurajeaz foarte mult comunicarea, atat client-dezvoltator, ct i in cadrul
echipei de dezvoltare, mici module fiind lucrate de programatori simultan i integrate la
sfrit.

Dezavantajele acestei metologii ar fi dificultatea estimrii atat a timpului, ct 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 dect 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 numrm un plan clar de lucru
la inceputul proiectului i posibilitatea unei estimri mai acurate [4]. Timpul de lucru si
bugetul sunt mult mai bine planificate, ceea ce este de obicei pe placul clienilor.
Deoarece se pune accent pe documentare si planificare, nlocuirea unui individ n timpul
procesului de dezvoltare nu este foarte dificil, o persoan nou putnd cu uurin s ia
locul altcuiva n timpul procesului de dezvoltare.

Pe de alt parte, dezavantajele acestei metode numr rigiditatea si lipsa de

flexibilitate pe parcursul ntregului proces. Etapele sunt bine fixate de la inceput, estimate
destul de exact, iar schimbrile n timpul procesului pot fi foarte dificile i necesit
eforturi considerabile. De asemenea, n cazul metodologiei clasice tradiionale de tip
cascad, testarea de orice fel are loc destul de trziu n cadrul proiectului, ceea ce face ca
soluionarea problemelor majore gsite s necesite timp i buget, de multe ori n afara
celor planificate iniial.

1.6 Ce alegem
Alegerea unei metodologii la nceputul proiectului poate fi dificil, ntruct este clar c
nici una nu este potrivit pentru toate cazurile i toate tipurile de proiecte. Susintorii
ambelor metodologii vor exista mereu i asta deoarece fiecare are avatanje considerabile
i se poate plia pe anumite tipuri de proiecte mai bine dect opusa ei.

n general, Waterfall tinde s fie mai util atunci cnd se estimeaz multe schimbri
pe parcursul proiectului, cnd se cunoate bugetul clientului de la nceput i ceea ce se
dorete a se obine 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
interaciune 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 tendine de schimbare pe
parcurs, echipe mai mici i independente, de obicei localizate n acelai loc.

n multe cazuri, procesul de dezvoltare ncepe Waterfall, ca imagine de ansamblu, i

continu Agile pe diverse module mai mici, n momentul cnd apare nevoia de detalii
insuficient descrise de cerine sau omise. Nu exist vreo abordare lege, ci se alege n
funcie de proiect, echip i experiena 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 interaciune intens ntre membrii echipei i adaptabilitate crescut la schimbrile ce
au loc pe parcursul dezvoltrii proiectului.

Majoritatea metodelor se bazeaz pe mprirea proiectului n mici module, uor de

dezvoltat i gestionat fr planificarea lor intensiv. Modulele se dezvolt n iteraii,
uneori numite sprinturi, care pot dura de la o sptmn pn la dou luni, dar preferabil
ct mai puin pentru a avea certitudinea livrrii unui produs calitativ, precum i a lsa loc
shimbrilor rapide ce pot avea loc. n timpul acestor iteraii, este esenial colaborarea
ntre membrii echipei, pentru a fi siguri c se realizeaz n mod corect toate etapele
dezvoltrii: planificarea, analiza cerinelor, arhitectura modulului, implementarea,
testarea.

O caracteristic destul de comun a metodelor Agile este prezena unor edine

zilnice, n care fiecare membru al echipei descrie ce a fcut n ziua anterioar, ce are de
fcut n continuare i ce probleme ntmpin, pentru ca ceilali mebri al echipei s l poat
eventual ajuta i ghida spre soluionarea problemelor.

Este necesar ca echipele s fie alctuite din indivizi cu diferite responsabiliti pentru
a putea fi atinse toate punctele anterioare. De asemenea este necesar prezena n
permanen a unui reprezentant al clientului la edinele ce au loc n cadrul echipei de
dezvoltatori sau posibilitatea contactrii acestuia n permanen, pentru a confirma cu
acetia cerinele necesare i a clarifica problemele decizionale care s-ar putea ivi.

Sfritul unui sprint nu are ca scop livrarea unui produs final, ci mai degrab livrarea
unor funcionaliti cu un numr 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 schimbri si planificare iniial minimal. Procesul Scrum se realizeaz n
scurte iteraii numite sprinturi, care dureaz pn la patru sptmni. Fiecare sprint ncepe
cu o sedin scurt de planificare i se finalizeaz cu un review. Ideea principal este de a
lsa dezvoltatorilor posibilitatea de a se auto planifica, ntruct ei sunt cei mai in msur
s estimeze si s realizeze corect livrarea i de asemenea de a rezolva problemele pe
msur ce acestea apar. n momentul de fa este cea mai des folosit metod din
categoria Agile, de sine stttoare sau n combinaie 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 lsate la
latitudinea echipei. Ei vor decide impreun sarcinile ce le va realiza fiecare membru n
parte i cum se rezolv problemele aprute pe parcurs. Toi sunt responsabili n aceeai
msur 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 sfarit (aa 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 edine (scrum zilnic), n care fiecare membru
va lua cuvntul pentru a prezenta ce a realizat n ziua anterioar, ce mai are de fcut i ce
eventuale probleme ntmpin. Taskurile se pot rempri n cazul n care unele dureaz
mai mult i altele mai puin dect estimate, pentru a realiza terminarea lor pn la sfritul
sprintului. Aceste edine sunt foarte importante n Scrum i ar trebui realizate cu
regularitate, deoarece astfel toi membri echipei vor fi pui la curent cu statusul
proiectului, progresul si probleme ivite, dar se realizeaz i sincronizarea taskurilor
membrilor. Aceste edine nu ar trebui s dureze mai mult de 15 minute.

La sfritul unui sprint se va realiza o demonstraie a livrrii mpreun cu un

reprezentant al clientului i echipa de dezvoltatori. Astfel se poate primi feedback de ctre
client i rezolva problemele aprute, precum i schimbarea anumitor specificaii dac este
necesar.
 - 19 -

De asemenea tot la sfritul sprintului, se face un o retrospectiv cu toi membri

echipei, pentru a se observa ce a mers bine, ce a mers prost si cum se poate mbunti
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 cteva roluri
secundare [9]:

a. Product Owner
Product Ownerul lucreaz n strns legtur cu clientul i este responsabil de
comunicarea cu echipa de dezvoltatori si explicarea acestora viziunea clientului asupra
proiectului. El reprezint interesele clientului prin descrierea cerinelor i prioritizarea lor
 - 20 -

corect. n general, n marile companii, acest rol are i responsabilitile unui Project
Manager, acest lucru neafectnd responsabilitile lui principale n dezvoltarea Scrum

b. Scrum Master
Scrum Masterul se asigur c procesul Scrum este urmat cu strictee si nu exist
impedimente care ar putea afecta livrarea la sfritul 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 alctuite din ingineri software, analiti, arhiteci,
programatori, testeri, designeri. Fiecare dintre aceti membri particp la sedinele zilnice
i ia parte la luarea de decizii. Echipa este autonom, fr a fi nevoie de prezena unui
team-leader.

d. Roluri secundare
Printre rolurile secundare se numr Stakeholders (prile interesate) clienii, care au
interes n finalizarea produsului, reprezentai de ctre Product Owner, i utilizatorii finali,
care sunt cei crora li se adreseaz produsul.
 - 21 -

2.2 Extreme programming (XP)

Aceast metodologie se bazeaz pe livrri rapide n cicluri scurte, orientat foarte
mult pe codul scris. Din acest motiv folosete tehnici ca pair-programming, unit testing pe
tot codul, code review n mod extensiv, i se aseaz pe pstrarea claritii si simplitii n
cod. Comunicarea ntre membrii echipei i client este incurajat foarte mult.

Dei la prima vedere pare foarte similar ca metodologie cu Scrum, ntre cele doua
exist i diferene notabile [10]:

o Sprinturile Scrum sunt pn la 4 sptmni, n XP se prefer iteraiile mai scurte, de

pn la 2 sptmni
o n Scrum nu se permit modificri n timpul sprintului, iar edina de sprint planning
este fcut pentru a se decide asupra unei liste de taskuri ce trebuie livrat la sfritul
sprintului; XP permite modificri n timpul sprintului, interschimbri ale unor taskuri
cu altele care ar avea aceeai durat, atta timp cat taskurile care se vor scoate nu au
fost ncepute deja
o n Scrum, prioritizarea sprinturilor este fcut n general de cter 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
obinerea unei caliti superioar a codului, cum ar fi unit-testing i testarea automat,
abloane de proiectare, refactorizare, pari programming, standarde de coding.

2.2.1 Termeni folosii n Extreme Programming

Extreme programming conine o list de termeni, mai precis de bune practici, pentru
ca metolodogia de dezvoltare s poat fi considerat ca fcnd parte din aceast
categorie, printre care se numr:
o Test Driven Development, explicat pe larg n capitolul urmtor
o Continuous integration, explicat ntr-un capitol viitor
 - 22 -

o Standarde de coding, printre care se numr respectarea notaiilor, regulilor de

coding, Clean coding i principiile SOLID
o Ritm sustenabil, cea ce nseamn c intreaga echip trebuie s munceasc n
acelai ritm, care este de obicei unul alert
o Refactoring, adic fiecare dezvoltator are obligaia mbuntirii codului
existent n momentul cnd lucreaz la un task
o Codul ca proprietate colectiv, respectiv toi dezvoltatorii trebuie s cunoasc
toate parile din proiect, nu se mpart pe module
o Planning game, care este o sedin de planificare, fcut la inceputul
sprintului. Nu se fac edine zilnice, dar, dat fiind faptul c sprinturile sunt scurte, o
astfel de edin va avea loc o data la 1-2 sptmni. Uneori, n aceast edin se
folosete planificare de tip poker, descris n capitolul urmtor
o Pair-programming, concept cheie care de obicei difereniaz extreme
programming de alte metodologii, reprezint munca n grupuri de cte doi, n cazul
ntmpinrii unor probleme mai complexe. n alte metodologii de dezvoltare, acest tip
de programare se folosete pentru ca un membru nou al echipei s fie familiaizat mai
uor cu proiectul, nvnd de la un membru mai experimentat
o Metafora sistemului, care reprezint viziunea comun iniial a echipei fa de
cum trebuie proiectul s arate i s se comporte
o Design simplu, pentru ca sistemul s poat fi extins cu uurin
o Testarea la nivel de client, pentru a-i oferi acestuia produsul conform
cerinelor sale
o Livrri scurte i dese (1-2 sptmni)
 - 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 puine, schimbrile n proiect sunt fcute exact atunci cnd este
nevoie i clientul supervizeaz evoluia prin prioritizarea taskurilor. Dezavantajele ar
numra faptul ca nu fiecare echip se preteaz la acest tip de metodologie, deoarece este
nevoie de programatori care s fie bine pregtii i cu o experien clar n spate. Este
dificil pentru programatorii juniori sau pentru inidivizii noi venii s se integreze cu toate
tehnicile de dezvoltare folosite n XP i s in pasul cu ceilali. Echipa trebuie s fie n
acest caz ct 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 sigurana unui cod lipsit de defecte n procent ct mai mare,
acest lucru favoriznd o mentena uoar i lipsit de probleme majore.

Fa de metodele trasiionale de programare, n TDD este necesar ca testele s fie

scrise naintea codului, iar codul s fie scris n asa fel nct la sfrit 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 alctuit din mai multe faze, ca n figura de
mai jos [15]:

a. Adaugarea unui nou test

Fiecare funcionalitate nou ncepe cu scrierea a unuia sau mai multor teste. Bazndu-
se pe cerine i cunoscnd foarte bine use-case-urile, un developer va scrie teste ca s
acopere ntreaga funcionalitate, aa cum va fi ea vzut de ctre utilzatorul final. Acest
detaliu, de a scrie testele naintea implementrii noi funcionaliti va face dezvoltatorul
 - 25 -

s cunoasc foarte bine cerinele naintea scrierii codului, ceea ce va ridica considerabil
calitatea codului i va mbunti aria de acoperire a sa.

b. Rularea testelor scrise anterior

n acest pas este extrem de omportant ca testele noi scrise s eueze. Astfel,
dezvoltatorul se asigur c sunt ndeplinite urmtoarele condiii:

- Funcionalitatea nou nu exist deja

- Testul este valid
n caz contrar, se va repeta primul pas i se va investiga ce anume a fost greit.

c. Implementarea funcionalitii
n aces pas, singurul scop este scrierea de cod care va face testele s fie terminate cu
succes. Nu este esenial atenia la calitatea codului, este important viteza cu care noua
funcionalitate este scris. Acest pas trebuie s dureze ct mai puin.

d. Rularea testelor scrise la primul pas

n acest pas, spre deosebire de pasul al II-lea, testele trebuie s treac. n caz contrar,
pn cand nu trec toate testele, dezvoltarul se va ntoarce la pasul anterior, repetndu-l
mpreun cu pasul curent, n ciclu, pn cnd toate testele trec.

e. Refactorizarea codului
Avnd certitudinea faptului c noua funcionalitate este complet implementat i n
conformitate cu cerinele, aces pas se asigur de calitatea codului. Codul va fi refactorizat,
respectnd tehnicile moderne de ingineria programrii. Acest pas se realizeaz
conconmitent cu pasul anterior, pentru a avea certitudinea c refactorizarea nu cauzeaz
defecte n funcionalitatea existent.

Toate etapele de mai sus se vor repeta ori de cte ori este necesar, pn la sfritul
proiectului. Acest tip de dezvoltare determin o mare calitate a codului scris i se asigur
c defectele sunt descoperite i reparate ct 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 cteva reguli best-practice, care ajut la obinerea
unei caliti superioare a TDD i implicit, a proiectului final. Printre ele se numr:

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 esenial 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 asteptrile
o Codul duplicat trebuie ters la fiecare refactoizare
o Orice refactorizare, orict de mic, trebuie s fie urmat de rularea suitei de
teste
o Codul nou trebuie scris doar atunci cnd un test pic; n caz contrar, ceea ce
trebuie fcut este o refactorizare
o n prim faz, codul care trebuie scris pentru ca testul s treac trebuie s fie
ct de simplu posibil
o Trebuie sa se elimine dependeele ntre teste: n orice ordine ar rula, testele
trebuie s aib aceelai comportament
o Testele trebuie s fie rapide, n caz contrar exist riscul s se treac cu vederea
testele lente i astfel va exista funcionalitate netestat sau testat insuficient
 - 27 -

2.4 Continuos Integration

Integrarea continu este un proces de dezvoltare software prin care codul comis de
ctre dezvoltatori pe un server de control al versiunilor trece prin diverse etape, pentru a
asigura calitatea integrrii n mod constant. Integrarea codului se poate face prin mai
multe metode, iar n Continuos Integration este necesar ca acest lucru s fie fcut de mai
multe ori pe zi.

Printre principiile acestui proces se numr:

a. Integrarea trebuie fcut mcar 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 fiecrui
dezvoltator, dar, dac acest lucru nu este posibil, se recomand ca aceast procedura s se
fac mcar 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 aceluiai proiect,
este esenial s existe o versiune principal i taskuri automate care s faca eventualele
merge-uri ntre versiuni, pentru a le aduce la nivel similar. Existena mai multor copii ale
aceluiai 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, ct i pentru a fi siguri c funcionalitatea existent nu a
fost afectat n vreun fel de ctre noul cod.

d. Existena unei maini de integrare

Este preferabil ca fiecare build automat s beneficieze de o main separat pentru
integrare, n care eventualele probleme ale integrrii automate s fie rezolvate apoi
 - 28 -

manual, nainte s se fac un deployment pe mainile de test. n acest caz se evit

diversele neconcordane ntre mainile de development i mainile de test, dar n acelai
timp se optimizeaz timpul pierdut pentru refacerea deploymentului pe mainile de test,
n cazul n care acesta nu a reuit de prima oar.

e. Testele s se fac pe o copie identic a mainilor de producie

Acest punct este esenial, deoarece se dorete reproducerea defectelor din producie cu
ct mai mult acuratee. Acest lucru nseamn copierea bazelor de date si serviciilor din
producie ct mai des, recomandabil zilnic, de ctre taskuri automate.

f. Deploymentul automat
Deploymentul automat uureaz foarte mult munca dezvoltatorilor. Ideal ar fi s
existe taskuri care realizeaz deployment automat pe toate mainile de integrare i testare,
eventual i n producie. Eventualele greeli de integrare pot fi apoi rezolvate manual, dar
un proces automat minimizeaz existena erorilor umane.

Continuous Deployment este un concept similar cu Continuous Integration, diferena

fiind scopul acestuia. Continuos Deployment se refer la livrarea n producie a acelor
pri din proiect care au respectat o parte din paii de mai sus: au trecut buildul i testele
automate. Aces lucru nseamn c mereu se va livra software calitativ, fr a fi afectate
funionalitile deja existente, iar livrrile se vor face foarte frecvent. De asemenea,
livrarile vor avea un grad sczut de risc i vor putea fi adaptate foarte rapid la cerinele
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
producie n orice domeniu. Dei tehnologia construciilor de maini nu are foarte multe
similariti cu ingineria software, procesul Kanban a fost bine primit n ultima vreme i se
regsete printre metodologiile Agile.

Se presupune c un proces de dezvoltare software trebuie s mearg continuu i

uniform. Dar frecvent vor aprea acele blocaje numite bottleneck, ca de exemplu: testerii
au capacitatea de a testa 5 bug-uri pe sptmn, dar dezvoltatorii sunt capabili s fixeze
10 buguri pe sptmn. n acest caz, testerii vor fi cei care creeaz blocajul [12].
Testerilor li se vor acumula volume imense de munc i inevitabil, produia va fi
ncetinit, clientul va fi nemulumit etc. Din pcate, blocaje similare se pot ntmpla la
momente diferite oricror roluri din procesul de dezvoltare, problemele nefiind vizibile la
timp.

Kanban i propune s rezolve aceast problem, limitnd dinamic volumul de munc

al fiecrui rol, folosind aa numita tabl Kanban, ca in figura de mai jos [11]:

Figura 8 Tabel Kanban [18]

 - 31 -

Cifrele de deasupra fiecrui pas reprezint numrul maxim de itemi care pot fi la un
moment dat n curs n pasul respectiv. Dac acest numr este depit pe vreuna dintre
coloane, aceasta devine blocaj i trebuie gsite rapid soluii pentru a scdea numrul
aferent. Oricare dintre coloane poate conine itemi n curs i terminai, 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
prile implicate ntr-un proiect software. Pornind de la calcule simple i pn la algoritmi
compleci, estimrile 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 ct va dura un task, deoarece exist prea muli factori de luat n considerare,
factori care includ tehnologiile folosite, experiena pe proiect, resursele fizice pe care va
rula proiectul etc.

n Agile exist dou tipuri de estimri 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]. Dei n trecut estimarea pe zile a fost mai des folosit,
metodologiile tradiionale avnd nevoie de estimri stricte pe perioade lungi de timp,
odat cu apariia Agile a inceput s prind contur estimarea bazat pe puncte [17].

n ambele cazuri, estimarea are loc n 4 pai standard, care se pot vedea n figura de
mai jos:

1. Clientul descrie user-story-urile

2. Dezvoltatorii estimeaz individual
3. Are loc o discuie pe baza estimrilor, n care se aduc argumente de ce s-a estimat
astfel
4. Dezvoltatorii estimeaz din nou individual

Dac este nevoie, ultimii 2 pai se pot repeta pn cnd se ajunge la un consens.
 - 33 -

Figura 9 Paii 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 reunete n sedina de Sprint planning,
se decide ce se va livra n cadrul sprintului (acel Sprint backlog, alctuit din user-story-
uri), apoi fiecarui user-story i se va ataa un numr de zile n care trebuie s fie terminat.
Aceste zile reprezint de fapt numrul de zile n care va putea fi rezolvat de ctre un
singur dezvoltator. Este o estimare simpl i nu necesit gsirea de legturi ntre user-
story-urile dintr-un sprint.

Uneori se folosete n acest caz estimarea n 3 puncte, care se realizeaz precum

urmeaz:
 - 34 -

- se decide cam ct ar dura realizarea taskului

- se decide ct va dura n cel mai bun caz i n cel mai ru caz
- se face media celor 3 estimri, rezultnd 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 crui 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, asignndu-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 numr de ore sau zile (man-
hours, man-days), iar celorlalte li se vor asigna estimri egale cu estimarea celei mai
simple nmulit cu numrul din irul lui Fibonacci aferent. Astfel se pot lua n calcul i
eventualele ntrzieri (similar cu un worst-case-scenario), spre deosebire de estimarea
simpl pe zile.

O variant a estimrii folosind puncte este planificarea poker, denumit astfel

deoarece se folosesc cri de joc sau cartonae coninnd numerele din irul lui Fibonacci.
Fiecare membru al echipei primete un set de astfel de cartonae i estimeaz, pe rnd,
cte un user-story. Important este la acest tip de estimare ca toi membrii echipei s arate
cartonaele pentru acelai user-story n acelai timp, pentru a nu fi influenati ntre ei. Se
presupune c toi vor da aceeai estimare sau foarte asemntoare. Dac se ntmpl totui
s fie diferene foarte mari, cei care au estimarea diferit de medie vor trebui s explice de
ce au ales aceast soluie i apoi se va vota din nou. Detalii n figura urmtoare [18]:
 - 35 -

Figura 10 Cri specifice estimrii Poker [18]

 - 36 -

4. Aplicaia Scrum Planner pentru managementul estimrilor

n ziua de astzi exist numeroase aplicaii 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. Aplicaiile 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 aplicaie (fiecare mebru al
echipei la ce a lucrat i in ce stadiu este fiecare task al proiectului). Unele dintre aceste
aplicaii de management au fost mbuntite i pot oferi soluii de management n
dezvoltarea de tip Agile, permind de exemplu realizarea unor tabele de tip Kanban,
grafice, evidena edinelor din Scrum etc. Printre aceste aplicaii se numr:

- Jira, VersionOne aplicaii independente, de sine stttoare

- Visual Studio Scrum pentru Visual Studio

- Agile for Oracle - pentru Oracle

Aceste aplicaii au foarte multe ntrebuinri 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 funcie 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 prioriti, le poate atribui dezvoltatorilor etc
o un tester poate realiza aceleai aciuni pe un test plan ca i dezvoltatorii pe taskuri
o un project manager poate observa planificrile, poate schimba diverse informaii la
nivel de proiect
o un project manager poate crea rapoarte despre taskurile terminate, n lucru sau
nencepute, i poate avea o imagine de ansamblu a muncii fiecrui membru al echipei
de dezvoltatori sau testeri
 - 37 -

4.1 Problema
Dei aplicaiile sunt fcute n aa fel nct s ofere foarte multe funcionaliti, ele
sunt organizate n aa fel nct s fie concentrate pe proiect i pe taskurile componente.
Un task poate fi estimat la nceputul proiectului la un numr de ore sau zile i eventual
reestimat pe parcurs, n funcie de diverse module care l-ar putea afecta. Apoi unui
dezvoltator i este atribuit acel task. Respectivul dezvoltator trebuie s ncerce pe ct
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 ajutai, probleme administrative n cadrul companiei, traininguri etc.
o Factori interni: capacitatea dezvoltatorului de a rezolva taskul, n funcie de
experiena sa, cunoasterea tehnologiilor necesare, talentului su de
programator etc.

Aceti factori ne duc cu gndul la nevoia unei funcionaliti ntr-o aplicaie de

management care s ia n calcul aceti factori descrii mai sus. Funcionalitatea ar trebui
orientat asupra dezvoltatorului i capacitii sale de a rezolva diverse taskuri, cu referire
att la factorii care i pot mbunti munca, ct i la factorii perturbani, care pot lungi
perioada petrecut lucrnd 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 iniial, pornind de la dezvoltatori, dar, trecnd prin
minile mai multor persoane, inclusiv project managerul, ele se pot scurta, deoarece se
dorete livrarea ct 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 ctre
dezvoltator, datorit cunotinelor acestuia despre proiect i modulele sale, dar c i-ar
putea crea anumite ntrzieri datorit limbajului L, de exemplu, limbaj pe care
 - 38 -

dezvoltatorul D n cunoate la nivel mediu. De asemenea, n ziua n care dezvoltatorul i

propusese s rezolve respectivul task, a venit un angajat nou, cruia D a trebuit s i faca
o introducere n companie i proiect, fapt ce i-a rpit cteva ore din munca la task. n
aceeai 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 ntrzieri mari, iar
timpul real n care taskul a fost terminat poate fi i dublu fa de estimarea iniial. i cu
toate c n unele companii este posibil i raportarea timpului petrecut n sedine, multe
aplicaii nu permit decr 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 ctre noul coleg, cu edina si cu alte eventuale modaliti de
distragere a ateniei, nu este posibil s se fi lucrat 100 % din zi la task, deci vor aprea
ntrzieri. Sub un deadline strns, multi dezvoltatori sunt nevoii s petreac foarte multe
ore n plus la servici, pentru a rezolva taskurile prost estimate in iniial. n urma multor
ore de munc n plus, productivitatea va scdea, nemulumirile personale vor crete, fapt
care nu este benefic nici pentru angajat, nici pentru proiect i nici pentru companie, pe
termen lung.

4.2 Soluia propus

Conform exemplului de mai sus, este clar c exist o variabil n procesul estimrii
de care aplicaiile deja existente nu in cont. Aceast variabil este chiar dezvoltatorul
cruia i este atribuit taskul, respectiv o msur a diverilor factori care pot contribui la
accelerarea sau dimpotriv, la ncetinirea procesului de rezolvare a taskului. El poate avea
o mulime personal de variabile, din care se pot calcula intrzierile care pot aprea n
munca sa, astfel ca project managerul s poat s aib o imagine de ansamblu i eventual
s discute cu clientul in cazul intrzierilor foarte mari.
 - 39 -

4.3 Aplicaia Scrum Planner

4.3.1 Termeni folosii

Sprint se refer la un sprint din modelul de dezvoltare Agile. Este important s fie
ct mai scurt, dar nu mai mult de 4 sptmni.

User story modulele care vor intra n sprintul curent. Mai multe persoane pot lucra
concomintent la acelai user story.

Task - unitate de munc, sarcin mic care intr n componena 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

numr maxim de ore de munc care i pot fi atribuite ntr-un sprint.

Skill calitile, abilitile i factorii externi care in strict de Resource i care

influeneaz estimarea taskurilor. Acestea au fiecare un Skill Weight (pondere): unele
sunt mai importante ca altele, n sensul c vor influena mai mult estimarea.

Productivity index numr repezentnd productivitatea dezvoltatorului, calculat n

funcie de mulimea de Skilluri, valorile i ponderile acestora

Estimated Hours orele estimate de ctre echip ale unui task

Real Hours orele calculate de ctre aplicaie, coninnd ntrzierea datorat

dezvoltatorului, conform Productivity Index
 - 40 -

Figura 11: lista de taskuri ale sprintului curent, mpreun cu informaii despre ele

4.3.2 Skills calitile dezvoltatorului software

Aceste skill-uri se pot defini dinamic, n funcie de necesitile proiectului, pentru a
exprima cu ct mai mult acuratee 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 caliti ale dezvoltatorului (cunoaterea diverselor
tehnologii, experiena n profesie sau experiena pe proiect), caliti care il vor ajuta n
realizarea mai rapid a taskurilor, iar cele negative reprezint diversele evenimente
perturbatoare, care l impiedic n munc (sedine, trainiguri etc).

Exemplu: un dezvoltator senior poate termina un task estimat la 8 ore n mai puin de
atta, dac lucreaz nentrerupt. Dar tot acelai programator senior mai are si alte atribuii
n afara sarcinilor ce in strict de proiect, cum ar fi realizarea de diverse trainiguri la
interni i juniori (inclusiv pregtirea prezentrilor respective), edine, ajutarea diverilor
colegi cu diverse probleme etc. Presupunnd 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 uor depit. Adugnd mai multe taskuri similare, ntr-un user
story este foarte uor s nu se respecte acel estimrile iniiale.
 - 41 -

Figura 12: Pagina de detalii a unui dezvoltator, coninnd detalii despre skilluri,
productivity index, taskuri atribuite

4.3.3 Productivity index (indexul de productivitate)

Acest index este specific fiecrui dezvoltator n parte, inandu-se cont de skillurile
anterioare (ponderea i valoarea). Se calculeaz conform formulei urmtoare:

( )

Unde simbolurile sunt:

Pi = Ponderea Skillului cu indexul i

 - 42 -

Vi = Valoarea Skillului cu indexul i

n = numrul de skilluri ale dezvoltatorului

n cadrul aplicaiei, acest ProdIndex va fi rotunjit pn la 2 zecimale, conform

standardului IEEE 754 [21], (rotunjirea bancherului sau rotunjirea la cel mai apropiat
numr).

4.3.4 Estimated Hours i Real Hours

Orele estimate sunt rezultatul edinei de Sprint planning, realizat de ctre 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 urmtoarea semnificaie:

RHT Orele reale ale taskului T

EHT Orele estimate pentru taskul T

PIR Indexul de productivitate al dezvoltatorului D

Formula folosete o diferen ntre 100 i Productivity Index, deoarece, cu ct acesta

este mai mare, cu att acel dezvoltator este mai bine pregtit i va putea rezolva mai rapid
taskul. Diferena 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 puin timp

4.3.5 Auto-atribuirea
n unele cazuri, project managerul poate dori ca aplicaia s atribuie automat taskurile
pentru a minimiza timpul de ntrziere. Aplicaia permite acest lucru prin folosirea unui
buton de Auto-assign, care va declana algoritmul de auto-atribuire a taskurilor. Nu este
obligatorie folosirea acestui algoritm, deoarece, de obicei, ntr-un proiect taskurile se
atribuie n funcie de experien, cunoaterea tehnologiilor etc. n Scrum, dezvoltatorii
 - 44 -

decid singuri cum ii vor atribui taskurile, de aceea este important ca aplicaia s permit
auto atribuirea, ct i atribuirea manual.

Algoritmul de auto-atribuire este euristic, care va sorta taskurile descresctor dup

numrul de ore estimate, apoi programatorii tot descresctor dup indexul de
productivitate. Apoi va asigna taskurile ncepnd cu programatorul cu indexul de
productivitate cel mai mare, pn la numrul maxim de ore ce i pot fi asignate,
continund 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 aprea cele
mai mari ntrzieri, sunt atribuite nti programatorilor cei mai buni. De asemenea se
asigur c, n procesul de atribuire de taskuri, programatorii cei mai buni vor fi luai n
calcul, nainte de a atribui taskuri celorlali.

Algoritmul funcioneaz doar cu meniunea c orele totale estimate ale taskurilor nu

trebuie s depeasc totalul orelor maxime care pot fi atribuite programatorilor, plus o
marj de eroare de 20%.

Studiu de caz auto-atribuire:

Pornim de la situaia user-story-urilor ca mai jos:

 - 45 -

Figura 13: User-story-urile i orele estimate, reale, precum i posibila ntrziere

Observm posibilitatea unor ntrzieri n proiect de 34 de ore, cu 43% mai mult dect
perioada estimat.

Taskurile sunt asignate astfel:

Figura 14: Taskurile sprintului curent i atribuirea resurselor

Aceast atribuire s-a fcut manual, n timpul edinei de sprint planning. Echipa este
alctuit din juniori i seniori. Acetia au totalul de ore atribuite, precum i productivity
index ca n figura mai jos:
 - 46 -

Figura 15: Indexul de productivitate i orele atribuite fiecrui dezvoltator

Folosind butonul de Auto-assign din pagina cu lista de taskuri, putem declana

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: Declanarea algoritmului de atribuite automat

Algoritmul ruleaz rapid, datorit mulimii reduse de date de procesat, apoi putem
urmri noua atribuite a taskurilor.

Deoarece algoritmul lucreaz cu constanta MAX-HOURS, n cazul aplicaiei

definit la 20 de ore, s-au putut atribui taskurile majore celor mai buni programatori,
taskurile mai simple fiind redistribuite celorlali, tot n ordine descresctoare 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:

Observm 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 urmtor, respectiv
Umberto Eco, are atribuite 2 taskuri care totalizeaz 20 de ore. Dan Brown din contr,
avnd indexul de productivitate cel mai mic, are cele mai puine ore atribuite, respectiv 10
ore ale unui singur task, dar care, datorit productivitii reduse, vor putea avea o
ntrziere 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 ntrzierea total posibil este acum de
doar 27 de ore. Acest algoritm a redus intrzierea posibil de la 42% la 33% din perioada
estimat.

4.3.6 Tehnologii folosite

Aplicaia folosete tehnologiile .NET 4.5, ca platform general de dezvoltare.

Limbajul de back-end este C# 4.5, iar pentru front se folosete ASP.MVC 4, rezultnd
o arhitectur Model View Controller.

Baza de date folosit este SQL Server Express 2008, iar ca Object Relational
Mapping (ORM) se folosete Entity Framework 5, disponibil n regim open-source.

Pentru limbajul de scripting pe partea de client se foloseste JavaScript i librria

jQuery.

4.3.7 Dezvoltri viitoare

Aplicaia poate fi cu uurin extins pe viitor, prin adugarea de noi module sau
mbuntirea celor existente. Printre aceste planuri de extindere se pot include:

o adugarea de funcionaliti pentru a realiza review-uri pentru membrii echipei, n

funcie de productivitatea lor n timp
o realizarea de grafice pentru a se observa estimrile, timpul petrecut pe taskuri, timpul
rmas etc.
o adugarea de tipuri noi de resurse (ex: testeri), care s aib seturi diferite de skill-uri,
pentru a extinde funcionalitatea existent i la alte tipuri de echipe
o adugarea unui modul de pontaj, prin care membrii echipei pot raporta timpul petrecut
pe diverse taskuri, i a unei funcionaliti care calculeaz diferenele dintre estimri i
timpul real, prin care se pot observa mai uor capacitile membrilor echipei
 - 49 -

Concluzie
Aplicaia Scrum Planner ofer o imagine nou estimrilor clasice, punnd accent pe
om n locul taskului. Programatorul, respectiv cel ce realizeaz taskul este cel de care
trebuie s inem seama atunci cnd estimm.

Aplicaia poate fi extins pentru a urmri i evoluia n timp a estimrilor i de a oferi

rapoarte bazate pe diverse sprinturi. Un project manager poate observa i evoluia unui
programator, care poate de exemplu s i mbunteasc performanele, s nvee
tehnologii noi i s capete experien. Folosind indexul de productivitate, se pot face
evalurile programatorilor etc.

Aplicaia 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
ntrziere.

Agile este o mulime de metodologii care, pentru a avea rezultate ct mai bune,
trebuie folosite mpreun. Important este cunoaterea proprietilor specifice fiecarei
metodologii i mularea pe proiectul care urmeaz a fi dezvoltat, precum i pe echipa de
dezvoltatori, testeri, business analiti, project manageri care vor lucra mpreun la proiect.
Nu exist nici o metodologie potrivit perfect oricrui tip de proiect i oricrei 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 susintorilor si,
va mbunti considerabil procesul de dezvoltare software. n ziua de astzi, multe
companii IT i muli clieni ai acestora se orienteaz spre aceste metodologii moderne,
deoarece au incredere n rezultatele obinute.

Agile este o direcie care ctig teren, iar n viitor probabil c vom vedea toate
proiectele IT coninnd, mcar 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/