1. Ce este Agile?

1.1 Introducere
 

Agile este un set de principii și valori, sub forma unui ghid ce ajută echipele de dezvoltare
software să ofere mai rapid și mai eficient produse de calitate clienților lor. Agile este o abordare
iterativă pentru livrarea de produse software, unde, la finalul fiecărei iterații este livrată o
versiune intermediară a produsului final. Fiecare versiune intermediară, deși nu reprezintă
funcționalitatea completă dorită de client, conține noi funcționalități față de versiunea anterioară.
Fiecare dintre aceste incrementări este validată de client, astfel încât, aceștia sunt participanți
activi în procesul de dezvoltare. 

În acest context, agilitatea reprezintă abilitatea continuă de adaptare, capacitatea unei echipe de
a îmbunătăți constant felul în care lucreză. Aplicând principiile Agile, dezvoltarea produselor
software devine un proces dinamic în care fiecare parte interesată(stakeholder) se poate implica
pe parcurs, în care deciziile inițiale se pot schimba în ritmul alert în care industria IT și opțiunile
existente pe piață evoluează. Acesta este motivul pentru care abordarea incrementală a
dezvoltării produselor software este atât de eficientă si populară comparativ cu livrarea singulară
a produsului complex, pentru care modificarea anumitor funcționalități presupune o dificultate
ridicată.

Principiile Agile sunt prezentate în documentul Agile Manifesto, despre care vom vorbi în unul
dintre capitolele următoare. Totuși, aceste principii au apărut înainte de a fi redactate în forma
finală în acest document. Agile a apărut ca un răspuns la stilul clasic de gestiune de proiect, în
încercarea de a optimiza timpii de analiză, design, implementare și în general a tuturor
proceselor prezente în ciclul de viață al unui proiect. La începutul anilor 1990, pentru că utilizarea
calculatorului s-a extins considerabil în companii, industria de dezvoltare software a întâmpinat
o criză. Experții au estimat că timpul de la validarea unei nevoi business până la instalarea
aplicației în producție era de trei ani. Problema era că business-ul se schimba mai repede de atât,
chiar și în acea perioadă. În cei trei ani, atât cerințele, cât și sistemele erau supuse schimbării, iar
produsul software final devenea inutilizabil, dacă ajungea la versiunea finală și nu era întrerupt
pe parcurs. În alte industrii precum cea aerospațială, dura chiar mai mult până ce un sistem
complex putea fi utilizat, durate estimate până la 20 de ani de design, implementare și testare
software. Frustrarea liderilor din domeniu i-a condus pe aceștia spre întâlniri frecvente unde se
dezbăteau și propuneau soluții pentru moduri mai eficiente de a organiza procesul de dezvoltare
software. Aceste întâlniri s-au concluzionat în 2001 cu documentul Agile Manifesto.

În prezent, Agile este folosit într-o formă sau alta de 71% dintre organizații, conform unui studiu
al Project Management Institute din 2018. Mai mult, un studiu realizat de Pricewaterhouse
Coopers în 2017 susține că proiectele care implementează o metodologie Agile sunt cu 28% mai
de succes decât proiectele tradiționale.
1.2 Waterfall vs. Agile
 Click to addBookmark this page

Waterfall este o abordare liniară a dezvoltării de produse software, care mai este cunoscută și
sub numele de Linear Sequential Life Cycle Model. În această definiție, secvențial (sequential)
indică faptul că etapele proiectului vor fi tratate în ordine, iar echipa nu va trece la următoarea
secvență până ce nu o va fi terminat cu succes pe cea anterioară. Etapele într-un proiect Waterfall
sunt următoarele:

- Obținerea si documentarea cerințelor

- Design

- Implementare și testare unitară (testarea unitară este procesul de testare independentă, ca

unitate, a părților care compun un sistem)

- Testare integrată de sistem

- Execuția testelor de acceptanță definite de utilizator (user acceptance testing – UAT)

- Rezolvarea problemelor detectate

- Livrarea produsului final

Deși această abordare este destul de clară si ajută clientul si echipa de dezvoltare să stabilească
încă de la început ce se va livra, după cum am discutat în capitolul anterior, aceasta nu poate ține
pasul cu schimbările de cerințe ce vor apărea inevitabil pe parcursul proiectului. O limitare
majoră a acestei metode este faptul că sunt necesare cerințe detaliate chiar de la începutul
proiectului. Un alt dezavantaj al Waterfall este că produsul final poate fi nesatisfăcător pentru
clientul care, în această abordare, nu are vizibilitate asupra diferitelor etape intermiedare ale
produsului. Odată obținut produsul final, aplicația software, modificarea acestuia poate fi dificilă
și costisitoare.
Spre deosebire de modelul Waterfall, în cazul Agile activitățile se desfășoară concomitent. În
abordarea Agile, eforturile se concentrează asupra livrării rapide a componentelor funcționale. În
locul planificărilor detaliate prezente în modelul Waterfall, în cazul Agile programul de
implementarea este împărțit în cadre de timp prestabilite (de obicei între 2 și 4 săptămâni)
numite iterații. Pentru fiecare iterație, la începutul acesteia, este stabilită o listă de livrabile,
prioritizată în funcție de valoarea business a acestora. Valoarea este stabilită de către clientul
care, pe măsură ce lucrările sunt finalizate, poate revizui si evalua livrabilele. Această abordare
incrementală permite clientului să modifice funcționalitățile aplicației pe parcurs și ajută echipa
de dezvoltare să rămână concentrată asupra sarcinilor curente.
 

1.3 Agile Manifesto – principii și valori

 Click to addBookmark this page

În 2001, 17 lideri din industria IT, reprezentanți ai diferitelor metodologii ce urmau a fi asociate
termenului de “Agile”, s-au adunat în Snowbird, Utah, pentru a găsi metode alternative la
procesele de dezvoltare software complexe (heavyweight) și bazate pe documentație.
Participanții își doreau să găsească o cale prin care să promoveze modele organizaționale bazate
pe oameni, pe colaborare, pe comunitate, astfel încât viziunea clientului să fie înțeleasă și
implementată cu succes. Concluzia acestei întâlniri și a discuțiilor purtate de participanți a fost
documentul Agile Manifesto, ce reprezintă un set de principii și valori. Autorii documentului
susțin că nu sunt împotriva documentației de proiect, atâta timp cât aceasta nu devine un
manuscris cu sute de pagini neactualizate si foarte rar folosite. În plus, aceștia se declară pro
planficare, dar recunosc limitările planificării într-un mediu turbulent cum este industra IT.

Următoarele rânduri reprezintă valorile prezentate în Agile Manifesto, așa cum sunt descrise în
document:

“ Descoperim căi mai bune de a dezvolta software, punând în practică și ajutându-i pe alții să
pună în practică. Prin această lucrare am ajuns să prețuim:

- Accentul ar trebui să se concentreze mai mult pe indivizi și interacțiuni, în loc de procese și

instrumente

- Software-ul funcțional este mai important decât o documentare completă

- Colaborarea cu clienții este mai importantă decât negocierea contractului

- Procesul ar trebui să răspundă la schimbări, mai degrabă decât să urmeze un plan

Asta înseamnă că, deși există valoare în lucrurile din partea dreaptă, le prețuim pe cele din partea
stângă mai mult.“

Principiile prezentate de Agile Manifesto sunt următoarele:

- Cea mai mare prioritate a noastră este să satisfacem clientul prin livrare timpurie și continuă de
software de calitate.

- Primim cu brațele deschise schimbarea cerințelor, chiar și târziu în procesul de dezvoltare.

Procesele Agile se folosesc de schimbare pentru avantajul competitv al clientului.

- Livrăm software funcțional frecvent, de la două săptămâni până la două luni, cu o preferință
pentru termenul mai scurt.

- Oamenii care cunosc business-ul și dezvoltatorii software trebuie să lucreze împreună zilnic pe
timpul proiectului.

- Construim proiecte în jurul unor persoane motivate. Le oferim mediul de lucru și sprijinul de
care au nevoie și avem încredere în ei pentru a finaliza cu succes treaba.

- Cea mai eficientă metodă de a transmite informația către și în cadrul echipei de dezvoltare este
conversația față în față.

- Software-ul funcțional este unitatea de măsură principală a progresului.

- Procesele Agile promovează dezvoltarea durabilă. Sponsorii, dezvoltatorii și utilizatorii ar trebui

să fie capabili de a menține un ritm constant pentru un termen de timp nedefinit.

- Atenția continuă asupra excelenței tehnice și a unui design bun îmbunătățește agilitatea.

- Simplitatea – arta de a maximiza munca nefăcută – este esențială.

- Cele mai bune arhitecturi, cerințe și design-uri apar în echipele auto-organizate.

- La intervale de timp regulate, echipa reflectează asupra modurilor de a se îmbunătăți, a deveni

mai eficientă, apoi își ajustează comportamentul în consecință. “

Mai multe informații despre autorii Agile Manifesto puteți găsi

aici: https://agilemanifesto.org/authors.html.
1.5 Beneficiile Agile
 Click to addBookmark this page

Beneficiile aduse de implementarea principiilor Agile sunt numeroase și vizează în mod direct
toate părțile implicate, de la client până la fiecare membru al echipei de dezvoltare. În
continuare, le vom detalia pe cele mai importante dintre acestea:

- Implicarea părților interesate 

Agile oferă oportunitatea de a se implica tuturor părților interesate, atât înainte de începerea
fiecărui sprint, cât și la finalul acestuia și chiar pe durata lui dacă este cazul. Implicând clientul în
fiecare pas al proiectului, este încurajată colaborarea între client și echipa de dezvoltare și astfel
se creează mai multe șanse pentru echipă de a pune întrebări, de a clarifica și a înțelege mai bine
viziunea clientului. Livrările frecvente cresc încrederea părților implicate în abilitatea echipei de
dezvoltare de a finaliza cu succes sarcinile și de a furniza software funcțional, de calitate.

- Transparența

Abordarea Agile oferă o oportunitate unică pentru client de a se implica pe întregul parcurs al
proiectului. Este necesar ca părțile implicate să înțeleagă că, la finalul fiecărei iterații, ceea ce văd
este un software în curs de implementare și nu produsul final. Acest lucru permite o vizibilitate
clară asupra progresului și a problemelor apărute pe parcurs, astfel ca procesele să poată fi
adaptate în funcție de aceste criterii.

- Livrare timpurie si previzibilă

La finalul fiecărei iterații, echipa de dezvoltare va livra noi funcționalități ale aplicației. Pentru că
iterațiile sunt cadre de timp relativ scurte, modificările aduse au rezultate previzibile. Frecvența
livrărilor are un impact pozitiv asupra valorii business a proiectului, pentru că echipa de
dezvoltare poate contura o imagine clară asupra felului în care va funcționa aplicația, iar
utilizatorii se pot obișnui treptat cu aceste funcționalități.

- Costuri și program previzibil

Pentru că fiecare iterație are o durată fixă, costul este previzibil și numărul de sarcini ce pot fi
îndeplinite în acest timp este limitat. Aceste aspecte, dar și estimările oferite clientului la
începutul fiecărei iterații, îl ajută pe acesta să își gestioneze bugetul, având un cost aproximat al
fiecărei sarcini de lucru, cost calculat în funcție de timp, complexitate și efort.

În plus, în funcție de costul și timpul estimat, clientul poate hotărî prioritatea fiecărei sarcini.

- Permite schimbări

În timp ce echipa se concentrează asupra implementării funcționalităților cerute în iterația

curentă, există oportunitatea de a redefini și reprioritiza funcționalitățile ce vor fi implementate în
iterațiile viitoare. Această șansă de a introduce cerințe pentru funcționalități noi chiar în decursul
a câteva săptămâni este o caracteristică specifică proiectelor Agile.
- Se concentrează asupra valorii business

Permițând clientului să ia toate deciziile legate de prioritatea sarcinilor de lucru, echipa înțelege
care funcționalități sunt cele mai importante pentru afacerea clientului și poate furniza funcțiile
care oferă cea mai multă valoare.

- Se concentrează asupra utilizatorilor

Centrul atenției într-un proiect Agile este utilizatorul. Fiecare cerință de implementare are
anumite criterii de acceptanță stabilite din punctul de vedere al utilizatorului. În astfel de
proiecte, feedback-ul de la utilizator poate fi decisiv asupra viitorului proiectului, pentru ca
software-ul final să ajungă să îi satisfacă nevoile.

- Riscul este redus

Este foarte improbabil ca un proiect Agile să devină un eșec total. Fiecare versiune intermediară a
produsului este în sine o aplicație funcțională, chiar dacă nu prezintă toate capabilitățile
produsului final. Acest lucru este asigurat la finalul fiecărei iterații, astfel că dacă proiectul va fi
întrerupt la un moment dat, chiar și varianta disponibilă la acel moment va putea fi folosită.
Situațiile neprevăzute sunt rare, pentru că în timpul scurt al unei iterații este improbabil să apară
probleme sau modificări. Acestea vor fi dezbătute și analizate în cadrul ședințelor și soluțiile vor
putea fi implementate chiar începând cu iterația imediat următoare.

- Moralul echipei este ridicat

Într-o echipă auto-organizată, cum este o echipă Agile, membrilor acesteia le este permis să fie
creativi, să inoveze și să își asume responsabilitatea. Fiecare membru are libertatea de a alege la
ce sarcină să lucreze astfel încât să se folosească de cunoștințele sale sau să dobândească unele
noi.

1.5 Instrumente software

 Click to addBookmark this page

În continuare vom discuta, pe scurt, despre câteva instrumente software ce facilitează

implementarea practicilor Agile. Unele dintre acestea sunt specifice anumitor metodologii Agile,
așa că puteți reveni la acest capitol pentru a putea identifica diferitele componente, după ce le
vom detalia pe fiecare în parte.

Instrumentele prezentate mai jos sunt de fapt aplicații online de gestiune a proiectelor, care
includ funcționalități specifice Agile, cum ar fi gestiunea sarcinilor, colaborarea echipei, metrici,
rapoarte, etc. 

 Jira este cea mai cunoscuta și folosită aplicație Agile. Deși a început ca un sistem de
urmărire a erorilor, acum este completat cu caracteristici ce permit gestiunea sarcinilor,
 colaborarea și raportarea în echipă. Jira poate gestiona o varietate de proiecte diferite
(Scrum, Kanban, chiar și management de proiect tradițional), fiind foarte flexibil în
configurare, astfel că permite definirea fluxurilor de lucru și proceselor unice pentru
echipa ce îl folosește. Este adesea folosit împreună cu suita de aplicații de la furnizorul
său, Atlassian, pentru a oferi o experiență dinamică, ușor de personalizat. Se poate
integra și cu GitHub(instrument de versionare software).

 Blossom este un instrument Agile modern, dedicat echipelor distribuite. Această aplicație include
caracteristicile necesare implementării metodologiei Kanban. Dispune de un flux de lucru
personalizabil pentru a reprezenta vizual starea sarcinilor efectuate. Accentul este pus pe simplitate și
claritate, pentru a identifica vizual ușor cine lucrează și la ce.
 Nostromo este o aplicație nouă, un instrument care include toate opțiunile pentru gestiunea de proiecte
în echipele de dezvoltare software sau, generic, echipe ce lucrează în domeniul digital. Include
funcționalități ca gestionarea sarcinilor, gestionarea timpului, raportare, analiză, colaborare, design.
 Zoho Sprints este un instrument simplu și flexibil de planificare care ajută echipele Agile să fie
pregătite de schimbare. Această aplicație își propune să ofere o abordare iterativă a muncii, susținând 
de asemenea colaborarea în echipă. Interfața este una intuitivă ce facilitează planificarea și prioritizarea
elementelor de lucru, vizualizarea sarcinilor în lucru sau finalizate. Este fezabil pentru echipe ce
implementează metodologiile Scrum, Kanban sau Scrumban. 

 Clarizen este o soluție software de automatizare a serviciilor profesionale din companii. Această
aplicație este concepută pentru a accelera ritmul de lucru, integrând munca, conținutul si procesele.
Este un instrument excelent pentru manageri ce gestionează mai multe proiecte în care există procese
repetabile, pentru că automatizează aceste fluxuri de lucru.
 2. Metodologii Agile
2.1 Scrum
 Click to addBookmark this page

Scrum este cea mai cunoscută și folosită metodologie Agile. Aceasta definește mai multe
reguli, practici și metode de a implementa principiile și valorile Agile. Metodologia
Scrum respectă principiile și valorile Agile în primul rând prin folosirea iterațiilor ca și
cadre de timp pentru dezvoltarea diferitelor versiuni intermediare ale produsului. În
Scrum, o iterație se numește sprint și durează ideal între 1 și 4 săptămâni. Ca și în cazul
Agile, Scrum oferă un ghid de implementare, fără a impune anumite aspecte, și de aceea
părțile implicate pot hotărî durata unui sprint, în funcție de nevoile clientului, de
capacitatea echipei sau alte considerente de proiect. Într-un proiect Scrum, cerințele sunt
definite într-o listă de priorități numită backlog și pot fi revizuite de către client pe tot
parcursul proiectului. Metodologia Scrum introduce rolurile de Scrum Master și Product
Owner, pe lângă echipa de dezvoltare. În plus, Scrum definește anumite evenimente ce
pot fi organizate pentru a îmbunătăți procesele și a aplica principiile Agile. Vom discuta
pe larg despre rolurile și ceremoniile Scrum în capitolele următoare.
 
Termenul de Scrum a fost folosit pentru prima dată de către Hirotaka Takeuchi și Ikujiro
Nonaka în lucrarea lor publicată în 1986 cu titlul ”The New New Product Development
Game”, lucrare în care este subliniată importanța muncii în echipă, a impactului pe care
colaborarea îl are asupra productivității și rezultatului final. Această lucrare se referă la
dezvoltarea de produse complexe în general, și nu numai produse software. Cercetarea
celor doi susține că echipele mici, auto-organizate, cărora li se oferă obiective în locul
sarcinilor, obțin rezultate remarcabile. Echipele implicate pot atinge această performanță
doar dacă le este oferită libertatea necesară pentru a-și defini strategiile proprii cu scopul
de a îndeplini țelul comun.
Autorii au ales acest termen, asemănând echipele de producție cu un grup de jucători din
echipa de rugby, care avansează cu mingea într-o anumită formație numită Scrum.
 
Ken Schwaber și Jeff Sutherland au elaborat conceptul de Scrum și aplicabilitatea
acestuia în industria de dezvoltare software într-o prezentare susținută la conferința
Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) din
1995. Ulterior, mai mulți experți și autori au continuat să rafineze conceptele și
metodologia Scrum. În ultimii ani, popularitatea acestei metodologii a crescut foarte mult,
ajungând să fie metodologia preferată de majoritatea organizațiilor, la nivel global.
 
Scrum este atât de popular mai ales datorită simplității sale. Este ușor de înțeles și ușor de
implementat. În plus, majoritatea organizațiilor care au implementat această metodologie
au reușit să își atingă scopurile, să își îmbunătățească procesele, să livreze mai rapid
produse de calitate și, în consecință, au devenit exemple de succes ale proiectelor care
folosesc Scrum. O altă cauză importantă a popularității Scrum este reprezentată de
varietatea de certificări care se pot obține. Scrum Alliance este organizația oficială Scrum
ce oferă numeroase certificări pentru rolurile de Scrum Master, Product Owner, Scrum
Developer, Agile Coach, Scrum Trainer.

2.2 Kanban
 Click to addBookmark this page

Kanban este o metodologie Agile bazată pe un sistem vizual de a gestiona sarcinile în

deplasarea lor printr-un proces. Scopul principal al acestei metodologii este de a identifica
potențialele blocaje în procesele existente pentru a le putea rezolva rapid și a permite
sarcinilor de lucru să avanseze în mod eficient din punctul de vedere al costurilor, la o
viteză sau un debit optim.
 
Principiile Kanban au fost introduse la începutul anilor 1940 de către Taiichi Ohno, un
inginer ce lucra în industria automobilelor, pentru Toyota. Acesta a creat un sistem
simplu de planificare prin care munca și inventarul să poată fi controlate și gestionate la
fiecare pas din procesul de producție. În mod ideal, un sistem Kanban controlează
întregul lanț valoric de la furnizor până la consumatorul final, astfel încât sa fie evitate
întreruperea aprovizionării și supraproducția de bunuri. Specific, în procesele de
fabricație Toyota, un proces anterior putea fi responsabil pentru a pregăti piesele necesare
în procesul curent. Metoda Kanban a revoluționat felul în care funcționau aceste
dependențe dintre procese, ajutând muncitorii să comunice prin cartele (în limba japoneză
Kanban înseamnă card/cartelă) pe care erau notate cantitățile necesare la fiecare pas din
proces. Acest lucru a condus la reducerea risipei și creșterea eficienței proceselor de
fabricație.
 
Ulterior, David J. Anderson a fost primul care a aplicat aceste concepte industriei de
dezvoltare software, în anul 2004. Ca și alte metodologii Agile, Kanban este folosită
pentru a îmbunătăți eficiența proceselor de lucru, a implica membrii echipei și a-i încuraja
să își asume responsabilitatea. Kanban folosește o tablă pe care diferite cartonașe, ce
reprezintă sarcinile de lucru ale echipei, sunt mutate dintr-un stadiu în altul. Vom discuta
în detaliu despre practicile Kanban în capitolele următoare.
 
Kanban este o metodologie populară pentru că ajută echipa să vizualizeze procesele, să
identifice cine și la ce lucrează la un anumit moment, ce mai este de făcut. Dar mai ales,
cea mai importantă caracteristică a metodologiei Kanban este că ajută la identificarea
blocajelor, reprezentate de zone ale tablei unde se aglomerează cartonașe, fără a avansa în
proces în același ritm. În plus, Kanban poate fi folosit în paralel cu alte metodologii Agile
sau alte modele de gestiune de proiect.
 
Alt motiv al popularității Kanban este efectul pe care îl are asupra moralului echipei.
Studii arată că acțiunile de a alege cartonașul (ce reprezintă o sarcină de lucru) și de a-l
muta de la stadiul ”în progres” la stadiul ”finalizat”, îmbunătățește starea de spirit a celui
care realizează munca respectivă pentru că acesta are un rezultat palpabil al efortului său
și, mai mult, crește încrederea echipei în abilitatea fiecărui membru de a-și îndeplini
sarcinile.

2.3 Scrumban
 Click to addBookmark this page

Scrumban este o metodologie Agile de tip hibrid care, după cum sugerează și numele,
propune o combinație între practicile prezente în Scrum și Kanban. Inițial, Scrumban a
fost conceput ca metodă de a face tranziția de la o organizare de tip Scrum către Kanban,
 dar, ulterior, îmbinând principiile ambelor metodologii, s-au constatat avantajele folosirii
acestui model combinat de gestiune a proiectelor. În prezent, Scrumban este folosit de
echipele care aleg să folosească Scrum ca stil de lucru, folosindu-se de flexibilitatea
acestei metodologii, dar care doresc să îmbunătățească felul în care lucrează, procesele pe
care le urmează, și se folosesc astfel de metodologia Kanban pentru a vizualiza și înțelege
mai bine care sunt ariile care necesită atenție sporită.
 
În Scrumban, munca este organizată în iterații scurte, ce păstrează denumirea de sprint-
uri. În plus, sarcinile de lucru sunt monitorizate cu ajutorul tablei și cartonașelor specifice
Kanban. Pentru a hotărî care sunt sarcinile la care se va lucra în iterația următoare, se țin
ședințe de planificare, dar dimensiunea backlog-ului (listei de sarcini) rămâne restrânsă,
aplicând principiul de work in progress limit de la Kanban. Această limită reprezintă
numărul maxim de sarcini la care echipa poate lucra în paralel la un anumit moment de
timp, pentru a evita începerea mai multor sarcini fără ca acestea să fie finalizate. Ședințele
de planificare nu se mai țin, ca în cazul Scrum, la începutul iterației, ci mai degrabă există
un eveniment ce declanșează nevoia pentru o astfel de ședință, de regulă când toate
cartonașele cu sarcini s-au deplasat din backlog către alte etape ale procesului, deci este
nevoie ca noi sarcini să fie luate în considerare și adăugate în listă.
 
Scrumban este considerat avantajos în următoarele situații:
-          Proiecte de mentenanță
-          Proiecte în care modificările de cerințe și/sau erorile de programare sunt frecvente
-          Echipe concentrate pe dezvoltarea de produse noi
-          Proiectele Scrum în care apar probleme datorate resurselor sau proceselor
 

Scrumban este de fapt foarte asemănător cu Scrum la nivel de practică, dar la nivel
cultural se apropie mai mult de Kanban – evoluție treptată, mai degrabă decât revoluție.

Avantajele Scrumban includ calitatea produsului, abordarea just-in-time (lucrurile se fac

atunci când este nevoie de ele, nu în avans), minimizarea risipei (risipa însemnând orice
proces ce nu aduce valoare clientului) și îmbunătățire continuă.

2.4 Alte metodologii

 Click to addBookmark this page

1.       Extreme Programming (XP)

Metodologia Extreme Programming a fost descrisă inițial de Kent
Beck, fiind una dintre cele mai cunoscute și controversate metodologii Agile.
Scopurile acestei metodologii sunt strâns legate de obiectivele Agile, și
anume livrarea continuă și rapidă, implementarea unui produs software de
calitate, flexibilitate în întâmpinarea noilor cerințe din partea clientului.
 Clientul este implicat în mod activ în procesele echipei, lucrând în cele mai
multe cazuri chiar în același spațiu cu echipa (on-site). Acesta efectuează
planificarea, testarea și oferă feedback rapid asupra progresului echipei. Unul
dintre motivele pentru care această metodologie este controversată este că
prezența clientului atât de aproape poate fi o cauză de stres pentru echipa de
dezvoltare. În plus, există riscul ca un reprezentant non-tehnic din partea
clientului să controleze îndeaproape munca fiecărui membru al echipei (acest
stil de management se numește micromanagement și este dăunător moralului
echipei/angajatului). Altă posibilă problemă care apare în cadrul acestei
metodologii este reprezentată de eventuale schimbări care se produc la mica
înțelegere între  client și echipă, fără a fi documentate, fără a fi estimat efortul
și a fi aprobate la nivel de management.
O altă caracteristică a acestei metodologii este realizarea unei sarcini în
perechi de câte doi programatori (pair programming), pentru a asigura
calitatea codului și a rezultatului, astfel că fiecare dintre cei doi se ocupă la
rândul său de revizuirea muncii celuilalt.
Iterațiile sunt scurte, iar livrările sunt frecvente și conțin funcționalități cu
complexitate redusă. Se pune accentul pe calitatea codului, astfel că există
standarde de calitate prestabilite, revizuiri frecvente și chiar modificări în
acest sens, iar o anumite parte din cod este responsabilitatea ambilor
programatori care au lucrat la acea funcționalitate.
 
2.       Crystal
Crystal nu este o metodologie în sine, ci mai degrabă o familie de
metodologii care variază în funcție de dimensiunea și complexitatea
proiectului. Fiecare metodologie este denumită în funcție de culoarea
corespunzătoare durității cristalului geologic, de aici denumirea de Crystal,
cu următoarele implementări :
Clear (1-6 membri), Yellow (7-20 membri), Orange (21-40 membri),
Red (41-80 membri), Maroon (81-200 membri).
Dacă un proiect începe după modelul Crystal Clear, clientul sau
managementul nu se pot aștepta ca acesta să devină direct Crystal Maroon. În
cazul în care proiectul evoluează, este recomandată trecerea la nivelul imediat
următor, mai degrabă decât extinderea regulilor nivelului curent.
Ideea principală care stă la baza metodologiilor Crystal este că echipa și
membrii acesteia sunt cei mai importanți în buna desfășurare a proiectului. În
cadrul oricărei echipe de dezvoltare, există seturi de abilități și talente
diferite, astfel că fiecare membru poate să folosească propria perspectivă în
beneficiul echipei și al proiectului. Fiecare membru al echipei este încurajat
să ia ocazional pauze de la sarcinile sale și să se gândească la cum ar putea să
își îmbunătățească stilul de lucru, procesele și metodele pe care le folosește zi
de zi. Uneori, echipa poate ține ședințe în care să facă același lucru, dar
împreună, dezbătând posibilele soluții la problemele identificate.
Ca și alte metodologii Agile, Crystal promovează livrarea rapidă și frecventă
de software funcțional, implicarea clientului, adaptabilitate, dar și eliminarea
birocrației excesive.
 
3.       Dynamic Systems Development Method (DSDM)
DSDM este o metodologie care susține principiile Agile cum ar fi: definirea
unui cadru de timp fix pentru iterații, livrarea incrementală de software
 funcțional, implicarea clientului. Această metodologie este adesea folosită
împreună cu alte metodologii, completând diferite abordări Agile.
În DSDM este introdus conceptul de seminarii (workshops) care facilitează
comunicarea între echipă și client. În aceste ședințe, fiecare parte implicată
poate să pună sau să răspundă la întrebări cu scopul de a clarifica eventualele
neînțelegeri.
Un alt termen prezent în DSDM este tehnica MoSCoW. Este un
acronim care reprezintă nivelurile de prioritate ale cerințelor și
specificațiilor :
-          Must – trebuie neapărat implementată această cerință
-          Should – ar trebui implementată aceasă cerință dacă este posibil
-          Could – această cerință ar putea fi implementată dacă poate fi livrată fără
un impact major
-          Would – nu ar fi rău dacă ar rămâne suficient timp pentru a implementa
această cerință
 
4.       Feature Driven Development (FDD)
FDD este o metodologie de dezvoltare software ce urmează un model iterativ
și incremental. FDD îmbină într-un ansamblu coeziv bunele practici
recunoscute de industria dezvoltării software, practici derivate din
perspectiva funcționalității evaluate de client. Este o metodologie bazată pe
modelul produsului și pe iterații scurte.
Această metodologie propune cinci activități :
- Definirea modelului general – rezultă modelul final dorit
- Definirea listei de caracteristici – vor fi grupate în seturi în funcție de
domeniile de funcționalitate
- Planificarea în funcție de caracteristici – pentru fiecare din caracteristicile
din lista anterioară se definește un plan de dezvoltare și un responsabil
- Design în funcție de caracteristici – se stabilesc detaliile de design și
implementare pentru fiecare din caracteristicile menționate mai sus
- Implementarea caracteristicilor – programarea propriu-zisă,
testarea, livrarea funcționalității
În această metodologie este important ca fiecare funcționalitate să
aibă un responsabil care se va ocupa de ea de la început până la
final, indiferent câte modificări sau evoluții pot interveni. Acest
responsabil este, de regulă, un membru al echipei de dezvoltare,
dar poate fi și un subgrup al echipei în cazul în care
funcționalitatea este complexă.

Product owner
 Click to addBookmark this page
 Product owner-ul este cel care definește cum va arăta produsul, ce funcționalități va conține.
El este cel care va comunica direct cu părțile implicate, iar prin feedback-ul acestora va hotărî
care sarcini aduc cea mai mare valoare incrementărilor curente si viitoare. Product owner-ul
este cel care gestionează lista de sarcini(backlog-ul) și se asigură că toată echipa cunoaște
prioritățile.
 
Funcțiile pe care acest rol le acoperă sunt:
-          Vocea clientului – el este cel care reprezintă dorințele și nevoile clientului
-          Comunicator – se ocupă cu adaptarea mesajelor pentru o mare varietate de părți
implicate; comunică pe înțelesul interlocutorilor săi, fie ei clienți, persoane care cunosc
business-ul sau chiar persoane tehnice din echipă
-          Decident – evaluează prioritățile concurente pentru a alege funcționalitățile potrivite și,
eventual, le amână pe restul sau le exclude din sprint; decide frecvența livrărilor

Activitățile întreprinse de product owner pot fi, dar nu se rezumă la:

o   Exprimă clar elementele din backlog

o   Ordonează elementele din backlog pentru a îndeplini cât mai eficient obiectivele
o   Optimizează valoarea muncii echipei de dezvoltare
o   Se asigură că backlog-ul este vizibil, clar pentru toată lumea și că acesta conține
funcționalitățile la care se va lucra în etapele imediat următoare
o   Se asigură că echipa de dezvoltare înțelege funcționalitățile cerute la nivelul necesar
implementării acestora

Caracteristicile ideale ale unui Product owner sunt:

ü  Responsabil – are autoritatea de a lua decizii legate de produs

ü  Cunoscător al business-ului – cunoaște domeniul, procesele, clientul și piața
ü  Persuasiv – lucrează bine cu echipa și cu părțile implicate; își argumentează deciziile
legate de priorități
ü  Informat – cunoaște piața și produsul; înțelege provocările de producție
ü  Disponibil – este ușor accesibil pentru echipă și pentru părțile interesate
 Previous
3. Scrum
3.1 Introducere
 Click to addBookmark this page

Primul pas în a cunoaște metodologia Scrum este înțelegerea definiției și a principiilor sale.
Conceptul care stă la baza acestei metodologii este empirismul, care afirmă că toate
cunoștințele provin din experiență. Al doilea concept important pe care se bazează acestă
metodologie este abordarea iterativă, care presupune câștiguri incrementale pentru fiecare
nouă parte de cunoaștere empirică dobândită. În consecință, tot ce se implementează trebuie
să fie testat pentru a putea fi transformat în cunoștințe. Apoi, cunoștințele acumulate sunt
folosite pentru a îmbunătăți constant rezultatul.

Ghidul oficial Scrum definește cele trei principii Scrum astfel:

- Transparența – toate caracteristicile în dezvoltare ale proiectului trebuie să aibă definiții

clare și obiective, comune tuturor participanților (echipa de dezvoltare, Scrum master, client,
etc.), astfel ca aceștia să ”vorbească aceeași limbă” pe parcursul execuției sarcinilor. În plus,
aceste informații trebuie să fie disponibile tuturor părților la orice moment de timp și
actualizate în conformitate cu modificările apărute.

- Inspecția – rezultatele parțiale trebuie evaluate în mod constant. Inspecțiile periodice

permit determinarea progresului înregistrat până la un anumit moment. Astfel, echipa,
clientul sau oricare dintre părțile interesate poate să hotărască dacă progresul obținut este
mulțumitor, dacă se încadrează în cadrul de timp estimat anterior, dacă se aliniază cu
obiectivele proiectului și dacă satisface nevoile clientului. Totuși, este important ca aceste
evaluări ale progresului să nu decaleze sarcinile de lucru care sunt în desfășurare

- Adaptarea – în urma unei inspecții care indică un progres nesatisfăcător, procesul sau
materialul produs trebuie să fie ajustat, iar această adaptare trebuie realizată cât mai repede cu
putință pentru a minimiza deviere ulterioară. Astfel, în urma experienței și a greșelilor sau a
rezultatelor slabe, echipa poate să facă trecerea la noi modele de procese chiar în momentul
identificării problemelor sau cel mai târziu în iterația următoare.

Valorile promovate de metodologia Scrum sunt următoarele:

  Angajamentul – având în vedere stilul de lucru propus de Scrum, este
important să existe încredere în cadrul echipei, astfel ca fiecare membru
să fie responsabil pentru angajamentele pe care și le-a asumat și pentru
finalizarea cu succes a sarcinilor sale și să se poată baza pe ceilalți că vor
face același lucru. Mai mult, echipa nu se angajează la mai mult decât
poate realiza într-o fereastră de timp(de exemplu într-un sprint)

 Curajul – în echipele Scrum este necesar ca fiecare membru să se simtă destul de în

  

siguranță pentru a refuza sarcini, pentru a cere ajutorul și, mai ales, pentru a încerca
lucruri noi. Echipa trebuie să fie destul de curajoasă încât să poată contesta status quo-
ul atunci când lucrurile nu merg sau pot fi îmbunătățite

 Concentrarea – se referă la abilitatea echipelor Scrum de a îndeplini cu

succes sarcinile începute, fără a fi distrase de elemente precum noile
cerințe ale clientului, preluarea de sarcini în timp ce există altele deja în
desfășurare

 Sinceritatea – membrii echipei Scrum trebuie să fie sinceri cu progresul

sarcinilor lor. Aceștia trebuie să exprime clar dificultățile pe care le
întâmpină, pentru ca restul echipei să îi poată ajuta, dar și invers, să ofere
ajutorul în cazul în care colegii sunt în aceeași situație

 Respectul – echipa Scrum se bazează foarte mult pe colaborare și de aceea este foarte
important ca între participanți să existe respect reciproc. Fiecare parte implicată
trebuie să respecte ideile, munca și realizările celorlalți, pentru că fiecarte dintre ei are
contribuția sa în evoluția proiectului

Oricine lucrează sau coordonează un proiect complex poate beneficia de utilizarea Scrum.
Scrum ajută echipele să prioritizeze liste lungi de îndatoriri în sarcini mici, ușor gestionabile.
Scrum ajută prin îmbunătățirea muncii în echipă, a comunicării și a rezultatelor finale.

Scrum este ușor aplicabil oricărei industrii, pentru că beneficiile sale sunt universale. Scrum
poate fi implementat în orice tip de proiecte, ale companiei sau chiar și de familie, de la
dezvoltarea de aplicații software sau gestionarea logisticii într-un magazin până la
organizarea unui eveniment.

3.2 Organizare
 Click to addBookmark this page
Echipele Scrum lucrează în perioade scurte de timp care pot varia în
durată, de la o săptămână până la o lună. Acestă iterație se
numește sprint. Sprinturile au loc unul după altul, fără pauze, pentru a
menține o cadență constantă a proiectului.  Fiecare sprint începe cu un
plan și se termină cu o revizuire a lucrărilor finalizate și o revizuire
suplimentară a modului în care echipa a lucrat împreună.

În timpul fiecărui sprint, întreaga echipă Scrum lucrează împreună pentru

a finaliza una sau mai multe incrementări ale unui produs sau proiect
general mai mare. Fiecare incrementare finalizată trebuie să fie potențial
livrabilă, ceea ce înseamnă că poate funcționa așa cum este. Pentru ca o
incrementare să fie livrabilă, aceasta trebuie să fie complet testată și
complet aprobată până la sfârșitul sprintului. Alegerea elementelor de
lucru potrivite pentru un sprint este un efort de colaborare între Product
owner, Scrum master și echipa de dezvoltare.

Pentru a asigura o bună desfășurare a activităților dintr-un sprint, trebuie

luate în considerare următoarele sugestii, prezente și în ghidul oficial
Scrum:

- echipa își stabilește și înțelege obiectivul sprintului și modul în care se

va măsura succesul, astfel ca toți membrii să înainteze în aceeași direcție

- anumite sarcini pot fi excluse din sprint, în condițiile în care acestea nu

vor putea fi îndeplinite din cauza dependențelor, cum ar fi munca de la o
altă echipă, design sau acorduri legale

- prioritățile și dependențele trebuie puse în ordine, altfel există șansa ca

proiectul să fie deraiat pentru că echipa poate alege să includă în sprint
sarcini ce au timpi mari de așteptare datorită dependențelor de alte
procese

- trebuie rezervat timp pentru asigurarea calității și lucrări care nu sunt

caracteristice, cum ar fi bug-urile(probleme de logică în software) și
calitatea codului

În timpul sprint-ului:

 Nu se fac modificări care să pună în pericol obiectivul

   Obiectivele de calitate nu scad

 Domeniul de aplicare poate fi clarificat și renegociat între proprietarul

produsului și echipa de dezvoltare, pe măsură ce se dobândesc mai multe
cunoștințe

Fiecare sprint poate fi considerat un proiect cu cel mult un orizont de o

lună. La fel ca proiectele, sprint-urile sunt folosite pentru a realiza ceva.
Fiecare sprint are un obiectiv asupra a ceea ce urmează să fie construit,
un plan de proiectare și flexibilitate care să ghideze construirea acestuia,
lucrările și incrementarea produsului rezultat.

Când orizontul unui sprint este prea lung, definiția a ceea ce este
construit se poate schimba, complexitatea poate crește și riscul poate
crește. Sprinturile permit predictibilitatea asigurând inspecția și adaptarea
progresului către un obiectiv în nu mai mult de o lună. Astfel, și riscurile
sunt limitate ca orizont de timp.

Echipa Scrum este cea care decide lungimea sprintului (Product owner,
Scrum master și echipa de dezvoltare). Scrum master-ul acționează ca un
facilitator pentru a ajuta echipa să ajungă la un consens.

Echipele care sunt noi în implementarea metodologiei Scrum tind să

experimenteze la început cu lungimea sprintului, până când au stabilit un
ritm. Echipa inspectează și se adaptează pe durata sprintului, ajungând
ulterior la un acord privind lungimea acestuia

Scrum folosește echipele multifuncționale, auto-organizate, fiecare dintre

acestea având toate capacitățile necesare pentru a livra o funcționalitate
de la idee până la livrare. Fiecare membru dintr-o echipă Scrum are mai
multe capabilități și o specializare, iar echipa ca întreg poate acoperi toate
activitățile necesare implementării proiectului.

Echipele auto-organizate aleg modul de a-și îndeplini cel mai bine munca, nefiind
direcționate de entități din afara echipei. Echipele de dezvoltare sunt structurate
și împuternicite de companie să organizeze și să gestioneze propria lor muncă.
Nimeni (nici măcar Scrum master-ul) nu spune echipei de dezvoltare cum să își
îndeplinească sarcinile, cine și cum să implementeze funcționalitățile cerute.

La începutul unui proiect Scrum, este recomandată definirea unui contract

social. Desigur, acesta va putea fi adaptat pe parcurs. Un contract social
este un acord conceput de echipă pentru un ansamblu aspirațional de
valori, comportamente și norme sociale. Regulile din contractul social
reprezintă o viziune pentru cum ar fi mediul ideal într-o echipă. Scrum se
bazează pe transparență, din care apoi se poate inspecta și adapta.
Transparența se aplică tuturor aspectelor din Scrum - inclusiv
comportamentului.

Având un contract social în vigoare, oricare membru poate evalua

comportamentul celuilalt și poate atrage atenția acestuia atunci când
consideră că este în contradicție cu ceea ce vizează contractul.
Contractele sociale oferă un mecanism pentru a face acest lucru fără ca
acesta să pară un atac personal. Este foarte important ca întreaga echipa
să fie implicată în definirea acestui tip de contract. De obicei, pe parcurs
apar diferite situații care nu au fost luate în calcul la definirea
contractului, așa că este la fel de important ca acesta să fie revizuit
periodic și actualizat în consecință. Contractul social crează un mediu
sigur pentru membrii echipei.

Studiu de caz
 Click to addBookmark this page
Pentru a înțelege mai bine conceptele Scrum, vom folosi ca exemplu proiectul renovării
bucătăriei într-un apartament. Pe măsură ce vom identifica noi concepte Scrum, vom
introduce detalii în studiul de caz pentru a vedea cum se pliază acestea în proiectul renovării
bucătăriei.

Clientul în acest proiect este proprietarul apartamentului, bucătăria renovată reprezintă

produsul final, iar echipa care va lucra la acest proiect va fi compusă din designer de interior,
electrician, instalator, tâmplar, etc. O parte implicată(stakeholder) în acest proiect poate fi
familia proprietarului, aceștia putând să aibă inițial un cuvânt de spus legat de design, dar și
un feedback pe parcurs legat de rezultatele parțiale. O altă parte implicată, poate fi asociația
de proprietari a blocului, de exemplu în cazul în care renvoarea va include modificări ale
instalației de gaze.

În prima fază, clientul si designerul de interior discută și stabilesc forma produsului final, se
pun de acord asupra materialelor, clientul își exprimă nevoile și dorințele, iar designerul
propune un model care să le satisfacă. Pe măsură ce lucrările avansează, pot apărea situații
neprevăzute (de exemplu nu există pe stoc un anumit tip de gresie pe care clientul o dorește),
care vor fi gestionate pe măsură ce apar. În acest caz modelul stabilit inițial se poate schimba,
cu acordul clientului. Acesta este ținut la curent cu progresul și obstacolele întâmpinate, cu
întârzierile apărute și motivul acestora, putând lua hotărâri legate de soluționarea acestora.

Echipa de lucrări împreună cu designerul de interior vor stabili durata unui sprint, iar clientul
poate aproba sau nu această durata. Pentru acest exemplu vom stabili durata unui sprint la o
săptămână, cu mențiunea că la fiecare final de sprint bucătăria trebuie să fie utilizabilă (un
produs parțial funcțional, chiar dacă nu include toate funcționalitățile încă). Clientul
împreună cu echipa pot stabili o durată estimată a proiectului (de exemplu o lună, 4 sprint-uri
de câte o săptămână), dar e posibil ca acestă durată să fie modifcată pe parcurs. De exemplu,
clientul poate hotărî că dorește și montarea unui sistem pentru colectare selectabilă a
gunoiului sau pot apărea blocaje ce nu depind de echipa de lucrători, iar acestea vor fi
reportate în sprintul 5, de comun acord cu clientul.

Odată începute lucrările, clientul nu se va implica direct în felul cum sunt desfășurate
activitățile. Muncitorii se vor coordona între ei, vor defini sarcini în aria proprie de expertiză,
vor estima efortul și vor decide cum este mai bine să îndeplinească aceste sarcini, fără a
împiedica progresul celuilalt.

Un contract social stabilit de către muncitori poate conține următoarele reguli, dar nu se va
rezuma neapărat la acestea (acesta este doar un exemplu; echipa va stabili aceste reguli de
comun acord):
  Toți membrii echipei se întâlnesc în fiecare zi la ora 8:00 pentru ședința
zilnică

 Dacă un membru al echipei întârzie la ședință, va face cinste cu cafea

 Când un membru al echipei are nevoie de ajutor, ceilalți se vor oferi, chiar
dacă nu este aria lor de expertiză

 Fiecare membru are dreptul de a-și exprima opinia, iar ceilalți îi vor asculta
punctul de vedere

 Toți membrii echipei vor purta echipamentul corespunzător pe durata

lucrărilor

 Vor fi respectate normele de siguranță

4. Roluri in echipa Scrum

4.1 Scrum master
 Click to addBookmark this page

Scrum master-ul este cel care ajută echipa să execute sarcinile la cel mai înalt nivel de
calitate. Tot el este cel care protejează echipa de distrageri ce pot apărea atât din interior cât și
din exterior. Scrum master-ul este în măsură să tragă echipa sau membrii acesteia la
răspundere în legătură cu angajamentele de lucru asumate și respectarea valorilor și a
metodologiei Scrum.
Funcțiile unui Scrum master pot fi rezumate la:
-          Antrenor – facilitează ședințele, discuțiile și propune îmbunătățiri
 -          Protector – acționează ca o interfață între echipă și restul părților implicate, pentru ca
echipa să poată rămâne concentrată
-          Lider care servește echipa – conduce echipa fără a-și impune autoritatea și pune echipa
pe primul loc
-          Avocat Agile – întărește principiile Agile în echipă și în organizație

Scrum master-ul servește echipa de dezvoltare și Product owner-ul în următoarele feluri:

o   Se asigură că obiectivele, domeniul de aplicare și domeniul produsului sunt înțelese

cât mai bine de toți membrii echipei Scrum
o   Găsește tehnici pentru gestionarea eficientă a backlog-ului (lista de sarcini
prevăzute)
o   Ajută echipa să înțeleagă nevoia de sarcini clar definite
o   Se asigură ca Product owner-ul știe cum să prioritizeze lista de sarcini astfel încât
să maximizeze valoarea obținută prin implementare
o   Facilitează ceremoniile Scrum la cerere sau la nevoie
o   Instruiește echipa de dezvoltare în a se coordona singură și încurajează membrii
echipei să își dezvolte abilitățile interdisciplinare
o   Se ocupă de impedimentele ce apar pe parcursul implementării

Caracteristicile ideale ale unui Scrum master sunt:

ü  Umil – recunoaște și scoate în evidență meritele echipei, nu pe cele proprii

ü  Respectuos – este respectuos și are o atitudine pozitivă față de membrii echipei, pe care
îi consideră persoane creative și capabile
ü  Empatic – ascultă și înțelege echipa, chiar și în momentele dificile
ü  Persuasiv – muncește continuu pentru a înlătura obstacolele în cadrul organizației
ü  Conectat – din punct de vedere social, știe sau află cu cine trebuie să discute pentru a
rezolva problemele apărute

4.2 Product owner

 Click to addBookmark this page

Product owner-ul este cel care definește cum va arăta produsul, ce funcționalități va conține.
El este cel care va comunica direct cu părțile implicate, iar prin feedback-ul acestora va hotărî
 care sarcini aduc cea mai mare valoare incrementărilor curente si viitoare. Product owner-ul
este cel care gestionează lista de sarcini(backlog-ul) și se asigură că toată echipa cunoaște
prioritățile.
 
Funcțiile pe care acest rol le acoperă sunt:
-          Vocea clientului – el este cel care reprezintă dorințele și nevoile clientului
-          Comunicator – se ocupă cu adaptarea mesajelor pentru o mare varietate de părți
implicate; comunică pe înțelesul interlocutorilor săi, fie ei clienți, persoane care cunosc
business-ul sau chiar persoane tehnice din echipă
-          Decident – evaluează prioritățile concurente pentru a alege funcționalitățile potrivite și,
eventual, le amână pe restul sau le exclude din sprint; decide frecvența livrărilor

Activitățile întreprinse de product owner pot fi, dar nu se rezumă la:

o   Exprimă clar elementele din backlog

o   Ordonează elementele din backlog pentru a îndeplini cât mai eficient obiectivele
o   Optimizează valoarea muncii echipei de dezvoltare
o   Se asigură că backlog-ul este vizibil, clar pentru toată lumea și că acesta conține
funcționalitățile la care se va lucra în etapele imediat următoare
o   Se asigură că echipa de dezvoltare înțelege funcționalitățile cerute la nivelul necesar
implementării acestora

Caracteristicile ideale ale unui Product owner sunt:

ü  Responsabil – are autoritatea de a lua decizii legate de produs

ü  Cunoscător al business-ului – cunoaște domeniul, procesele, clientul și piața
ü  Persuasiv – lucrează bine cu echipa și cu părțile implicate; își argumentează deciziile
legate de priorități
ü  Informat – cunoaște piața și produsul; înțelege provocările de producție
ü  Disponibil – este ușor accesibil pentru echipă și pentru părțile interesate
4.3 Echipa de dezvoltare
 Click to addBookmark this page

Echipa de dezvoltare este cea care îndeplinește sarcinile de lucru efective. Aceasta decide
cum să realizeze sarcinile propuse de Product owner. Echipa este structurată în
așa fel încât să poată fi responsabilă pentru propria organizare și gestiune a
muncii. Sinergia rezultată optimizează eficiența echipei și eficiența generală în
proiect.
Echipa de dezvoltare este responsabilă să livreze funcționalitățile agreate la
începutul sprint-ului și să păstreze transparența asupra muncii realizate și a
progresului pe parcursul sprint-ului.
Mărimea ideală a unei echipe Scrum este între 3 și 9 persoane, excluzând Scrum
master-ul și Product owner-ul. Dacă echipa ar fi mai mare, comunicarea ar deveni
greoaie.
 
Caracteristicile echipei de dezvoltare sunt următoarele:
o   Auto-organizată – nimeni, nici măcar Scrum master-ul nu le spune mebrilor echipei
cum să își facă treaba
o   Interdisciplinară – abilitățile cumulate ale membrilor echipei formează setul necesar
pentru implementarea funcționalităților și livrarea acestora cu fiecare incrementare de
produs
o   Membrii echipei nu au titluri predefinite, indiferent care este munca pe care aceștia o
îndeplinesc
o   Chiar dacă echipa este formată din persoane cu abilități în domenii diferite, cum ar fi
arhitectură software, testare, dezvoltare, operațiuni, nu există sub-echipe
 o   Deși fiecare membru poate fi specializat într-un anume domeniu, responsabilitatea
aparține echipei de dezvoltare în ansamblu

       

Studiu de caz
 Click to addBookmark this page

Reamintim proiectul renovării bucătăriei într-un apartament.

Clientul în acest proiect este proprietarul apartamentului, bucătăria renovată reprezintă produsul
final, iar echipa care va lucra la acest proiect va fi compusă din designer de interior, electrician,
instalator, tâmplar, etc. O parte implicată(stakeholder) în acest proiect poate fi familia
proprietarului, aceștia putând să aibă inițial un cuvânt de spus legat de design, dar și un feedback pe
parcurs legat de rezultatele parțiale. O altă parte implicată, poate fi asociația de proprietari a
blocului, de exemplu în cazul în care renvoarea va include modificări ale instalației de gaze.

În prima fază, clientul si designerul de interior discută și stabilesc forma produsului final, se pun de
acord asupra materialelor, clientul își exprimă nevoile și dorințele, iar designerul propune un model
care să le satisfacă. Clientul este ținut la curent cu progresul și obstacolele întâmpinate, cu
întârzierile apărute și motivul acestora, putând lua hotărâri legate de soluționarea acestora.

Echipa de lucrări împreună cu designerul de interior vor stabili durata unui sprint, iar clientul poate
aproba sau nu această durata. Pentru acest exemplu vom stabili durata unui sprint la o săptămână,
cu mențiunea că la fiecare final de sprint bucătăria trebuie să fie utilizabilă (un produs parțial
funcțional, chiar dacă nu include toate funcționalitățile încă).

Rolurile în această echipă Scrum pot fi atribuite astfel:

- Șeful se șantier/șeful de lucrări va avea rolul de scrum master. Acesta este cel care
facilitează buna desfășurare a proiectului. Dacă apar conflicte în echipă sau ineficiențe
de comunicare, acesta va interveni și le va propune soluții. În cazul blocajelor care apar,
șeful de lucrări va putea discuta cu echipa pentru a înțelege mai bine obstacolele
întâmpinate și va propune soluții. El este și cel care va gestiona relațiile cu terțe părți,
cum ar fi furnizori de materiale. De asemenea, el va gestiona posibilele conflicte cu
vecinii deranjați de zgomotul amenajărilor, protejând astfel echipa, pentru ca aceasta să
se poată concentra strict la munca pe care o are de îndeplinit.

- Designer-ul de interior va avea rolul de product owner. Acesta se va asigura că înțelege foarte bine
cerințele proprietarului și nevoile acestuia legate de spațiul amenajat. El va păstra mereu legătura cu
clientul, informându-l pe acesta legat de progres, dar și de obstacolele apărute. El este și cel care va
informa echipa legat de cerințele proprietarului, va clarifica orice nelămuriri ale acestora și va stabili
prioritatea lucrărilor. Designer-ul de interior se va asigura că echipa de dezvoltare înțelege foarte bine
ce are de făcut, care este standardul de calitate agreat, care sunt criteriile după care rezultatul va fi
evaluat.

- Echipa de dezvoltare va fi formată din: electrician, instalator, tâmplar, meseriaș-

constructor, meseriaș-zugrav. Aceștia vor colabora pentru a realiza lucrările cerute de
proprietar. Echipa se va coordona pentru a stabili cine, când și de ce anume se ocupă.
Desigur, tâmplarul va trebui să colaboreze cu instalatorul pentru a construi mobila
astfel încât instalațiile de alimentare cu apă/gaz să nu fie afectate. Electricianul va trebui
să colaboreze cu meseriașul constructor și cu zugravul, pentru a realiza circuitul electric
înainte de a fi montate gresia și faianța. Dacă în urma montării întrerupătoarelor și a
corpurilor de iluminat rezultă mici defecte, zugravul le va retușa, etc. Șeful de lucrări nu
va interveni asupra hotărârilor echipei, ci doar îi va ajuta pe aceștia, în caz de nevoie.

În practică, Scrum master-ul poate fi un membru al echipe de dezvoltare, deci în locul unui șef de
lucrări, oricare membru din echipa de dezvoltare își poate asuma acest rol.

5. Ceremonii Scrum
5.1 Sprint planning
 Click to addBookmark this page

După cum sugerează și numele, sprint planning este evenimentul sau ceremonia Scrum în
care se face o planificare a sarcinilor ce vor fi îndeplinite în următoarea iterație. Sarcinile cu
prioritate dorite de client sunt discutate în cadrul acestei ședințe, pentru a stabili obiectivele
sprint-ului. Rolul Scrum master-ului este de facilitator. Product owner-ul descrie obiectivele
sprint-ului și răspunde întrebărilor echipei de dezvoltare. Dacă se determină că anumite
sarcini nu sunt suficient de clar definite pentru a fi implementate, echipa și Product owner-ul
pot hotărî să le excludă din sprint până acestea se vor clarifica. Echipa de dezvoltare poate
pune întrebări legate de execuție și de criteriile de acceptanță pentru fiecare dintre sarcini.
Echipa este cea care are ultimul cuvânt legat de efortul pe care sarcinile îl presupun și ce
anume poate fi realizat pe durata sprint-ului. În final, sunt agreate funcționalitățile ce vor fi
incluse în sprint-ul curent și pe care echipa își asumă responsabilitatea să le implementeze cu
succes. În cele din urmă, planificarea rezultată este o negociere între echipa de dezvoltare și
Product owner, bazată pe valoare și efort.
 
Cine participă la sprint planning?
Întreaga echipă participă la sprint planning: Scrum master, Product owner, echipa de
dezvoltare.
 
Când are loc ședința de sprint planning?
La începutul fiecărui sprint.
 
Cât durează ședința de sprint planning?
În ghidul oficial Scrum este menționat că ședința de planificare a sprint-ului nu trebuie să
depășească 8 ore. Regula generală este de a acorda 2 ore de planificare pentru fiecare
săptămână din sprint. Totuși, pe măsură ce membrii echipei se cunosc mai bine, comunicarea
va fi mai eficientă și timpul ședinței va fi redus.

5.2 Daily Scrum

 Click to addBookmark this page

Daily scrum sau daily standup este ședința zilnică în care echipa de dezvoltare se întâlnește

pentru a evalua progresul către obiectivele sprint-ului. Acestă ședință are scopul de a informa
întreaga echipă asupra desfășurării sarcinilor. Fiecare membru al echipei prezintă sarcina la
care lucrează și descrie cum decurge aceasta, cât timp preconizează că îi rămâne de lucrat pe
acest subiect, dacă se va încadra sau nu în estimări. În plus, sunt puse în evidență blocajele
individuale sau generale care pun în pericol obținerea rezultatelor agreate la sprint planning.
În daily Scrum, fiecare membru poate cere ajutorul echipei atunci când consideră necesar.
Totuși, dacă un membru este blocat, dar nu cere ajutorul echipei, daily Scrum-ul este
oportunitatea perfectă pentru a identifica problemele și, eventual, echipa poate propune soluții
pentru colegul blocat la o sarcină dificilă, iar a doua zi, la următorul daily Scrum, acesta va
descrie progresul obținut (sau noile probleme apărute) în urma aplicării soluțiilor sugerate.
Această ședința oferă echipei ocazia să evalueze și adapteze produsul și/sau procesele pentru
a atinge obiectivul sprint-ului.
 
Cine participă la daily scrum?
Prezența este obligatorie pentru întreaga echipă de dezvoltare. Product owner-ul este invitat,
dar nu trebuie neapărat să participe. Scrum master-ul participă, în general, pentru a se asigura
că echipa înțelege și respectă scopul ședinței, fără a intra în detalii. Pentru echipele mature,
unde practicile Scrum sunt deja bine însușite, Scrum master-ul poate lipsi de la această
ședință.
 
Când are loc daily scrum?
O dată pe zi, de obicei la începutul fiecărei zile.
 
Cât durează daily scrum?
Daily standup este o ședință la care se stă în picioare. Toți participanții se ridică de la birou și
se adună într-un grup, stând în picioare pe toată durata ședinței. Această practică limitează
durata ședinței, astfel ca aceasta să nu ocupe prea mult din timpul efectiv de lucru al echipei
din ziua respectivă. Durata ideală pentru daily scrum este de maxim 15 minute, iar
informațiile trebuie să fie concise, fără a se intra în prea multe detalii. Scrum master-ul este
responsabil pentru ghidarea participanților în a rămâne conciși și a se încadra în timpul alocat.