Descrierea metodei

Principalele caracteristici  ale XP-ului sunt:

* Echipa de dezvoltare nu are o structura ierarhica; fiecare contribuie la proiect folosind maximul din cunostintele sale.
* Proiectul este In mintea tuturor programatorilor din echipa, nu in documentatii, modele sau rapoarte.
* Cerintele clientului sunt exprimate ca scenarii sau povestiri (“user stories”)
* Acestea sunt scrise pe biletele iar echipa de dezvoltare le imparte in sarcini de implementare (care stau la baza
planificarii orarului de lucru si a estimarii costurilor).
* La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerintelor.
* Scrierea de cod este activitatea cea mai importanta.
* La fiecare pas se face numai ce este absolut necesar in momentul urmator.
* Codul se scrie cat mai simplu si se optimizeaza (refactoring) de cate ori e posibil.
* Se scrie mai intai cod de test.
* Daca apare necesitatea rescrierii sau eliminarii codului, aceasta se face fara nici un fel de dubiu.
* Modificarile aduse codului sunt integrate continuu (de cateva ori pe zi).
* Se programeaza in echipa (programare in perechi); echipele se schimba la sfarsitul unei iteratii (1-2 saptamani).
* Se lucreaza 40 de ore pe saptamana, fara lucru suplimentar.
In cele ce urmeaza vom detalia fiecare caracteristica :
Clientul este membru al echipei – Clientul si dezvoltatorii lucreaza Impreuna pentru a rezolva problemele ce pot aparea
intr-un proiect (Customer team member). Clientul unei echipe XP este o persoana sau un grup de persoane care
definesc prioritatile proiectului. Cazul cel mai fericit este clientul sa fie localizat In aceeasi camera/cladire cu
dezvoltatorii proiectului.
Specificatii utilizatori – Pentru realizarea unui proiect, trebuie ca sa se cunoasca caracteristici ale cerintelor (user
stories), dar nu este nevoie sa se stie foarte mult. Este important sa se stie ca exista detalii, dar nu este obligatoriu sa
fie definite foarte precis. Detaliile unei specificari sunt subiectul schimbarilor in timp, in special cand clientul incepe sa
vada parti complete din sistem. Cand se foloseste XP, dezvoltatorii inteleg detaliile cerintelor vorbind cu clientii, dar vor
nota pe o carte de index cateva cuvinte despre continut si o estimare a costului acestora. O specificatie utilizator este
un articol referitor la o conversatie despre cerintele proiectului.
Cicluri scurte – In general, in cazul unui proiect XP, dezvoltatorii trimit la fiecare doua saptamani (parti de) soft care
ruleaza corect. La sfarsitul fiecarei iteratii (de doua saptamani), sistemul este verificat de clienti pentru a obtine
raspunsul lor.
Planul de iteratie – este o trimitere minora care ar putea fi adaugata In productie. Este o colectie de specificatii utilizator
selectate de client in functie de bugetul stabilit de dezvoltatori. In momentul Inceperii unei iteratii, clientul este de
acord sa nu mai schimbe definitia sau prioritatile specificatiilor din acea iteratie. Astfel, dezvoltatorii sunt liberi sa
imparta problema in subprobleme.
Planul de distribuire – se refera la iteratiile procesului, de obicei sase. Acesta reprezinta o trimitere majora care de
obicei este parte a productiei. Din nou, clientii selecteaza un numar de specificatii in functie de bugetul propus. Clientul
poate schimba continutul planului de distribuire in fiecare moment, poate rezilia anumite specificatii, sau schimba
prioritatea unei specificari.
Testele de acceptare – Detaliile despre specificatiile utilizator sunt scrise sub forma unor teste de acceptare (Acceptance
tests) specificate de client. Testele de acceptare ale unei specificatii sunt scrise de obicei Impreuna cu implementarea ei.
Acestea sunt colectate intr-un fel de limbaj de scriere (scripting language) care permit rularea lor automata si in mod
repetat. Dupa ce testele de acceptare au fost verificate, acestea se adauga la fisierul de teste existent. Acest fisier de
teste se ruleaza de fiecare data cand se lucreaza la constructia sistemului. Daca vreun test de acceptare esueaza, atunci
se depaneaza codul proiectului. In acest fel, o specificare implementata corect, va ramane corecta pana la sfarsitul
proiectului.
Programare In pereche – Codul de productie este scris in perechi de programatori lucrand impreuna la acelasi calculator
(pair programming). Unul din ei scrie codul, iar celalalt cauta erori si imbunatatiri. Apoi rolurile se schimba. Codul
rezultat este proiectat de ambii autori. In timpul unei iteratii, fiecare membru al echipei trebuie sa fi lucrat cu fiecare alt
membru, astfel incat toti stiu in final detaliile implementarii acelei iteratii. Studiile experimentale dovedesc ca
programare  in pereche nu reduce eficienta programarii, dar reduce semnificativ rata de defecte cu aproximativ 15%.
Dezvoltare dirijata de teste – Intreg codul de productie este scris pentru a testa modulele care nu sunt implementate
corect (Test Driven Development). Impreuna cu codul modulului, se creeaza si niste cazuri de testare (test cases).
Aceasta iteratie dintre scrierea codului si a cazurilor de testare este foarte rapida (de ordinul minutelor). Aceste teste
permit programatorilor sa verifice daca programul functioneaza corect.
Proprietate colectiva – O pereche de programatori are dreptul sa verifice orice modul si sa-l imbunatateasca. Nici un
programator nu este responsabil pentru un modul particular, ci participa prin rotatie la elaborarea Intregului proiect
(Collective ownership).
Integrare continua – Programatorii XP au permisiunea sa verifice orice modul In orice moment, indiferent cine l-a scris.
Cand programatorul verifica modulul dupa ce a fost modificat, el trebuie sa fie pregatit sa actualizeze schimbarile
facute de altii care au verificat modulul inaintea lor. Pentru evitarea sesiunilor de actualizare lungi, membrii echipei
verifica modulele frecvent (Continuous integration).
Mentinerea vitezei – Un proiect software este ca un maraton intre linia de plecare si cea de sosire, cu o viteza moderata,
fara oprire (Sustainable pace). Regula XP precizeaza ca echipelor nu le este permis sa lucreze peste timp, cu exceptia
ultimei saptamani cand are loc o trimitere de soft majora.
Spatiul de lucru deschis – Echipa XP lucreaza Intr-o camera deschisa (Open workspace), cu multe statii de lucru, iar
programatorii comunica intens intre ei. Cu toate ca imaginea aceasta ar sugera un mediu distractiv, un studiu facut la
Universitatea din Michigan sugereaza ca un astfel de mediu de lucru mareste de doua ori productivitatea.
Jocul de planificare – Esenta jocului de planificare (Planning game) este diviziunea responsabilitatilor Intre afacere si
dezvoltare. Oamenii de afaceri (clientii) decid cat de importanta este o functionalitate, iar dezvoltatorii decid cat costa
implementarea acesteia. La inceputul fiecarei trimiteri majore, dezvoltatorii trimit clientilor un buget, bazat pe cat sunt
capabili sa livreze la sfarsitul fiecarei iteratii minore sau majore. Clientii vor alege specificatiile conform bugetului
alocat. In acest fel, nu va dura mult pana cand clientii si dezvoltatorii vor decide asupra ritmului proiectului.
Proiectare simpla – O echipa XP face proiectarile cat mai simple si expresive posibil (Simple design). Acestea sunt
focalizate doar pe iteratia curenta, nu pe iteratiile viitoare. In schimb, acestea vor alege cea mai buna proiectare pentru
specificatiile pe care sistemul le implementeaza. Iata trei dintre trasaturile unui proiect bun:
Considerarea celui mai simplu lucru care ar putea functiona corect – Echipa XP incearca de fiecare data sa gaseasca cea
mai simpla proiectare pentru specificatiile existente. Daca aplicatia merge cu fisiere vide (fara informatii), atunci s-ar
putea sa nu fie nevoie sa o verificam si pentru o baza de date.
Presupunerea ca nu este nevoie de o infrastructura – O echipa XP considera ca daca nu este nevoie de o infrastructura,
atunci aceasta nu este introdusa. De exemplu, dezvoltatorii vor introduce baza de date In locul fisierului vid doar daca
exista probe ca infrastructura va fi mai efecienta acum decat daca ar fi introdusa mai tarziu.
Evitarea duplicarii codului – Echipa XP nu va permite duplicarea codului. De exemplu, daca exista mai multe lucruri
(metode, bucati de cod, etc.) care se repeta, atunci se utilizeaza abstractia pentru a le unifica. Actul de eliminare a
redundantelor forteaza echipa sa creeze multe abstractii si astfel sa reduca cuplajele.
Refactorizarea – Dupa ce se adauga din ce In ce mai mult cod care corecteaza anumite erori, structura codului se
degradeaza, devenind greu de mentinut. Echipa XP rezolva aceasta problema prin refactorizare (Refactoring).
Refactorizare Inseamna o serie de transformari mici care Imbunatatesc structura sistemului fara sa-i afecteze
comportarea. De exemplu, o metoda cu un cod prea mare poate fi impartit in trei metode, una pentru citirea si alocarea
datelor, a doua pentru executia programului, si a treia pentru incarcarea si scrierea rezultatelor intr-un vector.
Refactorizarea se face permanent la sfarsitul proiectului, a unei trimiteri mici sau mari de cod, sau chiar la sfarsitul zilei.
Asftel, codul va fi clar, simplu si expresiv.
Metafore – Metaforele nu au o definitie concreta, unii experti XP au propus chiar eliminarea utilizarii metaforelor din
practica XP. O metafora (Metaphor) este o imagine mare care leaga impreuna intregul sistem. Este viziunea sistemului
care face locatia si forma modulelor individuale evidente. Daca forma modulului este inconsistenta cu metafora, atunci
ceva este gresit In acel modul. De exemplu, a fost considerat un sistem care analizeaza traficul retelelor. Fiecare
adaptor de retea va furniza un bloc de date compus din variabile individuale. Aceste blocuri pot fi numite metaforic,
„felii” (slices). „Feliile” contin date care trebuie analizate. Programul de analiza „prajeste” aceste felii, deci poate fi numit
metaforic „Prajitorul” („The toaster”). Variabilele individuale se pot numi „firimituri” (crumbs).