Referat

1. UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞI
FACULTATEA DE ECONOMIE ŞI ADMINISTRAREA AFACERILOR
Metodologia XP
(eXtreme Programming)
Iaşi,
2013

2. 1
Cuprins
1. eXtreme Programming – o metodologie agilă
2. Necesitatea implementării Extreme Programming
3. Valorile eXtreme Programming-ului
4. Reguli & bune practici
5. O zi din viaț a unui programator XP
6. Implementări XP de succes
7. Avantaje ș i dezavantaje ale Extreme Programming

3. 2
1. eXtreme Programming – o metodologie agilă
Extreme Programming este atât un proces de dezvoltare cât ș i o metodologie. Un
proces (al dezvoltarii software) defineș te cine face, ce face ș i când face. Asta înseamnă că
furnizează principii, tehnici ș i practici pentru o dezvoltare eficientă, predictibilă ș i
repetitivă pentru aplicaț ii.1
Astfel un proces deserveș te drept ș ablon pentru crearea
proiectelor. Extreme Programming este de asemenea un suport pentru procese pentru că poate
fi (ș i mai mult ca sigur va fi) modelat pentru nevoile specifice ale echipelor, proiectelor ș i
companiilor. Extreme Programming este o metodologie foarte clară, specifică fiindu-i
productivitatea ș i toleranț a ridicată. Comunicarea este de obicei bine închegată, de obicei
informală (nedocumentată). Extreme Programming este aplicat doar problemelor din afaceri,
de exemplu proiect cu un client extern care necesită crearea unui produs specific. Aceste
proiecte au o durează între 6 ș i 15 luni de zile. Extreme Programming este folosit de echipe
mici formate din 2 până la 12 membri.
Extreme Programming are la bază următoarele valori:
• Oamenii ș i interacț iunea lor în locul proceselor ș i utilitarelor
• Software funcț ionabl în defavoarea documentaț iilor “stufoase”
• Colaborarea cu clientul pusă înaintea negocierii contractului
• Răspunderea la schimbare înaintea urmării unui plan.
Agile descrie o serie de metodologii. Cele mai importante ș i adaptate metodologii agile
sunt2
:
- Scrum de Ken Schwaber and Jeff Sutherland
- eXtreme Programming(XP) de Kent Beck,Ward Cunningham,Ron Jeffries
- CrystalMethods de Alistair Cockburn
- Feature Driven Development de Jeff DeLuca
- Dynamic Systems Development Method de DSDM Consortium
- Lean Systems and Software de Lean Systems & Software Consortium
1
http://www.ac.tuiasi.ro/upload_year/software%20engineering.pdf , accesat la data de 25.04.2013;
2
Metodologii „Agile”, http://gurtejpsingh.wordpress.com/2013/03/26/what-is-agile-its-characteristics-and-
most-famous-adapted-agile-methodologies-are/ , accesat la data de 7.05.2013

4. 3
Fig.1 Metodologii „Agile”
Din graficul de mai sus reiese că Extreme Programming este o metodologie folosită,
însă nu la fel de populară precum “rivala” SCRUM. Se observă că un hibrid între SCRUM ș i
XP este folosit fiind a 2-a metodologie pentru crearea de software. XP împărtăș eș te valorile
scoase în evidenț ă de Agile Manifesto ș i merge mai departe specificând seturi simple de
practici. În timp ce multe metodologii populare încearcă să răspundă la întrebarea “De care
practici avem nevoie pentru a dezvolta software?” XP doar răspunde “Care este setul
minimalist de practici de care aș putea avea nevoie ș i de ce am nevoie pentru a-mi limita
nevoile la acele practici?”.
Diferenț a dintre cele două întrebări nu poate fi subestimată. Cea mai frecventă critică
adusă XP este că este prea simplă pentru a funcț iona cu un set foarte limitat de criterii ale
unui proiect. Însă succesele înregistrate prin folosirea XP continuă să facă spaț iu pentru
implementarea sa3
.
Pentru mulț i XP este un set de 13 practici de dezvoltare a software-ului. Folosite
împreună aceste practici, au avut parte de mult succes, iniț ial la echipele mici, care au lucrat
la proiecte unde cerinț ele se schimbă des.
3
http://its.lnpu.edu.ua/edocs1/new_doc/en/Marchesi%20M.Extreme%20programming%20perspectives.2002.
pdf , accesat la data de 24.04.2013

5. 4
Ce este Extreme Programming?
XP reprezintă o metodologie pentru dezvoltarea de software ce se bazează pe valorile,
simplităț ii, comunicării, feedback-ului ș i curajului. Ea funcț ionează aducând împreună
toată echipa pentru a urma un set de practici simple, cu suficient feedback pentru ca echipa să
înț eleagă în ce stadiu se află ș i totodată să îș i îmbunătăț ească aceste practici în
conformitate cu stadiul în care se află4
.
În proiectele pentru care se aplică XP fiecare contribuitor pentru proiect este membru
al “întregii echipe”, o singură echipa de business/dezvoltare/testare care se ocupă de toate
aspectele creării software-ului. Central poziț ionat faț ă de această echipă se află clientul,
unul sau mai mulț i reprezentanț i ai afacerii care stau cu echipa ș i lucrează zilnic cu ea.
Echipele XP folosesc o formă simplă de planificare ș i urmărire a rezultatelor pentru a
se decide care e pasul următor ș i pentru a prezice când o nouă îmbunătăț ire va fi livrată.
Aceste echipe se focusează pe valoarea afacerii, echipa produce software-ul într-un set de
versiuni integrate ce trec orice test impus de către client5
.
Echipele XP sunt constituite din câte doi sau grupuri, cu design-uri simple, cod test
obsesiv, îmbunătăț ind mereu design-ul pentru a-l avea gata pentru nevoile curente.
Echipa XP ț ine sistemul integrat ș i gata de rulare mereu. Programatorii scriu codul
pentru aplicaț ie în perechi ș i toț i lucrează împreună mereu. Ei codează folosind un stil
consistent pentru ca toată lumea să poate înț elege ș i îmbunătăț i codul după cum se
doreș te.
Echipa XP împărtăș eș te o imagine simplă ș i comună asupra a felului în care
sistemul arată. Toată lumea lucrează într-un ritm care poate fi susț inut.
2. Necesitatea implementării XP
Abordarea clasică a deszvoltării de software întâmpină un set clasic de probleme:
• Nerespectarea termenilor de implementare
• Neînț elegerea cerinț elor afacerii
• Abaterea de la procese (defect rate)
4
Extreme programming, http://www.extremeprogramming.org/ , accesat la data de 15.04.2013
5
http://software2012team23.googlecode.com/git-
history/5127389d21813c2bd955c53999f66cede994578b/docs/literature/Extreme_Programming_Explained_K
ent_Beck_1999.pdf , accesat la data de 18.04.2013

6. 5
• Management
• Motivaț ia programatorilor
Aceste probleme au devenit critice în anumite domenii de dezvoltare software. De
exemplu, un proiect de afaceri care are ca scop capturarea unei noi niș e de piaț ă utilizând o
tehnologie nouă. Provocarea poate fi foarte mare în aceste scenarii, iar orice întârziere a
lansării produsului poate fi fatală. Extreme programming este destinat pentru a rezolva
acestea, si alte câteva probleme ”clasice” de dezvoltare a software-ului. Este bine de înteles,
totuș i, că problemele sunt legate foarte strâns ș i de aceea sunt necesare soluț ii complxe.
Nerespectarea termenilor de implementare: Acestea sunt problemele cel mai des
întâlnite în proiectele software. De obicei, cauzele apariț iei problemelor sunt schimbări ale
cerinț elor ș i subestimarea scopului proiectului. Soluț ie XP: Unul dintre principiile XP sunt
iteraț iile scurte. Ajută la respectarea termenilor stabiliț i ș i menț ine proiectul pregătit
pentru schimbarea cerinț elor.6
Neînț elegerea cerinț elor afacerii: De cele mai mult ori, clientul nu reuș este să
exprime clar cerinț ele în termeni tehnici. O metodă des întalnită este aceea de a discuta cu
cu programatorii doar începutul ș i sfârș itul ciclului de viaț ă a proectului. Adesea, acest
lucru generează probleme serioase iar afacerea primeș te un produc de care nu are nevoie.
Soluț ie XP: Permite clientului(afacerii) să fie o parte din echipa de proiect. Clienț ii ar
trebui să fie mereu la dispoziț ia programatorilor ș i vice versa. Mici comunicate (small
releases) permit afacerii să înteleagă direcț ia proiectul ș i să îl corecteze pe parcurs dacă este
necesar.
Abaterea de la procese (defect rate): Sunt multe probleme care pot împiedica
finalizarea unui proiect. De obicei, cauza abaterii de la procese o reprezintă forț area
programatorilor de a lucra mai repede (de exemplu când este stabilit programul de lucru). În
acest caz viteza de lucru este pusă în faț a calităț ii. Este cel mai rău lucru pe care îl pot face
managerii deoarece rezolvarea bug-urilor necesită mult mai mult timp. Soluț ie XP:
Dezvoltarea testdriven ș i testarea continuă. Testarea trebuie să fie o parte esenț ială a
proiectului.
Management: Uneori costurile de administrare se suprapun costurilor de dezvoltare.
Unul dintre cele mai importante lucruri în proiectele software este managementul eficient ș i
ieftin. Soluț ie XP: Extreme programming sugerează munca în echipă ș i totaț ia
persoanelor. Astfel persoanele vor avea o viziune comună a proiectului la care lucrează.
6
http://andrei.clubcisco.ro/cursuri/f/f-sym/4mps/elearn/37%20Programarea%20extrema%20(XP%20-
%20eXtreme%20Programming).pdf , accesat la data de 28.04.2013

7. 6
Motivaț ia programatorilor: Este o sarcină foarte dificilă ș i nu este neclară. Soluț ia
XP: Extreme Programming încearcă să împace productivitatea cu partea umană. Xp-ul este
pe placul utilizatorilor deoarece încurajează comunicarea, cross traning-ul, rotaț ia
personalului etc.7
2. Extreme programming – valori
Extreme Programming este recunoscut pentru cinci mari valori 8
:
Valori Descriere
Comunicarea
- este un proces prin care informaţia este interschimbată între indivizi,
comunicând faţă în faţă, zilnic, in toate fazele proiectului.Trebuie să fie
bidirecţională, informaţiile trebuie să fie atât dobândite cât şi furnizate,
între toate persoanele participante la proiect (dezvoltatori, acţionari,
beneficiari), reprezintă un criteriu important pentru succesul în dezvoltare.
Simplitatea
Scopul fundamental este de a păstra modelele cât mai simple posibil.
“Modelează astăzi pentru a prevedea nevoile de azi şi fă-ţi griji mâine
pentru nevoile de mâine!” Se aleg cele mai simple soluţii de proiectare,
tehnologii, tehnici şi se aplică principiului KISS (Keep It Simple, Stupid!)
Feedback-ul
Are mai multe aspecte pentru un sistem de dezvoltare:
- Feedback-ul din sistem: prin scrierea de teste de unitate, sau rulând
periodic testele integrate, programatorii au feedback direct din starea
sistemului după implementarea schimbărilor.
- Feedback-ul beneficiarului: teste de funcţionare (testele de acceptanţă)
sunt scrise de beneficiar şi de testeri. Ei vor primi feedback concret despre
starea curentă a sistemului. Acesta recenzie este planificată o data în fiecare
doua sau trei săptămâni aşa încât beneficiarul să poată superviza uşor
dezvoltarea.
- Feedback-ul din partea echipei: atunci când beneficiarii vin cu o noua
cerinţă în planul dezvoltării, echipa furnizează direct o estimare a timpului
care va fi consumat pentru implementare.
Feedback-ul este strans legat de comunicare si simplitate. Defectele din
sistem sunt uşor comunicate prin scrierea unui test de unitate care
dovedeşte că o anumită bucată de cod va produce o eroare. Feedback-ul
direct din sistem comunica programatorilor sa fie scris din nou codul pentru
aceasta parte. Un beneficiar este apt sa testeze sistemul periodic in
concordanta cu cerintele de functionare
Curajul
-de a rescrie codul lor oricând este necesar( verificarea sistemului existent
şi modificarea lui astfel încât eventualele schimbări in viitor sa fie cât mai
uşor de implementate.
- de a ştii când este nevoie de a renunţa la o parte din cod: curajul de a
renunţa la bucata de cod învechita, greşită, inutilă fără a tine cont de efortul
depus pentru crearea acelei bucate de cod.De asemenea presupune şi
7
http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la data de 27.04.2013
8
eXtreme programming, http://www.extremeprogramming.org/values.html, accesat la data de 25.04.2013

8. 7
persistenţă: Un programator poate să rămână blocat la o problema
complexa întreaga zi şi apoi s-o rezolve foarte rapid ziua următoare, doar
daca este persistent.
Respectul
(cea mai
recenta)
Se manifestă în mai multe moduri între membrii echipei, între aceştia şi
client.Membrii respectă munca lor tinzând întotdeauna la o calitate
superioară, la cel mai bun design.Adoptarea celor patru valori de mai sus
conduce la respect obţinut de la toţi membrii echipei.Nici un membru nu
trebuie să fie subestimat sau ignorat. Asta asigură un nivel ridicat de
motivare şi încurajează loialitate pe perioada proiectelor.
Tabel 1. Cele 5 valori eXtreme programming
4. Descriere, avantaje, dezavantaje practici
eXtreme programming este condus de 13 practici principale:
Practici Descriere, avantaje ș i dezavatanje
Planning Game9
(Jocul planificării)
Descriere- Există două etape de planificare cheie:
-releaseplanning (planificarea versiunii) – clientul prezintă
caracteristicile dorite ș i programatorii estimează dificultatea lor
O versiune durează până la 6 luni;
-iterationplanning (planificarea iteraț iei) – echipele construiesc
software-ul în iteraț ii de 2 săpt, rulând software-ul util la
sfârș itul fiecărei iteraț ii
Avantaje - reducerea timpuluipierdutpecaracteristici inutile;
aprecieremai marea clientului în costulunei caracteristici; mai
puț ine presupuneri în planificare.
Dezvantaje – disponibilitatea clientului; planificarea este necesara
de multe ori?
Whole Team10
(on-site customer) – echipă
integrală (clientul, membru
echipă)
Descriere - Echipa include deobicei : programatori, testeri,
analiș ti, antrenor, manager ș i nu în cel din urmă clientul. Toată
echipa contribuie cu tot ceea ce poate, cele mai bune echipe nu au
specialiș ti ci numai contribuabili generali cu aptitudini speciale.
Membrii echipei, inclusiv clientul, să fie disponibili tot timpul
pentru întrebări, cu efort ș i timp de aș teptare minime ș i să fie
localizaț i în acelaș i spaț iu de lucru.
Avantaje:poateoferi cunoș tinț e ș i răspunsuri rapidela
întrebărireale de dezvoltare; se asigurăcăceea ceeste
dezvoltatestenecesar ș i că funcț ionalitateaesteo prioritatecorectă.
Dezavantaje:greu pentru a obț ine un client, clientul nu poate da
cunoș tinț e vaste despre ceea ce înseamnă compania, nu poate
avea autoritatea de a lua mai multe decizii.
Customer Tests11
(teste definite de client)
Descriere – Clientul este responsabil cu verificarea corectitudinii
rezultatelor testării de acceptare. Echipa construieș te aceste teste
ș i le utilizează pentru a se convinge pe ei înș iș i sau pe client de
9
http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la data de 17.04.2013
10
http://www.csis.pace.edu/~ctappert/cs616-02/pres-xp.ppt , accesat la data de 19.04.2013
11
http://myopendraft.blogspot.ro/2010/01/12-practices-of-extreme-programming.html , accesat la data de
19.04.2013

9. 8
implementarea corectă a acestora. Testele de acceptare trebuie
automatizate, numărul testelor funcţionale (de acceptare) se
dublează cu fiecare versiune nouă, deşi se oferă acelaşi volum de
funcţionalitate, sunt definite pentru o iteraţie/versiune vor deveni
teste de regresie pentru iteraţiile/versiunile următoare şi reprezintă
un bun instrument de evaluare a progreselor unui proiect.
Avantaje:unitatea de testare promovează testarea completă;
primul test oferă dezvoltatorilor un obiectiv; testările automate
oferă o suită de teste de regresie.
Dezavantaje: unitatea de testare automată nu este pentru oricine;
bazarea pe unitatea de testare nu este o idee bună; un rezultat al
testului este la fel de bun ca ș i testul în sine.
Small Releases12
( versiuni mici)
Descriere- Echipele XP practica versiunile mici în două moduri
importante:În primul rând, echipa rulează versiunea, testează
software-ul, furnizarea valorile afaceri alese de client, cu fiecare
iteraț ie. Clientul poate utiliza acest software pentru orice scop, fie
pentru evaluare sau chiar pentru versiuni către utilizatorii finali
(care este recomandat). Cel mai important aspect este faptul că
software-ul este vizibil, ș i dat clientului la sfârș itul fiecărui
iteraț ie. Acest lucru ț ine totul deschis ș i tangibil.
În al doilea rând, echipele XP creează versiune de software pentru
utilizatorii finali. Produsele sunt chiar împachetate ș i sunt
expediate trimestrial.
Avantaje: feedback frecvent; urmărirea.
Dezavantaje: nu este uș or pentru toate proiectele; nu este necesar
pentru toate proiectele; probleme ale versiunilor.
Collective ownership13
(proprietate colectivă a
programului)
Descriere - Un proiect ce lucrează cu XP, orice pereche de
programatori pot îmbunătăț i codul în orice moment. Asta
înseamnă căci codul beneficiază de atenț ia a mai mulț i oameni,
astfel crescându-i-se calitatea ș i reducându-se defectele.
Proprietatea colectivă a programului ar putea fi o problemă dacă
oamenii ar lucra în neș tiinț ă de cauză pe un cod pe care nu îl
înț eleg. XP elimină aceste probleme prin două tehnici cheie:
testele capturează greș eli, si proiectarea în echipă înseamnă că cel
mai bun mod de a lucra cu un cod la care nu ne pricepem este sa
lucram cun un expert. Pe lângă asigurarea modificărilor bune când
avem nevoie, această practică ajută la răspândirea cunoș tinț elor
în echipă.
Avantaje:contribuie atunci când un membru al echipei pleacă;
promovează dezvoltatorii să îș i asume responsabilitatea pentru
sistem, ca un întreg.
Dezavantaje:pierderea responsabilităț ii, limitarea la cât poate o
persoană să facă dintr-un sistem mare.
Coding standard
(standarde de programare)
Descriere - Codultrebuie să fieformatatlaanumite standardede
codificare. Standarde de codificare trebuie menț inute pentru ca
ș icodul să fie consecventș iuș orpentru intreaga echipa.
Codcarearată la felîncurajeazăproprietate colectivă.
12
http://www.cse.lehigh.edu/~glennb/oose/ppt/XP.ppt , accesat la data de 20.04.2013
13
http://www.uces.csulb.edu/spin/media/ppslide/extremeprogramming.ppt , accesat la data de 20.04.2013

10. 9
Avantaje:reduce cantitatea de timp pe care dezvoltatorii îl petrec
pentru reformatarea codurilor altor persoane; reduce nevoia de
comentarii interne.
Dezavantaje:Degradează calitatea documentaț iei linie.
Sustainable pace
sau 40 Hours Week
(ritm de lucru ce poate fi
susț inut)
Descriere - ÎnXP, dezvoltareaîncomunicareeste mareș i se
mândreș te cuo viteza impresionanta. Dezvoltatoriisuntîntr-un
mediu de lucru în care stresulde schimbare estemereu prezent. Să
lucrezipeproiecteXPinseamna calitatede conducereîn mod
constantș ide performanț ăpe întreaga duratăaproiectului. Cum o
să vămenț ineț i o calitatecuechipele care lucrează ore
suplimentare? Răspunsuleste că nu poț i, ratele dedefectîncepe
săurceș icomunicarease deteriorează. Amintindu-ș icăîntr-
unprincipiude bazăXPestemenț ionată că ș i calitatea
munciinupoateficompromisă, vomaveadecontrolatcât de multe
oreș i de a menț inestandarde ridicate.
Avantaje: majoritatea dezvoltatorilor pierd din eficacitate după 40
de ore; managementul este obligat să găsească soluț ii reale.
Dezavantaje: principiul de bază este greș it; 40 de ore este un
număr magic; unii ar putea dori să lucreze mai mult de 40 de ore
pe săptămână.
Metaphor14
(Metaforă)
Descriere- Forma sistemului este definită de o metaforă sau un set
de metafore distribuite/împărț ite de client ș i programatori.
Avantaje:încurajează un set comun de termeni pentru sistem; un
mod rapid ș i uș or pentru a explica sistem(ul??).
Dezavantaje:metafora este adesea sistemul; o altă oportunitate
pentru probleme de comunicare; de multe ori sistemul nu este
înț eles ca o metaforă.
Continuous Integration15
(integrare continuă)
Descriere -Echipele XP menț in sistemul integrat mereu. O
echipă de 40 de oameni publică versiuni noi de cel puț in 8 sau 10
ori zilnic. Beneficiiile acestei practice pot fi văzute gândindu-ne la
proiecte unde versiunile apareau o dată pe săptămână sau chiar
mai rar ș i de obicei conduceau la adevărate probleme de integrare
când totul nu funcț iona corect ș i nimeni nu ș tia exact de ce.
Integrarea bucăț ilor noi de cod duce frecvent la probleme
serioase ale unui proiect. În primul rând deș i integrarea este
critică în livrarea unui cod bun, echipa nu face des asta ș i des este
delegata unor oameni care nu sunt familiari cu sistemul. În al
doilea rând codul neintegrat este de multe ori cod cu bug-uri.
Problemele apar în momentul în care codul trebuie integrat ș i
testarea codului nu a detectat nimic greș it pe sisteme neintegrate.
În al treilea rând integrarea slabă duce la încetinirea scrierii
codului, programatorii poate lucrează la niș te îmbunătăț iri
pentru aplicaț ie însă trebuie săse oprească.
Avantaje:reduce procesul lung; permite practica”SmallReleases”.
Dezavantaje: nuesteîntotdeauna practica limitată de o zi;
reduceimportanț aunei arhitecturi de ieș ire bine gândite.
Refactoring Descriere - Designul sistemului se dezvoltă prin transformarea
14
http://www.cse.lehigh.edu/~glennb/oose/ppt/XP.ppt , accesat la data de 20.04.2013
15
http://rria.ici.ro/ria2010_2/art03.pdf , accesat la data de 24.04.2013;

11. 10
(restructurarea programelor) designului existent care menț ine toate testele în stare de
funcț ionare/rulare.
Avantaje: solicitădezvoltatoriipentru a îmbunătăț iîn mod
proactiv produsuluicaunîntreg; măreș te cunoaș terea
dezvoltatorului în sistem.
Dezavantaje: nu toată lumeaestecapabilăderefactoring; nueste
întotdeauna apropiat; desenele ar elimina în avansrefactoringul?
Simple Design16
(proiectare ș i programare
căt mai simplă)
Descriere - În fiecare moment designul rulează toate testele,
comunică tot ce doresc programatorii să comunice, nu are cod
duplicat ș i conț ine cât mai puț ine clase ș i metode. Această
regulă poate fi rezumată la ”Say everything once, and only once”.
Avantaje: timpul nu este pierdut pentru adăugarea de
funcț ionalităț i de prisos; este mai uș or de înț eles ce se
întâmplă; este posibil refactoring ș i proprietatea colectivă; ajută la
ț inerea programatorilor pe drumul cel bun.
Dezavantaje: ce este"simplu?"; simplunuesteîntotdeauna cea mai
bună opț iune.
Pair Programming17
(Programare în pereche)
Descriere - Tot codul de producț ie este scris de două persoane la
acelaș i monitor/tastatură/mouse.
Avantaje: două capetesunt mai bunedecâtunul singur;
concentrarea; doi oamenisunt mult mai probabilsă răspundă la
următoareleîntrebări; toatăaceastăabordareva merge?;
suntunelecazuri de testarecarepot să nu funcț ionezeîncă?; există o
modalitatede asimplificaacesta?
Dezavantaje: multe sarcini nu au nevoie de doi programatori; o
vânzare grea pentru clienț i; nu este pentru toată lumea.
Test-Driven Development
(dezvoltare condusă de
testare)
Descriere - XP se bazează foarte mult pe feedback ș i în
dezvoltarea de software un feedback bun necesită testare. Echipele
XP practica dezvoltarea bazata pe testare, lucrand in cicluri foarte
scurte de adaugare a unui nou test. Aproape fara efort echipa
produce teste care trec verificarile cu un procent de aproape 100%.
Nu este de ajuns doar scrierea testelor, de asemenea trebuiesc
rulate. Aceste test sunt colectate, si de fiecare data cand un
programator dezvolta un nou cod pentru repository, fiecare test
trebuie sa ruleze perfect mereu. Asta inseamna ca programatorii
primesc feedback asupra a cum se descurca. In plus aceste teste
oferasuport pe masura ce software-ul este creat.
Avantaje:reduce timpul de dezvoltare; facilitează aplicarea altor
practici XP; programatorii înț eleg mai bine ceea ce au de făcut;
programele rezultate sunt mai simple şi testabile
Dezavantaje:Baza de date reală sau fiș ierul extern nu este testat
direct de TDD (puteț i testa doar codul de producț ie; dacă nu este
utilizat cu atenț ie, se poate adăuga la costurile totale ale
proiectului; TDD este foarte dependentă de refactoring ș i de
competenț ele programatorilor.
Tabelul 2. Cele 13 practici
16
Practices eXtreme programming, http://xprogramming.com/book/whatisxp/ , accesat la data de 20.04.2013;
17
http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la data de 20.04.2013

12. 11
În diferite lucrări de cercetare apar 12 practici, în unele 13. Am ales să le descriu pe
toate pentru a aduce la cunoș tintă ș i de existenț a celei de-a 13-a practică.
5. O zi din viaț a unui programator XP
Ziua dumneavoastră ca un dezvoltator într-o echipă XP ar putea începe de la ora opt
cu o scurtă întâlnire, astfel încât toată lumea poate spune ce a făcut în ziua precedentă ș i să
stabilească planurile pentru ziua următoare. O bună comunicare este esenț ială pentru buna
funcț ionare a echipei, iar aceste întâlniri dimineaț a sunt doar unul dintre modurile în care
acest obiectiv este atins. Această reuniunea este, de asemenea, o oportunitate pentru echipa ce
evaluează progresele privind proiectul ca un întreg.Membrii echipei îș i asumă
responsabilitatea pentru optimizarea performanț ei lor prin stabilirea unor indicatori,
monitorizarea lor, ș i a face apoi orice ajustări care ar putea fi necesare.Aceste valori sunt
afiș ate pe grafice mari, vizibile, fixate pe pereț ii biroului ș i conț in lucruricum ar fi o listă
de sarcini pentru iteraț ia curentă, sau procentul de zi cu zi a timpului petrecut la birou.
Personalul îș i însuș eș te pe rând rolul de "Tracker" (supervizor) al proiectului, să
înregistreze datele necesare pentru a produce aceste valori ș i apoi să actualizeze diagramele.
Echipa XP este extrem de auto-disciplinată.
După întrevederea de dimineaț ă te vei alătura colegului de echipă (pair
programming) ș i vei ridica următoarea sarcină din stiva pe care te-ai angajat să o finalizezi
pentru următoarea versiune a produsului. Fiecare dintre aceste sarcini corespunde unei scurte
”povestioare” scrise de client pe un index card pentru a descrie o funcț ionalitate a
produsului. Acest client se află la un birou alăturat, iar dacă este necesar puteț i discuta toț i
trei cerinț ele înainte de a începe lucrul de implementare. Eș ti ghidat de o ”metaforă” care
capturează natura proiectului în termeni care însumează cum ar trebui să funcț ioneze
lucrurile. În proiectul dumneavoastră, metafora reprezintă biroul de tranzacț ionare a unei
bănci de invesț itie.
Puteț i discuta împreună cerinț ele businessului, singurul lucru care îl veț i face este
să faceț ia aplicaț ia să funcț ioneaze nefiind necesară explicarea sau documentarea codului,
însă mereu înainte de a integra funcț ionealităț i noi va trebui să testaț i noile modificări.
Niciodată când se scrie cod acesta nu trebuie să fie cumva duplicat. Deș i colegul tău nu este

13. 12
un programator la fel de bun, surprinzător în echipă faceț i treabă bună fără a lăsa pe dinafară
latura socială a colaborării.18
Clientul auzind că v-aț i terminat task-ul va rula testele automate ce au fost stabilite
de el împreună cu echipa pentru a testa noua funcț ionalitate. Într-un proiect XP iteraț iile
sunt scurte ș i repere importante pentru crearea aplicaț iei nu se află mai departe de două
săptămâni, de asemenea termenele ț intă nu se încalcă niciodată! S-a făcut ora 16:30 ș i
programul de lucru s-a terminat. Ț i-ai terminat task-ul, ț i-ai programat ce vei face data
viitoare, ț i-ai ajutat colegul ș i în curând te vei relaxa.
Programatorul e un om normal, nu un robot. El ș tie că are anumite resurse (man-
hours) pe un proiect ș i o anumită calificare y.În realitate, managementul poate schimba
parametrii proiectului în timp ce el e construit pentru că aș a s-a hotărât brusc, se pot întâlni
dificultăț i tehnice majore, anumite porț iuni ale echipei pot să stagneze, alț ii ajung la
concluzia că au nevoie de mai multe resurse pentru testare (creș terea calităț ii produsului),
etc. Toate acestea sunt riscuri pentru orice proiect, potenț ial catastrofale.
Atunci programatorul porț ionează proiectul în iteraț ii mici, fiecare cu un obiectiv
clar, foarte conservatoare, cu un ciclu de viaț ă echivalent cu al unei aplicaț ii complete ș i
fiecare optimizată la maxim. Iteraț iile sunt "atomii" de lucru, la capătul fiecăreia (cam 2-4
săptămâni de muncă) se pune totul pe masă ș i se reanalizează perspectivele proiectului.
Managementul executiv al programării iterative e mai lejer din cauza faptului că poț i să
intervii cu schimbări în timp real fără să arunci partea tehnica a proiectului în haos. Pentru că
tehnicienii se aș teaptă ca specificaț iile iniț iale să se schimbe un pic intre iteraț ii.
Proiectul consumă mai multe resurse decât dacă ar fi dezvoltat cap-coadă într-un bloc
continuu de „n” luni, dar riscurile sunt mult mai mici, ș i întreg procesul de producț ie e mult
mai versatil. Astfel, dacă faci un fel de sumă probabilistică, iese si e mult mai optim din punct
de vedere al managementului resurselor.
6. Implementări XP de succes
Ford motor: O combinaț ie unică de agilitate ș i calitate
Echipă: 12 programatori, 17 total
Aplicaț ie: sistem de analiză a costurilor
18
http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la data de 24.04.2013

14. 13
Timp: 6 ani
Sistemul financiar al Ford Motor a dezvoltat Vehicle Costing and Profit
System(VCAPS)- Sistemul de profit ș i cost al vehiculelor, un instrument de analiză care
produce rapoarte privind veniturile din producț ie, cheltuieli, venitul net ș i profit. Venitul
este o factură a materialelor, costuri fixe ș i cheltuieli, ș i costurile variabile precum orele de
muncă. VCAPS asamblează aceste date în rapoarte detaliate de analiză a costurilor pentru a
prijini prognozele la nivel de corporaț ie ș i luarea de decizii19
.
Ford a început dezvoltarea sistemului VCAPS în 1993 ș i l-a construit cu
VsisualWorks ș i GemStome Smalltalk. VCAPS este acum întreț inută cu un personal redus
ș i urmează să fie înlocuit cu un sistem nou.
Sistemul VCAPS a provocat în două moduri. În primul rând analistul a dorit
modificări ș i noi funcț ionalităț i înainte de fiecare rulare. Cerinț ele în continuă schimbare
a ț inut echipa în stare de reacț ie. Nu au reuț it să ț ină pasul. În al doilea rând, sistemul
trebuia să ruleze într-o anumită limită de timp. Dar sistemul a avut nevoie de o perioadă
lungă de timp să proceseze ș i avea nevoie de introducere manuală a datelor pentru a
generare zultatul final, ceea ce necesita o perioadă lungă de timp. Dacă intervenea o problemă
(bug) se pierdea timp preț ios făcând o nouă rulare.
Extreme Programming le-a oferit o combinaț ie unică: agilitate pentru a îndeplini
cerinț ele volatile la timp ș i calitate pentru a evita rulările repetate.
Echipa a început XP-ul cu planificarea proiectului. A fost un eș ec. Clienț ii ș i
managemntul firmei nu erau obiș nuiț i cu negocierea programului de lucru. Programul
stabilitit a fost perceput ca fiind lipsit de credibilitate ș i utilitate. A fost necesară o trecere la
Microsoft Project care putea fi modificat fără întâlniri mari de personal ș i putea produce
tipuri de management pe care se putea lua măsuri.
Au continuat proiectul prin adăugarea de cazuti de testare. Cazurile de testare
automată au fost un mare succes. După un an au avut un procent de 40% acoperire de testare
ș i managementul a înregistrat o scădere de 40% a erorilor raportate. XP-ul a fost astfel luat
în considerare.
Au rezolvat problemele prin implementarea practicilor XP. Testele au permis
integrarea continuă ș i mici comunicate. Astfel lucrurile se îndreptau către un design simplu.
În acest ritm au încercat să abordeze programare în echipă (pair programming). Au trebuit să
lucreze din greu pentru a obț ine rezultate cu această abordare. Această tranziț ie la noua
19
http://capstone.cs.ucsb.edu/old/cs189a/papers/x-prog.pdf , accesat la data de 26.05.2013.

15. 14
metodologie nu a fost întâmpinată cu entuziasm de către programatori,ei având nevoie de o
perioadă de acomodare.
După un an jumătate scăderea numărului de erori din sistem a scăzut nurărul de
comunicate de urgentă ș i astfel clienț ii si managementul a constat o mai mare stabilitate a
sistemului. În general XP-ul a fost un succes pentru acest mediu de lucru.
Acxicom – lucrul împreună pentru acelaș i scop
Pe lângă un depozit de date, Acxicom a construit o aplicaț ie de manangent folosind
principiile dezvoltării orientate-obiect a aplicaț iei Forte. Mica echipă de dezvoltare
constituita din zece dezvoltatori a construit aplicaț ia bazându-se pe principiile bine stabilite
ale programării orientate pe obiect cât ș i pe un mod unitar de dezvoltare a aplicaț iei.
În ultimii doi ani din cei trei de dezvoltare a aplicaț iei, echipa compusă din
manageri, analiș ti ai business-ului, testeri ș i persoane ce scriu documentaț ie s-au folosit de
tehnicile Extreme Programming care s-au dovedit critice succesului.20
Ș tim cu toț ii că avem un design bun când acesta este simplu. Unele schț ie create anterior
au încercat chiar să conceapă ș i viitoare schimbări ale aplicaț iei. Echipa a descoperit că de
fapt nu erau prea pricepuț i la asta. Dacă se foloseau ș abloane ș i echipa comunica bine, se
puteau dezvolta aplicaț ii stabile care sunt flexibile ș i pot fi modificate în viitor.
Refolosirea codului este un element major a efortului de dezvoltare. Era evident
pentru echipă că dacă le era frică să modificăm o parte din cod findcă nu ș tiau ce fac, nu
erau niș te dezvoltatori foarte buni. Lăsau codul să îi controleze. În acest moment dacă nu
ș tiu ce face o bucată din cod, îl separă ș i reuș esc să se descurce. Este mai bine să
implementeze o parte bună din cod decât să lase o părticică din cod să controleze aplicaț ia.
Testarea cazurilor individuale a fost greu de implementat deoarce Forte nu aavea un
framework special dezvoltat pentru testare. Ș i-au dezvoltat propriul framework de testare ș i
au avut succes în implementarea sa. Recent au început să folosească Java drept limbaj de
dezvoltare ș i JUnit ca tool de testare.
Cheia Extreme Programming este stabilirea aș teptărilor din partea dezvoltatorilor ș i
a echipei. S-a descoperit că toț i dezvoltatorii din echipă trebuie să adopte această
metodologie altfel lucrurile nu vor merge bine. Echipa le explică din start dezvoltatorilor
prospectaț i spre angajare că dacă nu vor urma stilul de dezvoltare atunci aceasta nu va fi
ochipă bună pentru ei. O singură persoană dacă nu îmbrăț iș ează acest mod de lucru va trage
20
http://capstone.cs.ucsb.edu/old/cs189a/papers/x-prog.pdf , accesat la data de 26.05.2013.

16. 15
în urmă toată echipa. XP are ca scop ca întreaga echipă să lucreze ca un tot unitar pentru a
veni cu noi idei necesare dezvoltării sistemului.
Când erau la începuturile implementării XP, unii din dezvoltatori nu au vrut să
urmeze metodologia. Simț eau că le va fi afectat stilul de dezvoltare ș i nu vor fi la fel de
productivi. Ceea ce s-a întâmplat a fost că bucăț ile din codul lor produceau cele mai multe
probleme datorate faptului că aplicaț ia nu fusese dezvoltată în perechi, doi oameni nu au
participat la design-ul subsistemului ș i aveau de pierdut în faț a altor dezvoltatori ce
învăț au unul de la celălalt. Doi dezvoltatori bine pregătiț i întotdeauna vor depăș i un
dezvoltator inteligent ce lucrează singur.
O idee greș ită asupra XP este că îngrădeș te creativitatea ș i creș terea individuală.
De fapt este invers, XP stimulează creș terea valorii, creativitatea ș i încurajează membrii
echipei să facă alegeri. Cheia este în a decide direcț ia corporaț iei ș i asumarea alegerilor.
XP nu este extremă pentru echipa lor. E o metodologie ce se foloseș te de bunul simț
în dezvoltare. Toată lumea lucrează îmrepună pentru a atinge un scop comun.
DaimlerChrysler - Cea mai buna echipă din lume
Conceptul de programare extremă a fost „inventat” de către Kent Benk, Ward
Cunningham şi Ron Jeffries în timpul dezvoltării proiectului Crysler Comprehensive
Compensation System(C3)21
.
Kent Beck a devenit liderul proiectului C3 în Martie 1996 şi a început să rafineze
metodologia de dezvoltare folosită în proiect. Acesta a scris şi o carte, numită Extreme
Programming Explained, publicată în Octombrie 1999.
Chrysler este un producător de autoturisme din Statele Unite al Americii. Chrysler, împreună
cu subsidiarele, sale sunt acum parte a grupului DaimlerChrysler AG, după ce au fost
cumpărate de către Daimler-Benz in 1998. Chrysler Corporation există din 6 Iunie 1925, când
a fost înfiinţată de Walter Percy Chrysler.
Proiectul C3 a luat naș tere în anul 1995 pe baza unui contract cu sumă fixă lucru ce a
determinat crearea unei echipe comune pentru concernul Chrysler ș i angajarea de
subcontractori22
. O bună parte din procesul de dezvoltare a fost realizat înainte de 1996.
Subcontractorii DaimlerCrysler au folosit o metodologie de tip GUI ce ignora testarea
automată. Rezultatul a fost o salarizare eficientă prin calcularea tuturor salariilor plătite
21
Chrysler Comprehensive Compensation System ,
http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System , accesat la data de 17.04.2013;

17. 16
eronat, fiind necesare aproximativ 100 de zile pentru generarea fluturaș ului de salar.
Majoritatea dintre programatori ș tiau ca programul pe care l-au scris nu va ajunge în
producț ie.
S-a apelat la ajutorul lui Kent Beck pentru ajustări de performanț ă. El a întâmpinat
aceeaș i problema ca ș i în alte situaț ii: coduri sursă de producț ie slab dezvoltate,
imposibilitatea repetării unui test ș i o procedură neadecvată ce a dus la pierderea încrederii
în proiect. El a mers la administratorul serviciului de informaț ii a concernului Chrysler cu
rezultatele obț inute ș i a susț inut că poate rezolva problema, renunț ând la toate codurile
sursa pe care le avea. Atunci a luat ființ ă primul proiect în întregime XP.
L-au angajat pe Kent în companie ca nucleu central, urmând ca el sa îș i petreacă o
săptămână pe luna cu noi. Ron Jeffries a fost luat ca raportor a lui Kent în cele 3 săptămâni de
lipsa. Contractul cu sumă fixă a fost reziliat, iar o jumătate din dezvoltatori redistribuiț i pe
alte poziț ii. Consilierul pe proiecte al concernului Chrysler, Martin Fowler care s-a luptat cu
contractele cu sumă fixă, a intervenit în ajutorul clienț ilor, cerând de la aceș tia opinii. Din
acel moment l-au urmat pe Kent în implementarea regulilor din XP. Un program de
angajament a fost dezvoltat. Iteraț ii au fost adoptate, reguli pentru testare implementate ș i
programarea în paralel ca procedura standard.
La sfârș itul săptămânii a 33-a au avut un sistem gata să poată face ajustare,
performanț ă ș i testări simultane. Erau cu sistemul gata operaț ional ș i pus la punct. Se
putea deja efectua testări simultane, lucru ce a arătat clientului performanț a de care dădeau
dovada.
Implementarea lui C3 a apărut în Mai 1997 ș i nu mai devreme după cum s-a sperat. 23
Au
fost încetiniț i de către 2 factori. Primul a fost decizia de schimbare a modului de salarizare
intern. Au lăsat interfaț a externă intactă. Combinarea interfeț ei externă a noului sistem cu
sistemul vechi de salarizare s-a dovedit a fi o muncă de o amploare mult mai vasta decât ceea
ce estimaseră. Al doilea factor a fost decizia noastră de a nu folosi sistemul în perioada de
salarizare cu procese ce au cerinț e complexe de tip W-2, împărț irea profitului sau bonusuri.
Acest factor a eliminat funcț ionalitatea sistemului din Noiembrie până în Aprilie anul
următor.
Începând de la lansarea sistemului de plată lunar au adăugat noi funcț ii ș i l-au
ajustat ș i pentru plata angajaț ilor plătiț i bi-săptămânal. Au angajat un mic grup din August
1998 având rolul de a evita paralizarea sistemului din cauza erorii Y2K din noiembrie 1999.
23
http://www.computerworld.com/s/article/64850/Extreme_programming_moves_slowly_into_the_enterpris
e, accesat la data de 23.04.2013

18. 17
Privind în urmă, asupra acestei dezvoltări îndelungate s-ar putea spune că au fost
presaț i de timp în ceea ce priveș te promisiunea asupra administraț iei ș i a clienț ilor, s-au
abătut de la principiile sistemului XP. Atunci când au condus dezvoltarea prin teste, când au
scris coduri în paralel, când au făcut cele mai simple lucruri ce ar fi putut funcț iona, a fost
cea mai bună echipă de dezvoltatori de programe de pe faț a pământului.
Proiectul fiind fără succes, Crysler l-a oprit in Februarie 2000, dar metodologia a
rezistat în domeniul de inginerie a programării.
7. Avantaje ș i dezavantaje ale Extreme Programming
eXtreme programming pune accentul pe a testa eficient24
. Testele oferă securitate şi
încredere atât programatorilor cât clienţilor. Testele sunt create înainte de a scrie programele,
în timp ce sunt scrise programele şi după ce s-a terminat faza de implementare. Pe măsură ce
se descoperă erori, sunt adăugate alte noi teste
Punctul forte a eXtreme programming-ului constă în cooperarea diferitelor reguli ș i
practici. Programarea extremă este folosită în echipe de lucru mici sau medii pentru o
dezvoltare rapidă ș i eficientă, cu o durată ș i un cost predictibil25
.
XP funcț ionează foarte bine într-un mediu în care cerinț ele sunt vagi sau chiar
necunoscute. Produsul poate fi adaptat să îndeplinească cerinț ele business-ului iteraț ie cu
iteraț ie, în locul unei specificaț ii bine stabilite de la început. Nu este genul de process care
l-am folosi pentru a construi cel mai sigur sistem, deoarece nu putem da înapoi să vedem ce
s-a făcut. Însă dacă vrem un produs agil, ț intit către echipe ce au între 2 ș i 12 membri,
produs ce adduce o valoare cuantificabilă afacerii atunci XP este demn de luat în calcul.26
Cea mai mare problemă a XP sunt pretenț iile proiectate asupra persoanei cu rolul de
client în echipă. Se aș teaptă ca cineva care a fost în afara regulilor afacerii să aibă
responsabilitatea pentru a livra un sistem ce adaugă valoare afacerii. Ea este persoana care
descrie ce a văzut ș i produce testele funcț ionale pentru a dovedi că aplicaț ia este
completă. Astfel orice criticism asupra a ceea ce face sistemul este ț intit direct către client.
Adeseori aceș tia se regăsesc făcând ceva complet diferit într-un sistem pe care nu-l înț eleg
nefiind ajutaț i sau învăț aț i. Nu este un lucru surprinzător că rapoartele arată că ei sunt unii
din cei mai greu încercaț i într-o echipă XP.
24
http://revistaie.ase.ro/content/31/novac.pdf , accesat la data de 8.05.2013;
25
http://stst.elia.pub.ro/news/ , accesat la data de 8.05.2013
26
http://www.developerfusion.com/article/84310/extreme-programming/ , accesat la data de 07.05.2013;

19. 18
Pentru a face ca XP să funcț ioneze, costul schimbării trebuie menț inut la un nivel
scăzut pe durata proiectului, altfel iteraț iile următoare vor dura din ce în ce mai mult, în
acelaș i timp livrând mai puț in27
. Suporterii XP susț in că prin folosirea noilor tehnolgii ș i
a unor practci clare se schimbă fundamental modul în care se dezvoltă software-ul, lucru care
duce la atingerea obiectivului. Criticii XP arată asupra problemelor ce apar când XP este
scalat peste mărimea proiectului, astfel explicând ridicarea costului schimbării.
XP e o întreagă metodologie de lucru care porneș te de la ideea construcț iei iterative
versus construcț ie clasică28
. "Optimizare" nu înseamnă optimizare tehnică a codului, ci
optimizarea outputului faț ă de resursele consumate. Nu înseamnă că inginerii sunt roboț i
care trebuie să optimizeze totul, ci că echipa lucrează per total mai optim, pentru că riscurile
ș i lipsurile ei sunt diminuate. Totul porneș te de la ideea de principiu că dacă ai un
programator slab într-o anumita privinț ă, dar bun in general, un manager bun va găsi o
modalitate de a augmenta părț ile lui bune în cadrul proiectului, si de a găsi redundante
pentru părț ile proaste, în loc să urle la angajat.
În concluzie "Principalele linii de ghidare ale programării extreme sunt:simplitatea;
concentrarea asupra zilei de azi, lăsând la o parte tentaț iile de a face ceva în plus, deoarece
mai tarziu acestea s-ar putea să aducă numai probleme; replanificarea repetata a întregului
proiect sau a unor parț i din acesta pentru a putea redistribui optim resursele; productivitatea
maximă; disponibilitatea permanentă a clientului pentru o reacț ie rapidă; eliminarea orelor
de lucru peste program; ș i nu în cele din urmă, schimbarea regulilor dacă acestea dau
greș ."29
Bibliografie
1. Extreme programming, http://www.extremeprogramming.org/ , accesat la data de
15.04.2013;
2. http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la data
de 17.04.2013;
3. Chrysler Comprehensive CompensationSystem ,
http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System ,
accesat la data de 17.04.2013;
27
http://www.slideshare.net/MrSMAk/extreme-programming-12047889 , accesat la data de 4.05.2013
28
http://www.xf.ro/showthread.php?t=1209 , accesat la data de 7.05.2013
29
Revista NETReport numarul 117, articolul "Programarea la extrem", accesat la data de 7.05.2013

20. 19
4. http://www.csis.pace.edu/~ctappert/cs616-02/pres-xp.ppt , accesat la data de
19.04.2013;
5. http://myopendraft.blogspot.ro/2010/01/12-practices-of-extreme-programming.html ,
accesat la data de 19.04.2013
6. http://www.cse.lehigh.edu/~glennb/oose/ppt/XP.ppt , accesat la data de 20.04.2013;
7. http://www.uces.csulb.edu/spin/media/ppslide/extremeprogramming.ppt , accesat la
data de 20.04.2013;
8. PracticeseXtremeprogramming, http://xprogramming.com/book/whatisxp/ , accesat la
data de 20.04.2013;
9. http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la data
de 20.04.2013;
10. http://its.lnpu.edu.ua/edocs1/new_doc/en/Marchesi%20M.Extreme%20programming
%20perspectives.2002.pdf , accesat la data de 24.04.2013;
11. eXtremeprogramming, http://www.extremeprogramming.org/values.html, accesat la
data de 25.04.2013;
12. http://rria.ici.ro/ria2010_2/art03.pdf , accesat la data de 24.04.2013;
13. http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la data
de 24.04.2013
14. http://www.ac.tuiasi.ro/upload_year/software%20engineering.pdf , accesat la data de
25.04.2013;
15. http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la data
de 27.04.2013;
16. http://andrei.clubcisco.ro/cursuri/f/f-
sym/4mps/elearn/37%20Programarea%20extrema%20(XP%20-
%20eXtreme%20Programming).pdf , accesat la data de 28.04.2013;
17. http://www.slideshare.net/MrSMAk/extreme-programming-12047889 , accesat la
data de 4.05.2013;
18. http://capstone.cs.ucsb.edu/old/cs189a/papers/x-prog.pdf , accesat la data de
6.05.2013
19. http://www.developerfusion.com/article/84310/extreme-programming/ , accesat la
data de 07.05.2013;
20. http://www.xf.ro/showthread.php?t=1209 , accesat la data de 7.05.2013
21. Revista NETReportnumarul 117, articolul "Programarea la extrem", accesat la data de
7.05.2013;
22. Metodologii „Agile”, http://gurtejpsingh.wordpress.com/2013/03/26/what-is-agile-
its-characteristics-and-most-famous-adapted-agile-methodologies-are/ , accesat la
data de 7.05.2013;
23. http://www.computerworld.com/s/article/64850/Extreme_programming_moves_slowl
y_into_the_enterprise, accesat la data de 23.04.2013;
24. http://revistaie.ase.ro/content/31/novac.pdf , accesat la data de 8.05.2013;
25. http://stst.elia.pub.ro/news/ , accesat la data de 8.05.2013.