Extreme programming(xp)

716 views
571 views

Published on

Referat

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
716
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Extreme programming(xp)

  1. 1. UNIVERSITATEA „ALEXANDRU IOAN CUZA” IAŞIFACULTATEA DE ECONOMIE ŞI ADMINISTRAREA AFACERILORMetodologia XP(eXtreme Programming)Iaşi,2013
  2. 2. 1Cuprins1. eXtreme Programming – o metodologie agilă2. Necesitatea implementării Extreme Programming3. Valorile eXtreme Programming-ului4. Reguli & bune practici5. O zi din viaț a unui programator XP6. Implementări XP de succes7. Avantaje ș i dezavantaje ale Extreme Programming
  3. 3. 21. eXtreme Programming – o metodologie agilăExtreme Programming este atât un proces de dezvoltare cât ș i o metodologie. Unproces (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ă ș irepetitivă pentru aplicaț ii.1Astfel un proces deserveș te drept ș ablon pentru creareaproiectelor. Extreme Programming este de asemenea un suport pentru procese pentru că poatefi (ș i mai mult ca sigur va fi) modelat pentru nevoile specifice ale echipelor, proiectelor ș icompaniilor. Extreme Programming este o metodologie foarte clară, specifică fiindu-iproductivitatea ș i toleranț a ridicată. Comunicarea este de obicei bine închegată, de obiceiinformală (nedocumentată). Extreme Programming este aplicat doar problemelor din afaceri,de exemplu proiect cu un client extern care necesită crearea unui produs specific. Acesteproiecte au o durează între 6 ș i 15 luni de zile. Extreme Programming este folosit de echipemici 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 agilesunt2:- 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 Consortium1http://www.ac.tuiasi.ro/upload_year/software%20engineering.pdf , accesat la data de 25.04.2013;2Metodologii „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. 4. 3Fig.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 ș iXP este folosit fiind a 2-a metodologie pentru crearea de software. XP împărtăș eș te valorilescoase în evidenț ă de Agile Manifesto ș i merge mai departe specificând seturi simple depractici. În timp ce multe metodologii populare încearcă să răspundă la întrebarea “De carepractici avem nevoie pentru a dezvolta software?” XP doar răspunde “Care este setulminimalist de practici de care aș putea avea nevoie ș i de ce am nevoie pentru a-mi limitanevoile 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 aleunui proiect. Însă succesele înregistrate prin folosirea XP continuă să facă spaț iu pentruimplementarea 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 lucratla proiecte unde cerinț ele se schimbă des.3http://its.lnpu.edu.ua/edocs1/new_doc/en/Marchesi%20M.Extreme%20programming%20perspectives.2002.pdf , accesat la data de 24.04.2013
  5. 5. 4Ce 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 înconformitate cu stadiul în care se află4.În proiectele pentru care se aplică XP fiecare contribuitor pentru proiect este membrual “întregii echipe”, o singură echipa de business/dezvoltare/testare care se ocupă de toateaspectele 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 ase 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 deversiuni 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 testobsesiv, î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 codulpentru aplicaț ie în perechi ș i toț i lucrează împreună mereu. Ei codează folosind un stilconsistent pentru ca toată lumea să poate înț elege ș i îmbunătăț i codul după cum sedoreș te.Echipa XP împărtăș eș te o imagine simplă ș i comună asupra a felului în caresistemul arată. Toată lumea lucrează într-un ritm care poate fi susț inut.2. Necesitatea implementării XPAbordarea 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)4Extreme programming, http://www.extremeprogramming.org/ , accesat la data de 15.04.20135http://software2012team23.googlecode.com/git-history/5127389d21813c2bd955c53999f66cede994578b/docs/literature/Extreme_Programming_Explained_Kent_Beck_1999.pdf , accesat la data de 18.04.2013
  6. 6. 5• Management• Motivaț ia programatorilorAceste probleme au devenit critice în anumite domenii de dezvoltare software. Deexemplu, un proiect de afaceri care are ca scop capturarea unei noi niș e de piaț ă utilizând otehnologie nouă. Provocarea poate fi foarte mare în aceste scenarii, iar orice întârziere alansării produsului poate fi fatală. Extreme programming este destinat pentru a rezolvaacestea, 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 alecerinț elor ș i subestimarea scopului proiectului. Soluț ie XP: Unul dintre principiile XP suntiteraț iile scurte. Ajută la respectarea termenilor stabiliț i ș i menț ine proiectul pregătitpentru schimbarea cerinț elor.6Neî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 cucu programatorii doar începutul ș i sfârș itul ciclului de viaț ă a proectului. Adesea, acestlucru 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 artrebui să fie mereu la dispoziț ia programatorilor ș i vice versa. Mici comunicate (smallreleases) permit afacerii să înteleagă direcț ia proiectul ș i să îl corecteze pe parcurs dacă estenecesar.Abaterea de la procese (defect rate): Sunt multe probleme care pot împiedicafinalizarea unui proiect. De obicei, cauza abaterii de la procese o reprezintă forț areaprogramatorilor de a lucra mai repede (de exemplu când este stabilit programul de lucru). Înacest caz viteza de lucru este pusă în faț a calităț ii. Este cel mai rău lucru pe care îl pot facemanagerii 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ă aproiectului.Management: Uneori costurile de administrare se suprapun costurilor de dezvoltare.Unul dintre cele mai importante lucruri în proiectele software este managementul eficient ș iieftin. Soluț ie XP: Extreme programming sugerează munca în echipă ș i totaț iapersoanelor. Astfel persoanele vor avea o viziune comună a proiectului la care lucrează.6http://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. 7. 6Motivaț ia programatorilor: Este o sarcină foarte dificilă ș i nu este neclară. Soluț iaXP: Extreme Programming încearcă să împace productivitatea cu partea umană. Xp-ul estepe placul utilizatorilor deoarece încurajează comunicarea, cross traning-ul, rotaț iapersonalului etc.72. Extreme programming – valoriExtreme Programming este recunoscut pentru cinci mari valori 8:Valori DescriereComunicarea- este un proces prin care informaţia este interschimbată între indivizi,comunicând faţă în faţă, zilnic, in toate fazele proiectului.Trebuie să fiebidirecţ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.SimplitateaScopul 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âinepentru 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-ulAre mai multe aspecte pentru un sistem de dezvoltare:- Feedback-ul din sistem: prin scrierea de teste de unitate, sau rulândperiodic testele integrate, programatorii au feedback direct din stareasistemului 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 desprestarea curentă a sistemului. Acesta recenzie este planificată o data în fiecaredoua sau trei săptămâni aşa încât beneficiarul să poată superviza uşordezvoltarea.- Feedback-ul din partea echipei: atunci când beneficiarii vin cu o nouacerinţă în planul dezvoltării, echipa furnizează direct o estimare a timpuluicare va fi consumat pentru implementare.Feedback-ul este strans legat de comunicare si simplitate. Defectele dinsistem sunt uşor comunicate prin scrierea unui test de unitate caredovedeşte că o anumită bucată de cod va produce o eroare. Feedback-uldirect din sistem comunica programatorilor sa fie scris din nou codul pentruaceasta parte. Un beneficiar este apt sa testeze sistemul periodic inconcordanta cu cerintele de functionareCurajul-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 maiuşor de implementate.- de a ştii când este nevoie de a renunţa la o parte din cod: curajul de arenunţa la bucata de cod învechita, greşită, inutilă fără a tine cont de efortuldepus pentru crearea acelei bucate de cod.De asemenea presupune şi7http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la data de 27.04.20138eXtreme programming, http://www.extremeprogramming.org/values.html, accesat la data de 25.04.2013
  8. 8. 7persistenţă: Un programator poate să rămână blocat la o problemacomplexa întreaga zi şi apoi s-o rezolve foarte rapid ziua următoare, doardaca este persistent.Respectul(cea mairecenta)Se manifestă în mai multe moduri între membrii echipei, între aceştia şiclient.Membrii respectă munca lor tinzând întotdeauna la o calitatesuperioară, la cel mai bun design.Adoptarea celor patru valori de mai susconduce la respect obţinut de la toţi membrii echipei.Nici un membru nutrebuie să fie subestimat sau ignorat. Asta asigură un nivel ridicat demotivare şi încurajează loialitate pe perioada proiectelor.Tabel 1. Cele 5 valori eXtreme programming4. Descriere, avantaje, dezavantaje practicieXtreme programming este condus de 13 practici principale:Practici Descriere, avantaje ș i dezavatanjePlanning Game9(Jocul planificării)Descriere- Există două etape de planificare cheie:-releaseplanning (planificarea versiunii) – clientul prezintăcaracteristicile dorite ș i programatorii estimează dificultatea lorO versiune durează până la 6 luni;-iterationplanning (planificarea iteraț iei) – echipele construiescsoftware-ul în iteraț ii de 2 săpt, rulând software-ul util lasfârș itul fiecărei iteraț iiAvantaje - reducerea timpuluipierdutpecaracteristici inutile;aprecieremai marea clientului în costulunei caracteristici; maipuț ine presupuneri în planificare.Dezvantaje – disponibilitatea clientului; planificarea este necesarade multe ori?Whole Team10(on-site customer) – echipăintegrală (clientul, membruechipă)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 auspecialiș ti ci numai contribuabili generali cu aptitudini speciale.Membrii echipei, inclusiv clientul, să fie disponibili tot timpulpentru întrebări, cu efort ș i timp de aș teptare minime ș i să fielocalizaț 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 ceestedezvoltatestenecesar ș i că funcț ionalitateaesteo prioritatecorectă.Dezavantaje:greu pentru a obț ine un client, clientul nu poate dacunoș tinț e vaste despre ceea ce înseamnă compania, nu poateavea autoritatea de a lua mai multe decizii.Customer Tests11(teste definite de client)Descriere – Clientul este responsabil cu verificarea corectitudiniirezultatelor testării de acceptare. Echipa construieș te aceste testeș i le utilizează pentru a se convinge pe ei înș iș i sau pe client de9http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la data de 17.04.201310http://www.csis.pace.edu/~ctappert/cs616-02/pres-xp.ppt , accesat la data de 19.04.201311http://myopendraft.blogspot.ro/2010/01/12-practices-of-extreme-programming.html , accesat la data de19.04.2013
  9. 9. 8implementarea corectă a acestora. Testele de acceptare trebuieautomatizate, numărul testelor funcţionale (de acceptare) sedublează cu fiecare versiune nouă, deşi se oferă acelaşi volum defuncţionalitate, sunt definite pentru o iteraţie/versiune vor deveniteste 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 automateoferă 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 altestului este la fel de bun ca ș i testul în sine.Small Releases12( versiuni mici)Descriere- Echipele XP practica versiunile mici în două moduriimportante:În primul rând, echipa rulează versiunea, testeazăsoftware-ul, furnizarea valorile afaceri alese de client, cu fiecareiteraț ie. Clientul poate utiliza acest software pentru orice scop, fiepentru 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ăruiiteraț ie. Acest lucru ț ine totul deschis ș i tangibil.În al doilea rând, echipele XP creează versiune de software pentruutilizatorii finali. Produsele sunt chiar împachetate ș i suntexpediate trimestrial.Avantaje: feedback frecvent; urmărirea.Dezavantaje: nu este uș or pentru toate proiectele; nu este necesarpentru toate proiectele; probleme ale versiunilor.Collective ownership13(proprietate colectivă aprogramului)Descriere - Un proiect ce lucrează cu XP, orice pereche deprogramatori 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ă celmai bun mod de a lucra cu un cod la care nu ne pricepem este salucram cun un expert. Pe lângă asigurarea modificărilor bune cândavem 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 pentrusistem, ca un întreg.Dezavantaje:pierderea responsabilităț ii, limitarea la cât poate opersoană să facă dintr-un sistem mare.Coding standard(standarde de programare)Descriere - Codultrebuie să fieformatatlaanumite standardedecodificare. Standarde de codificare trebuie menț inute pentru caș icodul să fie consecventș iuș orpentru intreaga echipa.Codcarearată la felîncurajeazăproprietate colectivă.12http://www.cse.lehigh.edu/~glennb/oose/ppt/XP.ppt , accesat la data de 20.04.201313http://www.uces.csulb.edu/spin/media/ppslide/extremeprogramming.ppt , accesat la data de 20.04.2013
  10. 10. 9Avantaje:reduce cantitatea de timp pe care dezvoltatorii îl petrecpentru reformatarea codurilor altor persoane; reduce nevoia decomentarii interne.Dezavantaje:Degradează calitatea documentaț iei linie.Sustainable pacesau 40 Hours Week(ritm de lucru ce poate fisusț inut)Descriere - ÎnXP, dezvoltareaîncomunicareeste mareș i semândreș te cuo viteza impresionanta. Dezvoltatoriisuntîntr-unmediu de lucru în care stresulde schimbare estemereu prezent. SălucrezipeproiecteXPinseamna calitatede conducereîn modconstantș ide performanț ăpe întreaga duratăaproiectului. Cum osă vămenț ineț i o calitatecuechipele care lucrează oresuplimentare? Răspunsuleste că nu poț i, ratele dedefectîncepesăurceș icomunicarease deteriorează. Amintindu-ș icăîntr-unprincipiude bazăXPestemenț ionată că ș i calitateamunciinupoateficompromisă, vomaveadecontrolatcât de multeoreș i de a menț inestandarde ridicate.Avantaje: majoritatea dezvoltatorilor pierd din eficacitate după 40de ore; managementul este obligat să găsească soluț ii reale.Dezavantaje: principiul de bază este greș it; 40 de ore este unnumăr magic; unii ar putea dori să lucreze mai mult de 40 de orepe săptămână.Metaphor14(Metaforă)Descriere- Forma sistemului este definită de o metaforă sau un setde metafore distribuite/împărț ite de client ș i programatori.Avantaje:încurajează un set comun de termeni pentru sistem; unmod rapid ș i uș or pentru a explica sistem(ul??).Dezavantaje:metafora este adesea sistemul; o altă oportunitatepentru 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. Oechipă de 40 de oameni publică versiuni noi de cel puț in 8 sau 10ori zilnic. Beneficiiile acestei practice pot fi văzute gândindu-ne laproiecte unde versiunile apareau o dată pe săptămână sau chiarmai rar ș i de obicei conduceau la adevărate probleme de integrarecând totul nu funcț iona corect ș i nimeni nu ș tia exact de ce.Integrarea bucăț ilor noi de cod duce frecvent la problemeserioase ale unui proiect. În primul rând deș i integrarea estecritică în livrarea unui cod bun, echipa nu face des asta ș i des estedelegata unor oameni care nu sunt familiari cu sistemul. În aldoilea rând codul neintegrat este de multe ori cod cu bug-uri.Problemele apar în momentul în care codul trebuie integrat ș itestarea codului nu a detectat nimic greș it pe sisteme neintegrate.În al treilea rând integrarea slabă duce la încetinirea scrieriicodului, programatorii poate lucrează la niș te îmbunătăț iripentru 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 transformarea14http://www.cse.lehigh.edu/~glennb/oose/ppt/XP.ppt , accesat la data de 20.04.201315http://rria.ici.ro/ria2010_2/art03.pdf , accesat la data de 24.04.2013;
  11. 11. 10(restructurarea programelor) designului existent care menț ine toate testele în stare defuncț ionare/rulare.Avantaje: solicitădezvoltatoriipentru a îmbunătăț iîn modproactiv produsuluicaunîntreg; măreș te cunoaș tereadezvoltatorului în sistem.Dezavantaje: nu toată lumeaestecapabilăderefactoring; nuesteîntotdeauna apropiat; desenele ar elimina în avansrefactoringul?Simple Design16(proiectare ș i programarecăt mai simplă)Descriere - În fiecare moment designul rulează toate testele,comunică tot ce doresc programatorii să comunice, nu are codduplicat ș 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 defuncț 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 maibună opț iune.Pair Programming17(Programare în pereche)Descriere - Tot codul de producț ie este scris de două persoane laacelaș i monitor/tastatură/mouse.Avantaje: două capetesunt mai bunedecâtunul singur;concentrarea; doi oamenisunt mult mai probabilsă răspundă laurmătoareleîntrebări; toatăaceastăabordareva merge?;suntunelecazuri de testarecarepot să nu funcț ionezeîncă?; există omodalitatede asimplificaacesta?Dezavantaje: multe sarcini nu au nevoie de doi programatori; ovânzare grea pentru clienț i; nu este pentru toată lumea.Test-Driven Development(dezvoltare condusă detestare)Descriere - XP se bazează foarte mult pe feedback ș i îndezvoltarea de software un feedback bun necesită testare. EchipeleXP practica dezvoltarea bazata pe testare, lucrand in cicluri foartescurte de adaugare a unui nou test. Aproape fara efort echipaproduce teste care trec verificarile cu un procent de aproape 100%.Nu este de ajuns doar scrierea testelor, de asemenea trebuiescrulate. Aceste test sunt colectate, si de fiecare data cand unprogramator dezvolta un nou cod pentru repository, fiecare testtrebuie sa ruleze perfect mereu. Asta inseamna ca programatoriiprimesc feedback asupra a cum se descurca. In plus aceste testeoferasuport pe masura ce software-ul este creat.Avantaje:reduce timpul de dezvoltare; facilitează aplicarea altorpractici XP; programatorii înț eleg mai bine ceea ce au de făcut;programele rezultate sunt mai simple şi testabileDezavantaje:Baza de date reală sau fiș ierul extern nu este testatdirect de TDD (puteț i testa doar codul de producț ie; dacă nu esteutilizat cu atenț ie, se poate adăuga la costurile totale aleproiectului; TDD este foarte dependentă de refactoring ș i decompetenț ele programatorilor.Tabelul 2. Cele 13 practici16Practices eXtreme programming, http://xprogramming.com/book/whatisxp/ , accesat la data de 20.04.2013;17http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la data de 20.04.2013
  12. 12. 11În diferite lucrări de cercetare apar 12 practici, în unele 13. Am ales să le descriu petoate pentru a aduce la cunoș tintă ș i de existenț a celei de-a 13-a practică.5. O zi din viaț a unui programator XPZiua dumneavoastră ca un dezvoltator într-o echipă XP ar putea începe de la ora optcu 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 bunafuncț ionare a echipei, iar aceste întâlniri dimineaț a sunt doar unul dintre modurile în careacest obiectiv este atins. Această reuniunea este, de asemenea, o oportunitate pentru echipa ceevaluează 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 suntafiș 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ă (pairprogramming) ș i vei ridica următoarea sarcină din stiva pe care te-ai angajat să o finalizezipentru 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 aprodusului. Acest client se află la un birou alăturat, iar dacă este necesar puteț i discuta toț itrei cerinț ele înainte de a începe lucrul de implementare. Eș ti ghidat de o ”metaforă” carecapturează natura proiectului în termeni care însumează cum ar trebui să funcț ionezelucrurile. În proiectul dumneavoastră, metafora reprezintă biroul de tranzacț ionare a uneibănci de invesț itie.Puteț i discuta împreună cerinț ele businessului, singurul lucru care îl veț i face estesă 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. 13. 12un 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.18Clientul auzind că v-aț i terminat task-ul va rula testele automate ce au fost stabilitede el împreună cu echipa pentru a testa noua funcț ionalitate. Într-un proiect XP iteraț iilesunt 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 ș iprogramul de lucru s-a terminat. Ț i-ai terminat task-ul, ț i-ai programat ce vei face dataviitoare, ț 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 schimbaparametrii proiectului în timp ce el e construit pentru că aș a s-a hotărât brusc, se pot întâlnidificultăț i tehnice majore, anumite porț iuni ale echipei pot să stagneze, alț ii ajung laconcluzia 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 obiectivclar, foarte conservatoare, cu un ciclu de viaț ă echivalent cu al unei aplicaț ii complete ș ifiecare optimizată la maxim. Iteraț iile sunt "atomii" de lucru, la capătul fiecăreia (cam 2-4să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 bloccontinuu de „n” luni, dar riscurile sunt mult mai mici, ș i întreg procesul de producț ie e multmai versatil. Astfel, dacă faci un fel de sumă probabilistică, iese si e mult mai optim din punctde vedere al managementului resurselor.6. Implementări XP de succesFord motor: O combinaț ie unică de agilitate ș i calitateEchipă: 12 programatori, 17 totalAplicaț ie: sistem de analiză a costurilor18http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la data de 24.04.2013
  14. 14. 13Timp: 6 aniSistemul financiar al Ford Motor a dezvoltat Vehicle Costing and ProfitSystem(VCAPS)- Sistemul de profit ș i cost al vehiculelor, un instrument de analiză careproduce rapoarte privind veniturile din producț ie, cheltuieli, venitul net ș i profit. Venituleste o factură a materialelor, costuri fixe ș i cheltuieli, ș i costurile variabile precum orele demuncă. VCAPS asamblează aceste date în rapoarte detaliate de analiză a costurilor pentru aprijini prognozele la nivel de corporaț ie ș i luarea de decizii19.Ford a început dezvoltarea sistemului VCAPS în 1993 ș i l-a construit cuVsisualWorks ș 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 doritmodificări ș i noi funcț ionalităț i înainte de fiecare rulare. Cerinț ele în continuă schimbarea ț inut echipa în stare de reacț ie. Nu au reuț it să ț ină pasul. În al doilea rând, sistemultrebuia 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 agenerare 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 îndeplinicerinț 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 ș imanagemntul firmei nu erau obiș nuiț i cu negocierea programului de lucru. Programulstabilitit a fost perceput ca fiind lipsit de credibilitate ș i utilitate. A fost necesară o trecere laMicrosoft Project care putea fi modificat fără întâlniri mari de personal ș i putea producetipuri de management pe care se putea lua măsuri.Au continuat proiectul prin adăugarea de cazuti de testare. Cazurile de testareautomată 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 permisintegrarea 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 noua19http://capstone.cs.ucsb.edu/old/cs189a/papers/x-prog.pdf , accesat la data de 26.05.2013.
  15. 15. 14metodologie nu a fost întâmpinată cu entuziasm de către programatori,ei având nevoie de operioadă de acomodare.După un an jumătate scăderea numărului de erori din sistem a scăzut nurărul decomunicate de urgentă ș i astfel clienț ii si managementul a constat o mai mare stabilitate asistemului. În general XP-ul a fost un succes pentru acest mediu de lucru.Acxicom – lucrul împreună pentru acelaș i scopPe lângă un depozit de date, Acxicom a construit o aplicaț ie de manangent folosindprincipiile dezvoltării orientate-obiect a aplicaț iei Forte. Mica echipă de dezvoltareconstituita din zece dezvoltatori a construit aplicaț ia bazându-se pe principiile bine stabiliteale 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ă dinmanageri, analiș ti ai business-ului, testeri ș i persoane ce scriu documentaț ie s-au folosit detehnicile 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 anteriorau încercat chiar să conceapă ș i viitoare schimbări ale aplicaț iei. Echipa a descoperit că defapt nu erau prea pricepuț i la asta. Dacă se foloseau ș abloane ș i echipa comunica bine, seputeau dezvolta aplicaț ii stabile care sunt flexibile ș i pot fi modificate în viitor.Refolosirea codului este un element major a efortului de dezvoltare. Era evidentpentru echipă că dacă le era frică să modificăm o parte din cod findcă nu ș tiau ce fac, nuerau 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 unframework special dezvoltat pentru testare. Ș i-au dezvoltat propriul framework de testare ș iau avut succes în implementarea sa. Recent au început să folosească Java drept limbaj dedezvoltare ș i JUnit ca tool de testare.Cheia Extreme Programming este stabilirea aș teptărilor din partea dezvoltatorilor ș ia 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 dezvoltatorilorprospectaț i spre angajare că dacă nu vor urma stilul de dezvoltare atunci aceasta nu va fiochipă bună pentru ei. O singură persoană dacă nu îmbrăț iș ează acest mod de lucru va trage20http://capstone.cs.ucsb.edu/old/cs189a/papers/x-prog.pdf , accesat la data de 26.05.2013.
  16. 16. 15în urmă toată echipa. XP are ca scop ca întreaga echipă să lucreze ca un tot unitar pentru aveni 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 deproductivi. Ceea ce s-a întâmplat a fost că bucăț ile din codul lor produceau cele mai multeprobleme datorate faptului că aplicaț ia nu fusese dezvoltată în perechi, doi oameni nu auparticipat 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 undezvoltator 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ă membriiechipei 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 lumeConceptul de programare extremă a fost „inventat” de către Kent Benk, WardCunningham şi Ron Jeffries în timpul dezvoltării proiectului Crysler ComprehensiveCompensation System(C3)21.Kent Beck a devenit liderul proiectului C3 în Martie 1996 şi a început să rafinezemetodologia de dezvoltare folosită în proiect. Acesta a scris şi o carte, numită ExtremeProgramming 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 fostcumpărate de către Daimler-Benz in 1998. Chrysler Corporation există din 6 Iunie 1925, cânda 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 adeterminat crearea unei echipe comune pentru concernul Chrysler ș i angajarea desubcontractori22. O bună parte din procesul de dezvoltare a fost realizat înainte de 1996.Subcontractorii DaimlerCrysler au folosit o metodologie de tip GUI ce ignora testareaautomată. Rezultatul a fost o salarizare eficientă prin calcularea tuturor salariilor plătite21Chrysler Comprehensive Compensation System ,http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System , accesat la data de 17.04.2013;
  17. 17. 16eronat, 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 înproducț ie.S-a apelat la ajutorul lui Kent Beck pentru ajustări de performanț ă. El a întâmpinataceeaș 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 curezultatele obț inute ș i a susț inut că poate rezolva problema, renunț ând la toate codurilesursa 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ă osăptămână pe luna cu noi. Ron Jeffries a fost luat ca raportor a lui Kent în cele 3 săptămâni delipsa. Contractul cu sumă fixă a fost reziliat, iar o jumătate din dezvoltatori redistribuiț i pealte poziț ii. Consilierul pe proiecte al concernului Chrysler, Martin Fowler care s-a luptat cucontractele cu sumă fixă, a intervenit în ajutorul clienț ilor, cerând de la aceș tia opinii. Dinacel moment l-au urmat pe Kent în implementarea regulilor din XP. Un program deangajament a fost dezvoltat. Iteraț ii au fost adoptate, reguli pentru testare implementate ș iprogramarea î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. Seputea deja efectua testări simultane, lucru ce a arătat clientului performanț a de care dădeaudovada.Implementarea lui C3 a apărut în Mai 1997 ș i nu mai devreme după cum s-a sperat. 23Aufost încetiniț i de către 2 factori. Primul a fost decizia de schimbare a modului de salarizareintern. Au lăsat interfaț a externă intactă. Combinarea interfeț ei externă a noului sistem cusistemul vechi de salarizare s-a dovedit a fi o muncă de o amploare mult mai vasta decât ceeace estimaseră. Al doilea factor a fost decizia noastră de a nu folosi sistemul în perioada desalarizare 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 anulurmător.Începând de la lansarea sistemului de plată lunar au adăugat noi funcț ii ș i l-auajustat ș i pentru plata angajaț ilor plătiț i bi-săptămânal. Au angajat un mic grup din August1998 având rolul de a evita paralizarea sistemului din cauza erorii Y2K din noiembrie 1999.23http://www.computerworld.com/s/article/64850/Extreme_programming_moves_slowly_into_the_enterprise, accesat la data de 23.04.2013
  18. 18. 17Privind în urmă, asupra acestei dezvoltări îndelungate s-ar putea spune că au fostpresaț i de timp în ceea ce priveș te promisiunea asupra administraț iei ș i a clienț ilor, s-auabătut de la principiile sistemului XP. Atunci când au condus dezvoltarea prin teste, când auscris coduri în paralel, când au făcut cele mai simple lucruri ce ar fi putut funcț iona, a fostcea 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 arezistat în domeniul de inginerie a programării.7. Avantaje ș i dezavantaje ale Extreme ProgrammingeXtreme 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ă cese descoperă erori, sunt adăugate alte noi testePunctul forte a eXtreme programming-ului constă în cooperarea diferitelor reguli ș ipractici. Programarea extremă este folosită în echipe de lucru mici sau medii pentru odezvoltare 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 chiarnecunoscute. Produsul poate fi adaptat să îndeplinească cerinț ele business-ului iteraț ie cuiteraț ie, în locul unei specificaț ii bine stabilite de la început. Nu este genul de process carel-am folosi pentru a construi cel mai sigur sistem, deoarece nu putem da înapoi să vedem ces-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.26Cea mai mare problemă a XP sunt pretenț iile proiectate asupra persoanei cu rolul declient î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 caredescrie ce a văzut ș i produce testele funcț ionale pentru a dovedi că aplicaț ia estecompletă. 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ț elegnefiind ajutaț i sau învăț aț i. Nu este un lucru surprinzător că rapoartele arată că ei sunt uniidin cei mai greu încercaț i într-o echipă XP.24http://revistaie.ase.ro/content/31/novac.pdf , accesat la data de 8.05.2013;25http://stst.elia.pub.ro/news/ , accesat la data de 8.05.201326http://www.developerfusion.com/article/84310/extreme-programming/ , accesat la data de 07.05.2013;
  19. 19. 18Pentru a face ca XP să funcț ioneze, costul schimbării trebuie menț inut la un nivelscăzut pe durata proiectului, altfel iteraț iile următoare vor dura din ce în ce mai mult, înacelaș i timp livrând mai puț in27. Suporterii XP susț in că prin folosirea noilor tehnolgii ș ia unor practci clare se schimbă fundamental modul în care se dezvoltă software-ul, lucru careduce la atingerea obiectivului. Criticii XP arată asupra problemelor ce apar când XP estescalat 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 iterativeversus construcț ie clasică28. "Optimizare" nu înseamnă optimizare tehnică a codului, cioptimizarea outputului faț ă de resursele consumate. Nu înseamnă că inginerii sunt roboț icare 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 unprogramator slab într-o anumita privinț ă, dar bun in general, un manager bun va găsi omodalitate de a augmenta părț ile lui bune în cadrul proiectului, si de a găsi redundantepentru 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, deoarecemai tarziu acestea s-ar putea să aducă numai probleme; replanificarea repetata a întreguluiproiect sau a unor parț i din acesta pentru a putea redistribui optim resursele; productivitateamaximă; disponibilitatea permanentă a clientului pentru o reacț ie rapidă; eliminarea orelorde lucru peste program; ș i nu în cele din urmă, schimbarea regulilor dacă acestea daugreș ."29Bibliografie1. Extreme programming, http://www.extremeprogramming.org/ , accesat la data de15.04.2013;2. http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la datade 17.04.2013;3. Chrysler Comprehensive CompensationSystem ,http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System ,accesat la data de 17.04.2013;27http://www.slideshare.net/MrSMAk/extreme-programming-12047889 , accesat la data de 4.05.201328http://www.xf.ro/showthread.php?t=1209 , accesat la data de 7.05.201329Revista NETReport numarul 117, articolul "Programarea la extrem", accesat la data de 7.05.2013
  20. 20. 194. http://www.csis.pace.edu/~ctappert/cs616-02/pres-xp.ppt , accesat la data de19.04.2013;5. http://myopendraft.blogspot.ro/2010/01/12-practices-of-extreme-programming.html ,accesat la data de 19.04.20136. 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 ladata de 20.04.2013;8. PracticeseXtremeprogramming, http://xprogramming.com/book/whatisxp/ , accesat ladata de 20.04.2013;9. http://www.unf.edu/~broggio/cis6516/Extreme%20Programming.ppt , accesat la datade 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 ladata 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 datade 24.04.201314. http://www.ac.tuiasi.ro/upload_year/software%20engineering.pdf , accesat la data de25.04.2013;15. http://csis.pace.edu/~marchese/CS616/Agile/XP/XP_Overview.pdf , accesat la datade 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 ladata de 4.05.2013;18. http://capstone.cs.ucsb.edu/old/cs189a/papers/x-prog.pdf , accesat la data de6.05.201319. http://www.developerfusion.com/article/84310/extreme-programming/ , accesat ladata de 07.05.2013;20. http://www.xf.ro/showthread.php?t=1209 , accesat la data de 7.05.201321. Revista NETReportnumarul 117, articolul "Programarea la extrem", accesat la data de7.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 ladata de 7.05.2013;23. http://www.computerworld.com/s/article/64850/Extreme_programming_moves_slowly_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.

×