Universitatea Alexandru Ioan Cuza Iai

Facultatea de Economie i Administrarea Afacerilor

Master Sisteme Informaionale pentru Afaceri

SCRUM n managementul
proiectelor software

Coordonator tiinific,
Prof. Univ. Dr. Gabriela Meni

Absolvent,

Macuc Cristina-Adriana

Iai, februarie 2013

Cuprins:
Introducere ................................................................................................................................ 3
1.

2.

3.

Scrum moft sau necesitate? ........................................................................................... 4

1.1

Scrum i metodologia AGILE ..................................................................................... 4

1.2

Concepte, reguli i implicaii organizaionale n cadrul de lucru Scrum .................... 7

1.3

SCRUM vs. Kanban vs. eXtreme Programming (XP) .............................................. 11

Scrum - management al proiectelor mai eficient?........................................................ 13

2.1

Provocrile unui proiect ............................................................................................ 13

2.2

Reeta unui Scrum reuit ........................................................................................ 14

2.3

Probleme i rezolvri ................................................................................................. 18

Studiu de caz proiecte Smart2Tech Development ..................................................... 19

3.1

Premise, probleme i cerine n managementul proiectelor Smart2Tech .................. 19

3.2

Scrum n Smart2Tech Development ......................................................................... 30

3.3

Un alt fel de Scrum.................................................................................................... 38

Concluzii .................................................................................................................................. 42
Bibliografie .............................................................................................................................. 43

- 1-

Cuprins Tabele i Figuri:

Tabel nr. 1 Matricea de nelegere a componenei Echipei Scrum.......................................... 14
Tabel nr. 2 Cum s nelegem corect edinele Scrum? .......................................................... 16
Tabel nr. 3 Fazele modelului n cascad i problemele identificate........................................ 27

Figura nr. 1 Componena Echipei Scrum. Roluri i Caracteristici ......................................... 10

Figura nr. 2 Reprezentare mod de lucru Scrum ...................................................................... 11
Figura nr. 3 Portofoliu soluii de plat .................................................................................... 20
Figura nr. 4 Arhitectura Sistemului EuroPay.......................................................................... 21
Figura nr. 5 Arhitectura Sistemului GlobalPay ...................................................................... 23
Figura nr. 6 Modelul cascad al ciclului de via al dezvoltrii unei metode noi X............... 26
Figura nr. 7 Organizarea modului de lucru n Smart2Tech .................................................... 32
Figura nr. 8 Captur de ecran Backlog-ul EuroPay-ului ........................................................ 34
Figura nr. 9 Modelul incremental al ciclului de via al dezvoltrii unei metode noi X ........ 37
Figura nr. 10 Cerine, realizri i soluii de mbuntire ....................................................... 40

- 2-

Introducere
A devenit deja un clieu s afirmm c trim ntr-o lume n continu schimbare.
Dinamica cerinelor, incertitudinea i riscurile tot mai mari ajung a fi de cele multe ori
principalele caracteristici ale proiectelor software. Din aceast cauz, cel puin aa am constatat
din propria experien, managementul proiectelor a devenit o lupt continu de a gsi metoda de
lucru adaptat la specificului organizaiei care s cresc ansele de reuit. Prea mult timp n
managementul proiectelor a trebui s se aleag ntre a dezvolta produsul corect i a lucra corect.
Lucrarea de fa este un experiment ce a plecat de la ipoteza c Scrum-ul ca metod de
managementul al proiectelor face ca sintagmele de mai sus s fie complementare i a ajuns la
concluzia c modelul poate fi mbuntit. Pentru a putea aborda acest domeniu a fost
primordial definirea conceptelo, prezentarea particularitilor, a regulilor i a modului de
desfurare recomandat, stabilirea implicaiilor organizaionale i a rolurilor participanilor.
nelegerea provocrilor implementrii Scrum-ului duce la identificarea unui set de
recomandri i prezentarea a ceea ce a dori s fie, reeta spre reuita proiectelor Scrum,
reet structurat sub forma unor ntrebri la care literatura de specialitate a oferit rspuns.
Dincolo de aspectele teoretice, implementarea Scrum-ului este exemplificat pe baza
proiectelor companiei Smart2Tech Development. Prin realizarea unei imagini de ansamblu
asupra specificului proiectelor Smart2Tech, produselor i problemelor identificate datorit lipsei
unei metode de management al proiectelor se construiesc premisele apariiei Scrum-ului, ca nou
metod n Smart2Tech. Prezentarea schimbrilor ce s-au produs n modul de lucru i n ciclul de
via al dezvoltrii produselor software contureaz beneficiile acestui model dar i provocrile
ntmpinate.
Printr-un alt fel de Scrum ncerc s demonstrez c acest mod de lucru ar trebui s fie o
replic la haosul care exist n managementul proiectelor i nu un simplu set de
practici/concepte/reguli recomandate. Sistemul de gndire pe care mi doresc s l propag este
acela al soluiilor simple pentru problemele complicate: cu ct o procedur va fi mai complicat,
cu ct un document va fi mai stufos, cu att va fi respins mai mult sau va fi abandonat mai
repede.
Astfel, realitatea demonstreaz c replica lui Jim Coplien ctre Jeff Sutherland (creatorul
Scrum) este memorabil prin adevrul pe care l exprim: "Scrum va fi pe placul tuturor pentru
c este ceea ce facem deja atunci cnd nu mai avem ncotro."

- 3-

1. Scrum moft sau necesitate?

nelegerea raportul de legturi dintre Agile i Scrum, cercetarea principalelor mituri
legate de acestea sunt primordiale n cercetare. Imaginea de ansamblul asupra Scrum-ului
realizat prin prezentarea conceptelor, a regulilor de desfurare i a implicaiilor organizaionale
ofer premisele cunoaterii metodei de lucru. Studiul comparativ dintre principalele metode
cuprinse n metodologia Agile, realizat cu scopul de a pune accentul pe particularitile de lucru
Scrum, rspunde la ntrebarea din titlul capitolului: Scrum nu este doar o niruire de reguli, este
o necesitate n condiiile actuale de lucru al proiectelor, este un rspuns la nevoia de schimbare.

1.1 Scrum i metodologia AGILE

Metodele tradiionale erau eficiente, produceau software optimizat cu posibilitatea de a
reutiliza anumite elemente din procesul de dezvoltare dar costurile utilizrii acestor metode era
mult prea mare: timpul necesar elaborrii documentaiei era disproporional raportat la timpul
dedicat dezvoltrii software-ului; dac cerinele se schimbau actualizarea documentaiei devenea
un chin; optimizarea i reutilizarea codului lua att de mult timp nct adaptarea la noile
tehnologii se transforma n dorin imposibil.
Mai mult, Mike Cohn n Agile Estimating and Planning identific alte trei probleme1
ale abordrii tradiionale: sarcinile de lucru se organizeaz n abordarea tradiional pe individ i
nu pe grup, ceea ce duce la probleme; planificarea n abordarea tradiional se realizeaz plecnd
de la premisa c toate activitile identificate se vor realiza, lsndu-se prioretizarea s fie fcut
de echipa de dezvoltare; modelele tradiionale se axeaz foarte mult pe finalizarea activitilor i
nu pe livrarea produselor/funcionalitilor (practica demonstrnd de multe ori c s-au
implementat funcionaliti de care clientul nu avea nevoie).
Raportndu-se la aceste probleme i la cerinele n continu schimbare la care abordarea
tradiional nu poate s se adapteze n timp util, perspectiva n managementul proiectelor s-a
schimbat radical prin introducerea unei noi abordri: aa numit Agile. Dei a inceput cu muli
ani nainte, micarea Agile a fost declarat oficial prin crearea Manifestului Agile2 din
februarie 2001 (Beck). Autorii manifestului au precizat c ei valorizeaz:
1. Indivizii i interaciunile dintre acetia mai mult dect procesele i instrumentele de
lucru: se prefer comunicarea, fa n fa, verbal ntre persoane i se recunoate
unicitatea fiecrui individ i contribuia pe care o aduce n cadrul proiectului;
2. Dezvoltarea soft-ului mai mult dect ntocmirea documentelor: aceast valoare ar
putea fi definit mai degrab ca dezvoltarea produsului n loc de dezvoltarea software1
2

Cohn, M., Agile Estimating and Planning, Pearson Education Inc, SUA, 2006, pp. 16-17
http://agilemanifesto.org/ (accesat 20/01/2013)

- 4-

ului pentru c produsul final este cel care conteaz cel mai mult la sfritul unui proiect;
echipa ar trebui s depun mai mult efort n activitile care aduc valoare, dac se
lucreaz foarte mult la documentaie i mai puin la dezvoltarea produsului rezultatul nu
va fi unul favorabil;
3. Colaborarea cu clientul mai mult dect negocierea contractului: clientul trebuie s fie
integrat n etapele proiectului, nu doar n faz de analiz; produsul trebuie creat raportat
la nevoile clientului i nu la clauzele contractuale;
4. Flexibilitatea la schimbare mai mult dect urmrirea strict a planului: dac s-a
urmrit cu strictee respectarea planificrilor i finalizarea la timp a activitilor dar
rezultatul nu este pe msura ateptrilor clientului, proiectul nu va fi unul de succes.
Toate aceste valori fac ca Agile s fie neleas ca o metodologie bazat pe principiul
colabrrii, toi membri echipei avnd aceeai misiune: de a livra frecvent, iterativ, la cel mai
nalt nivel calitativ posibil, noi funcionaliti, noi componente, prioritizate dup necesitate i
valoarea pe care o aduc, lund n considerare viziunea utilizatorului i feedback-ul de la acesta.
Definiia Agile pentru muli autori de specialitate nseamn s produci software cu mai
puin documentaie n condiiile unor cerine care se schimb rapid i care satisface toate
necesitile clientului, definiie care ar deveni adevrat dac s-ar prezenta i riscurile.
Presupunerea c Agile nseamn lipsa documentaie este cel mai popular mit legat de aceast
metodologie, abordare cu care eu nu sunt de acord: documentele simple, uor de neles i
integrat n modul de lucru al echipei permit evitarea haosului distructiv i nu am lucrat pn
acum la proiecte n care lipsa unei documentaii mcar succinte s nu fie cauz a eecului.
Boehm i Turner identific corect riscurile acestei abordri greite n lucrarea Balancing
Agility and Discipline: A Guide for the Perplexed ca fiind3: implementarea proiectelor mari se
realizeaz cu dificultate fr o documentaie complet; dac costul identificrii tuturor
utilizatorilor finali este prea mare, acesta nu va putea fi compensat cu perioada de implementare
iar schimbarea unei cerine a unuia dintre utilizatori nu va putea fi acoperit n timp util.
Aceeai autori susin c metodele Agile i dovedesc eficiena mai mult n proiectele de
dimensiuni mici, 5-10 persoane, opinie cu care sunt de acord. Goodpasture, n lucrarea Project
Management the Agile Way. Making it Work in the Enterprise susine i el aceast opinie4 dar
lrgete numrul de membri la 50 i adaug faptul c Agile se potrivete mai mult echipelor
aflate n aceeai locaie dect celor multinaionale unde comunicarea se realizeaz cu dificultate.

Boehm, B., Turner., R., Balancing Agility and Discipline: A Guide for the Perplexed: A Guide for the
Perplexed, Addison-Wesley, Boston, 2004, pp.4-5
4
Goodpasture, J., C., Project Management the Agile Way. Making it Work in the Enterprise, J. Ross Publishing,
SUA, 2010, p.xiv

- 5-

Totodat el recomand metodologia Agile pentru acele proiecte realizate intern, in-house i nu
pentru cele pe baz contractual fix.
Metodologia Agile cuprinde mai multe metode de lucru, toate avnd un numitor comun5:
fiecare n modul propriu ncearc s rezolve aceeai dilem, omniprezent n procesul de
dezvoltare software: cum s reueti s livrezi produsul n condiiile n care cerinele i
necesitile clientului sunt incerte. Dintre metodele Agile se pot enumera: Scrum, Extreme
Programming (XP), metode Crystal, EVO (metod revoluionar brevetat de Tom Gilb), RAD
care a evoluat n DSDM (Metod Dinamic de Dezvotare a Sistemelor- n traducere). Pe lng
acestea mai sunt: modele orientate pe funcionaliti (Feature-driven Design), modele n
vederea adaptrii procesului de dezvoltare software (Adaptive Software Development), Lean
Development, Team Software Process (TSP) and Personal Software Process (PSP), ultimele
fiind create i folosite n cadrul universitii Carnegie Mellon. Primele metode Agile erau de tip
RUP (Rational Unified Process create de IBM/Rational), RAD (Rapid Application
Development) sau JAD (Joint Application Development). Metode mai noi dar discutabile n
privina apartenenei la Agile sunt Kanban i CleanRoom.
Aa cum se precizeaz i mai sus: Agile este metodologia iar Scrum este metoda de lucru
ce folosete principiile din metodologie dar are propriul set de reguli. n articolul Telling It Like
It Is Ken Schwaber folosete i recomand a se folosi pentru Scrum termenul de framework 6
tradus cadru de lucru. n opinia mea indiferent de cum i spunem: metodologie, metod,
important este modul n care se pune n practic.
Primele cercetri care fac referire la metode neconvenionale de management al
proiectelor sunt cele ale japonezilor Hirotaka Takeuchi i Ikujiro Nonaka care au studiat
proiectele de dezvoltare la companiile: Honda, Fuji-Xerox, Cannon, NEC and Epson. Chiar dac
subiectul studiului nu era dezvoltarea software, n lucrarea acestora The New Product
Development Game7 publicat n anul 1986 n Harvard Business Review au introdus termenul de
Scrum pentru a descrie un comportament observat n studiile de caz realizate foarte apropiat de
ce nseamn Scrum-ul astzi ca metod de management al proiectelor. Autorii numeau Scrum o
metod de formare a echipei n rugby ce presupune ca toat echipa s lucreze ca un colectiv.
Obiectivul era mutarea mingea folosind anumite tehnici improvizate i executate de membrii
echipei ct mai dinamic posibil.
Pentru munca sa creatorul Scrum este desemnat n Statele Unite ale Americii Jeff
Sutherland, care a lucrat cu Jeff McKenna i Ken Schwaber, Mike Smith i Chris Martin. Scrum
a fost prezentat oficial i publicat la OOPSLA (Object-Oriented Programming, Systems,
5
6
7

idem, p.xi
http://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/( accesat 12/02/2013)
http://hbr.org/1986/01/the-new-new-product-development-game/ar/1 (accesat 22/01/2013)

- 6-

Languages & Applications) n 1995. Primele proiecte pentru care s-a aplicat Scrum sunt cele de
la Individual, Fidelity Investments, i IDX (n prezent GE Medical).

1.2 Concepte, reguli i implicaii organizaionale n cadrul de lucru Scrum

Scrum nu este un proces sau o tehnic pentru dezvoltarea produselor; este mai mult un
cadru de lucru n care se pot dezvolta diferite tehnici i procese. Rolul Scrum-ului este de a pune
n eviden eficacitatea relativ a managementului de produs i a practicilor de dezvoltare
utilizate astfel nct s fie mbuntite, demonstrnd astfel necesitatea aplicrii lui ca i nou mod
de lucru al proiectelor.
Punerea n practic a Scrum-ului depinde de trei piloni8 importani ce determin la
nivelul organizaiei schimbri:

Transparena toate aspectele semnificative ale procesului trebuie s fie vizibile pentru
cei responsabili de rezultatul/finalizarea produsului. Limbajul trebuie s fie unul comun,
uor de neles pentru toi participanii;

Verificarea diferite aspecte ale procesului trebuie verificate suficient de frecvent, astfel
nct s fie identificate din timp problemele. Frecvena verificrilor trebuie totui s nu
afecteze ritmul de lucru, n acest caz pierzndu-i utilitatea;

Adaptarea dac pe durata verificrii se constant c s-a deviat de la cerinele iniiale i

c produsul final nu va fi acceptat atunci procesul/produsul trebuie ajustat i aceast
corecie trebuie realizat ct mai urgent posibil pentru a minimiza riscul unei viitoare
devieri.
Principala component a Scrum-ului este Sprint-ul, un interval de timp de o lun sau mai

puin n care o parte finalizat, utilizabil i potenial livrat a produsului este creat. Un nou
Sprint ncepe imediat dup ce precedentul s-a finalizat i s-au stabilit concluziile acestuia. Sprintul poate fi considerat un proiect care trebuie finalizat ntr-o lun cu anumite costuri i riscuri, la
finalul cruia va trebui s se livreze ceva. Pentru fiecare Sprint trebuie precizat ce trebuie
creat, care este planul de realizare, care va fi efortul de dezvoltare i care va fi produsul
rezultat.
Pe durat unui Sprint este esenial s se respecte urmtoarele reguli:

Nu se fac schimbri care afecteaz scopul Sprint-ului;

Componena echipei de dezvoltare rmne constant;

Calitatea muncii nu trebuie s scad;

Scopul Sprint-ului trebuie s fie clar i poate fi renegociat dac apar noi cerine/informaii
n cadrul unui Sprint se ofer patru oportuniti pentru realizarea verificrii i adaptrii:

Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org, SUA, 201, p.4

- 7-

 Sprint Planning Meeting (edina de Planificare a Sprint-ului se verific cum se poate

optimiza Sprint-ul, ct de clar este scopul Sprint-ului);
Daily Scrum (edina Scrum Zilnic se verific progresul ce se realizeaz zilnic pe
durata proiectului, se corecteaz nenelegerile n privina cerinelor (dac exist) i se
verific dac sunt impedimente)
Sprint Review (edina de Revizuire - se verific ce i ct din obiectivele stabilite pentru
lansarea componentei au fost ndeplinite)
Sprint Retrospective (edinta Retrospectiv se verific evoluia Sprint-ului anterior,
ce a fost bine i ce nu i se gsesc soluii de mbuntire a Sprint-urilor viitoare).
ntlnirile de mai sus se caracterizeaz prin stabilirea unei durate maxime a edinei astfel
nct timpul de planificare s fie optim i s nu afecteaz timpul de dezvoltare. Alturi de aceste
edine n componena unui Sprint mai intr munca de dezvoltare.
Mediul Scrum presupune formarea unor Echipe Scrum crora li se asociaz roluri,
evenimente/intervale de timp fixate, rezultate i reguli (fiecare component deservete un scop
bine definit i are un rol specific n utilizarea i succesul Scrum-ului). Conform autorilor Ken
Schwaber i Jeff Sutherland, Echipa Scrum se organizeaz singur, lucreaz n iteraii, se
bazeaz pe feedback-ul obinut cu regularitate, att n timpul fiecrui Sprint, la final acestora, ct
i la livrarea produsului final i este format din (componena i rolurile Echipei Scrum sunt
prezentate detaliat n figura nr 1):

Scrum Master (Coodonatorul Scrum-ului pentru a ilustra corespunztor acest rol voi
folosi n lucrare termenul n englez), cel care este responsabil ca tot procesul Scrum s
fie neles i respectat;

Product Owner (Proprietarul Produsului pentru a ilustra corespunztor acest rol voi
folosi n lucrare termenul n englez), cel care stabilete cerinele i evalueaz livrabilele;

Development Team (Echipa de Dezvoltare), cei ce pot finaliza cerinele Product Ownerului pn la sfritul Sprint-ului sub forma unui livrabil, parte component a produsului
final.
Backlog-ul Produsului (Lista de Cerine a Produsului - pentru a ilustra corespunztor

acest concept n lucrare voi folosi termenul de Backlog-ul Produsului) este o list ordonat a tot
ce este necesar pentru dezvoltarea i lansarea unui produs de succes: toate funcionalitile,
funciile, tehnologiile, mbuntirile i coreciile care vor fi implementate n vederea lansrilor
viitoare a produsului software. Backlog-ul evolueaz odat cu produsul i cu mediul n care va fi
folosit, dinamic necesar pentru a atinge obiectivele dezvoltrii produsului: de a fi
corespunztor, competitiv i util.

- 8-

SCRUM MASTER

PROCES SCRUM

C
-

H
I
P

PRODUCT OWNER

BACKLOG PRODUS

S
C
R

Este responsabil de aderarea

Echipei i a organizaiei la
valorile, practicile i regulile
Scrum
Ajut Echipa s neleag
conceptele de auto-organizare i
plurifuncionalitate
nltur impedimentele ce pot
aprea n timpul procesului
Ajut Echipa Scrum dar n
acelai timp este liderul ei

Explic clar ce se dorete de la

produs
Prioritizeaz
Backlog-ul
Produsului
Verific dac efortul depus de
Echipa de Dezvoltare este
calitativ
Se asigur c cerinele sunt
clare, vizibile oricui din echip
Specific Echipei Scrum la ce
se va lucra n continuare
Verific dac echipa de
dezvoltare a neles Backlog-ul
Produsului la un nivel care s
asigure livrarea produsului
conform ateptrilor clientului

U
M

DEVELOPMENT TEAM

PRODUS

- 9-

Transform, n fiecare iteraie,

Backlog-ul
Produsului
n
potenial livrabili secveniali
Au capacitatea de a transforma o
sarcin ntr-un livrabil dar
munca lor se realizeaz dup
propria organizare
Fiecare membru al Echipei se
folosete
de
propria
expertiz/cunotine/abiliti
pentru rezolvarea problemelor
dar responsabilitatea pentru
calitatea livrabilului aparine
Echipei
Dimensiunea optim a echipei
este de apte persoane, plus sau
minus doi

Figura nr. 1 Componena Echipei Scrum. Roluri i Caracteristici

(sursa: prelucrare dup Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org;
Schwaber, K., Agile Project Management with Scrum, Microsoft Press, Washington, 2004)
Elementele din Backlog-ul Produsului se caracterizeaz prin:

Descriere

Prioritatea este definit pe baza riscurilor, valorii i necesitii elementului;

Estimarea estimri mai bune se realizeaz atunci cnd elementul este definit clar i
detaliat.

Elementele cu cea mai mare prioritate vor fi dezvoltate imediat. Cu ct mai mare este
prioritatea, cu att elementul este mai urgent, cu att mai mult a fost analizat i s-a stabilit mai
clar care este valorea sa. Cu ct prioritatea elementului este mai mic, cu att este mai puin
detaliat. Pe msur ce un produs este folosit, valoarea lui i feedback-ul oferit de pia cresc iar
Backlog-ul Produsului crete i se completeaz (sarcinile se modific dinamic din cauza
modificrilor n cerinele de business, condiiilor de pia, tehnologie i dinamicii echipei).
Adesea, mai multe echipe Scrum lucreaz la acelai produs. n acest caz elementele din Backlog
conin un atribut adiional ce permite gruparea lor seturi de funcionaliti, tehnologie sau
arhitectur pentru a facilita organizarea muncii n echipe.
Elementele din Backlog-ul Produsului sunt estimate iniial n timpul Planificrii
Lansrilor (termenul n englez consacrat Release) i apoi pe msur ce sunt create. Estimrile
sunt revizuite i ajustate pe msur ce backlog-ul este analizat n detaliu i pot fi modificate
oricnd. Responsabilitatea estimrilor revine echipei i pot fi negociate cu Product Owner-ul.
Monitorizarea efortului rmas pentru elementele din Backlog-ul Produsului n funcie de
timp se realizeaz prin Diagrama Burndown (diagrama de evoluie a proiectului - pentru a
ilustra corespunztor acest concept voi folosi n lucrare termenul n englez). Efortul estimat este
msurat n orice unitate aleas de ctre Echipa Scrum i organizaie. De obicei unitile de timp
folosite sunt Sprint-urile.
Activitile pe care echipa le ndeplinete pentru a transforma elementele din Backlog-ul
Produsului ntr-o parte finalizat se concretizeaz n Backlog-ul Sprint-ului (lista de cerine
realizate n Sprint - pentru a ilustra corespunztor acest concept voi folosi n lucrare termenul n
englez). Multe dintre aceste activiti sunt identificate n timpul Planificrii Sprint-ului dar pe
msur ce Echipa de Dezvoltare lucreaz la sarcini de lucru individuale va afla c mai multe sau
mai puine dintre activitile planificate sunt necesare sau c o anumit activitate dureaz mai
mult sau mai puin dect durata estimat. Backlog-ul Sprintului este o imagine n timp real,
vizibil, a muncii pe care echipa plnuiete s o ndeplineasc n timpul Sprintului.
O sintez a modului de lucru Scrum este prezentat n figura nr.2 de mai jos:

- 10-

Figura nr. 2 Reprezentare mod de lucru Scrum

( sursa: http://www.altexsoft.com/how-we-work/agile-approach/)
Diagrama Burndown a Backlog-ului Sprint-ului este un grafic al muncii rmase ntr-un
Sprint fa de durata Sprint-ului, creat astfel: se calculeaz munca rmas prin adunarea zilnic a
estimrilor din backlog. Cantitatea de munc rmas ntr-un Sprint este suma muncii rmase
pentru ntreg Backlog-ul Sprint-ului. Evidena acestor sume zilnice se pstreaz i valorile sunt
folosite pentru a crea un grafic care arat munca rmas n funcie de timp. Prin desenarea unei
linii prin punctele graficului, Echipa poate observa progresul din cadrul Sprint-ului. Se studiaz
munca rmas i data estimat de finalizare.
Una din principalele reguli Scrum este ca la finalul fiecrui Sprint-ului acel increment ,
parte a produsului potenial livrabil, s adere la definiia curent a termenului finalizat: s fie
ceva n plus, adugat la toate mbuntirile anterioare, s fie complet testat iar integrarea
acestuia s nu afecteze celelalte componente deja integrate9.

1.3 SCRUM vs. Kanban vs. eXtreme Programming (XP)

n literatura de specialitate se disput destul de des care dintre metodele Scrum i
eXtreme Programming este cea mai popular. Boehm i Turner afirm n lucrarea Balancing
Agility and Discipline: A Guide for the Perplexed c Agile se identific de multe ori cu eXtreme
Programming, fiind cea mai vizibil metod dar dezaprob nelegerea aceste metode ca
posibilitate extremist de nterpretare a bunelor practici Agile10 (nu poi s afirmi c foloseti XP

Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org, SUA, 201, p.9
Boehm, B., Turner., R., Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley,
Boston, 2004, p.6
10

- 11-

dac nu utilizezi codarea n pereche: programator-observator, refactoring sau nici mcar

planificare de tip joc). Goodpasture, n Project Management the Agile Way. Making it Work in
the Enterprise susine c SCRUM este cea mai popular metod11, fiind i cea mai simpl prin
faptul c nu se prescriu practici, tehnici de lucru, ci doar se ofer un set de reguli Scrum.
Dei considerate dou metode de lucru Agile foarte apropiate, eXtreme Programming
este considerat a fi mai orientat pe definirea practicilor de dezvoltare software, pe cnd Scrum
mai mult pe practici de management. Pentru c n eXtreme Programming tehnicile de dezvoltare
au un caracter obligatoriu de utilizare, numeroi autori recomand nti s se nceap cu Scrum
pentru a echipa s ctige ncredere n autoorganizare, s i descopere propriul set de tehnici de
dezvoltare. Henrik Kniberg n Scrum and XP from the Trenches. How we do Scrum propune
chiar un mix12 dintre cele dou metode de lucru pentru eficientizarea att a managementului
proiectului, ct i a modului de dezvoltare.
Dac n Scrum nu se accept schimbri ale scopului Sprint-ului pe durata desfurrii
acestuia, XP permite acest lucru, atta timp ct nu afecteaz funcionalitatea la care echipa
lucreaz n acel moment.
Kanban este o metod de lucru Agile JUST-IN-TIME bazat pe fluxurile sarcinilor de
munc. Raportat la particularitile Scrum-ului, n Kanban nu exist iteraii sau Sprint-uri, nici
roluri definite (echipa de proiect sau clientul poate specifica orice rol este nevoie n proiect) iar
estimrile se consider c nu sunt necesare pentru c oricum nu se respect. Statusul curent al
unei cerine poate fi unul din urmtoarele: Backlog, n Lucru, Finalizat. Sarcinile de lucru
aflate n lucru sunt limitate pe fiecare etap permind urmrirea i rezolvarea blocajelor imediat.
Kanban se potrivete mai mult acelor proiecte de dezvoltare unde sarcinile de lucru sunt
n continu schimbare i nu exist o modalitate de a defini iteraii/Sprint-uri, dar necesit o foarte
bun cunoatere a ciclului de dezvoltare i o implicare a clientului pentru a livra tot timpul ceea
ce el are nevoie i nu ceea ce se poate dezvolta13.

11

Goodpasture, J., C., Project Management the Agile Way. Making it Work in the Enterprise, J. Ross Publishing,
SUA, 2010, p.xiv
12
Kniberg, H., Scrum and XP from the Trenches. How we do Scrum, C4Media, SUA, 2007, pp.81-86
13
Kniberg, H., Skarin, M., Kanban and Scrum making the most of both, C4Media, SUA, 2010, pp.3-6

- 12-

2. Scrum - management al proiectelor mai eficient?

Pentru a putea implementa cu succes cadrul de lucru Scrum trebuie mai nti nelese
principalele provocri ale proiectelor. Identificarea factorilor determinani ai succesului Scrumului ofer un ablon de lucru i recomandrile necesare pentru a ajunge la un management al
proiectelor mai eficient. Bineneles, probleme pe durata implementrii pot aprea dar literatura
de specialitate ofer prin studiile de caz prezentate posibile soluii.

2.1 Provocrile unui proiect

Principalele probleme ale proiectelor pleac chiar de la prima etap a managementului.
Practica n privina planificrii proiectelor este undeva la extreme: fie nu se planific deloc, fie se
pierde prea mult timp cu planificarea. n primul caz nu se va putea ti cnd se poate livra
produsul, n al doilea caz planul va prea att de bun nct orice modificare a planului va fi cu
greu realizat.
Dezvoltarea software nu trebuie luat ca pe o competiie intern: cine cere mai mult, cine
ctig lupta cu estimarea. Dac se dezvolt funcionaliti greite, pe care clientul nu le-a cerut
i nu le va folosi, pierde att echipa care a depus efort ntr-o direcie greit ct i clientul care va
trebui s mai atepte o perioad pn ce funcionalitile corespunztoare se vor dezvolta. Pentru
echipa planul reprezint o perspectiv asupra viitorului, dar pe parcursul proiectului, cu ct se
ctig mai mult experien i cunotine, aceast perspectiv se schimb.
n august 2007, Dynamic Markets a realizat o anchet14 pe 800 de manageri IT din opt
ri i au descoperit:
62% din proiecte depeau timpul alocat;
49% din proiectele depeau bugetul;
47% din proiectele necesit costurile de ntreinere mai mari dect cele estimate;
28% dintre organizaii au implementat proiecte care nu se potrivesc cerinelor;
25% dintre organizaii sunt reticente n a adopta noi tehnologii;
13% din organizaii spun c proiectele nu au adus valoarea adaugat la care se
ateptau.
Statisticile variaz ntre studii, n funcie de aspectele individuale examinate, dar este clar
c n industria IT proiectul este n criz continu i sufer n mod repetat rezultate negative, ca
urmare a depirilor de buget sau de timp, a livrrii unor cerine greite sau dezvoltate greit.

14

http://www.tcs.com/Insights/Documents/independant_markets_research_report.pdf (accesat 26/01/2013)

- 13-

ntr-un studiu15 realizat de IBM cu scopul de a investiga motivele pentru eecul

proiectelor IT s-au identificat cinci domenii cheie care influeneaz succesul sau eecul unui
proiect:
Managementul proiectelor (54%);
Mediul de afaceri (21%);
Oamenii (14%);
Procedurile(8%);
Tehnologia(3%).
Studiul demonstreaz c un management mai eficient ar crete probabilitatea de succes a
proiectelor i acest beneficiu l ofer Scrum-ul.

2.2 Reeta unui Scrum reuit

ansele de reuit a managementului unui proiect Scrum cresc exponenial cu nelegerea
rolurilor pe care le au membrii Echipei Scrum, ce pot face i ce nu i mai ales cine poate lua sau
nu, un anumit rol n cadrul echipei; tabelul nr. 1 Matricea de nelegere a Componenei
Echipei Scrum soluioneaz toate aceste ntrebri legate de membrii Echipei Scrum:
Tabel nr. 1 Matricea de nelegere a componenei Echipei Scrum
(sursa: prelucrare dup Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org, SUA)
SCRUM MASTER

PRODUCT OWNER

ECHIPA DE
DEZVOLTARE

Cine poate fi?

Scrum Master-ul poate fi un

membru al Echipei dar
acest lucru duce adesea la
conflicte n momentul cnd
va trebui s aleag ntre a
rezolva problemele ca
Scrum Master i a ndeplini
sarcinile din Sprint

Dac
proiectele
sunt
pentru clieni
poate fi chiar managerul
de produs

Membru al echipei
devine cel care are
abilitile necesare de a
transform o sarcin
ntr-un
livrabil
al
Dac proiectele vor fi produsului
folosite intern, Product
Owner poate fi managerul Membri Echipei sunt cei
departamentului
ce au deschiderea de a
care va folosi acel produs prelua sarcini, chiar
dac
acest
lucru
Product Owner poate fi nseamn s nvee noi
chiar un membru al lucruri
Echipei care face i
munc de implementare,
ns
aceast
responsabilitate l poate
mpiedica
s
lucreze
corespunztor cu toi cei
implicai)

15

http://www.ibmsystemsmag.com/power/Systems-Management/Workload
Management/project_pitfalls/project_success_or_failure/ (accesat 26/01/2013)

- 14-

Cine nu poate fi?

Scrum Master-ul nu poate fi Product Owner-ul nu Scrum Master-ul i

Product Owner
poate fi Scrum Master
Product Owner-ul nu
pot
fi
considerai
membri ai Echipei de
Dezvoltare dect n
cazul n care au sarcini
de ndeplinit n cadrul
unui Sprint sau mai
multora

Ce este?

Este veriga ce conecteaz Este o singur persoana

organizaia i Echipa Scrum responsabil cu Backog-ul
la practicile, valorile li produsului
regulile Scrum
Este mentor pentru Product
Owner privind modul de a
prezenta, creea i coordona
Backlog-ul Produsului

O echip cu un numr
de membri suficient
pentru a fi agili i pentru
a finaliza munca
O echip care are
capacitatea
de
a
transforma
cerinele
prezentate n Backlog-ul
Produsului n Produsul
Final

Este cel care nelege i

explic modul de lucru
Agile n organizaie
Ce nu poate fi?

Nu poate fi un comitet

Nu poate fi un comitet

Nu pot exista subechipe axate pe un

domeniu specific (de
exemplu sub-echipa de
Testare)

Ce poate face?

i poate ajuta pe cei din

exteriorul Echipei Scrum s
neleag procesul i s
descopere
care
dintre
interaciunile cu Echipa
sunt benefice i care nu

Poate reprezenta cerinele Sunt singurii care pot

unui comitet n Backlog- livra la sfritul fiecrui
ul Produsului;
Sprint
cte
o
component a ceea ce se
Este singurul care poate va numi la sfritul
schimba prioritile n proiectului Produsul
Backlog-ul Produsului
Finalizat (component
pe care autorii Ken
Schwaber
i
Jeff
Sutherland o numesc
Increment)

Ce nu poate face?

Nu
poate
schimba Chiar
dac
rolurile
prioritile n Backlog-ul Product Owner-ului pot fi
Produsului
preluate de Echipa de
Dezvoltare, acesta nu
Nu poate spune Echipei de poate
disprea
din
Dezvoltare cum s i duc componena Echipei
la ndeplinire sarcinile din
Sprint

Fiecare membru al
Echipei poate avea
abiliti pe o anumit
specializare dar Echipa
per ansamblu nu poate
s se comporte altfel
dect ca un TOT
responsabil
pentru
calitatea livrabilelor

Un alt factor important n reuita managementului proiectelor folosind Scrum este

nelegerea modului corect de desfurare a edinelor, a rolului i a utilizrii acelor ntrebri

- 15-

cheie care definesc fiecare tip de edin (tabelul nr. 2 Cum s nelegem corect edinele
Scrum? prezint un ablon de organizare):
Tabel nr. 2 Cum s nelegem corect edinele Scrum?
(sursa: prelucrare dup Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org;
Schwaber, K., Agile Project Management with Scrum, Microsoft Press, Washington, 2004)
edina de

edina Scrum

edina de

edina

Planificare a

Zilnic

Revizuire a

Retrospectiv a

Sprint-ului

Sprint-ului

Sprint-ului
Rol

edina
de
planificare
este
format din dou
pri: n prima se
va decide ce va fi
efectuat n Sprint
iar n a doua
Echipa identific
modalitatea
de
implementare
a
funcionalitilor

edina
Scrum
Zilnic are loc
pentru a inspecta
munca realizat de
la ultima edina, a
stabili i adapta din
mers munca care
trebuie
realizat
pn la urmtoarea
edina.

La
sfritul
fiecrui Sprint are
loc o edin de
Revizuire
a
Sprint-ului unde
pe baza a ceea ce
s-a finalizat i a
modificrilor
efectuate
n
Backlog-ul
Produsului
pe
edinele Zilnice parcursul Sprintmbuntesc
ului se stabilete
comunicarea,
planul
pentru
elimin obstacolele urmtorul Sprint
care
apar
n
dezvoltare,
promoveaz luarea
rapid a deciziilor
i
mbuntesc
nivelul
cunotinelor
despre proiect

n urma edinei de
Revizuire a Sprintului i nainte de
urmtoare edin de
Planificare, Echipa
Scrum
susine
Retrospectiva Sprintului cu scopul de a
revizui procesul de
dezvoltare n vederea
eficientizrii acestuia

Pn la sfritul
edinei se va
obine
un
Backlog-ul
al
Produsului
revizuit care va
defini cel mai
probabil
itemii
pentru urmtorul
Sprint

Pn la sfritul
edinei
Echipa
Scrum va identifica
msuri
de
mbuntire
a
proceselor, relaiilor,
oamenilor
i
instrumentelor
folosite, msuri ce se
vor implementa n
Sprint-ul urmtor

Cu fiecare edin
Retrospectiv,
Echipa
Scrum
gsete
noi
modaliti
de
a
mbunti calitatea
produsului
i
definiia
Produs
Finalizat
se
adapteaz

Obiectiv

Pn la sfritul
edinei Echipa de
Dezvoltare va fi
capabil s explice
Product Ownerului i Scrum
Master-ul
cum
intenioneaz s se
autoorganizeze
pentru a ndeplini
Scopul Sprint-ului

Obiectivul
edinelor Scrum
zilnice
este
creterea
probabilitii
de
ndeplinire
a
Obiectivului
Sprint-ului

Participani

Echipa Scrum
Pot
participa
consultani ce pot
oferi
sfaturi
tehnice
sau
recomandri

Echipa Scrum
Echipa Scrum + Echipa Scrum
Particip doar acele stakeholderipersoane
care persoane
transform
interesate
de
elementele
din proiect (acionari,
Backlog-ul
clieni, etc.)
Produsului
n
componente
ale

- 16-

produsului software
final
Algoritm de
calcul durat
edin

ntrebri cheie

Mod de
desfurare

Sprint = 1 lun
=> edina = 8 ore
=>2 pri= 2*4 ore
Sprint = 2 spt.
=> edina = 4 ore
=>2 pri= 2*2 ore
...
1.Ce vom livra la
sfritul
Sprintului?
2.Cum vom reui
s
realizm
obiectivul Sprintuli?
Prima parte:
Product Owner-ul
prezint
elementele
prioritare
din
Backlog-ul
Produsului
i
mpreuna
cu
Echipa
va
identifica
ce
funcionaliti se
vor implementa
n
funcie
de
funcionalitile
alese de Echip se
va
stabili
Obiectivul Sprintului

edina =15 minute

la aceeai or i n
acelai
loc
pe
parcursul
tuturor
Sprint-urilor

Sprint = 1 lun
=>edina = 4 ore

Sprint = 1 lun
=>edina = 3 ore

Sprint = 2 spt.
=>edina = 2 ore
...

Sprint = 2 spt.
=>edina = 1.5 ore
...

1.Ce s-a realizat de

la ultima ntlnire
pn acum?
2.Ce se va realiza
pn la urmtoarea
edin?
3.Ce
obstacole
sunt?
Scrum Master-ul se
asigur c Echipa
susine edina, se
aplic regulile i
edina dureaz 15
minute,
fiecare
membru vorbind pe
scurt

1.Ce s-a fcut?

2.Ce nu s-a fcut?
3.Ce a mers bine?
4. Ce probleme au
fost i cum s-au
rezolvat?
5.Care
sunt
urmtorii pai?
Product Owner-ul
identific ce a fost
finalizat i ce nu.
Echipa discut
despre ce a mers
bine n timpul
Sprint-ului i ce
probleme au
ntmpinat,
precum i modul
cum
au
fost
rezolvate.
Echipa
apoi
demonstreaz
munca efectuat
i rspunde la
ntrebri.
Product Owner-ul
discut
apoi
despre Backlog-ul
Produsului dnd o
estimare privind
finalizarea
acestuia.
ntregul
grup
colaboreaz apoi
n
privina lucrurilor
discutate pentru a
vedea cum le pot
folosi in Sprinturile viitoare

1.Ce a fost bine?

2.Ce am greit?
3.Ce
trebuie
s
ncercm n Sprint-ul
urmtor?
4.Ce nu mai are rost
s facem?

Pe
parcursul
edinei
Zilnice
fiecare membru al
Echipei
de
dezvoltare
va
rspunde
la
ntrebrile cheie

A doua parte:
Echipa stabilete
cum va transforma
elementeledin
Backlog-ul
produsului
n
software
funcional.
Se ncepe prin
proiectarea
muncii=>lista de
activiti=>Sprint
Backlog

ScrumMaster-ul
ncurajeaz Echipa
Scrum
s
i
revizuiasc,
n
cadrul procesului i
practicilor Scrum,
procesul
de
dezvoltare, urmrind
s
se
obin
rspunsul
la
ntrebrile cheie

Pe baza analizei
proceselor,
oamenilor, relaiilor
i
instrumentelor
folosite se identific
ce a mers bine i ce
trebuie mbuntit i
se creeaz un plan de
implementare
a
msurilor
de
mbuntire
identificate

Reuita implementrii Scrum depinde i de nelegerea modului de structurare a

elementelor din Backlog-ul Produsului pentru a putea fi gndite ca finalizabile n Sprint-uri.

- 17-

Elementele trebuie s fie bine nelese i uor de selectat n cadrul edinei de planificare a
Sprint-ului.
Elementele din Backlog-ul Sprint-ului trebuie s fie descompuse n aa fel nct progresul
s fie uor de neles n edina Scrum Zilnic. Durata tipic pentru un element din Backlog-ul
Sprint-ului este de cel mult o zi.
Echipa este cea care controleaz Backlog-ul Sprint-ului:

adaug activitile adiionale necesare;

modific Backlog-ul Sprint-ului n decursul Sprint-ului, inclusiv elementele ce apar n

decursul Sprint-ului;

actualizeaz timpul estimat pentru finalizarea celor n curs de dezvoltare;

terge activitile care se dovedesc inutile.

Implementarea cu succes a Scrum-ului presupune ca membrii echipei s fie motivai i s

posede abilitile de a crea produsul fr a avea prea mult documentaie i prea multe informaii
despre design. Att echipa, ct i organizaia trebuie s neleag i s accepte cadrul de lucru.

2.3 Probleme i rezolvri

Ca n orice cadru de lucru i n Scrum pot aprea probleme sau nenelegeri. Mai ales
pentru echipele care experimenteaz Scrum-ul i nva din experiene este destul de dificil de
definit Sprint-ul, Backlog-ului Produsului i Backlog-ul Sprint-ului i mai ales de estimat corect
durata de implementare a cerinelor.
Trebuie prevenite blocarea activitilor i nlturarea tendinei absolut fireti de a lucra
astfel nct sarcina de lucru s acopere perioada programat n cazul n care echipa simte c a
promis mai mult dect poate livra, se ntlnete cu Product Owner-ul pentru a elimina sau reduce
din activitile ce fac parte din Backlog-ul Produsului ce au fost selectate pentru Sprint. n cazul
n care echipa simte c are timp suplimentar la dispoziie, poate lucra cu Product Owner-ul
pentru a selecta activiti suplimentare din Backlog-ul Produsului.
De obicei, numai 60-70% din Backlog-ul Sprintului va fi tratat n edina de planificare a
Sprint-ului. Restul sunt detaliate ulterior sau sunt date estimri mari, ce vor fi segmentate pe
parcursul Sprint-ului.
Product Owner-ul este singurul care are autoritatea de a anula un Sprint, dei de multe ori
aceast decizie se ia sub influena Scrum Master-ului, Echipei de Dezvoltare sau a alor pri
interesate de proiect. Anularea unui Sprint poate fi necesar din mai multe motive: schimbare de
strategie a companiei, schimbare a tehnologiei, a circumstanelor de utilizare a produsului; dar se
recomand doar n cazuri excepionale pentru c se consum inutil foarte multe resurse (trebuie

- 18-

evaluat ct s-a realizat pn la anularea Sprint-ului, trebuie reestimai elementele nerealizate din
Backlog-ul Produsului, trebuie reorganizat echipa pentru a planifica un alt Sprint).
n unele organizaii, mai mult munc este adugat la Backlog dect este finalizat.
Acest lucru poate duce la o tendin constant sau cresctoare. Pentru a compensa, un nou prag
poate fi creat cnd se adaug sau scade in munc.
Se recomand desenarea pe o pagin mare de hrtie afiat n zona de lucru a Echipei.
Echipele vor observa mai uor o diagram mare i vizibil decat o diagrama dintr-un fiier Excel
sau din alt aplicaie. Cerinele nefinalizate se acumuleaz ntr-o categorie din Backlog-ul de
produs numit De finalizat sau De implementat. Astfel, cand se acumuleaz multe cerine,
burndown-ul pe Backlog-ul Produs-ului nu este afectat i reflect mai corect starea produsului.

3. Studiu de caz proiecte Smart2Tech Development

Obiectivul principal al acestui capitol este crearea unei imagini generale asupra
implementrii cadrului de lucru Scrum n Smart2Tech prin prezentarea comparativ a ce s-a
dorit, ce s-a obinut i cum ar fi trebuit s fie. Prezentarea general a tipologiei
proiectelor/produselor Smart2Tech, a lipsei unei metodologii de management al proiectelor i a
unui ciclul de via al dezvoltrii produselor software deficitar sunt premisele identificrii
problemelor ce au determinat dorina de schimbare a modului de lucru. Plecnd de la cerinele de
schimbare i de la scenariul parcurs pentru a folosi Scrum se constat c noul cadru de lucru i
dovedete eficiena, dar flexibilitatea nu trebuie dus la extreme pentru c se transform n haos
distructiv. Ultima parte a capitolului propune mbuntiri a modului de implementare, soluii
practice de urmat pentru ca probabilitatea succesului unui proiect s creasc.

3.1 Premise, probleme i cerine n managementul proiectelor Smart2Tech

Smart2Tech Development, companie nfiina n anul 2005 i parte a grupului olandez
Smart2Pay asigur dezvoltarea produselor software, mentenana acestora i suportul tehnic
necesar integrrii clienilor. Mai exact produsele software ale Smart2Tech Development sunt
cele dou sisteme EuroPay i GlobalPay, sisteme care asigur furnizarea de metode de plat
alternative comercianilor online i alte soluii software necesare n procesul de administrare i
transfer al banilor de la client, cel care pltete pentru un anumit produs-serviciu, la comerciantul
online, cel care vinde produsul-serviciu (grupul Smart2Pay este un intermediar n acest procesPayment Service Provider). Iniial format din 6 membri i extins n anul 2012 la 11,
Smart2Tech are sediul n Iai i se ocup aa cum induce i numele de partea tehnologic a

- 19-

procesului de cumprare online; Smart2Pay, companie aflat n acceai locaie, la fel parte a
grupului olandez Smart2Pay, se ocup de partea operaional i financiar a procesului.
Principalul avantaj16 al grupului olandez este c ofer servicii de plat local
comercianilor internaionali, acoperind peste 70 de ri din ntreaga lume. Opiunile de plat
alternative (alte categorii n afar de carduri) difer n funcie de specific: transfer bancar online,
transfer bancar regulat cu raportare n timpul zilei, pli ATM, pli n numerar, portofele
electronice (E-Wallet), vouchere, tichete sau bilete la ordin (n America Latin se numesc
boleto), metode de plat cu ajutorul telefonului mobil (plat prin SMS, plat prin deducere la
factura operatorului de telefonie mobil). Integrarea metodelor de plat la site-ul de comer
electronic al comerciantului duce la convertirea clientului din vizitator n cumprtor i implicit
la creterea vnzrilor. Portofoliul de soluii de plat este prezentat n figura nr.3 de mai jos:

Figura nr. 3 Portofoliu soluii de plat

(sursa: document intern prezentare Smart2Pay Corporate Presentation_2012_V14S)
Principalul produs software proiectat, creat i ntreinut de Smart2Tech este EuroPay17
(arhitectura sistemului este prezentat n figura nr. 4), sistem ale crui componente principale
sunt urmtoarele:

Metodele de plat integrate, fiecare avnd specificul ei (numr/tip de parametri trimii

pentru a iniia o tranzacie, numr de pai pn la realizarea plii, mod de a cere/primi
statusul pentru o tranzacie de la furnizorul metodei). Eterogenitatea metodelor de plat
face ca ncercarea de a folosi un prototip de implementare s fie una dificil,
incertitudinea devenind inevitabil n managementul proiectelor de implementare a unei
noi metode de plat;

16
17

http://www.smart2pay.com/ro/acasa (accesat 26/01/2013)

http://www.smart2pay.com/ro/produse/europay (accesat 27/01/2013)

- 20-

Tablou de bord Comerciant (termenul folosit n lucrare va fi cel de Dashboard acesta

fiind i numele aplicaiei): aplicaie web unde comerciantul i poate configura contul
EuroPay, poate vizualiza, filtra i exporta tranzaciile realizate cu o anumit metod.
Pentru c de multe ori comerciantul nu particip la elaborarea cerinelor (ulterior acesta
exprimndu-i dorina de a personaliza cmpurile n funcie de necesiti) Dashboard-ul
se caracterizeaz prin posibilitile extinse de personalizare. Problemele ce apar atunci
cnd aplicaia devine mult prea flexibil sunt dificultatea mentenanei i nivelul complex
al operaiunilor de configurare;

Aplicaia de BackOffice cu diferite funcionaliti de gestionare conturi comerciani,

tranzacii i configurri metode;

Servicii Windows: de monitorizare, de notificare a comercianilor;

Baza de Date caracterizat prin diversitatea tabelelor: fiecare metod presupune existena
propriilor tabele (de exemplu XMethodPayments, XMethodConfiguration).

Figura nr. 4 Arhitectura Sistemului EuroPay

(sursa: document intern - prezentare Smart2Pay_Tehnical Overview)

- 21-

Integrarea comercianilor cu acest sistem este caracterizat prin:

Durata foarte mare a procesului: n funcie de specificul afacerii comerciantului, ntre 1
sptmn -1 lun pentru fiecare metod de plat dorit;
Fiecare metod de plat integrat reprezint pentru comerciant un proiect, un efort
considerabil de programare/codare i testare deoarece parametrii metodelor ce trebuie
trimii de ctre comerciant pentru a iniia tranzacia difer foarte mult; statusurile
tranzaciilor nu sunt unitare);
Limitri de procesare a tranzaciilor n acele monede acceptate de furnizorul metodei de
plat (de exemplu, dac un comerciant vinde doar produse a cror pre este n moneda
euro i vrea i lrgeasc portofoliul de metode n Cehia folosind eBanka, nu putem s i
oferim aceast metod deoarece singura moned acceptat de furnizor este coroana ceh).
Odat cu criza financiar comercianii de produse/servicii online au nceput s reduc
costurile iar provocrile de mai sus au devenit pentru ei impedimente. Mai mult, comportamentul
clienilor se schimb odat cu extinderea metodelor alternative i introducerea metodelor de plat
folosind dispozitivele mobile: i doresc ca plata s se realizeze ct mai rapid i cu ct mai puini
pai dar cu un nivel mai ridicat al securitii informaiilor; i doresc s poate alege din ct mai
multe metode de plat locale fr a plti comisoane substaniale.
Toate aceste cerine de mai sus s-au concretizat n lansarea unui nou produs dezvoltat de
Smart2Tech- GlobalPay18 ce ofer toate metodele de plat ntr-o singur interfa grafic,
facilitnd astfel integrarea comerciantului s se realizeze n cteva zile o sptmn. GlobalPay
pstreaz aceeai structur ca cea a EuroPay-ului cu precizrile (arhitectura acestui sistem este
descris n figura nr.5 ):

Interfaa grafic ce folosete EuroPay-ul ca furnizor pentru metodele de plat; se creeaz

o interdependen ntre sisteme;

Dashboard Comerciant: aplicaie web unde comerciantul i poate configura contul

GlobalPay i i gestioneaz tranzaciile;

Aplicaia de BackOffice cu diverse funcionaliti de gestionare conturi comerciani,

tranzacii i configurri furnizori de metode din sistemul EuroPay;

18

Baza de date caracterizat prin optimizarea numrului de tabele.

http://www.smart2pay.com/ro/produse/globalpay (accesat 27/01/2013)

- 22-

Figura nr. 5 Arhitectura Sistemului GlobalPay

(sursa: document intern - prezentare Smart2Pay_Tehnical Overview)
Astfel, proiectele Smart2Tech pot fi clasificate dup urmtoarele criterii:

Dup tipologia solicitantului:

Proiecte externe care ar trebui s aduc un plus de valoare pentru parteneri;
acele proiecte solicitate de directorul general, directorul de vnzri sau clieni.
Exemple:
-

Implementarea unei noi metode

Adugarea unei noi funcionaliti la Dashboard Comerciant

Proiecte interne care ar trebui s aduc un plus de valoare la nivel

operaional: acele proiecte solicitate de Suport Clieni, Operaional, Financiar.
Exemple:
-

Implementarea unui sistem de Ticketing pentru Suport Clieni

Implementarea unei funcionaliti pentru cutarea tranzaciilor dup

anumite cmpuri n aplicaia de BackOffice

Dup mrimea proiectelor:

Proiecte mari cu durat de finalizare estimat ntre 6 luni i 2 ani
Exemple:
-

Lansare unui nou produs: GlobalPay

Schimbare arhitectural, proiectarea optimizat a EuroPay-ului

Proiecte medii cu durat de finalizare estimat ntre 1-6 luni

Exemple:
- 23-

Adugare funcionaliti necesare n GlobalPay pentru a realiza

Refund Generic (returnarea banilor clienilor prin aceeai metod de
plat)

Traducerea interfeei GlobalPay n cel puin 15 limbi de circulaie

internaional

Proiecte mici cu durat de finalizare estimat ntre 1-4 sptmni

Exemple:
-

Implementarea unei noi metode n cazul n care funcioneaz

corespunztor la furnizor

Adugare funcionalitate de Bad Notified Transactions la aplicaia de

BackOffice

Dup scopul proiectelor:

Proiecte strategice ce vizeaz ptrunderea pe o nou pia, ctigarea unui
nou client etc.
Exemple:
-

Lansare unui nou produs: GlobalPay

Implementarea unui sistem antifraud solicitat de client

Proiecte de funcionalitate ce vizeaz dezvoltarea de noi funcionaliti

aplicaiilor/metodelor curente
Proiecte de mentenan ce vizeaz actualizarea implementrii metodelor
conform noilor versiuni ale manualelor de integrare primite de la furnizori
Proiecte de optimizare: micorarea numrului de accesri a bazei de date
pentru serviciile de notificare.
Aa cum se i anuna pe site-ul companiei Smart2Tech19 iniial managementul proiectelor
de mai sus se dorea a se realiza utliznd metodologia CMMI (Capability Maturity Model
Integration) ce i propunea s evalueze att capacitile sistemelor ct i produsul integrat i
procesul de dezvoltare per ansamblu. Metodologia CMMI oferea un cadru de lucru pentru a
organiza etapele evolutive ale proiectului n termene de maturitate care se succed pentru a
mbunti continuu managementul acestuia.
Fiecare nivel de maturitate presupunea un set de obiective care, odat atinse, stabilizau o
component important a procesului de dezvoltare software i ducea la creterea performanei
organizaiei i calitatea produselor software. Obiectivele metodologiei CMMI erau: creterea
performanei i a eficienei managementului proiectelor, evitarea pierderii din vederea a
oportunitilor, resurse umane mai bine pregtite, produse software calitative.
19

http://smart2tech.com/news.html (accesat 07/02/2013)

- 24-

Metodologia s-a aplicat doar pentru cteva proiecte dar fiind destul de laborios i echipa
nenelegnd practicile i obiectivele s-a renunat la utilizarea ei. Aa c treptat n managementul
proiectelor Smart2Tech s-a renunat la a se mai folosi metodologii i s-a ajuns doar la o sum de
activiti i practici (rolul managerului de proiect transformndu-se n funcie de perioade i
activiti) :

Managerul de proiect planifica mpreun cu directorul general i directorul pe vnzri

care sunt viitoarele proiecte la care echipa va lucra (ROL: MANAGER DE PROIECT)

Imediat ce furnizorul metodei trimitea manualul de integrare, managerul de proiect

mpreun cu liderul echipei tehnice i cu dezvoltatorul analizau manualul i cerinele
(sursa acestor cerine putea fi directorul general, directorul de vnzri, un posibil
comerciant ce dorete metoda). Utilizatorul final- cumprtorul nu era inclus n faza de
analiz, necesitile acestuia ncercnd s fie anticipate de ctre participani
(ROL: ANALIST)

Dac o cerin nu era inclus n documentul de specificaii dezvoltatorul nu o

implementa; de aceea managerul trebuia s realizeze documentul cu atenie i cu eforturi
considerabile (ROL: MANAGER DE PRODUS)

Managerul de proiect trebuia s asigure buna funcionare i actualizare a metodelor deja

integrate pe mediile de testare i de producie. n cazurile n care erau raportate probleme
pe mediul de producie, activitatea era ntrerupt i se rezolva cu prioritate problema
(ROL: MANAGER DE PROIECT)

Managerul de proiect trebuia s asigure buna funcionarea i actualizare a site-ul grupului

Smart2Pay (ROL: ADMINISTRATOR SITE)

Managerul de proiect trebuia s asigure motivarea i perfecionarea continu a echipei

(ROL: MANAGER DE PROIECT)
Neavnd un model/un set de reguli de urmat n managementul proiectelor problemele

deveneau o prezen cotidian fiind accentuate i de: lipsa unui instrument software i /sau
platforme colaborative care s asigure centralizarea cerinelor, sarcinilor, viitoarelor proiecte,
defectelor de implementare (termen utilizat bug), problemelor constate la furnizorii metodelor de
plat (s-a ncercat implementare Microsoft Dot Project dar interfaa mai puin intuitiv i
introducerea cu dificultatea au fcut ca instrumentul s fie treptat respins i abandonat);
schimbarea managerului de proiect cu o periodicitate de 1-2 ani ce a afectat echipa i
continuitatea proiectelor; modelul cascad pentru ciclul de via al dezvoltrii sistemului.
Coordonarea proiectelor, rezolvarea problemelor, controlul i prioritizarea proiectelor se
fceua prin intermediul utilitarului de e-mail Outlook din pachetul Microsoft Office i a
documentelor Excel ce nu permiteau o colaborare n timp real, o transparena a informaiilo. Nu
- 25-

exista o baza de cunotine comun care s ajute echipa la rezolvarea problemelor n mod
eficient.
Legat de ciclul de via al dezvoltrii sistemului, modelul cascad20 (figura nr. 6 descrie
acest model pentru ciclul de via al dezvoltrii unei noi metode de plat X) prezinta dezvoltarea
unui produs software ca o successiune de faze ce se nlnuiau ntr-o derulare secvenial
(aceast secvenialitate de multe ori era teoretic, realitatea demostrnd aa cum arat i figura
nr.6 c se nregistrau reveniri la etapele anterioare), de la analiza cerinelor i pn la livrarea
produsului ctre client. Motivaia alegerii studiului de caz pe implementarea unei metode de
plat n sistemul EuroPay plec de la strategia dominant a grupului Smart2Pay de a mri ct
mai mult portofoliul de pli alternative prin implementarea a ct mai multor metode de plat.
Fiecare faz a modelului cascad corespundea unei activiti i trebuia s se termine la o
anumit dat prin producerea anumitor documente sau componente software ale produsului final.
Trecerea de la o faz la alta se realiza dup ce precedenta a fost parcurs n ntregime. Modelului
i se recunoteau nite avantaje, cum ar fi: favorizeaza managementul proiectelor prin
planificarea resurselor umane pe etape, estimri de cost mai exacte, fazele fiind ordonate,
previzibile, se evidenia clar ariile de ntindere a fiecrei etape sau component a ei i ducea la
un sistem bine documentat.

Figura nr. 6 Modelul cascad al ciclului de via al dezvoltrii unei metode noi X
(sursa: prelucrare proprie)
20

Oprea, D., Meni, G., Dumitriu, F., Analiza sistemelor informaionale, Editura Univesitii Alexandru Ioan
Cuza, Iai, 2012, p.33

- 26-

Din pcate, proba efectiv a bunei sau a proastei funcionri a produsului era realizat
numai n faza de integrare/lansare cnd era posibil evaluarea concret a programului (naintea
acestei faze au fost produse numai documente). Mai mult deoarece modelul era secvenial,
reacia/revizia apreau doar la tranziia ntre faze, multe probleme fiind identificate prea trziu.
Tabelul de mai jos surprinde problemele acestui model asociate fiecrei fazei, pe exemplul
dezvoltrii unei noi metode X:
Tabel nr. 3 Fazele modelului n cascad i problemele identificate
(sursa: prelucrare proprie)

Faza

Rezultatul fazei

Probleme identificate

Analiza i specificarea

Document Method X

cerinelor

Functional Specifications

Proiectarea

Document Method X

Completarea
documentului
presupunea
o
munc
laborioas ce bloca nceperea
dezvoltrii metodei
Cerinele se descopereau pe
parcursul
proiectului

documentul nu putea cuprinde

de la nceput toate cerinele
Dup finalizarea proiectului n
momentul cnd se fceau
schimbri documentul nu se
mai actualiza i pierdea
valoare
Dup finalizarea proiectului n
momentul cnd se fceau
schimbri documentul nu se
mai actualiza i pierde
valoare
Pe tot parcursul implementrii
metodei doar dezvoltatorul
tia ce a implementat
Costuri considerabile (media
timpului de implementarea a
metodei era de cel puin trei
sptmni)

Technical Specifications

Implementare Metod X

Lansare pe platforma de

Tabele necesare metodei

Schem XML a metodei
Mecanism necesar efecturii
plii
Servicii Windows de
notificare a statusului
Dashboard Comerciant
Aplicaie BackOffice pentru
configurare metod
Metod X integrat pe mediul

TEST

de TESTARE

Testare metod pe

Test Case Metod X

platform TEST

Metod X testat
- 27-

De multe ori nu se aprecia

corect impactul integrrii i
care erau elementele ce
trebuiau compilate din nou
pentru c au fost afectate la
integrare
Timpul necesar familiarizrii
tester-ului cu metoda X era
considerabil (media timpului

Testarea de regresie

Sistem de metode integrate

Testat

Integrare Comerciant cu

Primul pas al comerciantului

Metoda X n platforma de

realizat pentru a putea oferi

TEST

metoda

Lansare metod pe

Metod X integrat pe mediul

platform producie

de PRODUCIE

Testare metod pe

Metod X testat pe platforma

platforma de producie

de PRODUCIE

necesar testrii era de o

sptmn)
Problemele descoperite la
testare, n funcie de gravitatea
lor, au dus la reanalizarea
funcionalitilor, uneori la
restructurarea metodei
Testarea de regresie era
activitatea cea mai costisitoare
pentru firm (pentru c pe
durata a 2-3 sptmni testerii
erau pe deplin alocai)
Nu erau bine individualizate
zonele afectate prin integrarea
metodelor
Pe parcursul testrii metodei de
ctre comerciant se descopereau
noi cerine/probleme i se reluau
etapele anterioare

Nu exista informaii clare

despre ce fiiere/proceduri au
fost integrate i ce zone au fost
afectate
De multe ori testarea metodei
nu se realiza corespunztor
pentru c nu erau nc
disponibile
date
de
configurare (diverse cauze:
contractul
comercial
cu
furnizorul nc nu era gata,
furnizorul cerea a fi cel puin
un comerciant integrat cu
metoda de plat pentru a da
date de configurare)
Testerii nu aveau access la
fiiere de logare de pe
platforma de producie
problemele din log-uri uneori
treceau neobservate

Integrare Comerciant cu

Metoda X putea fi oferit de

Metoda X

ctre comerciant clienilor si,

mrindu-i astfel portofoliul
de metode

Utilizarea metodei n

Dovada clar a succesului sau

- 28-

Pe parcursul testrii metodei de

ctre comerciant se descopereau
noi cerine/probleme i se reluau
etapele anterioare costuri
ridicate/proiectul nu putea fi
considerat finalizat

Uneori
se
descopereau
probleme mult prea trziu se

producie

eecului proiectului
Tranzacii pe producie
realizate folosind metoda

producea o mobilizare de fore

pentru a rezolva problema ct
mai rapid dar acest efort nu
era benefic pentru planificarea
activitilor

Modelul cascad se aplica la nivel de sistem; or, tocmai cum demonstreaz tabelul de mai
sus ntruct EuroPay-ul este un sistem complex, cu un numr mare de aplicaii ce interacioneaz
ntre ele, fazele modelului sunt greu de controlat. Utilizarea acestui model a dus la apariia mai
multor categorii de nemulumiri: cele ale clienilor, care doreau ca modelul s fie mai deschis la
schimbrile ce pot interveni pe parcurs, cele ale directorului general i ale directorului de
vnzri nemulumii de perioada lung de timp i costurile considerabile necesare parcurgerii
tuturor etapelor i de faptul c nu pot vedea un prototip al metodei mai devreme i cele ale
echipei: ale testerului ce cunoatea metoda doar dup ce era lansat pe mediul de test, ale
managerului de proiect ce descoperea uneori destul de trziu unele probleme sau deficiene n
funcionaliti.
Plecnd de la problemele i nemultumirile descrise mai sus legate att de ciclul de via
al dezvoltrii metodelor ce influena managementul proiectelor se dorea o schimbare care s
asigure:

Un mod de lucru mai eficient bazat pe colaborare n timp real i urmrirea ntr-un mod
integrat a ntregului ciclul de dezvoltare software, de la cerinele de dezvoltare la
asigurarea calitii produsului i ntreinerea acestuia;

Transparen: tester-ul avea nevoie s primeasc informaiile depre proiect mai

devreme pentru ca familiarizarea cu metoda/produsul/funcionalitatea s nu dureze att
de mult; proiectele Smart2Tech trebuiau s nceteze a mai fi o cutie neagr unde doar
dezvoltatorul i liderul echipei tehnice tiau pn la lansarea pe platforma de TEST cum
va funciona produsul software;

Adaptare: riscul ca manual de integrare primit de la furnizor s nu fie clar sau metoda s
nu funcioneze corespunztor la furnizor nu se pot controla; era nevoie de o prioretizare
clar a proiectelor, dac unul ajungea la un punct mort managerul de proiect pierdea cel
puin o jumtate de zi pentru a stabili la ce va lucra dezvoltatorul n continuare, neavnd
o list clar a proiectelor; pentru c efortul realizrii documentelor i efectuarea analizei
proiectelor presupunea de multe ori termene de cteva zile, cerinele urgente din partea
partenerilor nu se puteau realiza prioritar;

Scderea costurilor (efortul de implementare/testare, durata de implementare/testare) i

a timpului de reacie la cerine: fiind perioad de criz i concurena din ce n ce mai
- 29-

acerb, principalul avantaj al companiei mici Smart2Tech, flexibilitatea i pierdea din

valoare nefiind corelat cu scderea timpului de implementare a cerinelor clienilor;

Anticiparea Riscurilor: nu poi anticipa riscurile dac nu tii la ce se lucreaz, dac

impedimentele nu se observ n timp util;

Rezolvarea defectelor i problemelor n timp util: prototipul metodei/funcionalitii

trebuia evaluat mai devreme pentru a se identifica eventualele probleme.
Cu att mai mult era nevoie de o schimbare cu ct o evaluare a proiectelor arta c chiar

dac timpul i efortul necesar dezvoltrii au fost considerabile, 70% dintre proiecte nu sunt
finalizate din diverse cauze: s-au schimbat ntre timp preferinele/cerinele comercianilor, dup
utilizare s-au descoperit i alte cerine care ateapt s fie dezvoltate, furnizorul ntre timp a
schimbat manualul de integrare.

3.2 Scrum n Smart2Tech Development

Cerinele fiind de adaptare continu la cerine, scderea timpului de reacie, metodologia
de management al proiectelor cea mai potrivit a fost Agile, modul de lucru ales fiind Scrum.
Trecerea la Scrum s-a fcut urmnd urmtorii pai:
1. Organizarea modului de lucru
Aa cum se preciza i n capitolul anterior o mare problem n modul de lucru ce
influena implicit i managementul proiectelor era lipsa unui instrument software i/sau
platforme colaborative care s asigure centralizarea cerinelor, sarcinilor, viitoarelor proiecte,
defectelor de implementare, problemelor constate la metodelor de plat curente i care se datorau
schimbrilor neanunate realizate de furnizorii metodelor.
Existena unei platforme colaborative Visual Studio Team Foundation Server 2010 a
facilitat instalarea ablonului MSF for Agile Software Development v5.0. S-a ncercat instalarea
unui ablon mai potrivit pentru Scrum: Microsoft Visual Studio Scrum 1.0 dar n acel moment
ablonul fiind n versiune beta nu s-a putut finaliza cu succes.
Apoi s-au configurat ariile de lucru, ncercnd o grupare a proiectelor: fiecare metod
devenea o arie de lucru (Bank Transfer, Pagosonline, QIWI, iDEAL etc), Dashboard, Aplicaie
BackOffice, Monitorizare i Raportare. Urmtorul pas a fost crearea portalul SharePoint pentru
ca membrii echipei ce nu aveau acces la Team Foundation Server folosind Visual Studio 2010
meniul Team, s se conecteze folosind browser-ul (de preferat Internet Explorer) cu adresa:
http://192.168.2.3/sites/S2TCollection/.

- 30-

ablonul Agile transforma modul de lucru specific Smart2Tech n ceea ce terminologia

Team Foundation Server numete Work Items21(voi folosi n lucrare termenii n englez pentru
a ilustra ct mai concludent modul de lucru):

Bug defect raportat de: testeri, comerciant, furnizor, departamentul operaional,

departamentul de suport clieni;

Issue un impediment ce nu poate fi rezolvat de echipa Smart2Tech pentru c provine

fie de la comerciant, fie de la furnizorul metodei de plat;

Shared steps nefolosit nc n modul de lucru Smart2Tech; n terminologia Agile

termenul22 definete acei pai care se folosesc n mai multe planuri de testare (de
exemplu, dac fiecare plan de testare presupune autentificarea n aplicaie, se pot crea
aceti pai pentru a realiza autentificarea);

Task sarcin de lucru, de obicei asociat cu un element de tip User Story;

Test case planul de testare asociat cu un element de tip User Story;

User story - cerin formulat cu urmtoarele precizri: tipul de utilizator, scopul

cerinei, motivul cerinei i criterii de acceptare (As a <type of user> I want <some goal>
so that <some reason>. Acceptance Criteria:....).
Mai corect ar fi fost abordarea din ablonul Scrum23: Product Backlog Item User Story

din Agile, Bug, Task, Impediment probleme care mpiedic echipa s i ndeplineasc taskurile
eficient, Test Case, dar imposibilitatea instalrii i specificul proiectelor Smart2Tech
(majoritatea proiectelor sunt de dimensiuni mici, poate chiar foarte mici, ntre 3 zile 2
sptmni) au fcut ca modul de lucru s urmeze n continuare ablonul Agile. Mai mult
instalarea ablonului Scrum ar fi presupus crearea unui Product Backlog pentru fiecare metod
de plat ceea ce ar fi fcut dificil aderarea echipei la acest mod de lucru.
Pentru a facilita introducerea i urmrirea ct mai interactiv a elementelor de lucru
prezentate mai sus s-a recomandat instalarea i folosirea unei aplicaii realizate de cei de la
Telerik: TFS Work Item Manager iar pentru pentru urmrirea evoluiei proiectelor se recomand
Telerik TFS Project Dashboard.
Astfel, modul de lucru haotic bazat pe pota electronic Outlook i pe documente Word i
Excel s-a transformat ntr-unul organizat, figura nr.7 ilustrnd aceast organizare:

21
22
23

http://192.168.2.3/sites/S2TCollection/ (accesat 09/02/2013)

http://msdn.microsoft.com/en-us/library/dd728086%28v=vs.100%29.aspx (accesat 09/02/2013)
http://msdn.microsoft.com/library/vstudio/ff731587.aspx (09/02/2013)

- 31-

Directorul general

Manager

Dezvoltator

Tester

Comunic
noile
cerine
i
le
prioretizeaz
mpreun
cu
managerul folosind
TFS Work Item
Manager

Introduce cerinele
ca User Story-uri
n TFS Work Item
Manager

i
introduce
sarcinile de lucru
legate de User
Story-urile
pe
care trebuie s le
implementeze, le
trece n statusul
Closed
la
finalizare
i
completeaz
numrul de ore
lucrate

i
introduce
sarcinile de lucru
legate de User
Story-urile
pe
care trebuie s le
testeze, le trece n
statusul Closed
la finalizare i
completeaz
numrul de ore
lucrate

Cere rapoarte ale

bug-urilor,
taskurilor
sau
ale
evoluiei
proiectelor
care
acum se export
din TFS Work Item
Manager

Discut cu echipa
pe baza acestora i
obinerea estimri
privind finalizarea
acestora
Rezolv
impedimentele
raportate ca Issues
Trece User Storyurile n statusul
Resolved
la
finalizarea lor
Dup lansare trece
US-urile i bugurile n statusul
Delivered

Verific bug-urile
asociate lui, le
rezolv i le pun
n
statusul
Resolved pentru
ca tester-ul sa
primeasc e-mail
i s l verifice

Verific bug-urile
rezolvate i le
trece n statusul
Closed
dac
problema a fost
rezolvat
Raporteaz Issueurile, descoperite
la testare

Figura nr. 7 Organizarea modului de lucru n Smart2Tech

(sursa: prelucrare proprie)
Principalele obiective ale acestei organizri erau de a creea transparen, de a reui o
prioritizare corect a proiectelor i a sarcinilor de lucru, de a permite o mai bun colaborare ntre
membrii echipei i de a facilita urmrirea elementelor de lucru i a efortului depus pentru a
rezolva n timp util problemele ce apar de-a lungul proiectelor.
2. Micarea de gheril: realizarea managementului proiectelor folosind Scrum
Aa cum am ilustrat i n partea teoretic a lucrrii pentru c Scrum nu este un proces sau
un set de reguli impuse, implementarea acestui cadru de lucru n Smart2Tech nu a fost una rigid
dar a fost o provocare avnd n vedere schimbarea de mentalitate organizaional ce trebuia
realizat. S-a nceput mai mult ca un experiment, adaptat la cerinele prezentate anterior i la
specificul proiectelor, fr a se oferi prea multe detalii, doar conceptele de baz fiind explicate.
Aceast micare de gheril (aa cum o numesc eu prelund un termen din marketing) viza ca
echipa s descopere beneficiile Scrum-ului i s l mbunteasc n mod continuu, detalierea
conceptelor Scrum urmnd a se realiza dup cteva proiecte realizate n acest mod.
Primul pas a fost formarea echipei Scrum, sau mai bine zis, rolurile s-au asignat din
inerie (dimensiunea echipei Scrum nu este cea optim de regul echipa avnd patru membri cu
- 32-

tot cu Scrum Master i Product Owner care au sarcini de ndeplinit n proiect, dar nu a fost un
impediment):

Scrum Master a devenit managerul de proiect;

Product Owner confuzia legat de acest rol n Smart2Tech vine de la numrul mare de
persoane care pot ndeplini acest rol: dac proiectul este integrarea unei metode noi Product
Owner este managerul de produs; dac proiectul se refer la BackOffice, Product Owner este
operatorul. Pentru c aceast confuzie ducea la ntrzieri n desfurarea proiectului, netiind
cine specific cerinele, Product Owner-ul s-a decis a fi doar managerul de produs;

Echipa de dezvoltare format n marea majoritate a proiectelor dintr-un dezvoltator i un

tester (doar proiectul GlobalPay a avut n echip patru dezvoltatori i doi testeri).
S-a trecut apoi la introducerea proiectelor/cerinelor ca User Story-uri n aplicaia TFS

Work Item Manager i formarea Backlog-ului Produsului (n cazul Smart2Tech sunt dou mari
liste: Backlog-ul EuroPay-ului prezentat n figura nr.8 de mai jos i Backlog-ul GlobalPay-ului).
Backlog-urile sunt prioretizate periodic de Product Owner.
Prioretizarea User Story-urilor se realizeaz lund n considerare valoarea pe care o aduc,
valoare exprimat de cele mai multe ori n numr de tranzacii ateptate a fi procesate i/sau ct
de grav este problema pe care implementarea User Story-ul o rezolv. Plecnd de la aceste
considerente prioretizarea User Story-urilor i Task-urilor se face n cadrul firmei Smart2Tech
rspunznd la trei ntrebri:
A aprut o problema la o metod utilizat n mediul de producie? Dac da, rezolvarea
acestei probleme este urgent i are prioritate maxim;
O nou metod de plat/funcionalitate a unei metode deja existente este cerut de un
potenial client i semnarea contractului este condionat de aceast dezvoltare?
O nou metod de plat ar asigura extinderea pe o noua pia financiar sau ptrunderea ntro nou ar?

- 33-

Figura nr. 8 Captur de ecran Backlog-ul EuroPay-ului

(sursa: aplicaie TFS Work Item Manager- raport Product Backlog)
Din Backlog-ul Produsului se aleg cteva User Story-uri n funcie de numrul de
dezvoltatori liberi din cei patru disponibili i urmtoarea etap este cea de estimare. De exemplu
pentru integrarea unei noi metode, dezvoltatorul analizeaz manual de implementare primit de la
furnizor, realizeaz anumite teste premergtoare implementrii pentru a nelege metoda de plat
i estimeaz care este efortul de codare necesar: de obicei media efortului pentru integrarea unei
metode noi de plat este de 10 zile.
edinele de planificare a Sprint-urilor nu s-au realizat din trei motive:

nu s-a neles corect care este importana acestora, fiind asociate cu edinele de analiza a
User Story-ului;

se continua s se gndeasc n termeni de care sunt rezultate implementrii (de exemplu

pentru o nou metod de plat: Flow, Dashboard Comerciant, Aplicaie BackOffice) n loc de
gndire n termen de funcionaliti oferite comerciantului (funcionalitate ce asigur iniierea
tranzaciei, redirectare client la pagina metodei de plat, redirectare client la pagina de
Succes/Eec/Anulare a comerciantului, notificare comerciant privind statusul tranzaciei,
funcionalitate Dashboard comerciant de export tranzacii, configurare detalii metod de plat
n aplicaie BackOffice);

Sprint-ul este componenta Scrum-ului cel mai greu de definit n Smart2Tech.

Incertitudinea a devenit o definiie a modului de lucru Smart2Tech. Din pcate nu poi

planifica livrarea funcionalitilor de procesare a unei metode ntr-o sptmn dac n timpul
dezvoltrii se ntmpl ceva pe producie cu o alt metod a dezvoltatorului i acesta nu mai este
alocat proiectului de implementare metoda X. Prioritate au rezolvarea problemelor din producie
i din pcate Scrum-ul nu a adus o rezolvare la discontinuitate proiectului datorat partajrii
membrilor echipei pe metodele dezvoltate de ctre acetia.
- 34-

Mai mult definiia teoretic a Sprint-ului, acel interval de timp n care o parte
finalizat, utilizabil i potenial livrat a produsului este creat, provoac numeroase discuii
n Smart2Tech pentru c finalitatea i utilizarea cu succes sau nu se vede n producie. ntrebri
gen Cnd putem considera integrarea unei metode de plat ca fiind finalizat avnd n vederea
c i furnizorul metodei influeneaz schimbrile?, Cum putem msura calitatea integrrii
metodei de plat dac de prea puine ori avem o reacie a unui client ce folosete aceast
metod? nc i caut rspuns.
Tot din aceste motive folosirea diagramei Burndown nu prezenta dect o imagine
dezolant a proiectelor (ntr-un singur proiect din cele apte al cror managementul proiectelor sa realizat folosind Scrum s-a respectat termenul limit a Sprint-urilor) i n consecin s-a decis
renunarea la aceast diagram.
Astfel, Scrum-ul n Smart2Tech pare a ncepe mai degrab de la edinele Scrum zilnice.
Contestate la nceput, fiind considerate pierdere de vreme, ele i-au dovedit eficiena n
momentul n care s-au neles mai bine cerinele, impedimentele au fost mult mai uor de
comunicat, adaptarea la schimbarea cerinelor s-a fcut treptat, iar probleme s-au identificat mult
mai repede. Mai mult participarea testerului de la primele edine Scrum zilnice, chiar dac nc
nu avea ce s testeze, l ajuta s neleag mai repede cerinele, i putea creea Test Case-ul
nainte de finalizarea

livrabilului, observaiile lui constatau mai rapid devierile sau

impedimentele proiectului.
Legat de aceste beneficii ale Scrum-ului, una din provocrile de a transforma echipa
dintr-una tradiional ntr-una Agile a fost schimbarea principiului se testeaz la sfritul
implementrii. Etapa de testare trebuia s nceap mult mai devreme, testndu-se pe pri
componente. n acest mod dac ceva nu merge bine sau nu este conform cerinelor se poate
descoperi mult mai rapid iar costul dezvoltrii proiectului era mult mai mic (s-a reuit o scdere
a perioadei de integrare a unei metode noi de la 15 zile la 10 zile).
Mai mult dect att echipa nu tia cum s se auto-organizeze i nici nu accepta autoorganizarea: la edinele zilnice Scrum Master-ul trebuia s ntrebe echipa cum au progresat fa
de edina trecut, ce vor face pn la edina viitoare i care sunt impedimentele; n loc ca
echipa s i prezinte singur activitatea; dezvoltatorii cereau ca sarcinile lor de lucru s fie
introduse de Product Owner n loc ca ei nii s i organizeze activitile. O alt problem era
nerespectatea regulilor edinelor Scrum zilnice: uneori dura mai mult de 15 minute, se discutau
probleme de analiz (detaliile ar fi trebuit discutate n edine separate) sau discuia devenea mai
mult o suit de plngeri. Dar treptat nelegnd scopul Scrum-ului, avnd o imagine mai clar
asupra activitilor i a beneficiilor edinelor Scrum, nclinaia echipei spre auto-organizare
apare.
- 35-

edina de Revizuire a Sprint-ului devenit n Smart2Tech edin de Revizuire a

Proiectului presupunea ca Scrum Master-ul (dei se ncearc ca rolul de prezentator s fie dat
trester-ului sau dezvoltatorului pentru a ajunge la abordarea teroretic: echipa trebuie s i
prezinte munca i s rspund la ntrebri) s realizeze un demo pentru a prezenta la ce s-a
lucrat, care au fost problemele pe parcursul proiectului i cum s-au rezolvat. Participanii la
aceast edin erau toi membrii companiei Smart2Tech, directorul general, directorul pe
vnzri, membri ai departamentului de integrare comerciani. Chiar dac aceast edin nici n
prezent nu se face la sfritul fiecrei Sprint cum ar trebui, ci doar la finalul ntregului proiect,
este foarte important s se realizeze pentru c aduce acea transparen dorit, pentru c n acest
mod se identific problemele nainte de lansare n producie, sau noile oportuniti (de exemplu,
n momentul prezentrii metodei de plat X s-a identificat posibilitatea creterii veniturilor prin
introducerea unei pagini care s realizeze conversia ntr-o alt moned).
Din pcate edina Retrospectiv a Sprint-ului a devenit i ea edina Retrospectiv
a Proiectului i chiar dac s-a discutat ce a fost bine i ce trebuie mbuntit de prea puine ori
s-au luat msuri de mbuntire.
Chiar dac edinele nu s-au putut respecta, chiar dac multe din recomandrile teoretice
nu s-au putut aplica n contextul Smart2Tech, cea mai mare greeal comis n procesul de
transformare de la tradiional la Agile/Scrum a companiei a fost exagerarea flexibilitii. Este
bine c s-a creat mai mult dinamic, cerinele pot fi acoperite cu costuri mai mici dar la
ntrebarea: pn unde poi lsa comerciantul s i schimbe produsul? de multe ori s-a rspuns
pn la instaurarea haosului distructiv, cnd nu mai tim dac schimbrile ad-hoc au afectat mai
mult sau mai puin sistemul.
3. Transformarea ciclului de via al dezvoltrii sistemelor din Modelul Cascad n
Modelul Incremental
Odat cu toate schimbrile realizate pentru implementarea Scrum era necesar i
transformarea modelului de dezvoltare a produselor software ntr-unul care s se plieze pe noul
model de management al proiectelor. Astfel, modelul cascad prezentat n subcapitolul anterior a
fost transformat n modelul incremental, al crui scop final era livrarea produsului treptat pe
componente distincte pentru a se putea descoperi ct mai rapid eventualele probleme.
De fapt modelul incremental este o alt form a celui cascad, etapele incipiente fiind la
fel descrise n cele dou modele: definirea cerinelor, ct i analiza se efectueaz la nivelul
ntregului sistem. Dup ce se parcurg aceste faze, se efectueaz descompunerea proiectului n
subproiecte, ele fiind urmrite pe activiti care vor concura la obinerea componenetelor

- 36-

necesare sistemului final24. Figura nr. 9 descrie acest model pentru ciclul de via al dezvoltrii
unei noi metode de plat X:

Figura nr. 9 Modelul incremental al ciclului de via al dezvoltrii unei metode noi X
(sursa: prelucrare proprie)
Comparativ cu modelul cascad rezultatele fazelor modelului incremental erau
aproximativ aceleai (folosind Scrum s-a renunat la documentul de specificaii i la cel de
proiectare tehnic) dar problemele din modelul cascad s-au ncercat a fi rezolvate prin cel
incremental:
n cazul n care se descopereau probleme la testarea unei componente, se ajungea din nou
la analizarea cerinelor dar problema se putea rezolva mult mai rapid, cu afectarea unei
componente a metodei i nu a ntregii metode;
Testnd metoda pe componente i era mult mai uor tester-ului s se familiarizeze cu
noua metod de plat i s descopere ct mai multe probleme;
Lansarea/Testare/Integrarea Comerciantului pe producie se putea realiza i pe
componente dar de obicei se realiza per ntreaga metod de plat;
Fiind testat metoda foarte bine pe componente, managementul i-a asumat rspunderea
de a nu realiza Testarea de regresie, bineneles cu riscul de a scpa de sub control celelalte
metode de plat din sistem, aceast testare realizndu-se o dat la patru luni. Pentru a diminua
acest risc s-a investit n crearea i rularea testelor automate pentru a verifica: dac se mai ajunge
la pagina furnizorului metodei de plat, dac tranzacia este n baza de date, dac redirectarea
clientului se face corect;
La testarea metodei pe componente, de multe ori nu se apreciaz impactul integrrii i
care sunt elementele ce trebuie executate din nou, problemele fiind detectate n mediul de
producie. Aceast problem este mai mult una de comunicare i soluia a fost crearea unui
24

Oprea, D., Meni, G., Dumitriu, F., Analiza sistemelor informaionale, Editura Univesitii Alexandru Ioan
Cuza, Iai, 2012, p.35

- 37-

document colaborativ care centralizeaz ce s-a lansat pe mediul de test i pe mediul de producie
i precizeaz ce zone/fiiere au fost afectate/executate la integrare.
Pentru a realiza o testare eficient a metodei pe producie, testerilor li s-a dat access la
fiierele de logare dar din pcate problema configurrilor de metod care de multe ori nu sunt
disponibile la lansarea metodei pe producie nu a putut fi rezolvat, cauzele fiind externe:
contractul cu furnizorul nc nu este gata, furnizorul cere a fi cel puin un comerciant integrat cu
metoda de plat pentru a da datele de configurri.
Pentru c exist o dependen foarte mare de sistemul furnizorului, riscul descoperirii
unor probleme pe mediul de producie datorate unor schimbri realizate de furnizor nu poate fi
eliminat; acceai regula a testului de perfoman a metodei rmne i n cazul modelului
incremental: dovada clar a bunei funcionri exist doar la primele tranzacii pltite cu succes.
Modelul incremental nu se poate aplica n toate proiectele Smart2Tech, uneori lipsind
elementele necesare descompunerii ntregului: de exemplu n cazul adugrii unei funcionaliti
la Dashboard Comerciant se va folosi modelul n cascad.

3.3 Un alt fel de Scrum

La o evaluare sumar a modului de implementare a Scrum-ului n Smart2Tech se
constat beneficiile dar i zonele problematice care prin soluii practice se pot mbuni (figura
nr. 10 de mai jos fiind o sintez a realizrilor, lipsurilor i soluiilor propuse):

Ce s-a dorit?

Un mod de
lucru mai eficient

Ce s-a obinut?

Soluii

edinele Zilnice Scrum

permit colaborarea n
timp util, identificarea
mai
rapid
a
problemelor

Seminar de nvare i
perfecionare Scrum cu
explicare obiectivelor
acestor edine

edinele
de
Planificare, Revizuire i
Retrospectiv a Sprintului nu se respect
edinele
zilnice
ajungeau s depeasc
15 minute, fiind mai
mult edine de discuii

- 38-

Realizarea unui proiect

model
Schimbarea mentalitii
organizaionale
Realizarea
edinelor
zilnice n picioare

Ce s-a dorit?

Transparen

Ce s-a obinut?

Soluii

Tester-ul
primea
informaiile
necesare
testrii
mult
mai
devreme

edinele
de
Planificare, Revizuire i
Retrospectiv trebuie
s se realizeze pe
fiecare Sprint, nu pe
ntregul proiect

La sfritul proiectului
directorul general i
toate
persoanele
interesate particip la
prezentarea produsului
i ofer feedback
Prin
segmentarea
angajailor Smart2Tech
n mai multe echipe
Scrum
anumite
informaii
organizaionale
nu
ajung la toi membrii
companiei

Adaptare

Schimbarea cerinelor
nu
mai
presupune
efortul chinuitor al
actualizrii
documentaiei,
ci
explicarea acestora n
cadrul edinelor zilnice

edinele Scrum zilnice

divizate pe proiecte se
transform n edin
organizaional; n care
pentru fiecare proiect
persoanele
implicate
spun ce au fcut i ce
urmeaz
s
fac.
Reguli:
edina
se
desfoar n picioare,
fiecare proiect are 2
minute, problemele se
detaliaz ulterior
Seminar de nvare i
perfecionare Scrum cu
explicare obiectivelor i
a regulilor recomandate
de desfurare
Realizarea unui proiect
model

n caz c un User Story

este blocat se trece la
urmtorul
Echipa
nu
autoorganizeaz

Scderea
costurilor i a
timpului de
reacie la cerine

se

Implementarea
unei
noi metode de plat a
sczut de la 15 zile la
10 zile
Cu anumite riscuri
asumate testarea de
regresie se realizeaz
din patru n patru luni
Flexibilitatea presupune
probleme: nu se tie ce
- 39s-a lansat n producie

A fi Agile nu nseamn
dispariia documentelor
Un document bine
structurat,
pus
pe
portalul SharePoint TFS
este necesar pentru a
ti: ce s-a lansat pe
mediul de test/producie
i cnd, care este
statusul
testrii
pe
mediul de test/producie

Ce s-a dorit?

Ce s-a obinut?

Soluii

edinele Scrum zilnice

faciliteaz comunicarea
impedimentelor

edinele
de
Planificare, Revizuire i
Retrospectiv trebuie
s se realizeze pe
fiecare Sprint, nu pe
ntregul proiect

edinele de revizuire a
proiectului se fac cnd
programul este mai
liber i nu la sfritul
proiectului,
anumite
probleme
fiind
descoperite prea trziu

Anticiparea
Riscurilor

Nefolosirea
diagramelor Borndown
nu permite anticiparea
corect a riscurilor
proiectului

Rezolvare
defectelor i
problemelor n
timp util

Crearea unei echipe de

suport tehnic pentru ca
dezvoltatorii s se poat
concentra
pe
implementarea
User
Story-urilor

50%
dintre
impedimente au fost
rezolvate mult mai uor,
edinele Scrum zilnice
facilitnd comunicarea

edinele
de
Planificare, Revizuire i
Retrospectiv trebuie
s se realizeze pe
fiecare Sprint, nu pe
ntregul proiect

Testerii comunicnd
bug-urile identificate la
edinele zilnice a fost
mult mai uoar
identificarea cauzelor

edinele Scrum zilnice

divizate pe proiecte se
transform n edin
organizaional; n care
pentru fiecare proiect
persoanele
implicate
spun ce au fcut i ce
urmeaz
s
fac.
Reguli:
edina
se
desfoar n picioare,
fiecare proiect are 2
minute, problemele se
detaliaz ulterior

edinele de revizuire a
proiectului se fceau
cnd programul era mai
liber i nu la sfritul
proiectului,
anumite
probleme
fiind
descoperite prea trziu

Figura nr. 10 Cerine, realizri i soluii de mbuntire

(sursa: prelucrare proprie)

- 40-

Pentru c n Scrum, poate mai mult dect n celelalte metode de lucru Agile, Echipa de
dezvoltare trebuie s se autoorganizeze, trebuie luate msuri de mbuntire prin:

nelegerea scopului autoorganizrii;

Organizarea pe o tabl cu foie grupate n: Ce se dorete a fi gata pn la data de

x (delimitare scop Sprint)?, Ce s-a realizat?, Ce s-a testat?, Ce s-a lansat (n
cazul Smart2Tech lansare pe test i lansare pe producie?(organizare ce se
construiete pe fiecare Sprint n parte pn la sfritul proiectului). n acest mod
echipa are tot timpul imaginea de ansamblu a Sprint-urilor;

Permutarea rolului de Scrum Master ntre membrii Echipa Scrum numai n

cazul n care Echipa Scrum a neles modul de desfurare corect al edinelor;

n cadrul unor edine tehnice sptmnale fiecare dezvoltator prezint ce a lucrat,

rspunznd la ntrebri; se propun mai multe soluii tehnice.

Cnd o companie se pregtete s adopte cadrul de lucru Scrum principalul risc ar fi acela
de a face totul scrum, cum de multe ori s-a ntmplat i cu proiectele Smart2Tech, multe dintre
ele fiind realizate fr prea multe edine sau fr specificaii clare dar plasa de siguran n
foarte multe dintre cazuri a fost testarea automat. Evaluarea zilnic att pe mediul de test, ct i
pe producie a metodelor de plat a permis identificarea problemelor fr a mai crea un efort n
plus pentru testare.
Soluiile i practicile de mbuntire a Scrum-ului trebuie s fie ct mai clare, uor de
realizat n practic pentru a deveni un mod de lucru adaptabil i raportat la specificul proiectelor
companiei. Schimbarea modului tradiional de gndire este o cerin promulgat de foarte muli
teoreticieni, dar n practic nu poi cere schimbare fr un mod organizat de lucru, fr
optimizarea proceselor de lucru.

- 41-

Concluzii
Avnd n vedere subiectele abordate se poate concluziona c prezenta lucrare intitulat
SCRUM n managementul proiectelor software, structurat pe trei capitole, prezint o
abordare teoretic i aplicativ a cadrului de lucru.
Primul capitol, intitulat Scrum - moft sau necesitate? introduce conceptul de Scrum, ce
implicaii are la nivelul managementului proiectelor i organizaional, care este legtura dintre
cadrul de lucru i metodologia Agile. Care sunt regulile cadrului de lucru i particularitile
raportate la alte metode de lucru din metodologia Agile sunt doar cteva din aspectele supuse
cercetrii n acest capitol.
Al doilea capitol este dedicat explicrii modului de implementare corect a Scrum-ului.
Cu titlul Scrum - management al proiectelor mai eficient? aceast parte a lucrrii se axeaz, de
asemenea i pe oferirea de soluii la problemele ce pot s apar pe parcursul implementrii.
Conform cercetrii patru factori influeneaz preponderent reuita managementului unui proiect
folosind Scrum: nelegerea rolurilor pe care le au membrii Echipei Scrum, nelegerea
particularitilor i a modului de desfurare a edinelor Scrum, nelegerea conceptelor de
Backlog Produs i Backlog Sprint i definirea clar a termenului finalizat.
Capitolul 3, intitulat Studiu de caz proiecte Smart2Tech Development realizeaz o
prezentare a companiei, a cele dou sistemele EuroPay i GlobalPay i a tipologiei proiectelor,
pe baza crora se realizeaz studiul de caz. Analiza are n vedere identificarea premiselor,
problemelor i cerinele de schimbare a modului de lucru: de la cel tradiional la cel bazat pe
Scrum, proiectul exemplificat fiind dezvoltarea unei noi metode de plat X. Realizarea unei
analize comparative dintre ce s-a dorit i ce s-a obinut permite identificarea unor soluii practice,
uor de utilizat pentru mbuntirea cadrului de lucru Scrum n compania Smart2Tech
Development.
Dac ar fi s sintetizez materialelor i ipotezele studiate i prezentate ntr-o singur fraz a
descoperi c Scrum n managementul proiectelor nseamn un mod de lucru mai eficient,
transparen, adaptare, scderea costurilor i a timpului de reacie la schimbrile de cerine,
anticiparea riscurilor, rezolvarea problemelor n timp util i n primul rnd schimbare.

- 42-

Bibliografie
M tem de omul unei singure cri. (Thomas DAquino)
Aa c am decis s cercetez mai multe.

Cri:
1. Boehm, B., Turner., R., Balancing Agility and Discipline: A Guide for the Perplexed: A
Guide for the Perplexed, Addison-Wesley, Boston, 2004
2. Cohn, M., Agile Estimating and Planning, Pearson Education Inc, SUA, 2006
3. Goodpasture, J., C., Project Management the Agile Way. Making it Work in the
Enterprise, J. Ross Publishing, SUA, 2010
4. Kniberg, H., Scrum and XP from the Trenches. How we do Scrum, C4Media, SUA, 2007
5. Kniberg, H., Skarin, M., Kanban and Scrum making the most of both, C4Media, SUA,
2010
6. Oprea, D., Meni, G., Dumitriu, F., Analiza sistemelor informaionale, Editura
Univesitii Alexandru Ioan Cuza, Iai, 2012
7. Resnick, S., Bjork, A, Michael de la Maza, Professional Scrum with Team Foundation
Server 2010, Wiley Publishing, Indianapolis, 2011
8. Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org, SUA, 2011
9. Schwaber, K., Agile Project Management with Scrum, Microsoft Press, Washington,
2004

Site-uri:
1. http://www.altexsoft.com
2. http://www.codeproject.com
3. http://kenschwaber.wordpress.com
4. http://www.managementul-proiectelor.ro
5. http://www.mountaingoatsoftware.com
6. http://msdn.microsoft.com
7. http://www.scrum.org
8. http://www.smart2pay.com
9. http://www.smart2tech.com
10. http://www.telerik.com
11. http://www.trilex.ro
12. http://www.vates.com
13. http://www.versionone.com
- 43-