Extreme Programming - Metodologia XP. Într-un proiect care funcționează conform metodologiei XP, procesul este structurat astfel. Feedback-ul în XP este implementat în trei direcții simultan

ÎN În ultima vreme printre dezvoltatori software a devenit
tehnologie populară numită „programare extremă” sau XP. Despre
se scriu o mulțime de articole și cărți care dau o idee despre fundamentele teoretice
această metodologie. Aș dori să vă spun cum arată asta în practică și
care sunt avantajele si dezavantajele

În primul rând, ce este XP? Puteți găsi o mulțime de definiții și descrieri pe Internet.
acest termen. În principiu, fiecare dintre ele reflectă mai mult sau mai puțin adecvat esența
fenomene, dar varietatea definițiilor poate deruta dezvoltatorul. Prin urmare este necesar
înțelegeți că XP este un set de tehnici dezvoltate pentru a se subordona
procesul de dezvoltare software patru principii de bază. Și anume:

• comunicare;
• simplitate;
• Părere;
• vitejie.

De obicei, aceste tehnici sunt specificate în materiale XP. Aici sunt cele mai multe
o listă tipică a acestora:

• Joc de planificare;
• Testarea înainte de începerea dezvoltării;
• Programare perechi;
• Reciclare constantă;
• Ușurință de dezvoltare;
• Proprietatea codului colectiv;
• Integrare continuă;
• Client la locul de muncă;
• Lansare rapidă a versiunilor;
• Săptămâna de lucru de patruzeci de ore;
• Standarde de codificare;
• Metafora sistemului.

Voi comenta doar câteva dintre tehnici, deoarece sensul majorității este
este destul de clar din denumire și este descris în detaliu în literatură. Unii dintre ei
metodele par destul de logice, unele, dimpotrivă, provoacă nedumerire.

Joc de planificare Ideea acestei tehnici este destul de simplă. Dezvoltatorii împreună cu
clienții se reunesc și joacă câteva situații posibile (în
ideal totul) care poate apărea la rezolvarea unei probleme din viață. Asemenea întâlniri
este indicat să se aranjeze înainte de a începe dezvoltarea fiecărui subsistem, adică să facă
acest lucru se face în mod regulat pe tot parcursul procesului de dezvoltare. Acest lucru vă permite să nu
se angajează în dezvoltare conform unui plan strict și se adaptează în timp util
schimbari in domeniul subiectului.

Testarea înainte de începerea dezvoltării. Se presupune că înainte de a începe dezvoltarea
din orice fragment al programului, se scrie un test pentru acesta. Acest lucru oferă o serie de avantaje.
În primul rând, se întâmplă că o schimbare într-o singură bucată de cod implică
greșeli la alții. Această abordare a testării vă permite să identificați instantaneu
asemenea situatii. În al doilea rând, este mai convenabil pentru client să vadă clar că testul funcționează,
decât citirea unor volume mari de documentaţie. De aceea rezultatul testului
trebuie vizualizat.

Metafora sistemului. Sunt comparate produsele sau fragmentele de cod în curs de dezvoltare
orice produse sau fenomene similare. Se construiesc metafore. Acest
simplifică înțelegerea problemei și, în consecință, accelerează dezvoltarea.

Dar trebuie să înțelegi și asta în acest caz, dacă din orice motiv
oricare dintre aceste tehnici începe să fie împotriva principiilor de bază ale XP și
Astfel de situații sunt destul de posibile, atunci ar trebui abandonate.

Sincer vorbind, în ciuda faptului că înainte de a începe evenimentele descrise, eu
avea o înțelegere generală a programării extreme, dar în proces
dezvoltarea aplicației despre care vreau să vă povestesc, să adere în mod conștient
Nu am încercat metodele XP. Cu toate acestea, în opinia mea, acest lucru este tipic
exemplu XP. În orice caz, s-a obținut un rezultat pozitiv.

Acum să vedem cum abordările XP pot fi folosite în practică în
conditiile noastre. Una dintre sarcinile mele la locul de muncă este automatizarea educației
proces. De fapt, pentru o perioadă destul de lungă de timp am
Scriu o aplicație care implementează (de la macar de proiectare
autor:)) soluție cuprinzătoare această problemă. Bugetul proiectului este mic, iar volumul
funcționează - decent. Un alt factor aproape decisiv a fost constanta
modificarea domeniului subiectului. Formularele de raportare se schimbă în mod regulat
documentatia si metodele de obtinere a acestora. O situație a apărut când proiectul a încetat
ține pasul cu cerințele utilizatorului. Și într-o zi a venit momentul când
din motive obiective și subiective, dezvoltarea ar putea fi îngropată în siguranță. in orice caz
în mod neaşteptat mi s-a dat sarcina specifică de a determina
volumul de muncă al fondului de clasă pentru semestru. În acest moment, dintre cei trei participanți
Am rămas singurul din proiect, dar acest subsistem nu a fost implementat și implementarea lui
nici măcar nu era în planurile imediate de dezvoltare ale proiectului. Despre astfel de lucruri mici ca
formularea competentă a problemei, calculul intensității muncii, alocarea
Nimeni nici măcar nu s-a gândit la resurse suplimentare. Pentru a finaliza sarcina a existat
sunt alocate două săptămâni. Totodată, argumentele mele referitoare la imposibilitatea îndeplinirii
această problemă nu a fost luată în considerare în principiu. Prima mea decizie a fost să găsesc
eu de alt angajator, pentru că în două săptămâni a trebuit să scriu nu numai
un modul de analiză a volumului de muncă al fondului sălii de clasă, dar și un sistem de intrare în program
cursuri, suprapuneri de control și multe altele. Deconectat, aceasta sarcina nu se poate rezolva
În principiu, avem nevoie de date inițiale. Și nu doar datele originale, ci și cele corecte
date inițiale, din care urmează toate sarcinile de mai sus. Cu toate acestea,
Nu știu de ce, dar am luat soluția la această problemă.

Este firesc să vorbim despre dezvoltare folosind metode clasice în acest caz
nepotrivit. Aici abordările XP sunt utile. Ideea generală a sarcinii
avea deja, dar existau multe nuanțe care ar putea
crește semnificativ volumul de muncă. Am început lucrul formând numărul
departamentul educațional și a început să bombardeze persoana care răspundea la telefon cu o mulțime de întrebări, răspunsuri la
pe care nu le-am putut găsi singură sau de care nu eram sigură.
.
Am lansat Rational Rose și am început să construiesc un model. Până la sfârșitul zilei de lucru
Am schițat un model care mi s-a părut mai mult sau mai puțin adecvat. După muncă, eu
a făcut încă un pas în conformitate cu ideologia XP. Mi-am scos prietenul afară
lucrează în departamentul educațional pentru a bea bere. În acest proces, important în toate
relațiile evenimentului, i-am conturat viziunea mea asupra programului, interfața acestuia și
logica muncii. El, la rândul său, a început să vorbească despre nevoie
rezolvarea unor subprobleme locale. Spre seară am înțeles mai clar ce
încă mai trebuie făcut în cadrul acestui proiect (nu mă mai îndoiam că sarcina
ar trebui considerat ca un proiect separat). Cu toate acestea, alta nu a fost rezolvată
O problemă importantă este alegerea instrumentelor de dezvoltare. Când au avut loc evenimentele descrise?
evenimente, am început să studiez activ tehnologia MDA. Pe scurt, esența este aceasta:
Fragmentele de cod de aplicație și structurile de date sunt generate automat pe baza
din modelul UML, care poate reduce semnificativ timpul de dezvoltare. În
În acest articol nu voi descrie în detaliu principiile de funcționare ale MDA, dar vreau
atrageți-vă atenția asupra faptului că utilizarea acestei tehnologii este completă
corespunde „spiritului XP”. Acest lucru se datorează faptului că una dintre condițiile în care
Tehnicile XP vor funcționa cu succes, ceea ce va reduce costul modificărilor aduse
Aplicația se află în stadii avansate de dezvoltare. Printre factorii care contribuie
Pentru a realiza acest lucru, nu este lipsit de importanță să folosiți diverse noi
tehnologii de programare. Observ că este tocmai simplitatea refactorizării MDA
aplicațiile este unul dintre principalele avantaje ale acestei tehnologii. În general, pe
Astăzi există destul de multe implementări MDA, am ales
Îndrăzneț pentru Delphi.

Dar în situația mea au fost câteva „momente alunecoase”. În primul rând, recunoscând asta
MDA oferă anumite beneficii, încă nu sunt suficient de încrezător
deținea această tehnologie și practic nu avea experiență în scrierea aplicațiilor MDA.
În al doilea rând, am înțeles că unele fragmente de cod ar fi problematice
implementează mijloace standard MDA și este multă muncă manuală de făcut
codificare”, care în acest caz va avea anumite specificități.

Alternativa a fost să scrieți o aplicație Delphi „obișnuită”. am lansat
ICQ și i-a scris un mesaj prietenului meu, un adept îndrăzneț. Dupa ce eu
I-am subliniat pe scurt esența problemei, l-am întrebat ce va face în locul meu.
El a răspuns ceva de genul acesta: „Fie scufundă-te cu capul înainte în Bold, fie
nu o vei stăpâni niciodată. A face un proiect serios este cel mai bun mod de a învăța
tehnologie." De fapt, nu mă așteptam la alt răspuns.

Dimineata am luat model existentși a început să construiască aplicația. Exact, construiește. LA
Nu am început să codific, doar am schițat interfața cu utilizatorul, mulți
elemente ale cărora au început să funcționeze aproape imediat. Pentru o pauză de fum am încercat să ies
companie de angajați ai departamentului de educație, asta mi-a permis să trag în altul
„victimă” pe ecranul monitorului său și (nu fără o anumită mândrie) a arătat
rezultate intermediare. Astfel, a fost implementat principiul feedback-ului.
Puteți observa pe bună dreptate: „Dar programarea în pereche?” Da,
Într-adevăr, am fost singurul implicat în proiect ca programator. Dar iată-mă
Permiteți-mi să menționez încă o coincidență fericită. În acea perioadă de timp
când au avut loc evenimentele descrise, eu, împreună cu un grup de dezvoltatori -
entuziaștii au dezvoltat un proiect Internet dedicat special MDA. Și atunci eu
a ajuns în cel mai dificil loc în dezvoltarea sa, acest proiect a adus
rezultate complet neașteptate.

Pe parcursul mai multor zile, am scris cod pentru o procedură care implementează afișarea activităților
pe ecran. Elemente standard controalele nu permiteau ca totul să fie afișat pe ecran
datele în forma în care sunt prezentate de obicei. Am vrut asta
dacă utilizatorul final înțelege cel puțin aproximativ ce face programul
și cum să lucrezi cu el. Am scris propria mea componentă pe baza unui TStringGrid obișnuit.
Nu eram sigur dacă aceasta este o soluție bună, dar codul a funcționat. Pe forum
din proiectul nostru, mi-am schițat soluția, așteptând să primesc un fel de evaluare în interior
pentru o perioadă destul de lungă de timp. Cu toate acestea, literalmente 15-20 de minute mai târziu a sosit
primul raspuns. Sugerat Opțiune alternativă soluții, iar după alte 10 minute
a sosit un exemplu de testare, nu doar unul, ci doi deodată, de la doi autori. Dacă
gândiți-vă de ce dezvoltatorii au început să rezolve cu atâta entuziasm
problema altcuiva, atunci poți veni la concluzie simplă. În primul rând, pur și simplu aveau
este interesant să găsim o soluție universală, care poate fi apoi
utilizați în proiectele dvs. Și în al doilea rând, au fost interesați de procesul în sine
comunicare. De menționat că și alte probleme au fost rezolvate cu același entuziasm.
diferite niveluri de dificultate. Desigur, aceasta nu este programare în pereche
înţelegerea obişnuită. Mai degrabă, este un fel de surogat, dar, cu toate acestea, există și
avantajele sale. Să spunem că toate gândurile și ideile exprimate sunt automat
au fost documentate și puteau fi accesate în orice moment.

Aș dori să mă opresc asupra testelor separat. După cum recomandă el în cartea sa
„Programare extremă” Kent Beck, testele ar trebui scrise în avans. Mai mult
Mai mult, pentru autor arată cam așa. Există un program special
scris de însuși dezvoltatorul, când dați clic pe unul dintre butoane
toate testele sunt lansate și, ca urmare, pe ecran apare o „lumină” verde
în cazul unui rezultat pozitiv și roșu în caz contrar. Aceasta este descrierea mea
oarecum descurajatoare. De acord, este greu de imaginat cum
poți scrie un program care simulează acțiunile utilizatorului în absolut toate
situatii.

După cum am spus deja, nu am încercat să adere strict la metodele extreme
programare. Și în cărțile pe care le-am citit s-a afirmat fără echivoc că
scrierea unui test este unul dintre cele mai importante puncte din XP, iar fără el restul
tehnicile nu ar trebui să funcționeze. De ce am realizat ceva pozitiv până la urmă?
rezultat? Totul s-a dovedit a fi destul de simplu. M-a ajutat să răspund la această întrebare
exact acest exemplu cu becuri verzi și roșii. Chestia este că în Bold
Este posibil să se arate dacă un anumit obiect corespunde modelului. ȘI
Acest lucru se face tocmai cu ajutorul unor astfel de „becuri”. Literal două rânduri
pe care l-am introdus aproape imediat în codul aplicației, mi-a permis să văd în care
unde apare discrepanța (dacă există). Aceasta este ceea ce a înlocuit
eu testeaza. Este posibil ca această abordare să nu fi fost pe deplin consecventă
ideea originală de „testare înainte de dezvoltare”, dar a funcționat.

Într-o săptămână am avut o aplicație aproape terminată. În timpul celui de-al doilea
săptămâni, am mai făcut două versiuni, în care am extins serios funcționalitatea și
a importat, de asemenea, majoritatea datelor necesare pentru muncă de la alții
sisteme de lucru. Problema a fost rezolvată și în mare parte datorită utilizării
tehnici XP. Semnificația tuturor celor de mai sus, văd doar în faptul că acest exemplu este
În practică, el a dovedit eficiența programării extreme.

În concluzie, vreau să mai fac un punct. Programare extremă,
dupa parerea mea, nu este un panaceu. Iar metodele lui pot fi aplicate departe de
pentru orice proiect. În principiu, proiectul considerat, după unele semne
a intrat tocmai în categoria proiectelor în care utilizarea XP nu este recomandată.
Cu toate acestea, cu o abordare mai flexibilă, utilizarea tehnicilor extreme
programarea poate aduce rezultate destul de uimitoare. Când citești
cărți de autori străini dedicate acestui subiect pentru cititorii autohtoni
S-ar putea crede că tehnicile XP nu pot fi utilizate, în principiu, în
conditiile noastre. Și nu este doar că relația dintre dezvoltatori și
clienții, precum și relațiile din echipa de dezvoltare descrise în cărți
exemplele se bazează pe principii ușor diferite. E mai mult o chestiune de diferență
mentalitate. Cu toate acestea, adaptarea XP la condițiile noastre este destul de posibilă, și acest lucru poate
da rezultate foarte impresionante.

http://xprogramming.com.ua/ - lume
programare extremă

http://www.xprogramming.ru/ —
programare extremă în rusă

http://www.maxkir.com/ - despre dezvoltare
software

http://xprogramming.com/ - site-ul web
Ideologul XP Ron Jeffries

Extreme Programming - sau, pe scurt, XP (eXtreme Programming) - este răspunsul comunității de programare la atacul abordărilor formale ale creării de produse software și este concepută pentru a readuce spiritul creativității în mediul dezvoltatorilor.

Orice idee dusă până la absurd degenerează în propriul ei opus. Aceasta este exact situația în industria de software din America de Nord cu instrumentele de dezvoltare RAD. La un moment dat, instrumente concepute pentru dezvoltare rapida aplicațiile au început să elimine orice altceva în mintea managerilor, inclusiv dezvoltatori, clienți și proiectul în sine. Atenția nejustificată, hipertrofiată a Procesului în detrimentul altor factori de dezvoltare a dat naștere la o mulțime de proceduri formale - dar calitatea produselor rezultate și cantitatea proiecte de succes s-a dovedit a fi dezamăgitor.

Inițiativa unui grup de dezvoltatori uniți sub sloganul Extreme Programming, sau XP, este menită să reziste presiunii formalismului în munca programatorilor.

Programarea extremă se bazează pe câteva principii foarte specifice, adesea exprimate numeric, care definesc ce trebuie făcut, când și cum ar trebui făcut. Fără a lua aceste numere drept dogme, trebuie totuși să ținem cont că ele au apărut ca urmare a analizei a numeroase proiecte reușite și nereușite, deci, cel puțin, trebuie să existe motive întemeiate pentru a face modificări.

Programarea extremă nu se bazează pe tehnici specifice, așa cum se crede în mod obișnuit, ci doar patru principii de baza: comunicare, simplitate, feedback și curaj. Aici trebuie să începi.

Extreme Programming oferă o soluție gata făcută: păstrați totul cât mai simplu posibil, păstrați clientul pentru dvs. sau rămâneți cu clientul, lăsați-l să monitorizeze în mod activ procesul de dezvoltare, salută schimbarea - iar succesul este aproape garantat.

În echipele XP, comunicarea este întotdeauna încurajată - cel mai rapid mod de a împărtăși informații și experiență. Acest lucru este foarte important atunci când este necesară viteza maximă de dezvoltare. Dar comunicarea, ca orice alt efort util, necesită sprijin constant. De aceea cineva din echipă trebuie să-și asume responsabilitatea monitorizării comunicării, devenind un așa-zis diplomat. Comunicarea și nevoia de a explica acțiunile tale altor membri ai echipei te obligă să faci totul cât mai simplu posibil. Dacă nu funcționează prima dată, ei lucrează la simplificare din nou și din nou până când obiectivul principal este atins - înțelegerea maximă a codului pentru alți dezvoltatori.

Ciclul Extrem

Programarea extremă se bazează pe un ciclu de dezvoltare foarte scurt, iterativ, de una până la trei săptămâni. Până la sfârșitul fiecărui ciclu, ar trebui să existe o versiune complet funcțională, funcțională și testată a aplicației. Aceste cicluri trebuie repetate și neîntrerupte pe tot parcursul proiectului.

Condiția prealabilă pentru acest mod de funcționare este faptul că cerințele sunt rareori complete, oportune și corecte, dovedit în mod repetat. Cu alte cuvinte, indiferent cât de bine este planificată o aplicație, aceasta va trebui reproiectată 100%. Mai mult, poate fi necesar să fie refăcut chiar și în etapa finală. Modificările nu trebuie amânate până la sfârșitul lucrării;

Ca o consecință a cerințelor în continuă schimbare, urmează un alt principiu - luarea tardivă a deciziilor.

Trimis de la Miercuri, 25.01.2012 - 02:28

7. Modele de procese de dezvoltare adaptive: Scrum

În prezent, acestea devin tot mai răspândite adaptiv sau ușor e, procese de dezvoltare „vii” (agile).
ei nu necesită o reglementare atât de strictă, admit posibilitatea unor schimbări frecvente și semnificative ale cerințelor clienților

Procese adaptive se concentreze pe utilizare dezvoltatori buni, mai degrabă decât procese de dezvoltare bine stabilite
ei evitați stabilirea unor modele clare de acțiune să ofere o mai mare flexibilitate în fiecare proiect specific și să nu necesite elaborarea unor documente intermediare suplimentare

Principiile dezvoltării vii

Principii de bază ale dezvoltării software live consemnată în manifestul apărut în 2000: =

1. Oamenii implicați într-un proiect și comunicarea lor sunt mai importante decât procesele și instrumentele
2. Un program de lucru este mai important decât o documentare cuprinzătoare
3. Cooperarea cu clientul este mai importantă decât discutarea detaliilor contractului
4. Lucrul la schimbări este mai important decât respectarea planurilor

Programare extremă

Cel mai des folosit model adaptiv este model de programare extremă(eXtreme Programming, proces XP)
Orientat spre proces XPîn echipe mici și mijlocii care dezvoltă software în condiții de cerințe incerte sau în schimbare rapidă

Procesul XP (programare extremă)

Ideea de bază a procesului XP – eliminați costul ridicat al modificărilor. Acest lucru este realizat prin reducerea bruscă (până la două săptămâni) a duratei iterațiilor individuale.
Acțiunile de bază ale lui xp sunt:=

1. codificare,
2. testare,
3. ascultarea clientului,
4. proiecta

Principiile XP

Dinamism ridicat dezvoltarea este asigurată de următoarele principii:=

1. comunicare continuă cu clientul,
2. simplitatea soluțiilor alese,
3. feedback rapid bazat pe teste operaționale,
4. prevenirea riscurilor

Practici de dezvoltare XP

Implementarea acestor principii este realizată prin utilizarea următoarelor metode:=

1. Metaforă– toată dezvoltarea se bazează pe o poveste simplă, disponibilă publicului, despre cum funcționează sistemul
2. Design simplu– se adoptă cele mai simple soluții de proiectare posibile
3. Testare continuă atât modulele individuale, cât și sistemul în ansamblu; criteriul de intrare pentru scrierea codului este un caz de testare eșuat
4. Reorganizare(Refactoring) - îmbunătățirea structurii sistemului menținând în același timp comportamentul acestuia
5. Programare pereche e – codul este scris de doi programatori pe un singur computer
6. Proprietatea codului colectiv– orice dezvoltator poate îmbunătăți codul oricărui modul de sistem
7. Integrare continuă – sistemul este integrat cât mai des posibil; Testarea continuă de regresie asigură că funcționalitatea rămâne aceeași pe măsură ce cerințele se modifică
8. Client local– un reprezentant competent al clientului trebuie să fie tot timpul în grup
9. Standarde de codificare– trebuie respectate reguli pentru a asigura aceeași prezentare a codului în toate părțile sistemului

Diagrama de dezvoltare XP

Imagine XP (diagrama de dezvoltare XP):

Model Scrum

Este un alt exemplu de proces de dezvoltare adaptativă (ne-am uitat anterior)
Principalele idei ale modelului au fost formulate de Hirotaka Takeuchi și Ikujiro Nonaka în 1986

Ideea principală a modelului Scrum

Fapt experimental: proiectele la care se lucrează de către echipe mici, interfuncționale, tind să producă în mod sistematic rezultate mai bune

Takeuki și Nonata au explicat asta ca "abordare rugby"și a introdus termenul în sine

"scrum"- „zdrobire; scrum în jurul mingii (la rugby)"

Metoda Scrum a fost prezentată pentru prima dată în formă documentată în 1996 împreună de Sutherland și Schwaber.

Roluri

1. ScrumMaster, cel care se ocupa de procese si lucreaza ca manager de proiect,
2. Proprietarul produsului, o persoană care reprezintă interesele utilizatorilor finali și ale altor părți interesate de produs,
3. Echipă, care include dezvoltatori

Etape de dezvoltare

Procesul de dezvoltare este împărțit în etape separate de o anumită durată – sprinturi(de obicei 15-30 de zile)
Fiecare sprint precedată de o etapă numită product backlog– documentarea cererilor de lucru

Planificarea sprintului

Solicitările de lucru sunt stabilite în timpul etapei Sprint Planning Board − întâlnire de planificare a sprintului

Planificarea sprintului
În timpul acestei întâlniri, Product Owner-ul informează despre sarcinile care trebuie îndeplinite
Echipa determină cât de mult din ceea ce dorește să realizeze pentru a finaliza piesele necesare în timpul următorului sprint

Executarea unui sprint

În timpul unui sprint, echipa completează o listă fixă ​​specifică de sarcini - articole în restante, crescând funcționalitatea produsului software

În această perioadă nimeni nu are dreptul să modifice lista de cerințe pentru post, care ar trebui înțeles ca cerințe de îngheț în timpul unui sprint

Diagrama Scrum =

textul răspunsului de referință (nu îl poziționez ca fiind obligatoriu)

Programare extremă

Tehnici XP de bază

· Ciclu scurt de feedback (feedback la scară fină)

o Dezvoltare bazată pe teste

o Joc de planificare

o Clientul este întotdeauna în apropiere (întreaga echipă, client la fața locului)

o Programare cu perechi

Proces continuu mai degrabă decât pe lot

o Integrare continuă

o Refactorizare (Îmbunătățirea designului, Refactorizarea)

o Lansări mici frecvente

· Înțelegerea împărtășită de toți

o Simplitate (design simplu)

o Metafora sistemului

o Proprietatea codului colectiv sau modelele de design selectate (proprietatea modelelor colective)

o Standard de codare sau convenții de codare

· Bunăstarea programatorului:

o saptamana de lucru de 40 de ore (ritm sustenabil, saptamana de patruzeci de ore)

Testare

În XP Atentie speciala Există două tipuri de testare:

· testarea unitară;

· testarea de acceptare.

Un dezvoltator nu poate fi sigur de corectitudinea codului pe care l-a scris până când nu au funcționat absolut toate testele modulelor sistemului pe care îl dezvoltă. Testele unitare permit dezvoltatorilor să verifice dacă codul lor funcționează corect. De asemenea, îi ajută pe alți dezvoltatori să înțeleagă de ce este necesară o anumită bucată de cod și cum funcționează. Testele unitare permit, de asemenea, dezvoltatorului să refactoreze fără griji.

Testele de acceptare asigură că sistemul are de fapt capabilitățile declarate. În plus, testele de acceptare vă permit să verificați funcționarea corectă a produsului în curs de dezvoltare.

Pentru XP, o prioritate mai mare este o abordare numită TDD (Test Driven Development) - mai întâi se scrie un test care nu trece, apoi se scrie codul astfel încât testul să treacă și abia apoi codul este refactorizat.

Joc de planificare

Scopul principal al jocului de planificare este de a formula rapid un plan de lucru brut și de a-l actualiza constant pe măsură ce condițiile problemei devin mai clare. Artefactele jocului de planificare sunt un set de carduri de hârtie pe care sunt notate dorințele clienților (povestiri ale clienților) și un plan de lucru brut pentru lansarea următoarei versiuni mici ale produsului. Factorul critic care face ca acest stil de planificare să fie eficient este că, în acest caz, clientul este responsabil pentru luarea deciziilor de afaceri, iar echipa de dezvoltare este responsabilă pentru luarea solutii tehnice. Dacă această regulă nu este respectată, întregul proces se destramă.

Clientul este mereu acolo

„Clientul” din XP nu este cel care plătește facturile, ci cel care folosește efectiv sistemul. XP afirmă că clientul trebuie să fie în contact în orice moment și disponibil pentru întrebări.

Programare pereche

Programarea în perechi implică crearea întregului cod de perechi de programatori care lucrează pe același computer. Unul dintre ele lucrează direct cu textul programului, celălalt se uită la activitatea acestuia și monitorizează imaginea de ansamblu a ceea ce se întâmplă. Dacă este necesar, tastatura este transferată liber de la una la alta. În timpul lucrului la un proiect, perechile nu sunt fixe: este recomandat să le amestecați, astfel încât fiecare programator din echipă să aibă o bună înțelegere a întregului sistem. În acest fel, programarea în pereche îmbunătățește colaborarea în cadrul echipei.

Integrare continuă

Dacă integrați suficient de des sistemul pe care îl dezvoltați, puteți evita majoritatea problemelor asociate acestuia. În metodele tradiționale, integrarea se realizează de obicei chiar la sfârșitul lucrului asupra unui produs, când se consideră că toate componentele sistemului în curs de dezvoltare sunt complet gata. În XP, integrarea codului întregului sistem se realizează de mai multe ori pe zi, după ce dezvoltatorii sunt încrezători că toate testele unitare se declanșează corect.

Refactorizarea

Aceasta este o tehnică de îmbunătățire a codului fără a-i schimba funcționalitatea. XP înseamnă că, odată ce codul este scris, acesta va fi aproape sigur rescris de mai multe ori pe parcursul unui proiect. Dezvoltatorii XP refac fără milă codul scris anterior pentru a-l îmbunătăți. Acest proces se numește refactorizare. Lipsa acoperirii testului provoacă un refuz de refactorare din cauza fricii de a rupe sistemul, ceea ce duce la degradarea treptată a codului.

Lansări mici frecvente

Versiunile (lansările) ale produsului ar trebui să fie puse în funcțiune cât mai des posibil. Fiecare versiune ar trebui să dureze cât mai puțin timp pentru a fi finalizată. Mai mult, fiecare versiune trebuie să fie suficient de semnificativă în ceea ce privește utilitatea pentru afaceri.

Cu cât îl lansăm mai repede pe primul versiune de lucru produs, cu atât mai devreme clientul va începe să primească profit suplimentar din acesta. Amintiți-vă că banii câștigați astăzi valorează mai mult decât banii câștigați mâine. Cu cât clientul începe să folosească produsul mai devreme, cu atât mai repede dezvoltatorii vor primi informații de la el despre ceea ce îndeplinește cerințele clientului. Aceste informații pot fi extrem de utile atunci când vă planificați următoarea lansare.

Simplitatea designului

XP pornește de la faptul că în timpul procesului de lucru, condițiile problemei se pot schimba în mod repetat, ceea ce înseamnă că produsul dezvoltat nu trebuie proiectat în avans în întregime. Dacă încercați să proiectați un sistem în detaliu de la început până la sfârșit atunci când începeți, vă pierdeți timpul. XP presupune că designul este așa proces important că trebuie efectuată continuu pe toată durata proiectului. Proiectarea trebuie realizată în pași mici, ținând cont de cerințele în continuă schimbare. În fiecare moment încercăm să folosim cel mai simplu design care este potrivit pentru rezolvarea problemei curente. În același timp, îl schimbăm pe măsură ce condițiile problemei se schimbă.

Metafora sistemului

Arhitectura este o idee despre componentele unui sistem și despre modul în care acestea sunt interconectate. Dezvoltatorii folosesc arhitectura pentru a înțelege unde în sistem se adaugă o nouă funcționalitate și cu ce va interacționa o componentă nouă.

Metafora sistemului este un analog a ceea ce se numește arhitectură în majoritatea tehnicilor. Metafora sistemului oferă echipei o idee despre modul în care sistemul funcționează în prezent, unde sunt adăugate noi componente și ce formă ar trebui să ia.

Alegând o metaforă bună, faceți mai ușor pentru echipa dumneavoastră să înțeleagă cum funcționează sistemul dumneavoastră. Uneori, acest lucru nu este ușor de făcut.

Standarde de codificare

Toți membrii echipei trebuie să respecte standardele comune de codificare în timpul lucrului. Astfel:

· membrii echipei nu pierd timpul cu argumente stupide despre lucruri care de fapt nu au nici un efect asupra vitezei de lucru la proiect;

· asigură implementarea eficientă a altor practici.

Dacă o echipă nu folosește standarde de codare consistente, devine mai dificil pentru dezvoltatori să refactorizeze; la schimbarea partenerilor în cuplu, apar mai multe dificultăți; în general, progresul proiectului devine dificil. În XP, este necesar să vă asigurați că este dificil să înțelegeți cine este autorul acestei sau acele bucăți de cod - întreaga echipă lucrează unitar, ca o singură persoană. Echipa trebuie să formeze un set de reguli, iar apoi fiecare membru al echipei trebuie să respecte acele reguli în timpul procesului de codificare. Lista de reguli nu trebuie să fie exhaustivă sau prea lungă. Scopul este de a oferi linii directoare generale care să facă codul ușor de înțeles pentru toată lumea din echipă. Standardul de codificare ar trebui să înceapă simplu și apoi să evolueze pe măsură ce echipa câștigă experiență. Nu ar trebui să petreceți prea mult timp dezvoltării preliminare a standardului.

Proprietatea colectivă

Proprietatea colectivă înseamnă că fiecare membru al echipei este responsabil pentru tot codul sursă. Astfel, toată lumea are dreptul de a face modificări în orice parte a programului. Programarea perechilor sprijină această practică: lucrând în perechi diferite, toți programatorii se familiarizează cu toate părțile codului sistemului. Un avantaj important al deținerii codului partajat este că accelerează procesul de dezvoltare, deoarece dacă apare o eroare, orice programator o poate remedia.

Oferind fiecărui programator dreptul de a schimba codul, riscăm să apară erori introduse de programatori care cred că știu ce fac, dar nu iau în considerare anumite dependențe. Testele UNIT bine definite rezolvă această problemă: dacă dependențele neexaminate generează erori, atunci următoarea rulare a testelor UNIT va eșua

Scrum este un set de principii pe care se construiește procesul de dezvoltare, permițând, în perioade scurte de timp strict fixate (sprinturi de la 2 la 4 săptămâni), să ofere utilizatorului final un software funcțional cu noi caracteristici pentru care a fost cea mai mare prioritate. determinat. Capacitățile software de implementare în următorul sprint sunt determinate la începutul sprintului în faza de planificare și nu se pot schimba pe toată durata acestuia. În același timp, durata scurtă strict fixată a sprintului oferă procesului de dezvoltare predictibilitate și flexibilitate.

Principalele roluri actoriale în Scrum: ScrumMaster este cel care conduce întâlnirile Scrum și se asigură că sunt respectate toate principiile Scrum (rolul nu implică altceva decât conduita corectă a Scrum în sine, managerul de proiect este mai probabil să fie Product Owner și nu ar trebui să fie un ScrumMaster); Product Owner - o persoană care reprezintă interesele utilizatorilor finali și ale altor părți interesate de produs; și o echipă interfuncțională (Scrum Team), formată atât din dezvoltatori, cât și din testeri, arhitecți, analiști etc. (mărimea ideală a echipei este de 7±2 persoane). Echipa este singurul participant pe deplin implicat în dezvoltare și este responsabilă pentru rezultat ca un întreg. Nimeni, în afară de echipa, nu poate interfera cu procesul de dezvoltare în timpul sprintului.

În timpul fiecărui sprint este creat crestere functionala software. Setul de caracteristici care sunt livrate în fiecare sprint provine dintr-o etapă numită product backlog, care are cea mai mare prioritate în ceea ce privește nivelul cerințelor de lucru care trebuie îndeplinite. Elementele de backlog identificate în timpul întâlnirii de planificare a sprintului sunt mutate în etapa de sprint. În timpul acestei întâlniri, Product Owner-ul comunică sarcinile care trebuie îndeplinite. Echipa determină apoi cât de mult din ceea ce dorește să realizeze pentru a finaliza părțile necesare în timpul următorului sprint. În timpul unui sprint, echipa finalizează o anumită listă fixă ​​de sarcini (așa-numitul sprint backlog). În această perioadă, nimeni nu are dreptul să modifice lista de cerințe de lucru, care trebuie înțeles ca cerințe de înghețare în timpul sprintului.

_____________
Facultatea de Matematică a VSU și alți clasici =)

• Conectați-vă pentru a posta comentarii

Extreme Programming sau XP, eXtreme Programming este o metodologie flexibilă de dezvoltare a software-ului. Ca și alte metodologii agile, are instrumente, procese și roluri specifice. Deși autorul XP nu a venit cu nimic nou, ci a luat cele mai bune practici dezvoltare agilă și întărită la maximum. De aceea programarea se numește programare extremă.

Autorul metodei este dezvoltatorul american Kent Beck. La sfârșitul anilor 90, a condus proiectul Chrysler Comprehensive Compensation System și acolo a fost pionier în practica programării extreme. El și-a descris experiența și conceptul creat în cartea Extreme Programming Explained, publicată în 1999. A fost urmată de alte cărți care detaliază practicile XP. Ward Cunningham, Martin Fowler și alții au fost, de asemenea, implicați în dezvoltarea metodologiei.

XP diferă de alte metodologii agile prin faptul că se aplică numai în domeniul dezvoltării software. Nu poate fi folosit în altă afacere sau în viața de zi cu zi precum scrum, kanban sau lean.

Scopul metodologiei XP este de a face față cerințelor în continuă schimbare pentru un produs software și de a îmbunătăți calitatea dezvoltării. Prin urmare, XP este potrivit pentru proiecte complexe și incerte

Metodologia XP este construită în jurul a patru procese: codificare, testare, proiectare și ascultare. În plus, Extreme Programming are valorile simplității, comunicării, feedback-ului, curajului și respectului.

1. Întreaga echipă

Toți participanții la proiect care folosesc XP lucrează ca o singură echipă. Trebuie să includă un reprezentant al clientului, este mai bine dacă acesta este un utilizator final real al produsului care înțelege afacerea. Clientul prezintă cerințe pentru produs și acordă prioritate implementării funcționalității. Analiștii de afaceri îl pot ajuta. Pe partea de execuție, echipa include dezvoltatori și testeri, uneori un antrenor care ghidează echipa și un manager care oferă echipei resurse.

2. Joc de planificare

Planificarea în XP se realizează în două etape - planificarea lansării și planificarea iterațiilor.

În timpul planificării lansării, echipa de programare se întâlnește cu clientul pentru a afla ce funcționalitate dorește să obțină pentru următoarea lansare, adică în 2-6 luni. Deoarece cerințele clienților sunt adesea vagi, dezvoltatorii le specifică și le descompun în părți, a căror implementare nu durează mai mult de o zi. Este important ca clientul să înțeleagă Mediul de operare, în care va funcționa produsul.

Sarcinile sunt notate pe carduri, iar clientul le stabilește prioritatea. În continuare, dezvoltatorii estimează cât timp va dura fiecare sarcină. Când sarcinile sunt descrise și evaluate, clientul revizuiește documentația și dă voie pentru începerea lucrărilor. Pentru succesul proiectului, este esențial ca clientul și echipa de programare să joace pe același domeniu: clientul alege funcționalitatea care este cu adevărat necesară în cadrul bugetului, iar programatorii compară în mod adecvat cerințele clientului cu capacitățile lor.

În XP, dacă echipa nu are timp să finalizeze toate sarcinile până la data lansării, atunci lansarea nu este respinsă, ci o parte din funcționalitatea care este cel mai puțin importantă pentru client este tăiată.

Se realizează planificarea iterației la fiecare doua saptamani, uneori mai mult sau mai rar. Clientul este mereu prezent: el determină funcționalitatea pentru următoarea iterație și face modificări la cerințele produsului.

3. Lansări frecvente de versiuni

În XP, versiunile sunt lansate frecvent, dar cu puține funcționalități. În primul rând, o cantitate mică de funcționalitate este ușor de testat și de întreținut funcționalitatea întregului sistem. În al doilea rând, la fiecare iterație clientul primește o funcționalitate care are valoare comercială.

4. Teste utilizator

Clientul însuși definește teste de acceptare automate pentru a verifica funcționalitatea următoarea funcție produs. Echipa scrie aceste teste și le folosește pentru a testa codul final.

5. Proprietatea codului colectiv

În XP, orice dezvoltator poate edita orice fragment de cod, deoarece... Codul nu este atribuit autorului său. Întreaga echipă deține codul.

6. Integrarea continuă a codului

Aceasta înseamnă că noi bucăți de cod sunt imediat integrate în sistem - echipele XP încarcă o nouă versiune la fiecare câteva ore sau mai des. În primul rând, este imediat clar cum ultimele modificari afectează sistemul. Dacă o nouă bucată de cod rupe ceva, atunci găsirea și remedierea erorii este mult mai ușoară decât o săptămână mai târziu. În al doilea rând, echipa lucrează întotdeauna cu cea mai recentă versiune a sistemului.

7. Standarde de codificare

Când toată lumea deține codul, este important să se adopte standarde de design consecvente, astfel încât codul să arate ca și cum ar fi fost scris de un singur profesionist. Puteți să vă dezvoltați propriile standarde sau să le adoptați pe cele gata făcute.

8. Metafora sistemului

O metaforă a sistemului este o comparație a sistemului cu ceva familiar pentru a crea o viziune comună în echipă. De obicei, metafora sistemului este gândită de persoana care proiectează arhitectura și imaginează sistemul ca întreg.

9. Ritm constant

Echipele XP operează la productivitate maximă, menținând în același timp un ritm constant. În același timp, programarea extremă are o atitudine negativă față de orele suplimentare și promovează o săptămână de lucru de 40 de ore.

10. Dezvoltare bazată pe teste

Una dintre cele mai dificile practici ale metodologiei. În XP, testele sunt scrise chiar de programatori, ÎNAINTE de a scrie codul care trebuie testat. Cu această abordare, fiecare piesă de funcționalitate va fi acoperită 100% cu teste. Când câțiva programatori încarcă cod în depozit, testele unitare sunt executate imediat. Și toți ar trebui să funcționeze. Apoi dezvoltatorii vor fi siguri că se mișcă în direcția corectă.

11. Programarea perechilor

Imaginați-vă doi dezvoltatori la un computer, lucrând la o singură bucată de funcționalitate a produsului. Aceasta este programarea în pereche, cea mai controversată practică XP. Vechea zicală „un cap este bun, doi sunt mai buni” ilustrează perfect esența abordării. Cel mai bun este selectat dintre două opțiuni pentru rezolvarea unei probleme, codul este optimizat imediat, iar erorile sunt surprinse înainte de a apărea. Ca rezultat, avem cod curat pe care doi dezvoltatori sunt bine versați.

12. Design simplu

Designul simplu în XP înseamnă să faceți doar ceea ce aveți nevoie acum, fără a încerca să ghiciți funcționalitatea viitoare. Designul simplu și refactorizarea continuă au un efect sinergic - atunci când codul este simplu, este ușor de optimizat.

13. Refactorizare

Refactorizarea este procesul de îmbunătățire continuă a designului unui sistem pentru a se adapta noilor cerințe. Refactorizarea implică eliminarea codului duplicat, creșterea coeziunii și reducerea cuplării. XP implică refactorizări constante, astfel încât proiectarea codului rămâne întotdeauna simplă.

Avantaje și dezavantaje XP

Metodologia XP provoacă multe controverse și critici din partea celor care nu au reușit niciodată să o implementeze în echipa lor.

Beneficiile programării extreme au sens atunci când echipa utilizează pe deplin cel puțin una dintre practicile XP. Deci, pentru ce merită încercat:

• clientul primește exact produsul de care are nevoie, chiar dacă la începutul dezvoltării el însuși nu își imaginează exact forma finală
• echipa efectuează rapid modificări de cod și adaugă noi funcționalități prin design simplu de cod, planificare frecventă și lansări
• codul funcționează întotdeauna datorită testării constante și integrării continue
• echipa menține ușor codul, pentru că este scris după un singur standard și este refactorizat constant
• ritm rapid de dezvoltare datorită programării perechilor, lipsei de reluare, prezenței clientului în echipă
• calitate înaltă a codului
• riscurile asociate dezvoltării sunt reduse, deoarece responsabilitatea pentru proiect este distribuită uniform și plecarea/sosirea unui membru al echipei nu va strica procesul
• costurile de dezvoltare sunt mai mici deoarece echipa este orientată spre cod, nu documentare și întâlniri

În ciuda tuturor avantajelor, XP nu funcționează întotdeauna și are o serie de puncte slabe. Deci, programare extremă - dezavantaje:

• succesul proiectului depinde de implicarea clientului, care nu este atât de ușor de realizat
• Este greu de prezis timpul petrecut într-un proiect, pentru că... la inceput nimeni nu stie lista plina cerințe
• succesul XP depinde foarte mult de nivelul programatorilor, metodologia funcționează doar cu specialiști seniori
• managementul are o atitudine negativă față de programarea în pereche, neînțelegând de ce ar trebui să plătească pentru doi programatori în loc de unul
• Întâlnirile regulate cu programatorii sunt costisitoare pentru clienți
• necesită prea multă schimbare culturală
• din cauza lipsei de structură și documentație, nu este potrivit pentru proiecte mari
• deoarece Metodologiile agile sunt orientate funcțional, cerințele nefuncționale pentru calitatea produsului sunt greu de descris sub formă de povești ale utilizatorilor.

Principiile XP

În prima sa carte, Kent Beck a articulat principiile programării extreme: simplitate, comunicare, feedback și curaj. În noua ediție a cărții, el a adăugat un al cincilea principiu - respectul.

1. Simplitate

În XP, dezvoltarea începe cu cea mai simplă soluție care va satisface nevoia actuală de funcționalitate. Membrii echipei iau în considerare doar ceea ce trebuie făcut acum și nu pun în cod funcționalitatea care va fi necesară mâine, peste o lună sau niciodată.

2. Comunicare

În XP, comunicarea între dezvoltatori nu se realizează prin documentare, ci în direct. Echipa comunică activ între ele și cu clientul.

3. Feedback

Feedback-ul în XP este implementat în trei direcții simultan:

1. feedback de la sistem în timpul testării constante a modulelor
2. feedback de la client, deoarece face parte din echipă și participă la teste de acceptare scrise
3. feedback din partea echipei în timpul planificării cu privire la timpul de dezvoltare.

4. Curaj

Unele tehnici de programare extreme sunt atât de neobișnuite încât necesită curaj și autocontrol constant.

5. Respect

În Extreme Programming, respectul este privit în termeni de respect pentru echipă și respect de sine. Membrii echipei nu ar trebui să încarce modificări care vor rupe compilarea, testele unitare sau vor încetini munca colegilor. Toată lumea se străduiește pentru cea mai bună calitate cod și design.

Algoritm pentru implementarea metodologiei XP și a procesului de lucru

Beck Kent recomandă implementarea XP pentru a rezolva problemele dintr-un proiect. Echipa alege cea mai presantă problemă și o rezolvă folosind una dintre practicile de programare extremă. Apoi trece la următoarea problemă folosind o altă practică. Cu această abordare, problemele acționează ca motivație pentru utilizarea XP și echipa stăpânește treptat toate instrumentele metodologiei.

Pentru a implementa XP într-un proiect existent, trebuie să-i stăpânești treptat tehnicile în următoarele domenii:

• testarea
• proiecta
• planificare
• management
• dezvoltare

Testare.

Echipa creează teste ÎNAINTE de a scrie cod nou și reproșează treptat cod vechi. Pentru codul vechi, testele sunt scrise după cum este necesar: atunci când trebuie să adăugați o nouă funcționalitate, să remediați o eroare sau să reluați o parte a vechiului cod.

Proiecta.

Echipa refactorizează treptat codul vechi, de obicei înainte de a adăuga funcționalități noi. Ca și în cazul testării, refactorizarea codului vechi se face numai atunci când este necesar. În același timp, echipa ar trebui să formuleze obiective pe termen lung pentru reelaborarea codului și să le atingă treptat.

Planificare.

Echipa trebuie să treacă la interacțiunea strânsă cu clientul. În această etapă, este important să-i transmiți avantajele de a lucra în aceeași echipă cu dezvoltatorii și să-l integrezi în echipă.

management.

Rolul managerilor în timpul tranziției la XP este de a se asigura că toți membrii echipei lucrează conform noilor reguli. Managerul de proiect decide când să se despartă de un membru al echipei care nu face față muncii în noul mediu sau să găsească unul nou și să-l integreze corespunzător în muncă.

Dezvoltare.

Transformările în dezvoltare încep cu organizarea stațiilor de lucru pentru programare în perechi. Următoarea provocare este să programezi în perechi de cele mai multe ori, indiferent cât de dificil ar fi pentru dezvoltatori.

Într-un proiect care funcționează conform metodologiei XP, procesul este structurat după cum urmează:

Cine folosește XP

Potrivit unui studiu din 2016 al Versionone, doar 1% dintre companiile agile folosesc programarea extremă în forma sa pură. Alți 10% lucrează folosind o metodologie hibridă scrum și XP.

Interesant, deși XP este departe de cea mai comună metodologie în forma sa pură, practicile sale sunt folosite de majoritatea companiilor care lucrează pe metodologii agile. Acest lucru este dovedit de datele din același studiu:

Nu este ușor să găsești informații despre echipele care folosesc XP, dar sunt cei care fac reclamă că această metodologie este motivul succesului lor. Un exemplu de programare extremă este Pivotal Software, Inc.

Pivotal Software, Inc.

O companie americană de software care dezvoltă software pentru analiza afacerilor pe baza datelor mari și oferă servicii de consultanță. Produsele pivot sunt folosite de Ford, Mercedes, BMW, GAP, corporațiile Humana, băncile mari, agentii guvernamentale, companii de asigurări etc.

Pivotal este un susținător al metodologiilor agile ca fiind singurele posibile în dezvoltarea modernă. Dintre toate opțiunile pentru metodologii flexibile, compania a ales XP ca o abordare câștigătoare pentru clienți și echipele de programare. Fiecare zi de lucru începe cu o întâlnire din mers și se termină prompt la ora 18:00 - fără ore suplimentare. Pivotal folosește planificarea jocului, programarea perechilor, testarea continuă, integrarea continuă și alte practici XP. Pentru multe practici, au propriul lor software.

Programare extremă,
Programare extremă: planificare,
Programare extremă: Dezvoltare bazată pe teste / Kent Beck

Despre programarea extremă de la creatorul metodologiei, Kent Beck. Începeți cu primul, care descrie conceptul XP cu exemple și justifică avantajele acestuia. Mai târziu, autorul a publicat mai multe cărți, unde a descris în detaliu practicile individuale XP.

Refactoring: Îmbunătățirea codului existent / Martin Fowler

Programare extremă: formularea procesului. De la primii pași până la sfârșitul amar / Ken Auer, Roy Miller

Deoarece Extreme Programming se străduiește să obțină un cod curat și ușor de întreținut, lista de cărți include toate publicațiile care vă învață cum să programați mai bine.

Aplicații pentru implementarea XP într-o echipă

Echipele care lucrează la proiecte folosind metodologia XP folosesc manageri de activități și servicii pentru proiecte agile. Există multe astfel de produse pe piață, ne vom uita la câteva exemple.

Manager de sarcini gratuit cu sursa deschisa. Funcții principale: lucrul la mai multe proiecte simultan, sistem flexibil de gestionare a sarcinilor, diagramă Gantt, controlul timpului, lucrul cu documentația, crearea de sarcini prin e-mail etc.

Simplu serviciu convenabil Pentru colaborare pe proiecte. Include un manager de activități, panou de mesaje, chat încorporat, stocare fișiere, calendar

Jira

Un serviciu puternic conceput special pentru dezvoltatorii de proiecte agile. Combină un instrument de urmărire a erorilor și un serviciu de management de proiect. Multe funcții plus sincronizare cu alte servicii. Soluții pentru echipe de diferite dimensiuni.

Pentru a lucra la proiecte. Vă permite să setați sarcini și să controlați procesul de execuție, să corespondeți între ele la o sarcină, să configurați filtre, să țineți cont de cheltuiala de timp și de finanțare și să lucrați cu fișiere.

Verdict

Extreme Programming este o metodologie flexibilă care se concentrează pe cod de înaltă calitate, funcțional, cu o arhitectură simplă. Scopul său este de a reduce nivelul de incertitudine în proiecte și de a răspunde cu adevărat flexibil la schimbările în cerințele produsului.

Această metodologie este destinată exclusiv domeniului dezvoltare de softwareși nu poate fi adaptat pentru o altă afacere.

Aceasta este una dintre cele mai dificil de implementat metodologii, deoarece include până la treisprezece practici!

Puține companii riscă să lucreze pe XP pur, dar practicile sale de dezvoltare sunt cele mai populare în proiectele agile. Și acesta este un argument puternic în favoarea eficienței lor.

Nimeni nu te obligă să implementezi XP pe bază de totul sau nimic. La sfârșitul zilei, metodologiile agile trebuie să fie flexibile în aplicarea lor - adaptate nevoilor unei echipe și unui proiect specific.

Probabil că fiecare designer sau analist cel puțin o dată în viață a întâlnit un client care caută să-și obțină proiectul cât mai ieftin și, mai mult, în cel mai scurt timp posibil. Dar dacă costul proiectului este un subiect foarte real de negociere, atunci negocierea privind ajustarea termenelor de livrare a proiectului este mult mai dificilă. Există astăzi din ce în ce mai mulți clienți nerăbdători, ceea ce se explică prin starea pieței dinamice moderne, scăderea nivelului de încredere între interpreți și clienți și comportamentul investitorilor al căror apetit vine în timp ce mănâncă (dacă există o activitate mai mult sau mai puțin funcțională). versiunea produsului, bani pentru dezvoltare ulterioară pe care o dau mult mai de bunăvoie), etc. În acest sens, metodologiile clasice de dezvoltare (în care un ciclu lung al designului propriu-zis și colectarea de informații, când clientul investește fonduri semnificative, dar nu primește rezultate reale pentru o perioadă destul de lungă) intră în conflict foarte strict cu interesele clientului nerăbdător. Toate acestea au dat impuls dezvoltării metodologiilor alternative de proiectare în două direcții principale: creșterea încrederii clienților prin furnizarea de dovezi reale ale procesului de dezvoltare cu succes și reducerea bruscă a timpului de dezvoltare a produsului. Un grup de astfel de metodologii se numește „programare activă”.

Dezvoltare accelerată și colaborativă de aplicații

ca o regula, utilizatori finali iar conducerea clientului consideră că procesul de proiectare nu are succes dacă nu sunt disponibile componente efective disponibile. Adesea, clientul insistă să realizeze etapa de implementare a proiectului înainte de termen pentru a obține un rezultat specific și a-l demonstra cât mai repede posibil. În acest caz, este foarte tentant să alegeți Accelerated Application Development (AAD) sau Collaborative Application Development (CAD). Astfel de metode implică dezvoltarea unui prototip funcțional și apoi demonstrarea acestuia utilizatorilor, care notează ce le place și ce nu. După aceasta, designerul rafinează prototipul ținând cont de comentariile făcute și apoi demonstrează din nou ce s-a întâmplat. Procesul se repetă până când utilizatorii sunt mulțumiți de ceea ce văd și prototipul devine o aplicație funcțională. De obicei, sunt stabilite o limită de timp și un număr de iterații, altfel utilizatorii vor cere la nesfârșit noi îmbunătățiri ale prototipului. În teorie, acest lucru vă permite să obțineți exact sistemul de care au nevoie utilizatorii.

Deci aici vedem un model de dezvoltare iterativ cu cicluri spiralate foarte scurte în ambele cazuri. În ambele metode, timpul petrecut în etapele inițiale de proiectare este redus: strategie (fie omisă cu totul, fie îmbinată cu analiza), analiză (în majoritatea cazurilor limitată la selecția inițială a informațiilor și analiza formularelor - de regulă, rapoarte, pe care încearcă să restabilească structura funcțiilor sistemului), proiectare (care vizează obținerea cât mai rapidă a unui prototip primar). Rezultatul dezvoltării este un prototip, care este apoi supus implementării industriale. În acest caz, testarea este efectuată cu participarea activă a clientului sau clientul devine un tester (în cel mai bun caz, un tester beta).

În practică, această abordare a dezvoltării aplicațiilor este asociată cu următoarele probleme:

Toată atenția este concentrată formulare de ecran, și tot ce ține de regulile de prelucrare a datelor și funcțiile sistemului, rămâne în culise. Există tentația de a începe lucrul cu rapoarte, în timp ce un raport nu este un produs de pornire, ci un produs derivat al unui sistem informațional.

Utilizatorii presupun că dacă versiunea prototip este convenită, atunci modulul este gata. De fapt, aceasta poate fi doar o imagine cu un set de „stubs” pentru apelarea funcțiilor sistemului și interacțiunea cu alte module.

Modulele sunt proiectate izolat unele de altele. Consecința acestui lucru este contradicțiile între module, duplicarea funcțiilor și a datelor, care pot fi identificate doar prin testarea unui set de module.

Funcționalitate sunt extinse în paralel în mai multe direcții, astfel încât structura depozitului de date trebuie controlată. Cu URP, designul bazei de date seamănă cu un depozit de vechituri, unde tabelele sunt aruncate împreună în grabă, iar rezultatul este un set de date contradictorii și duplicate.

Documentația la utilizarea metodei URP este de obicei absentă din două motive: nu există suficient timp și se creează iluzia că utilizatorul este capabil să înțeleagă esența a ceea ce se întâmplă fără documente. Când aplicația începe să funcționeze diferit decât se aștepta utilizatorul, apar probleme.

Modul în care sunt gestionate excepțiile se dovedește a fi diferit pentru diferite module.

Se pune problema integrării modulelor: de regulă, un sistem complet nu funcționează, deoarece a fost conceput inițial ca un set de componente care au fost ulterior conectate în grabă între ele.

Controlul calității produsului intră în conflict strict cu momentul dezvoltării proiectului, drept urmare etapele de testare și implementare ale următoarei versiuni a produsului practic se îmbină și sunt transferate direct pe site-ul de testare al clientului. Este clar ce se întâmplă în acest caz cu clientul, care este extrem de nemulțumit de calitatea produsului; cu alte cuvinte, rufele murdare sunt spălate în public la momentul absolut nepotrivit.

Se pune întrebarea: se pot rezolva astfel de probleme și cum? La urma urmei, chiar vrei să obții proiectul cât mai repede posibil! Într-o oarecare măsură, programarea extremă (eXtreme Programming, XP) poate fi considerată o evoluție, și poate chiar o revoluție, în domeniul metodologiilor mai tinere de programare activă. Dacă această metodologie este potrivită special pentru echipa ta de dezvoltare, depinde de tine și doar tu decizi, deoarece, de exemplu, nu toată lumea este încântată de sporturile extreme.

Programare extremă

Principii și metode XP utilizate pentru a accelera dezvoltarea

Kent Beck este considerat părintele-ideolog al programării extreme. XP este o metodologie destul de tânără, ale cărei evaluări sunt foarte contradictorii - de la entuziast la puternic negativ. Principiile principale sunt:

Simplitatea soluțiilor.

Dezvoltare intensivă în grupuri mici (nu mai mult de 10 persoane), comunicare activă în cadrul grupului și între grupuri (comunicare).

Părere cu clientul (feedback), care este implicat efectiv în procesul de dezvoltare.

Un grad suficient de curaj și disponibilitate de a-și asuma riscuri.

Primul factor în accelerarea dezvoltării este iterativitatea: dezvoltarea se realizează în iterații scurte cu o relație activă cu clientul. XP este un proces de dezvoltare iterativ, care în sine nu este revoluționar. Se propune menținerea iterațiilor ca atare scurte, durata recomandată este de 2-3 săptămâni și nu mai mult de 1 lună. Într-o singură iterație, un grup de programatori este necesar să implementeze mai multe proprietăți ale sistemului, fiecare dintre acestea fiind descrisă într-o poveste de utilizator. Poveștile utilizatorilor în acest caz sunt informațiile inițiale pe baza cărora este creat modulul. Poveștile utilizatorilor sunt diferite de cazurile de utilizare: o poveste de utilizator este scurtă - 1-2 paragrafe, în timp ce cazurile de utilizare sunt de obicei scrise destul de detaliate, cu un flux principal și alternativ - rezultând astfel aproximativ o pagină plus o diagramă (cea mai comună formalizare este propus în prezent în UML); Poveștile utilizatorilor sunt scrise de utilizatorii înșiși (care în XP fac parte din echipă), spre deosebire de cazurile de utilizare, care sunt de obicei scrise de un analist de sisteme. Lipsa de oficializare a descrierii datelor de intrare a proiectului în XP se urmărește a fi compensată prin includerea activă a clientului în procesul de dezvoltare ca membru cu drepturi depline al echipei și prin contactul constant cu clientul (comunicare activă și suport continuu cu feedback). ). În acest caz, extrem este gradul în care clientul este implicat în bucătăria de programare, care se datorează dorinței de a comprima timpul de dezvoltare prin comunicare și feedback.

Al doilea factor în accelerarea dezvoltării produselor este prezența unor grupuri mici și a programării în perechi (când doi programatori creează cod împreună într-un singur loc de muncă comun). Toate acestea vizează atingerea unui nivel ridicat de comunicare în grup, precum și detectarea problemelor (atât erorile, cât și termenele nerespectate) cât mai curând posibil. Programarea în pereche are scopul de a stabiliza proiectul, deoarece cu această metodologie există un risc mare de pierdere a codului din cauza plecării unui programator care nu a putut rezista programului intens de lucru. În acest caz, al doilea programator din pereche joacă rolul de „succesor” al codului (care în metodele clasice este implementat în documentația tehnică). De asemenea, este important cum exact sunt distribuite grupurile în spațiul de lucru - XP folosește un spațiu de lucru deschis, care presupune acces rapid și gratuit pentru toată lumea; De obicei, spațiul de lucru este construit în jurul unui cerc.

Al treilea factor în accelerarea dezvoltării procesului este realizarea primei soluții de lucru cele mai simple. În acest caz, extremitatea metodei este asociată cu un grad ridicat de risc de decizie din cauza superficialității analizei și a unui orar strâns. Implementat set minim funcțiile principale ale sistemului la prima și fiecare iterație ulterioară; funcționalitatea este extinsă cu fiecare iterație.

Practici

XP este de obicei caracterizat printr-un set de 12 acțiuni (practici) care trebuie efectuate pentru a obține un rezultat bun. Practicile XP nu definesc procesul XP în sine, dar XP definește acele practici - adică efectuarea practicilor nu garantează rezultate. Niciuna dintre practici nu este fundamental nouă, dar XP le aduce împreună.

Planificarea proceselor (joc de planificare). Întreaga echipă se reunește și se ia o decizie colectivă cu privire la ce proprietăți ale sistemului vor fi implementate în următoarea iterație. Setul de proprietăți este determinat de poveștile utilizatorilor. Complexitatea XP a fiecărei proprietăți este determinată de programatori înșiși.

Interacțiune strânsă cu clientul (feed-back, client la fața locului). Clientul trebuie să fie membru al echipei XP (client la fața locului). El scrie poveștile utilizatorilor, selectează poveștile care vor fi implementate într-o anumită iterație și răspunde la întrebările legate de afaceri. Clientul trebuie să fie un expert în domeniul automatizat. Este necesar să aveți în mod constant feedback de la client (feed-back).

Metafora sistemului. O metaforă bună a sistemului înseamnă denumirea simplă a claselor și a variabilelor. În viața reală, găsirea unei metafore este o sarcină extrem de dificilă; a găsi o metaforă bună nu este ușor. În orice caz, echipa trebuie să aibă reguli uniforme de denumire.

Arhitectură simplă (design simplu). Orice proprietate a sistemului ar trebui implementată cât mai simplu posibil. Programatorii din echipa XP lucrează sub motto-ul: „Nimic de prisos!” Este adoptată prima soluție de lucru cea mai simplă, pe care este implementat nivelul necesar de funcționalitate acest moment. Acest lucru economisește timpul programatorului.

Convenții de codificare. Sunt necesare standarde de codare pentru a sprijini alte practici: proprietatea partajată a codului, programarea perechilor și refactorizarea. Fără standard uniform Este cel puțin mai dificil să duci la îndeplinire aceste practici, iar în realitate este complet imposibil: grupul va lucra într-o lipsă constantă de timp. Nu sunt necesare standarde detaliate, trebuie standardizate doar lucrurile importante. Determinarea celor mai importante obiecte de standardizare în XP este subiectivă.

Refactorizarea. Refactorizarea este optimizarea codului existent spre simplificare, ceea ce implică o muncă constantă pentru simplificarea codului. Păstrând codul transparent și definind elementele de cod o singură dată, programatorii reduc numărul de erori pe care trebuie să le remedieze mai târziu. La implementarea fiecărei caracteristici noi a sistemului, programatorul trebuie să ia în considerare dacă este posibilă simplificarea codului existent și modul în care aceasta va ajuta la implementarea noii caracteristici. În plus, refactorizarea nu poate fi combinată cu proiectarea: dacă se creează un cod nou, refactorizarea trebuie amânată.

Programarea perechilor este una dintre cele mai cunoscute practici XP. Toți programatorii trebuie să lucreze în perechi: unul scrie codul, celălalt urmărește. Astfel, este necesar să plasați un grup de programatori într-un singur loc, ceea ce este cel mai ușor de făcut la sediul clientului (toți membrii echipei necesari sunt localizați geografic într-un singur loc); XP funcționează cel mai bine în echipe nedistribuite de programatori și utilizatori.

40 de ore de lucru pe săptămână. Un programator nu ar trebui să lucreze mai mult de 8 ore pe zi. Nevoia de ore suplimentare este un indicator clar al unei probleme în acest domeniu special de dezvoltare; În plus, clientul nu plătește orele suplimentare în XP. Găsirea motivelor orelor suplimentare și eliminarea lor cât mai rapidă este una dintre regulile de bază.

Proprietatea codului colectiv. Fiecare programator din echipa XP ar trebui să aibă acces la cod în orice parte a sistemului și să facă modificări la orice cod. Regula obligatorie: dacă un programator face modificări și după aceea sistemul nu funcționează corect, atunci acest programator este cel care trebuie să corecteze erorile. În caz contrar, funcționarea sistemului va semăna cu haosul total.

Schimbări frecvente ale versiunilor (versiuni mici). Iterația minimă este o zi, cea maximă este o lună; Cu cât sunt lansate mai des, cu atât vor fi identificate mai multe defecte ale sistemului. Primele versiuni ajută la identificarea deficiențelor în primele etape, apoi funcționalitatea sistemului este extinsă (pe baza acelorași povești ale utilizatorilor). Deoarece utilizatorul este implicat în procesul de dezvoltare începând cu prima versiune, el evaluează sistemul și oferă o poveste utilizator plus feedback. Pe baza acesteia, se determină următoarea iterație: care va fi noua versiune. XP se referă la furnizarea de feedback continuu utilizatorilor.

Integrare continuă. Integrarea noilor părți ale sistemului ar trebui să aibă loc cât mai des posibil, cel puțin o dată la câteva ore. Regula de bază a integrării este următoarea: integrarea poate fi efectuată dacă toate testele trec cu succes. Dacă testele eșuează, programatorul trebuie fie să facă corecții și apoi să integreze componentele sistemului, fie să nu le integreze deloc. Această regulă este strictă și lipsită de ambiguitate - dacă există cel puțin o eroare în partea creată a sistemului, atunci integrarea nu poate fi efectuată. Integrarea frecventă vă permite să obțineți un sistem finit mai rapid, în loc să petreceți o săptămână pe asamblare.

Testare Spre deosebire de majoritatea celorlalte metodologii, testarea în XP este una dintre cele mai importante componente. O abordare extremă este să scrieți teste înainte de a scrie cod. Fiecare modul trebuie să aibă un test unitar - un test al acestui modul; Astfel, în XP se efectuează teste de regresie (testare de returnare, „nedegradarea calității” la adăugarea de funcționalități). Majoritatea erorilor sunt corectate în etapa de codificare. Testele sunt scrise chiar de programatori; orice programator are dreptul de a scrie un test pentru orice modul. O alta principiu important: testul determină codul, și nu invers (această abordare se numește dezvoltare bazată pe test), adică o bucată de cod este introdusă în depozit dacă și numai dacă toate testele trec cu succes, altfel această modificare a codului este respinsă.

Deci, XP este extrem de disprețuitor de toate artefactele procesului de dezvoltare, cu excepția codului sursă. Procesul XP este foarte informal, dar necesită un nivel ridicat de autodisciplină. Dacă această regulă nu este respectată, atunci XP se transformă instantaneu într-un proces haotic și incontrolabil. XP nu necesită programatori să scrie o mulțime de rapoarte și să construiască o mulțime de modele. În XP, fiecare programator este considerat un muncitor calificat care își asumă responsabilitățile profesional și cu mare responsabilitate. Dacă echipa nu are acest lucru, atunci introducerea XP este absolut inutilă - este mai bine să începeți mai întâi să reconstruiți echipa. Riscul de dezvoltare este redus doar într-o echipă pentru care XP este ideal în toate celelalte cazuri, XP este procesul de dezvoltare cu cel mai mare grad de risc, deoarece pur și simplu nu există alte metode de reducere a riscurilor comerciale, cu excepția banalului factor uman; , în XP.

Riscurile existente ale utilizării metodologiei

Merită evidențiat riscurile XP care pot eșua un proiect dacă nu sunt luate în considerare și prevenite.

Joc de planificare. Programatorii implementează numai acele funcții care sunt necesare pentru caracteristicile selectate de client la o anumită iterație. Ca urmare a acestei decizii, dezvoltarea sistemului rămâne în spatele scenei, drept urmare în timpul dezvoltării este nevoie de a construi „stubs” și de a rescrie codul.

Participarea constantă a clientului (client la fața locului). În perioada de lucru la sistem, reprezentantul clientului se află în echipa de dezvoltare, iar cerințele pentru calificarea acestei persoane sau echipe sunt foarte mari. Dacă clientul nu este de acord să ofere personal la nivel de expert, atunci proiectul se încadrează în grupul cu cel mai mare risc.

Metaforă. Aspectul general al sistemului este determinat folosind o metaforă sau un set de metafore la care clientul și programatorii lucrează împreună. Dacă nu se ține log acest proces iar structura de numire nu este standardizată, un astfel de proces poate fi iterativ la nesfârșit.

Arhitectură simplă (design simplu). În fiecare moment, sistemul dezvoltat efectuează toate testele și suportă toate relațiile definite de programator, nu are cod duplicat și conține numărul minim posibil de clase și metode. Această regulă poate fi exprimată pe scurt după cum urmează: „Formulează fiecare gând o dată și o singură dată”. Acest principiu intră în conflict cu viteza de scriere a codului. Fără autodisciplină ridicată și standarde stricte de cod, sistemul devine imediat în pericol.

Schimbări frecvente ale versiunilor (versiuni mici). Sistemul este pus în funcțiune în decurs de câteva luni de la începerea implementării, fără a aștepta rezolvarea definitivă a tuturor problemelor ridicate. Frecvența lansării noilor versiuni poate varia de la zilnic la lunar. Este imposibil de testat o componentă mai mult sau mai puțin complexă într-o astfel de perioadă; clientul acționează de fapt ca un tester beta. Sistemele care necesită o funcționare fiabilă continuă (așa-numita cerință 24/7) sunt în pericol.

Refactorizarea sistemului. Arhitectura sistemului este în continuă evoluție. Proiectul actual este transformat, asigurându-se în același timp că toate testele sunt efectuate corect. Programarea extremă provine din faptul că este întotdeauna posibilă refacerea unei părți a sistemului și fără costuri speciale. Cu toate acestea, practica destul de des indică contrariul.

Integrare continuă. Cod nou se integrează în sistem existent cel târziu în câteva ore. După aceasta, sistemul este reasamblat într-un singur întreg și se execută toate testele. Dacă cel puțin unul dintre ele nu este efectuat corect, modificările efectuate sunt anulate. În acest caz, nu este întotdeauna clar cine exact va corecta erorile, nu numai cele locale, ci și cele cauzate de Cod greșit. Nu este planificată efectuarea de teste complexe în această etapă; În plus, modificările sunt salvate chiar dacă este detectată o eroare.

Programare pereche. Tot codul proiectului este scris de grupuri de două persoane folosind unul la locul de muncă. Factorul uman în acest caz joacă un rol decisiv: cuplul fie lucrează, fie nu, nu există a treia opțiune.

săptămâni de 40 de ore. Volumul orelor suplimentare nu poate depăși o săptămână lucrătoare ca durată. Chiar și cazurile izolate de ore suplimentare, repetate prea des, sunt un semn probleme serioase care necesită soluții urgente. După cum arată practica utilizării programării extreme (în ciuda numărului de exemple pozitive date de susținătorii acestei metode), orele suplimentare cu această abordare sunt regula, nu excepția, iar lupta împotriva problemelor în acest caz este un fenomen constant. Se intensifică în perioada de înlocuire a versiunii actuale brute a produsului cu alta - mai puțin brută. Dacă clientul nu primește dovezi consistente privind îmbunătățirea sistemului, atunci aveți o problemă serioasă.

Proprietatea colectivă. Fiecare programator are posibilitatea, dacă este necesar, de a îmbunătăți orice parte a codului din sistem în orice moment. Fără un standard de control al codului sursă, procesul de dezvoltare devine complet incontrolabil.

Deschideți spațiul de lucru. Echipa de dezvoltare este situată într-o cameră mare, înconjurată de încăperi mai mici. În centrul spațiului de lucru sunt instalate computere pe care lucrează perechi de programatori (și în conformitate cu principiile de mai sus, toate acestea ar trebui să fie amplasate la sediul clientului, deoarece acesta este implicat foarte activ în procesul de dezvoltare). Dacă există un grup de dezvoltatori și clienți distribuit geografic, proiectul necesită standardizarea protocolului de interacțiune (rapid, fiabil, fără probleme) sau se încadrează în grupul de risc.

Teste. Programatorii scriu teste unitare tot timpul. Luate împreună, aceste teste ar trebui să funcționeze corect. Pentru etapele de iterație, clienții scriu teste funcționale, care sunt, de asemenea, necesare pentru a funcționa corect. Cu toate acestea, în practică, acest lucru nu este întotdeauna realizabil. Pentru a lua decizia corectă, trebuie să înțelegeți cât va costa livrarea unui sistem cu un defect cunoscut și să comparați acest lucru cu costul amânării eliminării acestuia. Testele scrise de programatori înșiși (mai ales atunci când lucrează ore suplimentare) nu sunt pe deplin funcționale și cu siguranță nu țin cont de particularitățile muncii cu mai mulți utilizatori. De obicei, dezvoltatorii nu au suficient timp pentru teste mai avansate. Această problemă este rezolvată prin utilizarea contactoarelor pentru o anumită perioadă de timp, ceea ce este asociat cu rolul mare al factorului uman: deoarece documentatie tehnica este inițial absent, apoi informația este transmisă prin comunicare între programatori. Deși, desigur, este posibil să construiți un sistem de dezvoltare în așa fel încât aceiași oameni să se ocupe de totul de la început până la sfârșit. Este necesar să adăugăm la cele de mai sus că testarea sistemului nu se limitează la testarea componentelor (unităților); Testele de interacțiune dintre ele nu sunt mai puțin importante și același lucru este valabil și pentru testele de fiabilitate. Cu toate acestea, metoda de programare extremă nu prevede crearea de teste din această clasă. Acest lucru se explică prin faptul că astfel de teste în sine pot reprezenta destul de a cod complex(acest lucru este valabil mai ales pentru testele care imită funcționarea reală a sistemului). De asemenea, această tehnologie nu ține cont de o altă clasă importantă de teste - testele comportamentului sistemului atunci când volumul de informații procesate crește. Cu o frecvență mare de modificări de versiune, este imposibil din punct de vedere tehnologic să se efectueze un astfel de test, deoarece implementarea acestuia necesită un cod de proiect stabil și neschimbat, de exemplu, în decurs de o săptămână. În acest caz, va trebui fie să suspendați dezvoltarea componentelor, fie să creați o versiune paralelă a proiectului în timpul testului, care va rămâne neschimbată, în timp ce cealaltă se va modifica. Apoi va trebui să parcurgeți procesul de îmbinare a codului. Dar, în acest caz, testul va trebui creat din nou, deoarece metodele de programare extremă pur și simplu nu prevăd dezvoltarea de instrumente care să permită prezicerea comportamentului sistemului la anumite modificări. XP își propune să rezolve aceste probleme prin același factor uman și autodisciplină.

Nimic mai mult decât reguli. Membrii echipei care lucrează folosind tehnologia de programare extremă se angajează să respecte regulile menționate. Acestea nu sunt însă altceva decât reguli, iar echipa le poate schimba oricând dacă membrii săi ajung la un acord de principiu asupra modificărilor efectuate. Acest principiu este puternic dependent de factorul uman; Încălcarea disciplinei de dezvoltare implică nerespectarea termenelor limită și, ca urmare, duce la prăbușirea proiectului.

Ca urmare, obținem o metodă care este potențial foarte adaptabilă la cerințele proiectului în schimbare serioasă și frecventă, dar în același timp nu este lipsită de o serie de deficiențe fundamentale și este foarte dependentă de factorul uman.

Astfel, rezultatul aplicării metodei de programare extremă poate fi fie extrem de bun, fie extrem de rău.