Sunteți pe pagina 1din 44

Universitatea „Alexandru Ioan Cuza” Iaşi

Facultatea de Economie şi Administrarea Afacerilor


Master Sisteme Informaționale pentru Afaceri

SCRUM în managementul
proiectelor software

Coordonator ştiinţific,
Prof. Univ. Dr. Gabriela Meșniță

Absolventă,
Macuc Cristina-Adriana

Iaşi, februarie 2013


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

1. Scrum – moft sau necesitate? ........................................................................................... 4

1.1 Scrum și metodologia AGILE ..................................................................................... 4


1.2 Concepte, reguli și implicații organizaționale în cadrul de lucru Scrum .................... 7
1.3 SCRUM vs. Kanban vs. eXtreme Programming (XP) .............................................. 11

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

2.1 Provocările unui proiect ............................................................................................ 13


2.2 ”Rețeta” unui Scrum reușit ........................................................................................ 14
2.3 Probleme și rezolvări ................................................................................................. 18

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

3.1 Premise, probleme și cerințe î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 înțelegere a componenței Echipei Scrum.......................................... 14
Tabel nr. 2 Cum să înțelegem corect ședințele Scrum? .......................................................... 16
Tabel nr. 3 Fazele modelului în cascadă și problemele identificate........................................ 27

Figura nr. 1 Componența Echipei Scrum. Roluri și Caracteristici ......................................... 10


Figura nr. 2 Reprezentare mod de lucru Scrum ...................................................................... 11
Figura nr. 3 Portofoliu soluții 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 dezvoltării 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 dezvoltării unei metode noi X ........ 37
Figura nr. 10 Cerințe, realizări și soluții de îmbunătățire ....................................................... 40

- 2-
Introducere

A devenit deja un clișeu să afirmăm că trăim într-o lume în continuă schimbare.


Dinamica cerințelor, incertitudinea și riscurile tot mai mari ajung a fi de cele multe ori
principalele caracteristici ale proiectelor software. Din această cauză, cel puțin așa am constatat
din propria experiență, managementul proiectelor a devenit o luptă continuă de a găsi metoda de
lucru adaptată la specificului organizației care să crescă șansele de reușită. 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 îmbunătățit. Pentru a putea aborda acest domeniu a fost
primordială definirea conceptelo, prezentarea particularităţilor, a regulilor și a modului de
desfășurare recomandat, stabilirea implicaţiilor organizaţionale şi a rolurilor participanților.
Înțelegerea provocărilor implementării Scrum-ului duce la identificarea unui set de
recomandări și prezentarea a ceea ce aș dori să fie, ”rețeta” spre reușita proiectelor Scrum,
”rețetă” structurată sub forma unor întrebări la care literatura de specialitate a oferit răspuns.
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 apariției Scrum-ului, ca nouă
metodă în Smart2Tech. Prezentarea schimbărilor ce s-au produs în modul de lucru și în ciclul de
viață al dezvoltării produselor software conturează beneficiile acestui model dar și provocările
întâmpinate.
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 gândire pe care îmi doresc să îl propag este
acela al soluțiilor simple pentru problemele complicate: cu cât o procedură va fi mai complicată,
cu cât un document va fi mai stufos, cu atât va fi respins mai mult sau va fi abandonat mai
repede.
Astfel, realitatea demonstrează că replica lui Jim Coplien către Jeff Sutherland (creatorul
Scrum) este memorabilă prin adevărul pe care îl exprimă: "Scrum va fi pe placul tuturor pentru
că este ceea ce facem deja atunci când nu mai avem încotro."

- 3-
1. Scrum – moft sau necesitate?

Înțelegerea raportul de legături 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 desfășurare și a implicațiilor organizaționale
oferă premisele cunoașterii metodei de lucru. Studiul comparativ dintre principalele metode
cuprinse în metodologia Agile, realizat cu scopul de a pune accentul pe particularitățile de lucru
Scrum, răspunde la întrebarea din titlul capitolului: Scrum nu este doar o înșiruire de reguli, este
o necesitate în condițiile actuale de lucru al proiectelor, este un răspuns la nevoia de schimbare.

1.1 Scrum și metodologia AGILE


Metodele tradiţionale erau eficiente, produceau software optimizat cu posibilitatea de a
reutiliza anumite elemente din procesul de dezvoltare dar costurile utilizării acestor metode era
mult prea mare: timpul necesar elaborării documentaţiei era disproporţional raportat la timpul
dedicat dezvoltării software-ului; dacă cerinţele se schimbau actualizarea documentaţiei devenea
un chin; optimizarea şi reutilizarea codului lua atât de mult timp încât adaptarea la noile
tehnologii se transforma în dorinţă imposibilă.
Mai mult, Mike Cohn în ”Agile Estimating and Planning” identifică alte trei probleme1
ale abordării tradiţionale: sarcinile de lucru se organizează în abordarea tradițională pe individ și
nu pe grup, ceea ce duce la probleme; planificarea în abordarea tradițională se realizează plecând
de la premisa că toate activitățile identificate se vor realiza, lăsându-se prioretizarea să fie făcută
de echipa de dezvoltare; modelele tradiționale se axează foarte mult pe finalizarea activităților și
nu pe livrarea produselor/funcționalităților (practica demonstrând de multe ori că s-au
implementat funcționalități de care clientul nu avea nevoie).
Raportându-se la aceste probleme şi la cerinţele în continuă schimbare la care abordarea
tradiţională nu poate să se adapteze în timp util, perspectiva în managementul proiectelor s-a
schimbat radical prin introducerea unei noi abordări: aşa numită „Agile”. Deși a inceput cu mulți
ani înainte, ”mișcarea” Agile a fost declarată oficial prin crearea Manifestului Agile2 din
februarie 2001 (Beck). Autorii manifestului au precizat că ei valorizează:
1. Indivizii și interacțiunile dintre aceștia mai mult decât procesele și instrumentele de
lucru: se preferă comunicarea, față în față, verbală între persoane și se recunoaște
unicitatea fiecărui individ și contribuția pe care o aduce în cadrul proiectului;
2. Dezvoltarea soft-ului mai mult decât întocmirea documentelor: această valoare ar
putea fi definită mai degrabă ca dezvoltarea produsului în loc de dezvoltarea software-

1
Cohn, M., Agile Estimating and Planning, Pearson Education Inc, SUA, 2006, pp. 16-17
2
http://agilemanifesto.org/ (accesat 20/01/2013)
- 4-
ului pentru că produsul final este cel care contează cel mai mult la sfârșitul unui proiect;
echipa ar trebui să depună mai mult efort în activitățile care aduc valoare, dacă se
lucrează foarte mult la documentație și mai puțin la dezvoltarea produsului rezultatul nu
va fi unul favorabil;
3. Colaborarea cu clientul mai mult decât 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 decât urmărirea strictă a planului: dacă s-a
urmărit cu strictețe respectarea planificărilor și finalizarea la timp a activităților dar
rezultatul nu este pe măsura așteptărilor clientului, proiectul nu va fi unul de succes.
Toate aceste valori fac ca Agile să fie înțeleasă ca o metodologie bazată pe principiul
colabărării, toți membri echipei având aceeași misiune: de a livra frecvent, iterativ, la cel mai
înalt nivel calitativ posibil, noi funcționalități, noi componente, prioritizate după necesitate și
valoarea pe care o aduc, luând în considerare viziunea utilizatorului și feedback-ul de la acesta.
Definiţia Agile pentru mulţi autori de specialitate înseamnă să produci software cu mai
puţină documentaţie în condiţiile unor cerinţe care se schimbă rapid şi care satisface toate
necesităţile clientului, definiţie care ar deveni adevărată dacă s-ar prezenta şi riscurile.
Presupunerea că Agile înseamnă lipsa documentație este cel mai popular mit legat de această
metodologie, abordare cu care eu nu sunt de acord: documentele simple, ușor de înțeles și
integrat în modul de lucru al echipei permit evitarea haosului distructiv și nu am lucrat până
acum la proiecte în care lipsa unei documentații măcar succinte să nu fie cauză a eșecului.
Boehm şi Turner identifică corect riscurile acestei abordări greșite în lucrarea Balancing
Agility and Discipline: A Guide for the Perplexed ca fiind3: implementarea proiectelor mari se
realizează cu dificultate fără o documentaţie completă; dacă costul identificării tuturor
utilizatorilor finali este prea mare, acesta nu va putea fi compensat cu perioada de implementare
iar schimbarea unei cerinţe a unuia dintre utilizatori nu va putea fi acoperită în timp util.
Aceeaşi autori susţin că metodele Agile îşi dovedesc eficienţa 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 susţine și el această opinie4 dar
lărgeşte numărul de membri la 50 şi adaugă faptul că Agile se potriveşte mai mult echipelor
aflate în aceeaşi locaţie decât celor multinaţionale unde comunicarea se realizează cu dificultate.

3
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 având un numitor comun5:
fiecare în modul propriu încearcă să rezolve aceeaşi dilemă, omniprezentă în procesul de
dezvoltare software: cum să reuşeşti să livrezi produsul în condiţiile în care cerinţele şi
necesităţile clientului sunt incerte. Dintre metodele Agile se pot enumera: Scrum, Extreme
Programming (XP), metode Crystal, EVO (metodă revoluționară brevetată de Tom Gilb), RAD
care a evoluat în DSDM (Metodă Dinamică de Dezvotare a Sistemelor- în traducere). Pe lângă
acestea mai sunt: modele orientate pe funcţionalităţi („Feature-driven Design), modele în
vederea adaptării 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 universităţii 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
privinţa apartenenţei la Agile sunt Kanban şi CleanRoom.
Așa cum se precizează și mai sus: Agile este metodologia iar Scrum este metoda de lucru
ce folosește principiile din metodologie dar are propriul set de reguli. În articolul Telling It Like
It Is Ken Schwaber folosește ș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 cercetări care fac referire la metode neconvenționale 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 astăzi 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 cât 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
idem, p.xi
6
http://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/( accesat 12/02/2013)
7
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 implicații organizaționale î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 încât să fie îmbunătățite, demonstrând astfel necesitatea aplicării lui ca și nou mod
de lucru al proiectelor.
Punerea în practică a Scrum-ului depinde de trei piloni8 importanți ce determină la
nivelul organizației schimbări:
 Transparența – toate aspectele semnificative ale procesului trebuie să fie vizibile pentru
cei responsabili de rezultatul/finalizarea produsului. Limbajul trebuie să fie unul comun,
ușor de înțeles pentru toți participanții;
 Verificarea – diferite aspecte ale procesului trebuie verificate suficient de frecvent, astfel
încât să fie identificate din timp problemele. Frecvența verificărilor trebuie totuși să nu
afecteze ritmul de lucru, în acest caz pierzându-și utilitatea;
 Adaptarea – dacă pe durata verificării se constantă că s-a deviat de la cerințele inițiale și
că produsul final nu va fi acceptat atunci procesul/produsul trebuie ajustat și această
corecție trebuie realizată cât 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
puțin în care o parte ”finalizată”, utilizabilă și potențial livrată a produsului este creată. Un nou
Sprint începe imediat după ce precedentul s-a finalizat și s-au stabilit concluziile acestuia. Sprint-
ul poate fi considerat un proiect care trebuie finalizat într-o lună cu anumite costuri și riscuri, la
finalul căruia 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 esențial să se respecte următoarele reguli:
 Nu se fac schimbări care afectează scopul Sprint-ului;
 Componența echipei de dezvoltare rămâne constantă;
 Calitatea muncii nu trebuie să scadă;
 Scopul Sprint-ului trebuie să fie clar și poate fi renegociat dacă apar noi cerințe/informații
În cadrul unui Sprint se oferă patru oportunități pentru realizarea verificării și adaptării:

8
Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org, SUA, 201, p.4
- 7-
 Sprint Planning Meeting (Ședința de Planificare a Sprint-ului – se verifică cum se poate
optimiza Sprint-ul, cât de clar este scopul Sprint-ului);
 Daily Scrum (Ședința Scrum Zilnică – se verifică progresul ce se realizează zilnic pe
durata proiectului, se corectează neînțelegerile în privința cerințelor (dacă există) și se
verifică dacă sunt impedimente)
 Sprint Review (Ședința de Revizuire - se verifică ce și cât din obiectivele stabilite pentru
lansarea componentei au fost îndeplinite)
 Sprint Retrospective (Ședinta Retrospectivă – se verifică evoluția Sprint-ului anterior,
ce a fost bine și ce nu și se găsesc soluții de îmbunătățire a Sprint-urilor viitoare).
Întâlnirile de mai sus se caracterizează prin stabilirea unei durate maxime a ședinței astfel
încât timpul de planificare să fie optim și să nu afectează timpul de dezvoltare. Alături de aceste
Ședințe în componența unui Sprint mai intră munca de dezvoltare.
Mediul Scrum presupune formarea unor Echipe Scrum cărora li se asociază roluri,
evenimente/intervale de timp fixate, rezultate și reguli (fiecare componentă deservește 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 iterații, se
bazează pe feedback-ul obținut cu regularitate, atât în timpul fiecărui Sprint, la final acestora, cât
și la livrarea produsului final și este formată din (componența și rolurile Echipei Scrum sunt
prezentate detaliat în figura nr 1):
 Scrum Master (Coodonatorul Scrum-ului – pentru a ilustra corespunzător acest rol voi
folosi în lucrare termenul în engleză), cel care este responsabil ca tot procesul Scrum să
fie înțeles și respectat;
 Product Owner (Proprietarul Produsului – pentru a ilustra corespunzător acest rol voi
folosi în lucrare termenul în engleză), cel care stabilește cerințele și evaluează livrabilele;
 Development Team (Echipa de Dezvoltare), cei ce pot finaliza cerințele Product Owner-
ului până la sfârșitul Sprint-ului sub forma unui livrabil, parte componentă a produsului
final.
Backlog-ul Produsului (Lista de Cerințe a Produsului - pentru a ilustra corespunzător
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 funcționalitățile,
funcțiile, tehnologiile, îmbunătățirile și corecțiile care vor fi implementate în vederea lansărilor
viitoare a produsului software. Backlog-ul evoluează odată cu produsul și cu mediul în care va fi
folosit, dinamică necesară pentru a atinge obiectivele dezvoltării produsului: de a fi
corespunzător, competitiv și util.

- 8-
- Este responsabil de aderarea
Echipei și a organizației la
valorile, practicile și regulile
Scrum
- Ajută Echipa să înțeleagă
SCRUM MASTER PROCES SCRUM conceptele de auto-organizare și
plurifuncționalitate
- Înlătură impedimentele ce pot
apărea în timpul procesului
- Ajută Echipa Scrum dar în
același timp este liderul ei

- Explică clar ce se dorește de la


produs
E
- Prioritizează Backlog-ul
C Produsului
- Verifică dacă efortul depus de
H
Echipa de Dezvoltare este
I calitativ
PRODUCT OWNER BACKLOG PRODUS - Se asigură că cerințele sunt
P
clare, vizibile oricui din echipă
A - Specifică Echipei Scrum la ce
se va lucra în continuare
- Verifică dacă echipa de
S dezvoltare a înțeles Backlog-ul
Produsului la un nivel care să
C
asigure livrarea produsului
R conform așteptărilor clientului
U
M
- Transformă, în fiecare iterație,
Backlog-ul Produsului în
potențial livrabili secvențiali
- Au capacitatea de a transforma o
sarcină într-un livrabil dar
munca lor se realizează după
propria organizare
- Fiecare membru al Echipei se
DEVELOPMENT TEAM PRODUS folosește de propria
expertiză/cunoștințe/abilități
pentru rezolvarea problemelor
dar responsabilitatea pentru
calitatea livrabilului aparține
Echipei
- Dimensiunea optimă a echipei
este de șapte persoane, plus sau
minus doi

- 9-
Figura nr. 1 Componența 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 necesității elementului;
 Estimarea – estimări mai bune se realizează atunci când elementul este definit clar și
detaliat.
Elementele cu cea mai mare prioritate vor fi dezvoltate imediat. Cu cât mai mare este
prioritatea, cu atât elementul este mai urgent, cu atât mai mult a fost analizat și s-a stabilit mai
clar care este valorea sa. Cu cât prioritatea elementului este mai mică, cu atât este mai puțin
detaliat. Pe măsură ce un produs este folosit, valoarea lui și feedback-ul oferit de piață cresc iar
Backlog-ul Produsului crește și se completează (sarcinile se modifică dinamic din cauza
modificărilor în cerințele de business, condițiilor de piață, tehnologie și dinamicii echipei).
Adesea, mai multe echipe Scrum lucrează la același produs. În acest caz elementele din Backlog
conțin un atribut adițional ce permite gruparea lor seturi de funcționalități, tehnologie sau
arhitectură pentru a facilita organizarea muncii în echipe.
Elementele din Backlog-ul Produsului sunt estimate inițial în timpul Planificării
Lansărilor (termenul în engleză consacrat Release) și apoi pe măsură ce sunt create. Estimările
sunt revizuite și ajustate pe măsură ce backlog-ul este analizat în detaliu și pot fi modificate
oricând. Responsabilitatea estimărilor revine echipei și pot fi negociate cu Product Owner-ul.
Monitorizarea efortului rămas pentru elementele din Backlog-ul Produsului în funcție de
timp se realizează prin Diagrama Burndown (diagrama de evoluție a proiectului - pentru a
ilustra corespunzător acest concept voi folosi în lucrare termenul în engleză). Efortul estimat este
măsurat în orice unitate aleasă de către Echipa Scrum și organizație. De obicei unitățile de timp
folosite sunt Sprint-urile.
Activitățile pe care echipa le îndeplinește pentru a transforma elementele din Backlog-ul
Produsului într-o parte finalizată se concretizează în Backlog-ul Sprint-ului (lista de cerințe
realizate în Sprint - pentru a ilustra corespunzător acest concept voi folosi în lucrare termenul în
engleză). Multe dintre aceste activități sunt identificate în timpul Planificării Sprint-ului dar pe
măsură ce Echipa de Dezvoltare lucrează la sarcini de lucru individuale va afla că mai multe sau
mai puține dintre activitățile planificate sunt necesare sau că o anumită activitate durează mai
mult sau mai puțin decât durata estimată. Backlog-ul Sprintului este o imagine în timp real,
vizibilă, a muncii pe care echipa plănuiește 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 rămase într-un


Sprint față de durata Sprint-ului, creat astfel: se calculează munca rămasă prin adunarea zilnică a
estimărilor din backlog. Cantitatea de muncă rămasă într-un Sprint este suma muncii rămase
pentru întreg Backlog-ul Sprint-ului. Evidența acestor sume zilnice se păstrează și valorile sunt
folosite pentru a crea un grafic care arată munca rămasă în funcție de timp. Prin desenarea unei
linii prin punctele graficului, Echipa poate observa progresul din cadrul Sprint-ului. Se studiază
munca rămasă și data estimată de finalizare.
Una din principalele reguli Scrum este ca la finalul fiecărui Sprint-ului acel increment ,
parte a produsului potențial livrabilă, să adere la definiția curentă a termenului ”finalizat”: să fie
ceva în plus, adăugat la toate îmbunătățirile 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ă înţelegerea aceste metode ca
posibilitate extremistă de înterpretare a bunelor practici Agile10 (nu poţi să afirmi că foloseşti XP

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

- 11-
dacă nu utilizezi „codarea în pereche: programator-observator”, „refactoring” sau nici măcar
„planificare de tip joc”). Goodpasture, în Project Management the Agile Way. Making it Work in
the Enterprise susţine că SCRUM este cea mai populară metodă11, fiind şi cea mai simplă prin
faptul că nu se prescriu practici, tehnici de lucru, ci doar se oferă un set de reguli Scrum.
Deși considerate două metode de lucru Agile foarte apropiate, eXtreme Programming
este considerată a fi mai orientată pe definirea practicilor de dezvoltare software, pe când Scrum
mai mult pe practici de management. Pentru că în eXtreme Programming tehnicile de dezvoltare
au un caracter obligatoriu de utilizare, numeroși autori recomandă întâi să se înceapă cu Scrum
pentru a echipa să câștige î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 atât a managementului
proiectului, cât și a modului de dezvoltare.
Dacă în Scrum nu se acceptă schimbări ale scopului Sprint-ului pe durata desfășurării
acestuia, XP permite acest lucru, atâta timp cât nu afectează funcționalitatea 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 particularitățile Scrum-ului, în Kanban nu există iterații sau Sprint-uri, nici
roluri definite (echipa de proiect sau clientul poate specifica orice rol este nevoie în proiect) iar
estimările se consideră că nu sunt necesare pentru că oricum nu se respectă. Statusul curent al
unei cerințe poate fi unul din următoarele: ”Backlog”, ”În Lucru”, ”Finalizat”. Sarcinile de lucru
aflate în lucru sunt limitate pe fiecare etapă permițând urmărirea și rezolvarea blocajelor imediat.
Kanban se potrivește mai mult acelor proiecte de dezvoltare unde sarcinile de lucru sunt
în continuă schimbare și nu există o modalitate de a defini iterații/Sprint-uri, dar necesită o foarte
bună cunoaștere 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 întâi înțelese
principalele provocări ale proiectelor. Identificarea factorilor determinanți ai succesului Scrum-
ului oferă un șablon de lucru și recomandările necesare pentru a ajunge la un management al
proiectelor mai eficient. Bineînțeles, probleme pe durata implementării pot apărea dar literatura
de specialitate oferă prin studiile de caz prezentate posibile soluții.

2.1 Provocările unui proiect


Principalele probleme ale proiectelor pleacă chiar de la prima etapă a managementului.
Practica în privința planificării 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 când se poate livra
produsul, în al doilea caz planul va părea atât de bun încât orice modificare a planului va fi cu
greu realizată.
Dezvoltarea software nu trebuie luată ca pe o competiție internă: cine cere mai mult, cine
câștigă lupta cu estimarea. Dacă se dezvoltă funcționalități greșite, pe care clientul nu le-a cerut
și nu le va folosi, pierde atât echipa care a depus efort într-o direcție greșită cât și clientul care va
trebui să mai aștepte o perioadă până ce funcționalitățile corespunzătoare se vor dezvolta. Pentru
echipa planul reprezintă o perspectivă asupra viitorului, dar pe parcursul proiectului, cu cât se
câștigă mai multă experiență și cunoștințe, această perspectivă se schimbă.
În august 2007, Dynamic Markets a realizat o anchetă14 pe 800 de manageri IT din opt
țări și au descoperit:
 62% din proiecte depășeau timpul alocat;
 49% din proiectele depășeau bugetul;
 47% din proiectele necesită costurile de întreținere mai mari decât cele estimate;
 28% dintre organizații au implementat proiecte care nu se potrivesc cerințelor;
 25% dintre organizații sunt reticente în a adopta noi tehnologii;
 13% din organizații spun că proiectele nu au adus valoarea adaugată la care se
așteptau.
Statisticile variază între studii, în funcție 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 depășirilor de buget sau de timp, a livrării unor cerințe greșite sau dezvoltate greșit.

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 eșecul
proiectelor IT s-au identificat cinci domenii cheie care influențează succesul sau eșecul unui
proiect:
 Managementul proiectelor (54%);
 Mediul de afaceri (21%);
 Oamenii (14%);
 Procedurile(8%);
 Tehnologia(3%).
Studiul demonstrează că un management mai eficient ar crește probabilitatea de succes a
proiectelor și acest beneficiu îl oferă Scrum-ul.

2.2 ”Rețeta” unui Scrum reușit


Șansele de reușită a managementului unui proiect Scrum cresc exponențial cu înțelegerea
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 Înțelegere a Componenței
Echipei Scrum soluționează toate aceste întrebări legate de membrii Echipei Scrum:
Tabel nr. 1 Matricea de înțelegere a componenței 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 Dacă proiectele sunt Membru al echipei
membru al Echipei dar pentru clienți devine cel care are
acest lucru duce adesea la poate fi chiar managerul abilitățile necesare de a
conflicte în momentul când de produs transformă o sarcină
va trebui să aleagă între a într-un livrabil al
rezolva problemele ca Dacă proiectele vor fi produsului
Scrum Master și a îndeplini folosite intern, Product
sarcinile din Sprint 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ă învețe noi
chiar un membru al lucruri
Echipei care face și
muncă de implementare,
însă această
responsabilitate îl poate
împiedica să lucreze
corespunzător cu toți cei
implicați)

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 considerați
membri ai Echipei de
Dezvoltare decât î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 O echipă cu un număr


organizația și Echipa Scrum responsabilă cu Backog-ul de membri suficient
la practicile, valorile li produsului pentru a fi agili și pentru
regulile Scrum a finaliza munca
O echipă care are
Este mentor pentru Product capacitatea de a
Owner privind modul de a transforma cerințele
prezenta, creea și coordona prezentate în Backlog-ul
Backlog-ul Produsului Produsului în Produsul
Final
Este cel care înțelege și
explică modul de lucru
Agile în organizație

Ce nu poate fi? Nu poate fi un comitet Nu poate fi un comitet Nu pot exista sub-


echipe axate pe un
domeniu specific (de
exemplu sub-echipa de
Testare)

Ce poate face? Îi poate ajuta pe cei din Poate reprezenta cerințele Sunt singurii care pot
exteriorul Echipei Scrum să unui comitet în Backlog- livra la sfârșitul fiecărui
înțeleagă procesul și să ul Produsului; Sprint câte o
descopere care dintre componentă a ceea ce se
interacțiunile cu Echipa Este singurul care poate va numi la sfârșitul
sunt benefice și care nu schimba prioritățile î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 Fiecare membru al


prioritățile în Backlog-ul Product Owner-ului pot fi Echipei poate avea
Produsului preluate de Echipa de abilități pe o anumită
Dezvoltare, acesta nu specializare dar Echipa
Nu poate spune Echipei de poate dispărea din per ansamblu nu poate
Dezvoltare cum să își ducă componența Echipei să se comporte altfel
la îndeplinire sarcinile din decât ca un TOT
Sprint responsabil pentru
calitatea livrabilelor

Un alt factor important în reușita managementului proiectelor folosind Scrum este


înțelegerea modului corect de desfășurare a ședințelor, a rolului și a utilizării acelor întrebări

- 15-
cheie care definesc fiecare tip de ședință (tabelul nr. 2 – Cum să înțelegem corect ședințele
Scrum? prezintă un șablon de organizare):
Tabel nr. 2 Cum să înțelegem corect ședințele Scrum?
(sursa: prelucrare după Schwaber, K., Sutherland, J., The Scrum Guide, Scrum.org;
Schwaber, K., Agile Project Management with Scrum, Microsoft Press, Washington, 2004)

Ședința de Ședința Scrum Ședința de Ședința


Planificare a Zilnică Revizuire a Retrospectivă a
Sprint-ului Sprint-ului Sprint-ului
Rol Ședința de Ședința ScrumLa sfârșitul În urma Ședinței de
planificare este Zilnică are loc fiecărui Sprint are Revizuire a Sprint-
formată din două pentru a inspecta loc o Ședință de ului și înainte de
părți: în prima se munca realizată de Revizuire a următoare Ședință de
va decide ce va fi la ultima ședința, aSprint-ului unde Planificare, Echipa
efectuat în Sprint stabili și adapta din
pe baza a ceea ce Scrum susține
iar în a doua mers munca care s-a finalizat și a Retrospectiva Sprint-
Echipa identifică trebuie realizată
modificărilor ului cu scopul de a
modalitatea de până la următoarea efectuate în revizui procesul de
implementare a ședința. Backlog-ul dezvoltare în vederea
funcționalităților Produsului pe eficientizării acestuia
Ședințele Zilnice parcursul Sprint-
îmbunătățesc ului se stabilește Cu fiecare Ședință
comunicarea, planul pentru Retrospectivă,
elimină obstacolele următorul Sprint Echipa Scrum
care apar în găsește noi
dezvoltare, modalități de a
promovează luarea îmbunătăți calitatea
rapidă a deciziilor produsului și
și îmbunătățesc definiția ”Produs
nivelul Finalizat” se
cunoștințelor adaptează
despre proiect

Obiectiv Până la sfârșitul Obiectivul Până la sfârșitul Până la sfârșitul


ședinței Echipa de Ședințelor Scrum ședinței se va ședinței Echipa
Dezvoltare va fi zilnice este obține un Scrum va identifica
capabilă să explice creșterea Backlog-ul al măsuri de
Product Owner- probabilității de Produsului îmbunătățire a
ului și Scrum îndeplinire a revizuit care va proceselor, relațiilor,
Master-ul cum Obiectivului defini cel mai oamenilor și
intenționează să se Sprint-ului probabil itemii instrumentelor
autoorganizeze pentru următorul folosite, măsuri ce se
pentru a îndeplini Sprint vor implementa în
Scopul Sprint-ului Sprint-ul următor

Participanți Echipa Scrum Echipa Scrum Echipa Scrum + Echipa Scrum


Pot participa Participă doar acele stakeholderi-
consultanți ce pot persoane care persoane
oferi sfaturi transformă interesate de
tehnice sau elementele din proiect (acționari,
recomandări Backlog-ul clienți, etc.)
Produsului în
componente ale
- 16-
produsului software
final

Algoritm de Sprint = 1 lună Ședința =15 minute Sprint = 1 lună Sprint = 1 lună
calcul durată => Ședința = 8 ore la aceeași oră și în =>Ședința = 4 ore =>Ședința = 3 ore
ședință =>2 părți= 2*4 ore același loc pe
parcursul tuturor Sprint = 2 săpt. Sprint = 2 săpt.
Sprint = 2 săpt. Sprint-urilor =>Ședința = 2 ore =>Ședința = 1.5 ore
=> Ședința = 4 ore ... ...
=>2 părți= 2*2 ore
...
Întrebări cheie 1.Ce vom livra la 1.Ce s-a realizat de 1.Ce s-a făcut? 1.Ce a fost bine?
sfârșitul Sprint- la ultima întâlnire 2.Ce nu s-a făcut? 2.Ce am greșit?
ului? până acum? 3.Ce a mers bine? 3.Ce trebuie să
2.Cum vom reuși 2.Ce se va realiza 4. Ce probleme au încercăm în Sprint-ul
să realizăm până la următoarea fost și cum s-au următor?
obiectivul Sprint- ședință? rezolvat? 4.Ce nu mai are rost
uli? 3.Ce obstacole 5.Care sunt să facem?
sunt? următorii pași?
Mod de Prima parte: Scrum Master-ul se Product Owner-ul ScrumMaster-ul
desfășurare Product Owner-ul asigură că Echipa identifică ce a fost încurajează Echipa
prezintă susține ședința, se finalizat și ce nu. Scrum să își
elementele aplică regulile și Echipa discută revizuiască, în
prioritare din ședința durează 15 despre ce a mers cadrul procesului și
Backlog-ul minute, fiecare bine în timpul practicilor Scrum,
Produsului și membru vorbind pe Sprint-ului și ce procesul de
împreuna cu scurt probleme au dezvoltare, urmărind
Echipa va întâmpinat, să se obțină
identifica ce Pe parcursul precum și modul răspunsul la
funcționalități se Ședinței Zilnice cum au fost întrebările cheie
vor implementa fiecare membru al rezolvate.
În funcție de Echipei de Echipa apoi
funcționalitățile dezvoltare va demonstrează Pe baza analizei
alese de Echipă se răspunde la munca efectuată proceselor,
va stabili întrebările cheie și răspunde la oamenilor, relațiilor
Obiectivul Sprint- întrebări. și instrumentelor
ului Product Owner-ul folosite se identifică
discută apoi ce a mers bine și ce
A doua parte: despre Backlog-ul trebuie îmbunătățit și
Echipa stabilește Produsului dând o se creează un plan de
cum va transforma estimare privind implementare a
elementeledin finalizarea măsurilor de
Backlog-ul acestuia. îmbunătățire
produsului în Întregul grup identificate
software colaborează apoi
funcțional. în
Se începe prin privința lucrurilor
proiectarea discutate pentru a
muncii=>lista de vedea cum le pot
activități=>Sprint folosi in Sprint-
Backlog urile viitoare

Reușita implementării Scrum depinde și de înțelegerea modului de structurare a


elementelor din Backlog-ul Produsului pentru a putea fi gândite ca finalizabile în Sprint-uri.

- 17-
Elementele trebuie să fie bine înțelese și ușor de selectat în cadrul ședinței de planificare a
Sprint-ului.
Elementele din Backlog-ul Sprint-ului trebuie să fie descompuse în așa fel încât progresul
să fie ușor de înțeles în Ședința 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ă activitățile adiționale 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 activitățile care se dovedesc inutile.
Implementarea cu succes a Scrum-ului presupune ca membrii echipei să fie motivaţi şi să
posede abilităţile de a crea produsul fără a avea prea multă documentaţie şi prea multe informaţii
despre design. Atât echipa, cât şi organizaţia trebuie să înţeleagă şi să accepte cadrul de lucru.

2.3 Probleme și rezolvări


Ca în orice cadru de lucru și în Scrum pot apărea probleme sau neînțelegeri. Mai ales
pentru echipele care experimentează Scrum-ul și învață din experiențe 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 cerințelor.
Trebuie prevenite blocarea activităților și înlăturarea tendinței absolut firești de a lucra
astfel încât sarcina de lucru să acopere perioada programată În cazul în care echipa simte că a
promis mai mult decât poate livra, se întâlnește cu Product Owner-ul pentru a elimina sau reduce
din activitățile ce fac parte din Backlog-ul Produsului ce au fost selectate pentru Sprint. În cazul
în care echipa simte că are timp suplimentar la dispoziție, poate lucra cu Product Owner-ul
pentru a selecta activități suplimentare din Backlog-ul Produsului.
De obicei, numai 60-70% din Backlog-ul Sprintului va fi tratat în ședința de planificare a
Sprint-ului. Restul sunt detaliate ulterior sau sunt date estimări mari, ce vor fi segmentate pe
parcursul Sprint-ului.
Product Owner-ul este singurul care are autoritatea de a anula un Sprint, deși de multe ori
această decizie se ia sub influența Scrum Master-ului, Echipei de Dezvoltare sau a alor părți
interesate de proiect. Anularea unui Sprint poate fi necesară din mai multe motive: schimbare de
strategie a companiei, schimbare a tehnologiei, a circumstanțelor de utilizare a produsului; dar se
recomandă doar în cazuri excepționale pentru că se consumă inutil foarte multe resurse (trebuie

- 18-
evaluat cât s-a realizat până la anularea Sprint-ului, trebuie reestimați elementele nerealizate din
Backlog-ul Produsului, trebuie reorganizată echipa pentru a planifica un alt Sprint).
În unele organizații, mai multă muncă este adăugată la Backlog decât este finalizată.
Acest lucru poate duce la o tendință constantă sau crescătoare. Pentru a compensa, un nou prag
poate fi creat când se adaugă sau scade in muncă.
Se recomandă desenarea pe o pagină mare de hârtie afișată în zona de lucru a Echipei.
Echipele vor observa mai ușor o diagramă mare și vizibilă decat o diagrama dintr-un fișier Excel
sau din altă aplicație. Cerințele nefinalizate se acumulează într-o categorie din Backlog-ul de
produs numită “De finalizat” sau “De implementat”. Astfel, cand se acumulează multe cerințe,
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
implementării cadrului de lucru Scrum în Smart2Tech prin prezentarea comparativă a ce s-a
dorit, ce s-a obținut ș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 dezvoltării produselor software deficitar sunt premisele identificării
problemelor ce au determinat dorința de schimbare a modului de lucru. Plecând de la cerințele de
schimbare și de la scenariul parcurs pentru a folosi Scrum se constată că noul cadru de lucru își
dovedește eficiența, dar flexibilitatea nu trebuie dusă la extreme pentru că se transformă în haos
distructiv. Ultima parte a capitolului propune îmbunătățiri a modului de implementare, soluții
practice de urmat pentru ca probabilitatea succesului unui proiect să crească.

3.1 Premise, probleme și cerințe în managementul proiectelor Smart2Tech

Smart2Tech Development, companie înfiinţaţă în anul 2005 şi parte a grupului olandez


Smart2Pay asigură dezvoltarea produselor software, mentenanţa acestora şi suportul tehnic
necesar integrării clienţilor. Mai exact produsele software ale Smart2Tech Development sunt
cele două sisteme EuroPay şi GlobalPay, sisteme care asigură furnizarea de metode de plată
alternative comercianţilor online şi alte soluţii software necesare în procesul de administrare şi
transfer al banilor de la client, cel care plăteşte pentru un anumit produs-serviciu, la comerciantul
online, cel care vinde produsul-serviciu (grupul Smart2Pay este un intermediar în acest proces-
Payment Service Provider). Iniţial formată din 6 membri şi extinsă în anul 2012 la 11,
Smart2Tech are sediul în Iaşi şi se ocupă aşa cum induce şi numele de partea tehnologică a

- 19-
procesului de cumpărare online; Smart2Pay, companie aflată în acceaşi locaţie, la fel parte a
grupului olandez Smart2Pay, se ocupă de partea operațională și financiară a procesului.
Principalul avantaj16 al grupului olandez este că oferă servicii de plată locală
comercianţilor internaţionali, acoperind peste 70 de ţări din întreaga lume. Opţiunile de plată
alternative (alte categorii în afară de carduri) diferă în funcţie de specific: transfer bancar online,
transfer bancar regulat cu raportare în timpul zilei, plăţi ATM, plăţi î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 cumpărător şi implicit
la creşterea vânzărilor. Portofoliul de soluții de plată este prezentat în figura nr.3 de mai jos:

Figura nr. 3 Portofoliu soluții de plată


(sursa: document intern – prezentare Smart2Pay Corporate Presentation_2012_V14S)

Principalul produs software proiectat, creat şi întreţinut de Smart2Tech este EuroPay17


(arhitectura sistemului este prezentată în figura nr. 4), sistem ale cărui componente principale
sunt următoarele:
 Metodele de plată integrate, fiecare având specificul ei (număr/tip de parametri trimişi
pentru a iniţia o tranzacţie, număr de paşi până la realizarea plăţii, mod de a cere/primi
statusul pentru o tranzacţie 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
http://www.smart2pay.com/ro/acasa (accesat 26/01/2013)
17
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 aplicației): aplicaţie web unde comerciantul îşi poate configura contul
EuroPay, poate vizualiza, filtra şi exporta tranzacţiile realizate cu o anumită metodă.
Pentru că de multe ori comerciantul nu participă la elaborarea cerințelor (ulterior acesta
exprimându-și dorința de a personaliza câmpurile în funcție de necesități) Dashboard-ul
se caracterizează prin posibilitățile extinse de personalizare. Problemele ce apar atunci
când aplicația devine mult prea flexibilă sunt dificultatea mentenanței și nivelul complex
al operațiunilor de configurare;
 Aplicaţia de BackOffice cu diferite funcţionalităţi de gestionare conturi comercianți,
tranzacții și configurări metode;
 Servicii Windows: de monitorizare, de notificare a comercianţilor;
 Baza de Date caracterizată prin diversitatea tabelelor: fiecare metodă presupune existența
propriilor tabele (de exemplu XMethodPayments, XMethodConfiguration).

Figura nr. 4 Arhitectura Sistemului EuroPay


(sursa: document intern - prezentare Smart2Pay_Tehnical Overview)

- 21-
Integrarea comercianților cu acest sistem este caracterizată prin:
 Durata foarte mare a procesului: în funcţie de specificul afacerii comerciantului, între 1
săptămână -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
trimiși de către comerciant pentru a iniția tranzacția diferă foarte mult; statusurile
tranzacţiilor nu sunt unitare);
 Limitări de procesare a tranzacțiilor în acele monede acceptate de furnizorul metodei de
plată (de exemplu, dacă un comerciant vinde doar produse a căror preț este în moneda
euro și vrea își lărgească 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ă comercianţii de produse/servicii online au început să reducă
costurile iar provocările de mai sus au devenit pentru ei impedimente. Mai mult, comportamentul
clienţilor se schimbă odată cu extinderea metodelor alternative şi introducerea metodelor de plată
folosind dispozitivele mobile: îşi doresc ca plata să se realizeze cât mai rapid şi cu cât mai puţini
paşi dar cu un nivel mai ridicat al securităţii informaţiilor; îşi doresc să poate alege din cât mai
multe metode de plată locale fără a plăti comisoane substanţiale.
Toate aceste cerinţe 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ă,
facilitând astfel integrarea comerciantului să se realizeze în câteva zile – o săptâmână. GlobalPay
păstrează aceeaşi structură ca cea a EuroPay-ului cu precizările (arhitectura acestui sistem este
descrisă în figura nr.5 ):
 Interfaţa grafică ce foloseşte EuroPay-ul ca furnizor pentru metodele de plată; se creează
o interdependență între sisteme;
 Dashboard Comerciant: aplicaţie web unde comerciantul îşi poate configura contul
GlobalPay și își gestionează tranzacțiile;
 Aplicaţia de BackOffice cu diverse funcţionalităţi de gestionare conturi comercianți,
tranzacții și configurări furnizori de metode din sistemul EuroPay;
 Baza de date caracterizată prin optimizarea numărului de tabele.

18
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ă următoarele 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 vânzări sau clienți.
Exemple:
- Implementarea unei noi metode
- Adăugarea unei noi funcționalități la Dashboard Comerciant
 Proiecte interne care ar trebui să aducă un plus de valoare la nivel
operațional: acele proiecte solicitate de Suport Clienți, Operațional, Financiar.
Exemple:
- Implementarea unui sistem de Ticketing pentru Suport Clienți
- Implementarea unei funcționalități pentru căutarea tranzacțiilor după
anumite câmpuri în aplicația de BackOffice
 După mărimea 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-
- Adăugare funcționalități necesare în GlobalPay pentru a realiza
Refund Generic (returnarea banilor clienților prin aceeași metodă de
plată)
- Traducerea interfeței GlobalPay în cel puțin 15 limbi de circulație
internațională
 Proiecte mici cu durată de finalizare estimată între 1-4 săptămâni
Exemple:
- Implementarea unei noi metode în cazul în care funcționează
corespunzător la furnizor
- Adăugare funcționalitate de Bad Notified Transactions la aplicația de
BackOffice
 După scopul proiectelor:
 Proiecte strategice ce vizează pătrunderea pe o nouă piață, câștigarea unui
nou client etc.
Exemple:
- Lansare unui nou produs: GlobalPay
- Implementarea unui sistem antifraudă solicitat de client
 Proiecte de funcționalitate ce vizează dezvoltarea de noi funcționalități
aplicațiilor/metodelor curente
 Proiecte de mentenanță ce vizează actualizarea implementării metodelor
conform noilor versiuni ale manualelor de integrare primite de la furnizori
 Proiecte de optimizare: micșorarea numărului de accesări a bazei de date
pentru serviciile de notificare.
Așa cum se și anunța pe site-ul companiei Smart2Tech19 inițial managementul proiectelor
de mai sus se dorea a se realiza utlizând metodologia CMMI (Capability Maturity Model
Integration) ce își propunea să evalueze atât capacitățile sistemelor cât ș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
îmbunătăți 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 creșterea performanței
organizației și calitatea produselor software. Obiectivele metodologiei CMMI erau: creșterea
performanței și a eficienței managementului proiectelor, evitarea pierderii din vederea a
oportunităților, resurse umane mai bine pregătite, produse software calitative.

19
http://smart2tech.com/news.html (accesat 07/02/2013)
- 24-
Metodologia s-a aplicat doar pentru câteva proiecte dar fiind destul de laboriosă și echipa
neînțelegând practicile și obiectivele s-a renunțat la utilizarea ei. Așa că treptat în managementul
proiectelor Smart2Tech s-a renunțat la a se mai folosi metodologii și s-a ajuns doar la o sumă de
activități și practici (rolul managerului de proiect transformându-se în funcție de perioade și
activități) :
 Managerul de proiect planifica împreună cu directorul general și directorul pe vânzări
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 cerințele
(sursa acestor cerințe putea fi directorul general, directorul de vânzări, un posibil
comerciant ce dorește metoda). Utilizatorul final- cumpărătorul nu era inclus în faza de
analiză, necesitățile acestuia încercând să fie anticipate de către participanți
(ROL: ANALIST)
 Dacă o cerință nu era inclusă în documentul de specificații dezvoltatorul nu o
implementa; de aceea managerul trebuia să realizeze documentul cu atenție și cu eforturi
considerabile (ROL: MANAGER DE PRODUS)
 Managerul de proiect trebuia să asigure buna funcționare și actualizare a metodelor deja
integrate pe mediile de testare și de producție. În cazurile în care erau raportate probleme
pe mediul de producție, activitatea era întreruptă și se rezolva cu prioritate problema
(ROL: MANAGER DE PROIECT)
 Managerul de proiect trebuia să asigure buna funcționarea și actualizare a site-ul grupului
Smart2Pay (ROL: ADMINISTRATOR SITE)
 Managerul de proiect trebuia să asigure motivarea și perfecționarea continuă a echipei
(ROL: MANAGER DE PROIECT)
Neavând 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 cerințelor, sarcinilor, viitoarelor proiecte,
defectelor de implementare (termen utilizat bug), problemelor constate la furnizorii metodelor de
plată (s-a încercat implementare Microsoft Dot Project dar interfața mai puțin intuitivă și
introducerea cu dificultatea au făcut 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 dezvoltării sistemului.
Coordonarea proiectelor, rezolvarea problemelor, controlul și prioritizarea proiectelor se
făceua prin intermediul utilitarului de e-mail Outlook din pachetul Microsoft Office și a
documentelor Excel ce nu permiteau o colaborare în timp real, o transparența a informațiilo. Nu
- 25-
exista o baza de cunoștințe comună care să ajute echipa la rezolvarea problemelor în mod
eficient.
Legat de ciclul de viață al dezvoltării sistemului, modelul cascadă20 (figura nr. 6 descrie
acest model pentru ciclul de viață al dezvoltării unei noi metode de plată X) prezinta dezvoltarea
unui produs software ca o successiune de faze ce se înlănțuiau într-o derulare secvențială
(această secvențialitate de multe ori era teoretică, realitatea demostrând așa cum arată și figura
nr.6 că se înregistrau reveniri la etapele anterioare), de la analiza cerințelor și până la livrarea
produsului către client. Motivația alegerii studiului de caz pe implementarea unei metode de
plată în sistemul EuroPay plecă de la strategia dominantă a grupului Smart2Pay de a mări cât
mai mult portofoliul de plăți alternative prin implementarea a cât mai multor metode de plată.
Fiecare fază a modelului cascadă corespundea unei activități ș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 recunoșteau niște avantaje, cum ar fi: favorizeaza managementul proiectelor prin
planificarea resurselor umane pe etape, estimări de cost mai exacte, fazele fiind ordonate,
previzibile, se evidenția clar ariile de întindere a fiecărei etape sau componentă a ei și ducea la
un sistem bine documentat.

Figura nr. 6 Modelul cascadă al ciclului de viață al dezvoltării unei metode noi X
(sursa: prelucrare proprie)

20
Oprea, D., Meşniţă, G., Dumitriu, F., Analiza sistemelor informaţionale, Editura Univesităţii “Alexandru Ioan
Cuza”, Iaşi, 2012, p.33
- 26-
Din păcate, proba efectivă a bunei sau a proastei funcționări a produsului era realizată
numai în faza de integrare/lansare când era posibilă evaluarea concretă a programului (înaintea
acestei faze au fost produse numai documente). Mai mult deoarece modelul era secvențial,
reacția/revizia apăreau doar la tranziția între faze, multe probleme fiind identificate prea târziu.
Tabelul de mai jos surprinde problemele acestui model asociate fiecărei fazei, pe exemplul
dezvoltării 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 Completarea documentului
presupunea o muncă
cerințelor Functional Specifications”
laborioasă ce bloca începerea
dezvoltării metodei
Cerințele se descopereau pe
parcursul proiectului –
documentul nu putea cuprinde
de la început toate cerințele
După finalizarea proiectului în
momentul când se făceau
schimbări documentul nu se
mai actualiza – își pierdea
valoare
Proiectarea Document ”Method X După finalizarea proiectului în
Technical Specifications” momentul când se făceau
schimbări documentul nu se
mai actualiza – își pierde
valoare
Implementare Metodă X Tabele necesare metodei Pe tot parcursul implementării
Schemă XML a metodei metodei doar dezvoltatorul
Mecanism necesar efectuării știa ce a implementat
plății
Costuri considerabile (media
Servicii Windows de
notificare a statusului timpului de implementarea a
Dashboard Comerciant metodei era de cel puțin trei
Aplicație BackOffice pentru săptămâni)
configurare metodă
Lansare pe platforma de Metodă X integrată pe mediul De multe ori nu se aprecia
TEST de TESTARE corect impactul integrării și
care erau elementele ce
trebuiau compilate din nou
pentru că au fost afectate la
integrare
Testare metodă pe Test Case Metodă X Timpul necesar familiarizării
platformă TEST Metodă X testată tester-ului cu metoda X era
considerabil (media timpului
- 27-
necesar testării era de o
săptămână)
Problemele descoperite la
testare, în funcție de gravitatea
lor, au dus la reanalizarea
funcționalităților, uneori la
restructurarea metodei
Testarea de regresie Sistem de metode integrate Testarea de regresie era
Testat activitatea cea mai costisitoare
pentru firmă (pentru că pe
durata a 2-3 săptămâni testerii
erau pe deplin alocați)
Nu erau bine individualizate
zonele afectate prin integrarea
metodelor
Integrare Comerciant cu Primul pas al comerciantului Pe parcursul testării metodei de
către comerciant se descopereau
Metoda X în platforma de realizat pentru a putea oferi
noi cerințe/probleme și se reluau
TEST metoda etapele anterioare
Lansare metodă pe Metodă X integrată pe mediul Nu exista informații clare
platformă producție de PRODUCȚIE despre ce fișiere/proceduri au
fost integrate și ce zone au fost
afectate
Testare metodă pe Metodă X testată pe platforma De multe ori testarea metodei
nu se realiza corespunzător
platforma de producție de PRODUCȚIE
pentru că nu erau încă
disponibile date de
configurare (diverse cauze:
contractul comercial cu
furnizorul încă nu era gata,
furnizorul cerea a fi cel puțin
un comerciant integrat cu
metoda de plată pentru a da
date de configurare)

Testerii nu aveau access la


fișiere de logare de pe
platforma de producție –
problemele din log-uri uneori
treceau neobservate
Integrare Comerciant cu Metoda X putea fi oferită de Pe parcursul testării metodei de
către comerciant se descopereau
Metoda X către comerciant clienților săi,
noi cerințe/probleme și se reluau
mărindu-și astfel portofoliul etapele anterioare – costuri
de metode ridicate/proiectul nu putea fi
considerat finalizat
Utilizarea metodei în Dovada clară a succesului sau Uneori se descopereau
probleme mult prea târziu – se
- 28-
producție eșecului proiectului producea o mobilizare de forțe
pentru a rezolva problema cât
mai rapid – dar acest efort nu
Tranzacții pe producție
era benefic pentru planificarea
realizate folosind metoda activităților

Modelul cascadă se aplica la nivel de sistem; or, tocmai cum demonstrează tabelul de mai
sus întrucât EuroPay-ul este un sistem complex, cu un număr mare de aplicații ce interacționează
între ele, fazele modelului sunt greu de controlat. Utilizarea acestui model a dus la apariția mai
multor categorii de nemulțumiri: cele ale clienților, care doreau ca modelul să fie mai deschis la
schimbările ce pot interveni pe parcurs, cele ale directorului general și ale directorului de
vânzări nemulțumiți 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 cunoaștea metoda doar după ce era lansată pe mediul de test, ale
managerului de proiect ce descoperea uneori destul de târziu unele probleme sau deficiențe în
funcționalități.
Plecând de la problemele și nemultumirile descrise mai sus legate atât de ciclul de viață
al dezvoltării metodelor ce influența managementul proiectelor se dorea o schimbare care să
asigure:
 Un mod de lucru mai eficient bazat pe colaborare în timp real și urmărirea într-un mod
integrat a întregului ciclul de dezvoltare software, de la cerințele de dezvoltare la
asigurarea calității produsului și întreținerea acestuia;
 Transparență: tester-ul avea nevoie să primească informațiile depre proiect mai
devreme pentru ca familiarizarea cu metoda/produsul/funcționalitatea să nu dureze atât
de mult; proiectele Smart2Tech trebuiau să înceteze a mai fi o ”cutie neagră” unde doar
dezvoltatorul și liderul echipei tehnice știau până la lansarea pe platforma de TEST cum
va funcționa produsul software;
 Adaptare: riscul ca manual de integrare primit de la furnizor să nu fie clar sau metoda să
nu funcționeze corespunzător 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
puțin o jumătate de zi pentru a stabili la ce va lucra dezvoltatorul în continuare, neavând
o listă clară a proiectelor; pentru că efortul realizării documentelor și efectuarea analizei
proiectelor presupunea de multe ori termene de câteva zile, cerințele urgente din partea
partenerilor nu se puteau realiza prioritar;
 Scăderea costurilor (efortul de implementare/testare, durata de implementare/testare) și
a timpului de reacție la cerințe: fiind perioadă de criză și concurența din ce în ce mai
- 29-
acerbă, principalul avantaj al companiei mici Smart2Tech, flexibilitatea își pierdea din
valoare nefiind corelată cu scăderea timpului de implementare a cerințelor clienților;
 Anticiparea Riscurilor: nu poți 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/funcționalității
trebuia evaluat mai devreme pentru a se identifica eventualele probleme.
Cu atât mai mult era nevoie de o schimbare cu cât o evaluare a proiectelor arăta că chiar
dacă timpul și efortul necesar dezvoltării au fost considerabile, 70% dintre proiecte nu sunt
finalizate din diverse cauze: s-au schimbat între timp preferințele/cerințele comercianților, după
utilizare s-au descoperit și alte cerințe care așteaptă să fie dezvoltate, furnizorul între timp a
schimbat manualul de integrare.

3.2 Scrum în Smart2Tech Development


Cerințele fiind de adaptare continuă la cerințe, scăderea timpului de reacție, metodologia
de management al proiectelor cea mai potrivit a fost Agile, modul de lucru ales fiind Scrum.
Trecerea la Scrum s-a făcut urmând următorii pași:
1. Organizarea modului de lucru
Așa cum se preciza și în capitolul anterior o mare problemă în modul de lucru ce
influența implicit și managementul proiectelor era lipsa unui instrument software și/sau
platforme colaborative care să asigure centralizarea cerințelor, sarcinilor, viitoarelor proiecte,
defectelor de implementare, problemelor constate la metodelor de plată curente și care se datorau
schimbărilor neanunțate realizate de furnizorii metodelor.
Existența 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, încercând o grupare a proiectelor: fiecare metodă
devenea o arie de lucru (Bank Transfer, Pagosonline, QIWI, iDEAL etc), Dashboard, Aplicație
BackOffice, Monitorizare și Raportare. Următorul 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 numește ”Work Items”21(voi folosi în lucrare termenii în engleză pentru
a ilustra cât mai concludent modul de lucru):
 Bug – defect raportat de: testeri, comerciant, furnizor, departamentul operațional,
departamentul de suport clienți;
 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 definește acei pași care se folosesc în mai multe planuri de testare (de
exemplu, dacă fiecare plan de testare presupune autentificarea în aplicație, se pot crea
acești pași 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 următoarele precizări: tipul de utilizator, scopul
cerinței, motivul cerinței ș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 instalării și specificul proiectelor Smart2Tech
(majoritatea proiectelor sunt de dimensiuni mici, poate chiar foarte mici, între 3 zile – 2
săptămâni) au făcut 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 făcut dificilă aderarea echipei la acest mod de lucru.
Pentru a facilita introducerea și urmărirea cât mai interactivă a elementelor de lucru
prezentate mai sus s-a recomandat instalarea și folosirea unei aplicații realizate de cei de la
Telerik: TFS Work Item Manager iar pentru pentru urmărirea evoluției proiectelor se recomandă
Telerik TFS Project Dashboard.
Astfel, modul de lucru haotic bazat pe poșta electronică Outlook și pe documente Word și
Excel s-a transformat într-unul organizat, figura nr.7 ilustrând această organizare:

21
http://192.168.2.3/sites/S2TCollection/ (accesat 09/02/2013)
22
http://msdn.microsoft.com/en-us/library/dd728086%28v=vs.100%29.aspx (accesat 09/02/2013)
23
http://msdn.microsoft.com/library/vstudio/ff731587.aspx (09/02/2013)
- 31-
Directorul general Manager Dezvoltator Tester
Comunică noile Introduce cerințele Își introduce Își introduce
cerințe și le ca User Story-uri sarcinile de lucru sarcinile de lucru
prioretizează în TFS Work Item legate de User legate de User
împreună cu Manager Story-urile pe Story-urile pe
managerul folosind care trebuie să le care trebuie să le
TFS Work Item Discută cu echipa implementeze, le testeze, le trece în
Manager pe baza acestora și trece în statusul statusul ”Closed”
obținerea estimări ”Closed” la la finalizare și
Cere rapoarte ale privind finalizarea finalizare și completează
bug-urilor, task- acestora completează numărul de ore
urilor sau ale numărul de ore lucrate
evoluției Rezolvă lucrate
proiectelor care impedimentele Verifică bug-urile
acum se exportă raportate ca Issues Verifică bug-urile rezolvate și le
din TFS Work Item asociate lui, le trece în statusul
Manager Trece User Story- rezolvă și le pună ”Closed” dacă
urile în statusul în statusul problema a fost
”Resolved” la ”Resolved” pentru rezolvată
finalizarea lor ca tester-ul sa
primească e-mail Raportează Issue-
După lansare trece și să îl verifice urile, descoperite
US-urile și bug- la testare
urile în statusul
”Delivered”

Figura nr. 7 Organizarea modului de lucru în Smart2Tech

(sursa: prelucrare proprie)


Principalele obiective ale acestei organizări erau de a creea transparență, de a reuși o
prioritizare corectă a proiectelor și a sarcinilor de lucru, de a permite o mai bună colaborare între
membrii echipei și de a facilita urmărirea elementelor de lucru și a efortului depus pentru a
rezolva în timp util problemele ce apar de-a lungul proiectelor.
2. Mișcarea de gherilă: realizarea managementului proiectelor folosind Scrum
Așa cum am ilustrat și în partea teoretică a lucrării 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 având în vedere schimbarea de mentalitate organizațională ce trebuia
realizată. S-a început mai mult ca un experiment, adaptat la cerințele prezentate anterior și la
specificul proiectelor, fără a se oferi prea multe detalii, doar conceptele de bază fiind explicate.
Această ”mișcare de gherilă” (așa cum o numesc eu preluând un termen din marketing) viza ca
echipa să descopere beneficiile Scrum-ului și să îl îmbunătățească în mod continuu, detalierea
conceptelor Scrum urmând a se realiza după câteva proiecte realizate în acest mod.
Primul pas a fost formarea echipei Scrum, sau mai bine zis, rolurile s-au asignat din
inerție (dimensiunea echipei Scrum nu este cea optimă – de regulă echipa având 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 numărul 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 întârzieri în desfășurarea proiectului, neștiind
cine specifică cerințele, 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/cerințelor ca User Story-uri în aplicația 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ă luând în considerare valoarea pe care o aduc,
valoare exprimată de cele mai multe ori în număr de tranzacții așteptate a fi procesate și/sau cât
de gravă este problema pe care implementarea User Story-ul o rezolvă. Plecând de la aceste
considerente prioretizarea User Story-urilor și Task-urilor se face în cadrul firmei Smart2Tech
răspunzând la trei întrebări:
 A apărut o problema la o metodă utilizată în mediul de producție? Dacă da, rezolvarea
acestei probleme este urgentă și are prioritate maximă;
 O nouă metodă de plată/funcționalitate a unei metode deja existente este cerută de un
potențial client și semnarea contractului este condițonată de această dezvoltare?
 O nouă metodă de plată ar asigura extinderea pe o noua piață financiară sau pătrunderea într-
o nouă țară?

- 33-
Figura nr. 8 Captură de ecran Backlog-ul EuroPay-ului
(sursa: aplicație TFS Work Item Manager- raport Product Backlog)
Din Backlog-ul Produsului se aleg câteva User Story-uri în funcție de numărul de
dezvoltatori liberi din cei patru disponibili și următoarea etapă este cea de estimare. De exemplu
pentru integrarea unei noi metode, dezvoltatorul analizează manual de implementare primit de la
furnizor, realizează anumite teste premergătoare implementării pentru a înțelege 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.
Ședințele de planificare a Sprint-urilor nu s-au realizat din trei motive:
 nu s-a înțeles corect care este importanța acestora, fiind asociate cu ședințele de analiza a
User Story-ului;
 se continua să se gândească în termeni de care sunt rezultate implementării (de exemplu
pentru o nouă metodă de plată: Flow, Dashboard Comerciant, Aplicație BackOffice) în loc de
gândire în termen de funcționalități oferite comerciantului (funcționalitate ce asigură inițierea
tranzacției, redirectare client la pagina metodei de plată, redirectare client la pagina de
Succes/Eșec/Anulare a comerciantului, notificare comerciant privind statusul tranzacției,
funcționalitate Dashboard comerciant de export tranzacții, configurare detalii metodă de plată
în aplicație BackOffice);
 Sprint-ul este componenta Scrum-ului cel mai greu de definit în Smart2Tech.
Incertitudinea a devenit o definiție a modului de lucru Smart2Tech. Din păcate nu poți
planifica livrarea funcționalităților de procesare a unei metode într-o săptămână dacă în timpul
dezvoltării se întâmplă ceva pe producție cu o altă metodă a dezvoltatorului și acesta nu mai este
alocat proiectului de implementare metoda X. Prioritate au rezolvarea problemelor din producție
și din păcate Scrum-ul nu a adus o rezolvare la discontinuitate proiectului datorată partajării
membrilor echipei pe metodele dezvoltate de către aceștia.
- 34-
Mai mult definiția teoretică a Sprint-ului, acel interval de timp în care o parte
”finalizată”, utilizabilă și potențial livrată a produsului este creată, provoacă numeroase discuții
în Smart2Tech pentru că finalitatea și utilizarea cu succes sau nu se vede în producție. Întrebări
gen ”Când putem considera integrarea unei metode de plată ca fiind finalizată având în vederea
că și furnizorul metodei influențează schimbările?”, ”Cum putem măsura calitatea integrării
metodei de plată dacă de prea puține ori avem o reacție a unui client ce folosește această
metodă?” încă își caută răspuns.
Tot din aceste motive folosirea diagramei Burndown nu prezenta decât o imagine
dezolantă a proiectelor (într-un singur proiect din cele șapte al căror managementul proiectelor s-
a realizat folosind Scrum s-a respectat termenul limită a Sprint-urilor) și în consecință s-a decis
renunțarea la această diagramă.
Astfel, Scrum-ul în Smart2Tech pare a începe mai degrabă de la ședințele Scrum zilnice.
Contestate la început, fiind considerate pierdere de vreme, ele și-au dovedit eficiența în
momentul în care s-au înțeles mai bine cerințele, impedimentele au fost mult mai ușor de
comunicat, adaptarea la schimbarea cerințelor s-a făcut treptat, iar probleme s-au identificat mult
mai repede. Mai mult participarea testerului de la primele ședințe Scrum zilnice, chiar dacă încă
nu avea ce să testeze, îl ajuta să înțeleagă mai repede cerințele, își putea creea Test Case-ul
înainte de finalizarea livrabilului, observațiile lui constatau mai rapid devierile sau
impedimentele proiectului.
Legat de aceste beneficii ale Scrum-ului, una din provocările de a transforma echipa
dintr-una tradițională într-una Agile a fost schimbarea principiului ”se testează la sfârșitul
implementării”. Etapa de testare trebuia să înceapă mult mai devreme, testându-se pe părți
componente. În acest mod dacă ceva nu merge bine sau nu este conform cerințelor se poate
descoperi mult mai rapid iar costul dezvoltării proiectului era mult mai mic (s-a reușit o scădere
a perioadei de integrare a unei metode noi de la 15 zile la 10 zile).
Mai mult decât atât echipa nu știa cum să se auto-organizeze și nici nu accepta auto-
organizarea: la ședințele zilnice Scrum Master-ul trebuia să întrebe echipa cum au progresat față
de ședința trecută, ce vor face până la ședința 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 înșiși să își organizeze activitățile. O altă problemă era
nerespectatea regulilor ședințelor Scrum zilnice: uneori dura mai mult de 15 minute, se discutau
probleme de analiză (detaliile ar fi trebuit discutate în ședințe separate) sau discuția devenea mai
mult o suită de plângeri. Dar treptat înțelegând scopul Scrum-ului, având o imagine mai clară
asupra activităților și a beneficiilor ședințelor Scrum, înclinația echipei spre auto-organizare
apare.

- 35-
Ședința de Revizuire a Sprint-ului devenită în Smart2Tech Ședință de Revizuire a
Proiectului presupunea ca Scrum Master-ul (deși 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ă răspundă la întrebări) să realizeze un demo pentru a prezenta la ce s-a
lucrat, care au fost problemele pe parcursul proiectului și cum s-au rezolvat. Participanții la
această ședință erau toți membrii companiei Smart2Tech, directorul general, directorul pe
vânzări, membri ai departamentului de integrare comercianți. Chiar dacă această ședință nici în
prezent nu se face la sfârșitul fiecărei 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 producție, sau noile oportunități (de exemplu,
în momentul prezentării metodei de plată X s-a identificat posibilitatea creșterii veniturilor prin
introducerea unei pagini care să realizeze conversia într-o altă monedă).
Din păcate Ședința Retrospectivă a Sprint-ului a devenit și ea Ședința Retrospectivă
a Proiectului și chiar dacă s-a discutat ce a fost bine și ce trebuie îmbunătățit de prea puține ori
s-au luat măsuri de îmbunătățire.
Chiar dacă ședințele nu s-au putut respecta, chiar dacă multe din recomandările teoretice
nu s-au putut aplica în contextul Smart2Tech, cea mai mare ”greșeală” comisă în procesul de
transformare de la tradițional la Agile/Scrum a companiei a fost exagerarea flexibilității. Este
bine că s-a creat mai multă dinamică, cerințele pot fi acoperite cu costuri mai mici dar la
întrebarea: ”până unde poți lăsa comerciantul să îți schimbe produsul?” de multe ori s-a răspuns
”până la instaurarea haosului distructiv, când nu mai știm dacă schimbările ad-hoc au afectat mai
mult sau mai puțin sistemul”.

3. Transformarea ciclului de viață al dezvoltării sistemelor din Modelul Cascadă în


Modelul Incremental
Odată cu toate schimbările 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 cărui scop final era livrarea produsului treptat pe
componente distincte pentru a se putea descoperi cât 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 cerințelor, cât și analiza se efectuează la nivelul
întregului sistem. După ce se parcurg aceste faze, se efectuează descompunerea proiectului în
subproiecte, ele fiind urmărite pe activități care vor concura la obținerea componenetelor

- 36-
necesare sistemului final24. Figura nr. 9 descrie acest model pentru ciclul de viață al dezvoltării
unei noi metode de plată X:

Figura nr. 9 Modelul incremental al ciclului de viață al dezvoltării unei metode noi X
(sursa: prelucrare proprie)

Comparativ cu modelul cascadă rezultatele fazelor modelului incremental erau


aproximativ aceleași (folosind Scrum s-a renunțat la documentul de specificații ș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 cerințelor dar problema se putea rezolva mult mai rapid, cu afectarea unei
componente a metodei și nu a întregii metode;
 Testând metoda pe componente îi era mult mai ușor tester-ului să se familiarizeze cu
noua metodă de plată și să descopere cât mai multe probleme;
 Lansarea/Testare/Integrarea Comerciantului pe producție 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 răspunderea
de a nu realiza Testarea de regresie, bineînțeles cu riscul de a scăpa de sub control celelalte
metode de plată din sistem, această testare realizându-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ă tranzacția este în baza de date, dacă redirectarea
clientului se face corect;
La testarea metodei pe componente, de multe ori nu se apreciază impactul integrării și
care sunt elementele ce trebuie executate din nou, problemele fiind detectate în mediul de
producție. Această problemă este mai mult una de comunicare și soluția a fost crearea unui

24
Oprea, D., Meşniţă, G., Dumitriu, F., Analiza sistemelor informaţionale, Editura Univesităţii “Alexandru Ioan
Cuza”, Iaşi, 2012, p.35
- 37-
document colaborativ care centralizează ce s-a lansat pe mediul de test și pe mediul de producție
și precizează ce zone/fișiere au fost afectate/executate la integrare.
Pentru a realiza o testare eficientă a metodei pe producție, testerilor li s-a dat access la
fișierele de logare dar din păcate problema configurărilor de metodă care de multe ori nu sunt
disponibile la lansarea metodei pe producție nu a putut fi rezolvată, cauzele fiind externe:
contractul cu furnizorul încă nu este gata, furnizorul cere a fi cel puțin un comerciant integrat cu
metoda de plată pentru a da datele de configurări.
Pentru că există o dependență foarte mare de sistemul furnizorului, riscul descoperirii
unor probleme pe mediul de producție datorate unor schimbări realizate de furnizor nu poate fi
eliminat; acceași regula a testului de perfomanță a metodei rămâne și în cazul modelului
incremental: dovada clară a bunei funcționări există doar la primele tranzacții plătite cu succes.
Modelul incremental nu se poate aplica în toate proiectele Smart2Tech, uneori lipsind
elementele necesare descompunerii întregului: de exemplu în cazul adăugării unei funcționalități
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 soluții practice se pot îmbunăți (figura
nr. 10 de mai jos fiind o sinteză a realizărilor, lipsurilor și soluțiilor propuse):

Ce s-a dorit? Ce s-a obținut? Soluții

Ședințele Zilnice Scrum Seminar de învățare și


permit colaborarea în perfecționare Scrum cu
timp util, identificarea explicare obiectivelor
mai rapidă a acestor ședințe
problemelor
Realizarea unui proiect
Un mod de Ședințele de model
Planificare, Revizuire și
lucru mai eficient Retrospectivă a Sprint- Schimbarea mentalității
ului nu se respectă organizaționale

Ședințele zilnice Realizarea ședințelor


ajungeau să depășească zilnice în picioare
15 minute, fiind mai
mult ședințe de discuții

- 38-
Ce s-a dorit? Ce s-a obținut? Soluții

Tester-ul primea Ședințele de


informațiile necesare Planificare, Revizuire și
testării mult mai Retrospectivă trebuie
devreme să se realizeze pe
fiecare Sprint, nu pe
La sfârșitul proiectului întregul proiect
directorul general și
toate persoanele
Transparență interesate participă la Ședințele Scrum zilnice
prezentarea produsului divizate pe proiecte se
și oferă feedback transformă în ședință
organizațională; în care
Prin segmentarea pentru fiecare proiect
angajaților Smart2Tech persoanele implicate
în mai multe echipe spun ce au făcut și ce
Scrum anumite urmează să facă.
informații Reguli: ședința se
organizaționale nu desfășoară în picioare,
ajung la toți membrii fiecare proiect are 2
companiei minute, problemele se
detaliază ulterior

Schimbarea cerințelor Seminar de învățare și


nu mai presupune perfecționare Scrum cu
efortul chinuitor al explicare obiectivelor și
actualizării a regulilor recomandate
documentației, ci de desfășurare
explicarea acestora în
Adaptare cadrul ședințelor zilnice Realizarea unui proiect
model
În caz că un User Story
este blocat se trece la
următorul

Echipa nu se
autoorganizează

Implementarea unei A fi Agile nu înseamnă


noi metode de plată a dispariția documentelor
Scăderea scăzut de la 15 zile la Un document bine
10 zile structurat, pus pe
costurilor și a portalul SharePoint TFS
Cu anumite riscuri este necesar pentru a
timpului de asumate testarea de ști: ce s-a lansat pe
regresie se realizează mediul de test/producție
reacție la cerințe din patru în patru luni și când, care este
statusul testării pe
Flexibilitatea presupune mediul de test/producție
probleme: nu se știe ce
- 39-
s-a lansat în producție
Ce s-a dorit? Ce s-a obținut? Soluții

Ședințele Scrum zilnice Ședințele de


facilitează comunicarea Planificare, Revizuire și
impedimentelor Retrospectivă trebuie
să se realizeze pe
Ședințele de revizuire a fiecare Sprint, nu pe
proiectului se fac când întregul proiect
Anticiparea programul este mai
liber și nu la sfârșitul Crearea unei echipe de
Riscurilor proiectului, anumite suport tehnic pentru ca
probleme fiind dezvoltatorii să se poată
descoperite prea târziu concentra pe
implementarea User
Nefolosirea Story-urilor
diagramelor Borndown
nu permite anticiparea
corectă a riscurilor
proiectului

50% dintre Ședințele de


impedimente au fost Planificare, Revizuire și
rezolvate mult mai ușor, Retrospectivă trebuie
ședințele Scrum zilnice să se realizeze pe
facilitând comunicarea fiecare Sprint, nu pe
întregul proiect
Rezolvare Testerii comunicând
Ședințele Scrum zilnice
bug-urile identificate la
defectelor și ședințele zilnice a fost
divizate pe proiecte se
transformă în ședință
mult mai ușoară
problemelor în organizațională; în care
identificarea cauzelor
pentru fiecare proiect
timp util persoanele implicate
Ședințele de revizuire a
spun ce au făcut și ce
proiectului se făceau
urmează să facă.
când programul era mai
Reguli: ședința se
liber și nu la sfârșitul
desfășoară în picioare,
proiectului, anumite
fiecare proiect are 2
probleme fiind
minute, problemele se
descoperite prea târziu
detaliază ulterior

Figura nr. 10 Cerințe, realizări și soluții de îmbunătățire

(sursa: prelucrare proprie)

- 40-
Pentru că în Scrum, poate mai mult decât în celelalte metode de lucru Agile, Echipa de
dezvoltare trebuie să se autoorganizeze, trebuie luate măsuri de îmbunătățire prin:
 Înțelegerea scopului autoorganizării;
 Organizarea pe o tablă cu foițe grupate în: Ce se dorește a fi gata până 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 producție?(organizare ce se
construiește pe fiecare Sprint în parte până la sfârșitul 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 înțeles modul de desfășurare corect al ședințelor;
 În cadrul unor ședințe tehnice săptămânale fiecare dezvoltator prezintă ce a lucrat,
răspunzând la întrebări; se propun mai multe soluții tehnice.
Când o companie se pregătește să adopte cadrul de lucru Scrum principalul risc ar fi acela
de a face totul ”scrum”, cum de multe ori s-a întâmplat și cu proiectele Smart2Tech, multe dintre
ele fiind realizate fără prea multe ședințe sau fără specificații clare dar ”plasa de siguranță” în
foarte multe dintre cazuri a fost testarea automată. Evaluarea zilnică atât pe mediul de test, cât și
pe producție a metodelor de plată a permis identificarea problemelor fără a mai crea un efort în
plus pentru testare.
Soluțiile și practicile de îmbunătățire a Scrum-ului trebuie să fie cât mai clare, ușor de
realizat în practică pentru a deveni un mod de lucru adaptabil și raportat la specificul proiectelor
companiei. Schimbarea modului tradițional de gândire este o cerință promulgată de foarte mulți
teoreticieni, dar în practică nu poți cere schimbare fără un mod organizat de lucru, fără
optimizarea proceselor de lucru.

- 41-
Concluzii

Având î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
implicaţii are la nivelul managementului proiectelor şi organizaţional, care este legătura dintre
cadrul de lucru și metodologia Agile. Care sunt regulile cadrului de lucru și particularitățile
raportate la alte metode de lucru din metodologia Agile sunt doar câteva din aspectele supuse
cercetării în acest capitol.
Al doilea capitol este dedicat explicării modului de implementare corectă a Scrum-ului.
Cu titlul Scrum - management al proiectelor mai eficient? această parte a lucrării se axează, de
asemenea și pe oferirea de soluții la problemele ce pot să apară pe parcursul implementării.
Conform cercetării patru factori influențează preponderent reușita managementului unui proiect
folosind Scrum: înțelegerea rolurilor pe care le au membrii Echipei Scrum, înțelegerea
particularităților și a modului de desfășurare a ședințelor Scrum, înțelegerea 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 cărora se realizează studiul de caz. Analiza are în vedere identificarea premiselor,
problemelor și cerințele de schimbare a modului de lucru: de la cel tradițional 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 obținut permite identificarea unor soluții practice,
ușor de utilizat pentru îmbunătățirea 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, scăderea costurilor și a timpului de reacție la schimbările de cerințe,
anticiparea riscurilor, rezolvarea problemelor în timp util şi în primul rând schimbare.

- 42-
Bibliografie
„Mă tem de omul unei singure cărţi.” (Thomas D’Aquino)
Aşa că am decis să cercetez mai multe.

Cărţi:

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., Meşniţă, G., Dumitriu, F., Analiza sistemelor informaţionale, Editura
Univesităţii “Alexandru Ioan Cuza”, Iaşi, 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-