SCRUM in managementul proiectelor software
description
Transcript of SCRUM in managementul proiectelor software
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
- 1-
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
- 2-
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
- 3-
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."
- 4-
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)
- 5-
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
- 6-
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 framework6 –
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)
- 7-
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
- 8-
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.
- 9-
- Este responsabil de aderarea
Echipei și a organizației la
valorile, practicile și regulile
Scrum
- Ajută Echipa să înțeleagă
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
- Prioritizează Backlog-ul
Produsului
- Verifică dacă efortul depus de
Echipa de Dezvoltare este
calitativ
- Se asigură că cerințele sunt
clare, vizibile oricui din echipă
- Specifică Echipei Scrum la ce
se va lucra în continuare
- Verifică dacă echipa de
dezvoltare a înțeles Backlog-ul
Produsului la un nivel care să
asigure livrarea produsului
conform așteptărilor clientului
SCRUM MASTER PROCES SCRUM
PRODUCT OWNER BACKLOG PRODUS
DEVELOPMENT TEAM PRODUS
E
C
H
I
P
A
S
C
R
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
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
- 10-
(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:
Figura nr. 1 Componența Echipei Scrum. Roluri și Caracteristici
- 11-
Figura nr. 2 Reprezentare mod de lucru Scrum
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
( sursa: http://www.altexsoft.com/how-we-work/agile-approach/)
- 12-
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
- 13-
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)
- 14-
Î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
membru al Echipei dar
acest lucru duce adesea la
conflicte în momentul când
va trebui să aleagă între a
rezolva problemele ca
Scrum Master și a îndeplini
sarcinile din Sprint
Dacă proiectele sunt
pentru clienți
poate fi chiar managerul
de produs
Dacă proiectele vor fi
folosite intern, Product
Owner poate fi managerul
departamentului
care va folosi acel produs
Product Owner poate fi
chiar un membru al
Echipei care face și
muncă de implementare,
însă această
responsabilitate îl poate
împiedica să lucreze
corespunzător cu toți cei
implicați)
Membru al echipei
devine cel care are
abilitățile necesare de a
transformă o sarcină
într-un livrabil al
produsului
Membri Echipei sunt cei
ce au deschiderea de a
prelua sarcini, chiar
dacă acest lucru
înseamnă să învețe noi
lucruri
15
http://www.ibmsystemsmag.com/power/Systems-Management/Workload
Management/project_pitfalls/project_success_or_failure/ (accesat 26/01/2013)
- 15-
Cine nu poate fi? Scrum Master-ul nu poate fi
Product Owner
Product Owner-ul nu
poate fi Scrum Master
Scrum Master-ul și
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ă
organizația și Echipa Scrum
la practicile, valorile li
regulile Scrum
Este mentor pentru Product
Owner privind modul de a
prezenta, creea și coordona
Backlog-ul Produsului
Este cel care înțelege și
explică modul de lucru
Agile în organizație
Este o singură persoana
responsabilă cu Backog-ul
produsului
O echipă cu un număr
de membri suficient
pentru a fi agili și pentru
a finaliza munca
O echipă care are
capacitatea de a
transforma cerințele
prezentate în Backlog-ul
Produsului în Produsul
Final
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
exteriorul Echipei Scrum să
înțeleagă procesul și să
descopere care dintre
interacțiunile cu Echipa
sunt benefice și care nu
Poate reprezenta cerințele
unui comitet în Backlog-
ul Produsului;
Este singurul care poate
schimba prioritățile în
Backlog-ul Produsului
Sunt singurii care pot
livra la sfârșitul fiecărui
Sprint câte o
componentă a ceea ce se
va numi la sfârșitul
proiectului ”Produsul
Finalizat” (componentă
pe care autorii Ken
Schwaber și Jeff
Sutherland o numesc
Increment)
Ce nu poate face? Nu poate schimba
prioritățile în Backlog-ul
Produsului
Nu poate spune Echipei de
Dezvoltare cum să își ducă
la îndeplinire sarcinile din
Sprint
Chiar dacă rolurile
Product Owner-ului pot fi
preluate de Echipa de
Dezvoltare, acesta nu
poate dispărea din
componența Echipei
Fiecare membru al
Echipei poate avea
abilități pe o anumită
specializare dar Echipa
per ansamblu nu poate
să se comporte altfel
decât ca un TOT
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
- 16-
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
Planificare a
Sprint-ului
Ședința Scrum
Zilnică
Ședința de
Revizuire a
Sprint-ului
Ședința
Retrospectivă a
Sprint-ului
Rol Ședința de
planificare este
formată din două
părți: în prima se
va decide ce va fi
efectuat în Sprint
iar în a doua
Echipa identifică
modalitatea de
implementare a
funcționalităților
Ședința Scrum
Zilnică are loc
pentru a inspecta
munca realizată de
la ultima ședința, a
stabili și adapta din
mers munca care
trebuie realizată
până la următoarea
ședința.
Ședințele Zilnice
îmbunătățesc
comunicarea,
elimină obstacolele
care apar în
dezvoltare,
promovează luarea
rapidă a deciziilor
și îmbunătățesc
nivelul
cunoștințelor
despre proiect
La sfârșitul
fiecărui Sprint are
loc o Ședință de
Revizuire a
Sprint-ului unde
pe baza a ceea ce
s-a finalizat și a
modificărilor
efectuate în
Backlog-ul
Produsului pe
parcursul Sprint-
ului se stabilește
planul pentru
următorul Sprint
În urma Ședinței de
Revizuire a Sprint-
ului și înainte de
următoare Ședință de
Planificare, Echipa
Scrum susține
Retrospectiva Sprint-
ului cu scopul de a
revizui procesul de
dezvoltare în vederea
eficientizării acestuia
Cu fiecare Ședință
Retrospectivă,
Echipa Scrum
găsește noi
modalități de a
îmbunătăți calitatea
produsului și
definiția ”Produs
Finalizat” se
adaptează
Obiectiv Până la sfârșitul
ședinței Echipa de
Dezvoltare va fi
capabilă să explice
Product Owner-
ului și Scrum
Master-ul cum
intenționează să se
autoorganizeze
pentru a îndeplini
Scopul Sprint-ului
Obiectivul
Ședințelor Scrum
zilnice este
creșterea
probabilității de
îndeplinire a
Obiectivului
Sprint-ului
Până la sfârșitul
ședinței se va
obține un
Backlog-ul al
Produsului
revizuit care va
defini cel mai
probabil itemii
pentru următorul
Sprint
Până la sfârșitul
ședinței Echipa
Scrum va identifica
măsuri de
îmbunătățire a
proceselor, relațiilor,
oamenilor și
instrumentelor
folosite, măsuri ce se
vor implementa în
Sprint-ul următor
Participanți Echipa Scrum
Pot participa
consultanți ce pot
oferi sfaturi
tehnice sau
recomandări
Echipa Scrum
Participă doar acele
persoane care
transformă
elementele din
Backlog-ul
Produsului în
componente ale
Echipa Scrum +
stakeholderi-
persoane
interesate de
proiect (acționari,
clienți, etc.)
Echipa Scrum
- 17-
produsului software
final
Algoritm de
calcul durată
ședință
Sprint = 1 lună
=> Ședința = 8 ore
=>2 părți= 2*4 ore
Sprint = 2 săpt.
=> Ședința = 4 ore
=>2 părți= 2*2 ore
...
Ședința =15 minute
la aceeași oră și în
același loc pe
parcursul tuturor
Sprint-urilor
Sprint = 1 lună
=>Ședința = 4 ore
Sprint = 2 săpt.
=>Ședința = 2 ore
...
Sprint = 1 lună
=>Ședința = 3 ore
Sprint = 2 săpt.
=>Ședința = 1.5 ore
...
Întrebări cheie 1.Ce vom livra la
sfârșitul Sprint-
ului?
2.Cum vom reuși
să realizăm
obiectivul Sprint-
uli?
1.Ce s-a realizat de
la ultima întâlnire
până acum?
2.Ce se va realiza
până la următoarea
ședință?
3.Ce obstacole
sunt?
1.Ce s-a făcut?
2.Ce nu s-a făcut?
3.Ce a mers bine?
4. Ce probleme au
fost și cum s-au
rezolvat?
5.Care sunt
următorii pași?
1.Ce a fost bine?
2.Ce am greșit?
3.Ce trebuie să
încercăm în Sprint-ul
următor?
4.Ce nu mai are rost
să facem?
Mod de
desfășurare
Prima parte:
Product Owner-ul
prezintă
elementele
prioritare din
Backlog-ul
Produsului și
împreuna cu
Echipa va
identifica ce
funcționalități se
vor implementa
În funcție de
funcționalitățile
alese de Echipă se
va stabili
Obiectivul Sprint-
ului
A doua parte:
Echipa stabilește
cum va transforma
elementeledin
Backlog-ul
produsului în
software
funcțional.
Se începe prin
proiectarea
muncii=>lista de
activități=>Sprint
Backlog
Scrum Master-ul se
asigură că Echipa
susține ședința, se
aplică regulile și
ședința durează 15
minute, fiecare
membru vorbind pe
scurt
Pe parcursul
Ședinței Zilnice
fiecare membru al
Echipei de
dezvoltare va
răspunde la
întrebările cheie
Product Owner-ul
identifică ce a fost
finalizat și ce nu.
Echipa discută
despre ce a mers
bine în timpul
Sprint-ului și ce
probleme au
întâmpinat,
precum și modul
cum au fost
rezolvate.
Echipa apoi
demonstrează
munca efectuată
și răspunde la
întrebări.
Product Owner-ul
discută apoi
despre Backlog-ul
Produsului dând o
estimare privind
finalizarea
acestuia.
Întregul grup
colaborează apoi
în
privința lucrurilor
discutate pentru a
vedea cum le pot
folosi in Sprint-
urile viitoare
ScrumMaster-ul
încurajează Echipa
Scrum să își
revizuiască, în
cadrul procesului și
practicilor Scrum,
procesul de
dezvoltare, urmărind
să se obțină
răspunsul la
întrebările cheie
Pe baza analizei
proceselor,
oamenilor, relațiilor
și instrumentelor
folosite se identifică
ce a mers bine și ce
trebuie îmbunătățit și
se creează un plan de
implementare a
măsurilor de
îmbunătățire
identificate
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.
- 18-
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
- 19-
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
- 20-
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)
- 21-
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)
- 22-
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)
- 23-
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:
- 24-
- 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)
- 25-
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
- 26-
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
- 27-
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
cerințelor
Document ”Method X
Functional Specifications”
Completarea documentului
presupunea o muncă
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
Technical Specifications”
După finalizarea proiectului în
momentul când se făceau
schimbări documentul nu se
mai actualiza – își pierde
valoare
Implementare Metodă X Tabele necesare metodei
Schemă XML a metodei
Mecanism necesar efectuării
plății
Servicii Windows de
notificare a statusului
Dashboard Comerciant
Aplicație BackOffice pentru
configurare metodă
Pe tot parcursul implementării
metodei doar dezvoltatorul
știa ce a implementat
Costuri considerabile (media
timpului de implementarea a
metodei era de cel puțin trei
săptămâni)
Lansare pe platforma de
TEST
Metodă X integrată pe mediul
de TESTARE
De multe ori nu se aprecia
corect impactul integrării și
care erau elementele ce
trebuiau compilate din nou
pentru că au fost afectate la
integrare
Testare metodă pe
platformă TEST
Test Case Metodă X
Metodă X testată
Timpul necesar familiarizării
tester-ului cu metoda X era
considerabil (media timpului
- 28-
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
Testat
Testarea de regresie era
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
Metoda X în platforma de
TEST
Primul pas al comerciantului
realizat pentru a putea oferi
metoda
Pe parcursul testării metodei de
către comerciant se descopereau
noi cerințe/probleme și se reluau
etapele anterioare
Lansare metodă pe
platformă producție
Metodă X integrată pe mediul
de PRODUCȚIE
Nu exista informații clare
despre ce fișiere/proceduri au
fost integrate și ce zone au fost
afectate
Testare metodă pe
platforma de producție
Metodă X testată pe platforma
de PRODUCȚIE
De multe ori testarea metodei
nu se realiza corespunzător
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
Metoda X putea fi oferită de
către comerciant clienților săi,
mărindu-și astfel portofoliul
de metode
Pe parcursul testării metodei de
către comerciant se descopereau
noi cerințe/probleme și se reluau
etapele anterioare – costuri
ridicate/proiectul nu putea fi
considerat finalizat
Utilizarea metodei în Dovada clară a succesului sau Uneori se descopereau
probleme mult prea târziu – se
- 29-
producție eșecului proiectului
Tranzacții pe producție
realizate folosind metoda
producea o mobilizare de forțe
pentru a rezolva problema cât
mai rapid – dar acest efort nu
era benefic pentru planificarea
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
- 30-
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/.
- 31-
Ș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)
- 32-
(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
Directorul general
Comunică noile
cerințe și le
prioretizează
împreună cu
managerul folosind
TFS Work Item
Manager
Cere rapoarte ale
bug-urilor, task-
urilor sau ale
evoluției
proiectelor care
acum se exportă
din TFS Work Item
Manager
Manager
Introduce cerințele
ca User Story-uri
în TFS Work Item
Manager
Discută cu echipa
pe baza acestora și
obținerea estimări
privind finalizarea
acestora
Rezolvă
impedimentele
raportate ca Issues
Trece User Story-
urile în statusul
”Resolved” la
finalizarea lor
După lansare trece
US-urile și bug-
urile în statusul
”Delivered”
Dezvoltator
Își introduce
sarcinile de lucru
legate de User
Story-urile pe
care trebuie să le
implementeze, le
trece în statusul
”Closed” la
finalizare și
completează
numărul de ore
lucrate
Verifică bug-urile
asociate lui, le
rezolvă și le pună
în statusul
”Resolved” pentru
ca tester-ul sa
primească e-mail
și să îl verifice
Tester
Își introduce
sarcinile de lucru
legate de User
Story-urile pe
care trebuie să le
testeze, le trece în
statusul ”Closed”
la finalizare și
completează
numărul de ore
lucrate
Verifică bug-urile
rezolvate și le
trece în statusul
”Closed” dacă
problema a fost
rezolvată
Raportează Issue-
urile, descoperite
la testare
Figura nr. 7 Organizarea modului de lucru în Smart2Tech
- 33-
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ă?
- 34-
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.
- 35-
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.
- 36-
Ș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
- 37-
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
- 38-
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
Un mod de
lucru mai eficient
Ședințele Zilnice Scrum
permit colaborarea în
timp util, identificarea
mai rapidă a
problemelor
Ședințele de
Planificare, Revizuire și
Retrospectivă a Sprint-
ului nu se respectă
Ședințele zilnice
ajungeau să depășească
15 minute, fiind mai
mult ședințe de discuții
Seminar de învățare și
perfecționare Scrum cu
explicare obiectivelor
acestor ședințe
Realizarea unui proiect
model
Schimbarea mentalității
organizaționale
Realizarea ședințelor
zilnice în picioare
- 39-
Adaptare
Schimbarea cerințelor
nu mai presupune
efortul chinuitor al
actualizării
documentației, ci
explicarea acestora în
cadrul ședințelor zilnice
În caz că un User Story
este blocat se trece la
următorul
Echipa nu se
autoorganizează
Seminar de învățare și
perfecționare Scrum cu
explicare obiectivelor și
a regulilor recomandate
de desfășurare
Realizarea unui proiect
model
Ce s-a dorit? Ce s-a obținut? Soluții
Transparență
Tester-ul primea
informațiile necesare
testării mult mai
devreme
La sfârșitul proiectului
directorul general și
toate persoanele
interesate participă la
prezentarea produsului
și oferă feedback
Prin segmentarea
angajaților Smart2Tech
în mai multe echipe
Scrum anumite
informații
organizaționale nu
ajung la toți membrii
companiei
Ședințele de
Planificare, Revizuire și
Retrospectivă trebuie
să se realizeze pe
fiecare Sprint, nu pe
întregul proiect
Ședințele Scrum zilnice
divizate pe proiecte se
transformă în ședință
organizațională; în care
pentru fiecare proiect
persoanele implicate
spun ce au făcut și ce
urmează să facă.
Reguli: ședința se
desfășoară în picioare,
fiecare proiect are 2
minute, problemele se
detaliază ulterior
Scăderea
costurilor și a
timpului de
reacție la cerințe
Implementarea unei
noi metode de plată a
scăzut de la 15 zile la
10 zile
Cu anumite riscuri
asumate testarea de
regresie se realizează
din patru în patru luni
Flexibilitatea presupune
probleme: nu se știe ce
s-a lansat în producție
A fi Agile nu înseamnă
dispariția documentelor
Un document bine
structurat, pus pe
portalul SharePoint TFS
este necesar pentru a
ști: ce s-a lansat pe
mediul de test/producție
și când, care este
statusul testării pe
mediul de test/producție
- 40-
(sursa: prelucrare proprie)
Ce s-a dorit? Ce s-a obținut? Soluții
Anticiparea
Riscurilor
Ședințele Scrum zilnice
facilitează comunicarea
impedimentelor
Ședințele de revizuire a
proiectului se fac când
programul este mai
liber și nu la sfârșitul
proiectului, anumite
probleme fiind
descoperite prea târziu
Nefolosirea
diagramelor Borndown
nu permite anticiparea
corectă a riscurilor
proiectului
Ședințele de
Planificare, Revizuire și
Retrospectivă trebuie
să se realizeze pe
fiecare Sprint, nu pe
întregul proiect
Crearea unei echipe de
suport tehnic pentru ca
dezvoltatorii să se poată
concentra pe
implementarea User
Story-urilor
Rezolvare
defectelor și
problemelor în
timp util
50% dintre
impedimente au fost
rezolvate mult mai ușor,
ședințele Scrum zilnice
facilitând comunicarea
Testerii comunicând
bug-urile identificate la
ședințele zilnice a fost
mult mai ușoară
identificarea cauzelor
Ședințele de revizuire a
proiectului se făceau
când programul era mai
liber și nu la sfârșitul
proiectului, anumite
probleme fiind
descoperite prea târziu
Ședințele de
Planificare, Revizuire și
Retrospectivă trebuie
să se realizeze pe
fiecare Sprint, nu pe
întregul proiect
Ședințele Scrum zilnice
divizate pe proiecte se
transformă în ședință
organizațională; în care
pentru fiecare proiect
persoanele implicate
spun ce au făcut și ce
urmează să facă.
Reguli: ședința se
desfășoară în picioare,
fiecare proiect are 2
minute, problemele se
detaliază ulterior
Figura nr. 10 Cerințe, realizări și soluții de îmbunătățire
- 41-
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.
- 42-
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.
- 43-
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