SCRUM in managementul proiectelor software

44
Universitatea „Alexandru Ioan Cuza” Iaşi Facultatea de Economie şi Administrarea Afacerilor Master Sisteme Informaționale pentru Afaceri SCRUM în managementul proiectelor software Coordonator ştiinţific, Prof. Univ. Dr. Gabriela Meșniță Absolventă, Macuc Cristina-Adriana Iaşi, februarie 2013

description

Lucrarea de față este un experiment ce a plecat de la ipoteza că Scrum-ul ca metodă demanagementul al proiectelor face ca sintagmele de mai sus să fie complementare și a ajuns laconcluzia că modelul poate fi îmbunătățit. Pentru a putea aborda acest domeniu a fostprimordială definirea conceptelo, prezentarea particularităţilor, a regulilor și a modului dedesfășurare recomandat, stabilirea implicaţiilor organizaţionale şi a rolurilor participanților.

Transcript of SCRUM in managementul proiectelor software

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

Page 2: SCRUM in managementul proiectelor software

- 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

Page 3: SCRUM in managementul proiectelor software

- 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

Page 4: SCRUM in managementul proiectelor software

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

Page 5: SCRUM in managementul proiectelor software

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

Page 6: SCRUM in managementul proiectelor software

- 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

Page 7: SCRUM in managementul proiectelor software

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

Page 8: SCRUM in managementul proiectelor software

- 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

Page 9: SCRUM in managementul proiectelor software

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

Page 10: SCRUM in managementul proiectelor software

- 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

Page 11: SCRUM in managementul proiectelor software

- 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

Page 12: SCRUM in managementul proiectelor software

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

Page 13: SCRUM in managementul proiectelor software

- 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

Page 14: SCRUM in managementul proiectelor software

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

Page 15: SCRUM in managementul proiectelor software

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

Page 16: SCRUM in managementul proiectelor software

- 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

Page 17: SCRUM in managementul proiectelor software

- 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

Page 18: SCRUM in managementul proiectelor software

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

Page 19: SCRUM in managementul proiectelor software

- 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

Page 20: SCRUM in managementul proiectelor software

- 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

Page 21: SCRUM in managementul proiectelor software

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

Page 22: SCRUM in managementul proiectelor software

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

Page 23: SCRUM in managementul proiectelor software

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

Page 24: SCRUM in managementul proiectelor software

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

Page 25: SCRUM in managementul proiectelor software

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

Page 26: SCRUM in managementul proiectelor software

- 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

Page 27: SCRUM in managementul proiectelor software

- 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

Page 28: SCRUM in managementul proiectelor software

- 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

Page 29: SCRUM in managementul proiectelor software

- 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

Page 30: SCRUM in managementul proiectelor software

- 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

Page 31: SCRUM in managementul proiectelor software

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

Page 32: SCRUM in managementul proiectelor software

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

Page 33: SCRUM in managementul proiectelor software

- 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

Page 34: SCRUM in managementul proiectelor software

- 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ă?

Page 35: SCRUM in managementul proiectelor software

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

Page 36: SCRUM in managementul proiectelor software

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

Page 37: SCRUM in managementul proiectelor software

- 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

Page 38: SCRUM in managementul proiectelor software

- 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

Page 39: SCRUM in managementul proiectelor software

- 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

Page 40: SCRUM in managementul proiectelor software

- 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

Page 41: SCRUM in managementul proiectelor software

- 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

Page 42: SCRUM in managementul proiectelor software

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

Page 43: SCRUM in managementul proiectelor software

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

Page 44: SCRUM in managementul proiectelor software

- 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