Perspectiva Agile în dezvoltarea

sistemelor software - I
Introducere
FDD, DSDM, Crystal Clear, Extreme Programming
Valori, Principii, Ciclu de viață, Roluri și responsabilități
Obiectivele afacerii Agile
Valori ale conducerii de tip Agile
Declarația de interdependență
Manifestul Agile
Performanțele dezvoltării Agile
Modelul de management de proiect Agile
faze MPA: Viziune, Speculație, Explorare, Adaptare, Încheiere
Introducere
Ingineria software - aplicarea unei abordări sistematice,
disciplinate și cuantificabile în dezvoltarea, operarea și întreținerea
sistemelor software1
Metodologiile tradiționale (specifice ingineriei software) au succes atunci când2:
 Cerinţele sunt stabile
 Tehnologia este bine cunoscută şi matură
 Totul se întâmplă după aşteptări
 Nu se ia în considerare nimic nou şi/sau necunoscut
 Au mai fost realizate astfel de proiecte

Proiectele cu aceste caracteristici se întâlnesc destul de rar2.

Metodologiile tradiționale sunt potrivite în anumite situații dar presupun costuri

relativ ridicate și utilizarea lor într-un mediu dinamic implică un risc foarte
mare. 2
1. IEEE Standard Computer Dictionary, ISBN 1-55937-079-3, 1990
2. Naresh and Bala, Agile overview. Embrace Uncertainty, http://www.slideshare.net/nashjain/agile-overview
 Introducere

Metodologiile inginerești planifică în

Metdologiile inginerești sunt
detaliu o mare parte a procesului de
rezistente la schimbare
dezvoltare software3

Metodologiile Agile sunt3:

• mai degrabă adaptive decât Metodologiile Agile ”așteaptă
predictive
schimbarea”
• mai degrabă orientate spre oameni
decât spre procese

3. C.N. Bodea, Agile Software Project Management Methodologies, Economy Informatics, 1-4/2005
Introducere
Abordarea Agile a început în 1994 cu câteva încercări ale unor
metodologii semi-formale4:

FDD | Feature Driven Development (Jeff DeLuca)

DSDM | Dynamic System Development Method (Dane Faulkner)
Crystal Clear (Alistair Cockburn)
SCRUM (Ken Schwaber)
XP | Extreme Programming (Kent Beck)
Lean Software Development (Mary Poppendieck)
Adaptive Software Development (Jim Highsmith)

4. C.N. Bodea, Agile Software Project Management Methodologies, Economy Informatics, 1-4/2005
 FDD - Feature Driven Development
Proces pragmatic de dezvoltare software centrat pe client și arhitectură5
Client în FDD  project stakeholders în Agile Modeling (AM)  customer în XP5
Prima utilizare – proiect dezvoltat pentru o bancă din Singapore pe durata a 15
luni, cu o echipă de 50 persoane, în 1997;
a fost urmat imediat de un proiect ce a implicat 250 de persoane pe o durată
de 18 luni5
Funcționalitate (Feature) – oferă valoare pentru client, exprimată sub forma:
<acțiune><rezultat><obiect>5
Exemple de funcționalități:
“Calculează totalul vânzărilor“
“Validează parola pentru un utilizator"
Funcționalități în FDD  cazuri de utilizare in RUP  stories in Scrum5

5. http://www.agilemodeling.com/essays/fdd.htm
 FDD – ciclu de viață

• 75% din efortul depus în

proiectele FDD
• Taskuri:
The FDD project lifecycle6
• modelare detaliată
• implementare
Notă. O descriere detaliată - A Practical Guide to Feature-Driven
Development sau Feature Driven Development
• testare
• packaging
6. http://www.agilemodeling.com/essays/fdd.htm
 FDD – roluri și responsabilități
Rol cheie Responsabilități7

Manager de proiect raportează progresul, administrează buget, spațiu, resurse etc.

Arhitect șef proiectarea arhitecturală a sistemului (abilități tehnice și de modelare foarte

bune, facilitator)
Manager de conducerea activităților zilnice de dezvoltare; rezolvarea conflictelor pentru
dezvoltare resurse

Programatori șefi dezvoltatori cu experiență

• participă la analiza cerințelor și la activitățile de proiectare
• conduc echipe mici – de la 3 la 6 dezvoltatori

Proprietarii claselor membrii echipelor de dezvoltare care proiectează, implementează, testează și

(Class Owners) documentează caracteristicile sistemului

Experți în domeniul • utilizatori, sponsori, analiști ai afacerii sau orice combinație a acestora
produsui • ajută dezvoltatorii să livreze sistemul corect
• abilități de comunicare verbală și prezentare
• cunoștințele și participarea acestora – factori critici ai succesului proiectului

7. http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf
 FDD – roluri și responsabilități
Roluri suport Responsabilități8
Manager lansare se asigură că programatorii șefi raportează progresul săptămânal; raportează
direct managerului de proiect
Programator expert specialist într-un limbaj de programare sau într-o tehnologie specifică; rol
(Language Guru) esențial dacă limbajul sau tehnologia sunt utilizate de dezvoltatori pentru
prima dată
Inginer dezvoltare persoană responsabilă de înființarea, întreținerea și derularea procesului de
dezvoltare
Toolsmith creează mici instrumente de dezvoltare pentru dezvoltatori, testeri etc.
Administrator sistem configurează și administrează rețeaua de calculatoare și serverele necesare
echipei proiectlui
Roluri suplimentare Responsabilități8
Testeri validare și verificare
Deployers convertesc datele existente în noile formate cerute de sistem și lucrează la
plasarea fizică a livrabilelor

Technical Writers pregătesc manualele de utilizare

8. http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf
 Dynamic System Development Method
Framework pentru managementul de proiect de tip Agile9
Creat inițial în 1994 cu participarea unui număr mare de practicieni în domeniul
managementului de proiect din mai multe companii9
Aplicabil pentru un domeniu larg de proiecte – de la proiecte de dimensiuni mici
la proiecte ample
Este eficient și se utilizează ușor la proiecte de dimensiuni mici
Filozofia DSDM:

Cea mai mare valoare a unui produs se obține atunci când când proiectul
este strâns conectat la obiectivele clare ale afacerii, când se fac livrări
frecvente și când implică colaborarea unor oameni motivați și cu putere de
decizie.9

9. http://www.dsdm.org/dig-deeper/book/dsdm-agile-project-framework
 DSDM – principii10
1. Focalizarea pe necesitățile afacerii - se livrează ceea ce cere afacerea respectivă și la
momentul oportun; obiectivele importante şi cerinţele principale trebuie stabilite clar
înainte de a începe proiectul
2. Livrare la timp– factor major al succesului; se pleacă de la premisa că oferirea un produs
”destul de bun” mai devreme este întotdeauna mai indicată decât livrarea unui produs
„perfect” cu întârziere;
3. Colaborare – echipele trebuie să fie extrem de implicate și să colaboreze atât între ele
cât și cu clientul
4. Nu se acceptă compromisuri d.p.d.v. al calității - calitatea produsului livrat trebuie să fie
agreată de la startul proiectului; se urmărește atingerea nivelului de calitate propus - nu
mai mult și nici mai puțin
5. Dezvoltare incrementală – furnizează un anumit nivel de încredere stakeholderilor și o
imagine timpurie asupra beneficiilor produsului
6. Dezvoltare iterativă - se bazează pe feedback-ul de la utilizatori pentru evoluţia către o
soluţie validă
7. Comunicare clară și continuă - practicile DSDM sunt astfel proiectate încât să
îmbunătățească eficiența comunicării între echipe și între membrii echipei
8. Control - poate fi realizat prin raportarea la un plan de lucru, care este în mod clar
aliniat cu obiectivele convenite ale afacerii; este vital să se asigure transparența tuturor
lucrărilor efectuate de către echipă

10. http://www.dsdm.org/dig-deeper/book/dsdm-agile-project-framework
DSDM – ciclul de viață
Se inițiază • Perspectiva tehnică
proiectele • Perspectiva afacerii
corecte? Înțelegerea elementelor de bază (nu
detaliată) ale:
• motivației afacerii
• soluției potențiale
• administrării dezvoltării și livrării

Evoluția către
soluție
Se aduce o soluție de bază în faza
operațională:
• soluția finală
• submulțime a soluției finale

Se verifică gradul de îndeplinire al

obiectivelor afacerii
Ciclul de viață DSDM11

11. http://www.dsdm.org/dig-deeper/book/dsdm-agile-project-framework
 DSDM – Roluri și responsabilități12
• Direcția strategică generală
• Finanțare/buget pentru proiect Administrează mediul de lucru în
care evoluează soluția
Impune direcții de urmat și
viziunea asupra afacerii
Conducerea tehnică

Furnizează un punct de plecare

pentru dezv. soluției sau pentru Facilitează relația dintre rolurile
testarea soluției d.p.d.v. tehnic tehnice și cele ale afacerii

Furnizează un punct de plecare

Impune direcția pentru dezv. soluției sau pentru
afacerii zilnic testarea soluției d.p.d.v. al afacerii

Creează soluția

Realizează testarea în concordanță Lucrează cu echipa la planificarea și

cu strategia agreată coordonarea aspectelor legate de
livrarea produsului la nivel detaliat

Framework-ul DSDM
Administrează workshop-uri

12. http://www.dsdm.org/dig-deeper/book/dsdm-agile-project-framework
 DSDM - Tehnici
Tehnica Descriere
Timeboxing - are la bază împărţirea proiectului în livrabile cu buget fixat şi termen de livrare
fixat;
MoSCoW - metoda reprezintă o manieră de prioritizare a cerinţelor:
MUST – trebuie să aibă cerinţa x pentru a îndeplini necesităţile afacerii;
o
SHOULD – succesul proiectului nu se bazează pe existenţa cerinţei x
COULD – ar putea să aibă cerinţa, dacă aceasta nu afectează nevoile afacerii
o
WOULD – dacă mai este timp disponibil cerinţa x va fi implementată
Prototipul - tehnica se referă la crearea prototipurilor sistemului de la stagiile timpurii ale
proiectului, urmărind descoperirea devreme a deficienţelor din sistem şi permite
utilizatorilor să testeze sistemul
Testarea - este urmărită crearea unei aplicaţii de o bună calitate, aplicaţia fiind testată la
fiecare iteraţie, cu orice metodă de testare la alegere
Workshop-ul - are ca scop atragerea beneficiarilor proiectului la discuţii legate de cerinţe,
funcţionalităţi şi înţelegeri mutuale
Modelarea - folosită pentru a vizualiza reprezentarea aspectelor specifice ale sistemului şi ale
zonei de afaceri ce este dezvoltată
Managementul - o bună implementare a acestuia este importantă pentru natura dinamică a
configuraţiei sistemului, pentru controlul strict al realizărilor din cadrul proiectului
Crystal Clear
Metodologie AGILE (Alistair Cockburn)
Pune accentul pe oameni (procesele sunt pe locul doi), interacţiunile dintre
aceştia, abilităţile şi comunicarea dintre ei - aceşti factori au cel mai mare
impact asupra performanţei muncii depuse13
Fiecare echipă are un set diferit de abilităţi  fiecare echipă ar trebui sa
urmeze o secvenţă de procese proprie, mulată pe nevoile acesteia
”Crystal Clear” - asemănarea dintre o echipă şi diferitele faţete ale unei
pietre preţioase13
Interiorul (nucleul) reprezintă valorile şi principiile
Exteriorul (faţetele) reprezintă fiecare câte un set de elemente precum
tehnici, roluri, utilitare şi politici

13. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii
Livrarea frecventă14
Cel mai important aspect al oricărui proiect este livrarea de cod funcţional, testat,
către utilizatori, o dată la câteva luni
Sponsorii primesc informaţii despre progresul echipei
Utilizatorii au şansa să descopere dacă cerinţele lor iniţiale sunt formulate corect
Dezvoltatorii îşi păstrează concentrarea, eliminând factori care ar putea cauza nelămuriri
Echipa reuşeşte să îşi analizeze propriul progres şi metodele de livrare

Studiile conduse de Cockburn arată că perioada de livrare optimă este cuprinsă

între 2 şi 4 luni
Programatorii web ar putea face acest lucru săptămânal

Comunitatea de utilizatori poate fi deranjată de livrări prea dese, iar dacă acest
lucru este făcut prea rar, pot apărea probleme la integrare
Este propusă soluţia găsirii a cel puţin unui utilizator care vrea să testeze produsul, fie din
politeţe, fie din curiozitate, iar produsul să fie instalat pe staţia lui de lucru  este primit
feedback eficient de la măcar un utilizator

14. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii
Îmbunătăţirea prin reflectare15
Un proiect îşi poate schimba radical cursul, de la un eşec de mari proporţii la
succes, dacă echipa se întâlneşte, discută ce ar trebui făcut în punctul în care se
află şi, mai important, dacă va face acele schimbări la următoarea iteraţie.
O pauză de la dezvoltarea produsului şi reflectarea asupra ce ar putea să meargă
mai bine este foarte eficientă.
Sunt cazuri de proiecte care încep dezastruos, care pe lângă depăşirea timpului
alocat pentru o iteraţie, au şi design-ul total greşit, în care reflectarea asupra ce
nu a mers şi de ce nu a mers a salvat întregul proiect.

15. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii
Comunicarea osmotică16
Membrii echipei pot obţine informaţii utile de la colegii lor auzind conversaţiile
dintre aceştia; acest lucru are de obicei loc atunci când toţi membrii unei echipe
împart aceeaşi încăpere.
Când cineva pune o întrebare, unii pot reacţiona intrând sau nu în conversaţie.
Atunci când echipa se pretează la acest tip de comunicare, întrebările şi răspunsurile au un
demers natural, nederanjându-i prea mult pe membrii echipei.
Acest tip de comunicare este aplicabil în special echipelor cu un număr redus de
membri.
Există situaţii în care echipa este împărţită în mai multe camere adiacente şi sunt
folosite o reţea internă, webcam-uri şi sesiuni de chat pentru a schimba păreri sau
bucăţi de cod.
Această metodă nu poate înlocui punerea echipei în aceeaşi cameră.
Neajunsuri:
Zgomot şi un număr foarte mare de întrebări direcţionate către cel mai experimentat
membru al echipei.
Poziţionarea membrului expert într-o cameră separată nu este nici ea favorabilă, pentru că atunci
membrii începători nu au şansa să se dezvolte cum trebuie şi fac greşeli care rămân necorectate.
Soluţie: poziţionarea expertului în aceeaşi cameră, eventual la mijloc.
Pentru a evita supraîncărcarea acestuia, se foloseşte o tehnică denumită „Conul Tăcerii”, în
care liderul îşi alege un interval orar în care nu poate fi deranjat.
16. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii
Siguranţa personală 17
Capacitatea de a spune când ceva deranjează:
informarea managerului că orarul nu este realistic;
informarea unui coleg că design-ul său necesită îmbunătăţiri etc.
Siguranţa personală e importantă pentru că atunci când echipa e capabilă să îşi
descopere slăbiciunile, e capabilă să le şi repare.
Siguranţa personală este primul pas către încredere.
Pentru a exista încredere între membrii echipei, trebuie în primul rând să existe
sinceritate, aceştia trebuind să fie capabili să îşi recunoască greşelile, ignoranţa,
sau lipsa de expertiză pe care o au pentru o anumită sarcină.
Siguranţa personală merge mână în mână cu capacitatea de a-i asculta pe ceilalţi.
Această capacitate nu trebuie confundată cu politeţea
Unele echipe pot părea amiabile, însă membrii pot fi doar politicoşi pentru că nu sunt
dispuşi să îşi spună părerea

17. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii
Concentrarea 18
Presupune mai întâi cunoaşterea obiectului muncii şi mai apoi găsirea timpului
necesar şi a gândirii limpezi pentru a lucra.
Aceste lucruri presupun existenţa unui mediu unde oamenii nu sunt întrerupţi de
la sarcina lor curentă pentru a lucra la altele, cu care pot fi incompatibili.
Oamenii care sunt puşi să lucreze la două sau trei proiecte deodată de multe
ori raportează că nu au fost capabili să progreseze la nici unul din ele.
Soluţia este simplă: stabilirea priorităţilor pe care le are fiecare membru în parte.
Pe lângă prioritizare, trebuie adoptate anumite convenţii care să poată diminua
întreruperile.
O greşeală des întâlnită este alocarea a 2-3 ore pentru întreruperi, sau crearea
unei reguli de genul “doar dimineaţa”.
Este normal ca întreruperile să apară şi unele din ele pot avea o prioritate destul
de mare. De aceea, un mod mai eficient este acela de a crea o fereastră de circa 2
ore în care întreruperile sunt blocate.
Unele echipe aleg intervalul 10-12.

18. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii
Accesul uşor la utilizatorii experţi – avantaje19:
un loc unde pot testa diferitele livrabile;
feedback rapid asupra calităţii;
feedback rapid asupra design-ului;
actualizare rapidă a cerinţelor.

Un alt factor important este durata de timp în care este dat un răspuns.
Dacă, de exemplu, nu este primit un răspuns în 3 zile, programatorii vor fi tentaţi să
implementeze ghicind soluţia şi vor uita să o pună pe listă pentru a fi revizuită mai
târziu.
Cele mai răspândite metode de comunicare cu utilizatorii sunt următoarele:
întâlniri săptămânale sau de două ori pe săptămână, cu posibilitatea de contact
telefonic;
unul sau mai mulţi utilizatori experimentaţi implicaţi direct în echipă: acest caz este
rareori posibil, dar este întâlnit;
trimiterea dezvoltatorilor să fie antrenaţi ca utilizatori: deşi sună ciudat, unele echipe
de dezvoltare îşi trimit membrii pentru a ocupa rolul de utilizator.
19. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Principii

Mediu de lucru tehnic, cu teste automate, management al configuraţiei şi

integrare frecventă20
Testarea automată este din ce în ce mai extinsă, datorită faptului că oferă o
anumită simplitate şi siguranţă.
Sistemul de management al configuraţiei permite:
verificarea produsului;
folosirea unei anumite configuraţii pentru lansare;
revenirea la această configuraţie atunci când apar probleme.
De asemenea, cu cât integrarea sistemului este făcută mai des, cu atât sunt
detectate mai repede erorile.

20. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Strategii
Explorarea 360o 21
La începutul unui nou proiect, echipa are nevoie să stabilească dacă proiectul are sens şi
dacă îl poate livra folosind tehnologia pe care intenţionează să o folosească. Examinarea
se face în toate direcţiile (360o) după următoarele aspecte:
Valoarea afacerii - depistarea, împreună cu principalii stakeholderi, a ceea ce ar
trebui să ofere sistemul utilizatorilor şi organizaţiilor pentru care e destinat.
Aceasta rezultă în numirea unor use-case-uri cheie pentru proiect, împreună cu aflarea unor funcţii
importante pe care sistemul va trebui să fie capabil să le aibă.
Detectarea cerinţelor - se referă la crearea de use-case-uri care arată ce trebuie să
facă sistemul şi cu ce persoane şi sisteme va trebui să interacţioneze.
Modelul de domeniu - ajută la plasarea proiectului într-o anumită categorie, la aflarea
conceptelor cheie cu care va trebui lucrat, la metoda de dezvoltare etc.
Planurile referitoare la tehnologie - sunt create testând anumite tehnologii şi făcând
anumite experimente pentru a vedea dacă tehnologiile care sunt implicate pot fi
conectate sau dacă dezvoltatorii sunt capabili de a lucra cu ele.
Planul proiectului - echipa creează un plan al proiectului, folosind tehnica ”blitz-
planning (va fi explicată ulterior).
Alcătuirea echipei
Metodologii şi convenţii de lucru
21. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Strategii
Victoria timpurie22
La proiectele software, o victorie timpurie ar fi o primă bucată de cod testat care
rulează aşa cum trebuie.
Echipele dezbat modul în care să abordeze o anumită problemă:
Worst Thing First (Ce e mai rău prima dată) - motivul este că odată ce partea cea mai
grea a fost terminată, restul va fi mai uşor.
Neajunsul acestei metode e atunci când echipa nu reuşeşte să implementeze ce trebuie şi nu se ştie exact
unde stă greşeala apar următoarele întrebări: echipa nu e competentă, tehnologia nu e compatibilă sau
tot procesul pe care l-au gândit e greşit?
Easiest Thing First, Hardest Second (Ce e mai uşor prima dată, iar a doua oară ce e
mai greu) – este o abordare mai bună decât precedenta deoarece membrii echipei
reuşesc să se acomodeze unul cu altul şi să comunice între dânşii pentru a
implementa o funcţionalitate simplă;
Mai mult, şi sponsorul are încredere în echipă. Dacă liderul de echipă consideră că lucrul cel mai greu de
implementat este încă prea avansat pentru echipă în acel moment, acesta caută lucrul cel mai uşor care
poate fi implementat.
Highest Business Value First (Cea mai mare valoare pentru afacere la început) – este
dezvoltată mai întâi componenta cu cea mai mare valoare pentru afacere,
demonstrând că echipa nu generează doar ore de lucru, ci şi profit maxim.
Aceasta va asigura sponsorii că nu au investit greşit.

22. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Strategii
Schelet funcţional23
Un schelet funcţional este o implementare de bază a sistemului care are o
funcţionalitate simplă, dar care leagă împreună toate componentele principale.
Arhitectura şi funcţionalitatea pot mai apoi să evolueze în paralel.
Un schelet funcţional nu este complet şi nici robust.
El doar funcţionează şi nu are decât puţin din funcţionalitatea aplicaţiei care trebuie dezvoltată.
Incremental, în timp, această infrastructură va fi completată şi vor fi adăugate elemente pentru a
se ajunge la un model cu funcţionalitate completă

Arhitectura incrementală23
Echipa îmbunătăţeşte arhitectura pe etape, menţinând sistemul funcţional în acest
timp.
Avantaje:
arhitectura este uşor de modificat atunci când este cazul;
dezvoltarea funcţionalităţii şi a infrastructurii pot merge în paralel;
utilizatorii sunt capabili să vadă funcţionalitatea sistemului din momentele incipiente;
sistemul în fază incipientă poate fi folosit pentru detectarea anumitor greşeli care nu au fost
prevăzute în planul iniţial;
sistemul funcţional poate fi lansat pe o piaţă limitată la început şi poate începe să aducă venit
care poate ajuta la restul dezvoltării.
23. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Strategii
Monitoare de performanţă24
Afişaj plasat într-un loc vizibil tuturor membrilor echipei care marchează informaţii
importante despre funcţionarea sistemului și care:
să fie destul de mare şi uşor de observat;
să fie explicit;
să permită actualizarea periodică a informațiilor .
Un monitor de performanţă este reprezentat fie pe hârtie, fie pe un site web pe care
membrii echipei intră frecvent.
Sunt cazuri în care monitorul de performanţă este un monitor de calculator atârnat pe
perete în hol sau un semafor.
Aceste monitoare sunt folosite pentru a informa de obicei pe cei care lucrează în afara
echipei proiectului, deoarece cei din urmă ştiu aproape toate datele necesare, însă cei
din afară au nevoie de informaţii pentru a lua propriile decizii.
Astfel, nu e nevoie să întrerupă pe cineva din echipă sau să meargă pe presupuneri.
Informaţiile de pe monitoarele de performanţă pot fi: use-case-uri, numărul de teste
scrise (sau trecute), numărul de use-case-uri acoperite, statutul server-elor cheie,
rezultatele ultimei şedinţe de reflectare asupra proiectului, modul curent de împărţire a
sarcinilor.

24. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Strategii
Formarea metodologiei25
Se ocupă de stabilirea metodologiei de start, în doi paşi:
Interviuri - duc la formarea unei mici biblioteci care arată punctele forte şi punctele
slabe ale organizaţiei (un fel de analiză SWOT);
Atelier de formare a metodologiei - se examinează datele din prima etapă şi se discută
cum se pot pune în evidenţă şi folosi punctele forte şi cum se pot compensa (sau
ocoli) punctele mai puţin favorabile.

Atelier de reflectare25
Echipa trebuie să facă o pauză de o oră periodic pentru a discuta ce merge cum
trebuie, ce are nevoie de îmbunătăţiri şi ce vor face diferit în perioada care urmează.
Estimare Delphi folosind rangurile de expertiză25
O problemă a oricărui proiect este estimarea timpului necesar dezvoltării lui. Un
exemplu de estimare presupune împărţirea în patru faze:
estimarea mărimii sistemului;
estimarea timpului de lucru în concordanţă cu tipul de membru de care este nevoie;
sugerarea incrementelor, în funcţie de dependenţe (tehnice, venit etc.);
balansarea incrementelor astfel încât să aibă dimensiuni similare.

25. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
Crystal Clear - Strategii
Blitz Planning26
Această tehnică a pornit de la aşa numitul
„planning game” din Extreme Programming.
În această tehnică, persoanele participante pun
carduri (bilete) care reprezintă câte un user story
pe masă.
Grupul pretinde mai apoi că nu există nicio
dependenţă între ele şi le aliniază în ordinea
preferată de dezvoltare.
Apoi dezvoltatorii scriu pe fiecare card un timp
estimat care reprezintă cât le va lua să
implementeze acea funcţionalitate, iar sponsorul
(sau un expert) le pune în ordinea priorităţilor,
luând în calcul timpul necesar dezvoltării şi
valoarea pe care o reprezintă pentru afacere.
Aceste carduri sunt dezvoltate ca iteraţii, iar
iteraţiile în livrabile Sursa - 26

26. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
 Crystal Clear - Strategii
Design de interacţionare27 - studiu al dispozitivelor folosite de utilizator
Acesta defineşte comportamentul dispozitivului în diferite cazuri. Un sistem poate avea mai
multe aşa-numite personalităţi. Poate fi rapid şi eficient, sau prietenos şi informativ. Aceste
personalităţi sunt alese în funcţie de utilizatorul principal care va folosi produsul.
Daily Stand-Up27
O întâlnire de acest tip este scurtă şi este folosită pentru a face schimb de notiţe cu privire la
statusul, progresul şi problemele care apar; nu are ca scop discutarea problemelor, ci doar
identificarea lor
La ce am lucrat ieri? La ce plănuiesc să lucrez azi? Ce îmi stă în cale?
Miniatura procesului27
Un nou tip de proces este greu de înţeles. Cu cât o etapă durează mai mult, cu atât poate deveni
mai confuză, de aceea trebuie explicate bazele şi grăbite lucrurile, pentru a simula un demers
real, cu o anume finalitate.
Programare „side - by – side” 27 – doi oameni sunt puşi unul lângă celălalt, dar are fiecare staţia
sa de lucru şi propria sarcină.
Astfel, pot să lucreze separat, dar pot să îşi ceară părerea unul altuia în legătură cu o porţiune de
cod, un test-case etc.
Burn charts27
Burn chart-ul este o reprezentare grafică a lucrului rămas de făcut versus timp. Este o metodă
pentru estimarea timpului necesar pentru terminarea unui proiect.

27. A. Cockburn, Crystal Clear. A Human-Powered Methodology for Small Teams, Addison Wesley, 2004
 eXtreme Programming
Extreme Programming (XP, programare extremă - Jon Jeffries şi Kent Beck ) este o
metodologie de dezvoltare Agile, inspirată din RUP, dar care propune rezolvări
originale problemelor care apar în dezvoltarea de programe28.

Carta drepturilor dezvoltatorului28 Carta drepturilor clientului28

 Ai dreptul să ştii ceea ce se cere, prin
cerinţe clare, cu declaraţii clare de
prioritate.
 Ai dreptul să spui cât îţi va lua să
implementezi fiecare cerinţă şi să îţi
revizuieşti estimările în funcţie de
experienţă.
 Ai dreptul să preiei responsabilităţile, în
loc ca acestea să-ţi fie asignate.
 Ai dreptul să produci muncă de calitate
în orice moment.
 Ai dreptul la linişte, distracţie şi la muncă
productivă şi plăcută.
 Ai dreptul la un plan general, să ştii ce poate
fi făcut, când, şi la ce preţ.
 Ai dreptul să vezi progresul într-un sistem
care rulează şi care se dovedeşte că
funcţionează trecând teste repetabile pe care
tu le specifici.
 Ai dreptul să te răzgândeşti, să înlocuieşti
funcţionalităţi şi să schimbi priorităţile.
 Ai dreptul să fii informat de schimbările în
estimări, suficient de devreme pentru a
putea reduce cerinţele astfel ca munca să se
termine la data prestabilită. Poţi chiar să te
opreşti la un moment dat şi să rămâi cu un
sistem folositor care să reflecte investiţia
până la acea dată.

28. Kent Beck, Extreme Programming Explained, Addison Wesley, 1999

XP – Principii29
Planificarea incrementală. Cerinţele sunt înregistrate pe card-uri iar scenariile ce
trebuie incluse într-o lansare sunt determinate de timpul disponibil şi de prioritatea lor
relativă. Dezvoltatorii împart aceste scenarii în sarcini (taskuri) de dezvoltare.
Lansări mici. Mai întâi se dezvoltă un set util minimal de funcţionalitate care oferă
valoare economică. Lansările sistemului sunt frecvente şi adaugă funcţionalitate primei
lansări.
Proiectare simplă. Este realizată suficientă proiectare, dar nu mai mult, astfel încât să
fie îndeplinite cerinţele curente.
Programarea în pereche. Dezvoltatorii lucrează în perechi, verificându-se reciproc.
Echipele se schimbă la sfârşitul fiecărei iteraţii (în general după 1-2 săptămâni).
Dezvoltarea mai întâi a testelor. Testele se dezvoltă de la început, incremental, pe baza
scenariilor.
Utilizatorul este implicat direct în dezvoltarea şi validarea testelor şi se utilizează un cadru
automat pentru testarea unităţilor.
Se scriu teste pentru noi funcţionalităţi înainte ca acestea să fie implementate.
Toate testele anterioare şi testele noi sunt executate automat atunci când se adaugă o nouă
funcţionalitate, verificându-se astfel faptul că funcţionalitatea nouă nu a introdus erori.
29. Kent Beck, Extreme Programming Explained, Addison Wesley, 1999
XP – Principii30
Programare simplă. Codul se scrie cât mai simplu şi se optimizează de câte ori e posibil.
Proprietatea colectivă. Perechile de dezvoltatori lucrează în toate zonele sistemului,
astfel încât nu se creează insule de expertiză; toţi dezvoltatorii sunt proprietarii
întregului cod şi „oricine poate schimba orice”.
Integrare continuă. Îndată ce lucrul la un task este finalizat, are loc integrarea sa în
întregul sistem. După fiecare astfel de integrare trebuie trecute toate testele unităţilor
sistemului. Modificările aduse codului se integrează de asemenea continuu (de câteva
ori pe zi).
Ritm susţinut. Nu se lucrează ore suplimentare deoarece efectul ar fi reducerea calităţii
codului şi a productivităţii pe termen mediu.
Prezenţa continuă a clientului. Un reprezentant al utilizatorului final al sistemului
trebuie să fie permanent la dispoziţia echipei. Într-un proces de programare extremă
clientul este membru al echipei de dezvoltare şi este responsabil cu transmiterea
cerinţelor sistem către echipă pentru a fi implementate

30. Kent Beck, Extreme Programming Explained, Addison Wesley, 1999

XP - Ciclul de viață $
Plan Analysis Design Design Test Deploy
3-24 months

Modelul în cascadă
$ $ $
Analysi

Analysi

Analysi
Deploy

Deploy

Deploy
Design

Design

Design
Code

Code

Code
Paln

Plan

Plan
Test

Test

Test
s

s
1-3 months 1-3 months 1-3 months
Model iterativ
$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $
Iteration
Iteration
Iteration
Iteration
Iteration

.....

Analysis
Deploy

Design $ - livrare potențială

Code
Plan

Test
Ciclul de viață XP31
1 week

31. J. Shore, S. Warden, The Art of Agile Development, O’Reilly Media, Inc., 2008
 XP- Roluri și responsabilități
Rol32
Echipa (ca întreg)
Reprezentantul clientului
în echipă
(On-site customers)
Manager produs
Experți în domeniu
Proiectanți UI
Analiști afacere
32. J. Shore, S. Warden, The Art of Agile Development, O’Reilly Media, Inc., 2008
Responsabilități32
Stă împreună într-un spațiu de lucru deschis; auto-organizată;
ședințe de planidicare a iterațiior, de demonstrare a rezultatelor,
retrospective - 2-4 ore; întâlniri zilnice (daily stand-up meetings) - 5-10
minute fiecare
Definirea a ceea ce trebuie să dezvolte echipa; planificare livrări;
identificare funcționalități și story-uri; stabilește modul de grupare a
funcționalităților în livrări mici, frecvente; identifică și administrează riscuri
Menține și promovează viziunea produsului; documentează viziunea, o
împărtășește cu părțile interesate, încorporează feedback, generează
funcționalități și stories, stabilește priorități pentru planificarea lansării,
analizează lucrările în desfășurare
Responsabil de găsirea tuturor detaliilor din regulile și cunoștințele
domeniului
Definirea interfeței utilizator
Clarificarea și rafinarea nevoilor clienților; analistul o face și în sprijinul
celorlalți clienți locali (on-site customers)
 XP- Roluri și responsabilități
Rol33 Responsabilități33
Programatori Contribuie direct la crearea codului: scriu teste, implementează cod,
refactorizează și proiectează incremental aplicația
Proiectanți și arhitecți Ghidarea eforturilor de proiectare incrementală; ajută echipa să realizeze o
arhitectură cât mai simplă
Specialiști tehnici Proiectanți baze de date, experți securitate, arhitecți rețele
Testeri Ajută echipele XP să producă soft de calitate de la început; unele echipe nu
au testeri dedicați
Antrenori Se asigură că echipa include persoanelepotrivite ; ajută echipa să
interacționeze cu restul organizației;
Antrenor-programator Ajută alți programatori să deprindă practicile XP; în general sunt
programatori cu mare experiență
Manager proiect Ajută echipa să lucreze cu restul organizației; abilități în practicile care nu
se referă la programare

33. J. Shore, S. Warden, The Art of Agile Development, O’Reilly Media, Inc., 2008