Aplicații  

Testare extremă. Beneficiile programării extreme au sens atunci când echipa utilizează pe deplin cel puțin una dintre practicile XP. Deci, pentru ce merită să încerci? Principiile dezvoltării vii

Extreme Programming - sau, pe scurt, XP (eXtreme Programming) - este răspunsul comunității de programatori 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, instrumentele concepute pentru dezvoltarea rapidă a aplicațiilor au început să elimine orice altceva în mintea managerilor, inclusiv dezvoltatorii, clienții ș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 numărul de proiecte de succes s-au dovedit a fi dezamăgitoare.

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 de succes ș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 pe patru principii de bază: 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.

Programare extremă(XP) este o metodologie simplificată pentru organizarea dezvoltării software pentru echipele de dezvoltare mici și mijlocii care creează un produs software în condiții de cerințe neclare sau în schimbare rapidă.

Principalele obiective ale XP sunt creșterea încrederii clienților La produs software prin furnizarea de dovezi reale ale succesului procesului de dezvoltare şi reducerea bruscă a timpului de dezvoltare a produsului . În același timp, XP se concentrează pe minimizarea erorilor din primele etape de dezvoltare. Acest lucru vă permite să obțineți viteza maximă de eliberare a produsului finit și face posibil să vorbiți despre predictibilitatea muncii. Aproape toate tehnicile XP au ca scop îmbunătățirea calității produsului software.

Principiile XP

Principiile principale sunt:

  • Iterativitatea. Dezvoltarea se realizează în iterații scurte cu o relație activă cu clientul. Iterațiile ca atare sunt propuse a fi 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 (UI) în acest caz sunt informațiile inițiale pe baza cărora este creat modulul. Ele sunt diferite de cazurile de utilizare (VI). Descrierea PI este scurtă - 1-2 paragrafe, în timp ce VI-urile sunt de obicei descrise suficient de detaliat, cu fluxurile principale și alternative și sunt completate de model. Interfețele de utilizator sunt scrise de utilizatorii înșiși, care în XP fac parte din echipă, spre deosebire de interfețele care sunt descrise de un analist de sisteme. Lipsa de formalizare a descrierii datelor de intrare a proiectului în XP este căutată să fie compensată prin includerea activă a clientului în procesul de dezvoltare ca membru cu drepturi depline al echipei.
  • Simplitatea soluțiilor. Primul cel mai simplu este acceptat solutie de lucru. Natura extremă a metodei este asociată cu un grad ridicat de risc de decizie din cauza superficialității analizei și a unui orar strâns. Un set minim de funcții principale ale sistemului este implementat la prima și fiecare iterație ulterioară; funcționalitatea este extinsă cu fiecare iterație.
  • Dezvoltare intensivă în grupuri mici(nu mai mult de 10 persoane) și programarea perechilor(când doi programatori creează cod împreună la un loc de muncă comun), comunicare activăîn cadrul unui grup și între grupuri. Toate acestea au ca scop detectarea problemelor (atât erorile, cât și termenele limită ratate) cât mai curând posibil. Programarea perechilor are ca scop rezolvarea problemei stabilizării proiectului. La utilizarea metodologiei XP, există un risc mare de a pierde codul din cauza plecării unui programator care nu a putut face față programului intens de lucru. În acest caz, al doilea programator al perechii joacă rolul de „succesor” al codului. De asemenea, este important cum exact sunt distribuite grupurile în spațiul de lucru - XP folosește open spatiu de lucru, care presupune acces rapid și gratuit de către toată lumea pentru toată lumea.
  • Feedback cu clientul, al cărui reprezentant este de fapt implicat în procesul de dezvoltare.
  • Grad suficient de curajși dorința de a-și asuma riscuri.

Tehnici XP (practici)

XP este de obicei caracterizat de un set de 12 reguli (practici) care trebuie urmate pentru a obține un rezultat bun. Niciuna dintre practici nu este fundamental nouă, dar XP le aduce împreună.

  1. Planificarea procesului.Întreaga echipă de dezvoltare 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. Complexitatea implementării fiecărei proprietăți este determinată de programatori înșiși.
  2. Interacțiune strânsă cu clientul. Reprezentantul clientului trebuie să fie membru al echipei XP. El scrie interfața de utilizare, selectează poveștile care vor fi implementate într-o anumită iterație și răspunde la întrebările legate de afaceri. Reprezentantul clientului trebuie să fie expert într-un domeniu automatizat. Este necesară disponibilitatea constantă părere cu un reprezentant al clientului.
  3. Reguli de denumire la nivel de sistem. Convențiile bune de denumire a sistemului sugerează ușurința de a numi clase si variabile. Echipa de dezvoltare ar trebui să aibă reguli uniforme de denumire.
  4. Arhitectură simplă. 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.
  5. Refactorizarea. Aceasta este optimizarea codului existent pentru a-l simplifica. Această lucrare ar trebui efectuată în mod constant. 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 trebuie combinată cu proiectarea: dacă se creează un cod nou, refactorizarea ar trebui amânată.
  6. Programarea perechilor. 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. XP funcționează cel mai bine în echipe nedistribuite de programatori și utilizatori.
  7. 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 acel domeniu special de dezvoltare. Găsirea motivelor orelor suplimentare și eliminarea lor cât mai rapidă este una dintre regulile de bază.
  8. Proprietatea codului colectiv. Fiecare programator din echipă trebuie să aibă acces la codul oricărei părți a sistemului și dreptul de a face 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.
  9. Standarde de codificare unificate. Sunt necesare standarde de codare pentru a sprijini alte practici: proprietatea partajată a codului, programarea perechilor și refactorizarea. Fără un standard unificat, este cel puțin mai dificil de realizat aceste practici, iar în realitate este complet imposibil: grupul va lucra într-o lipsă constantă de timp. Echipa care lucrează la proiect perioadă lungă de timp. Oamenii vin și pleacă. Nimeni nu codifică singur și codul aparține tuturor. Întotdeauna vor exista momente când trebuie să înțelegeți și să ajustați codul altcuiva. Dezvoltatorii vor elimina codul duplicat, vor analiza și îmbunătăți clasele altor persoane etc. În timp, va fi imposibil de spus cine este autorul unei anumite clase. Prin urmare, toată lumea trebuie să se supună standardelor comune de codare - formatarea codului, denumirea claselor, variabilelor, constantelor, stilul de comentariu. Cele de mai sus înseamnă că toți membrii echipei trebuie să cadă de acord asupra standardelor comune de codare. Nu contează care dintre ele, dar toată lumea este obligată să le asculte.
  10. Lansări mici. Iterația minimă este o zi, cea maximă este o lună; Cu cât se fac mai des lansări, 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 interfeței de utilizare. Deoarece utilizatorul este implicat în procesul de dezvoltare de la prima versiune, el evaluează sistemul și oferă istoricul utilizatorului și comentarii. Pe baza acesteia, se determină următoarea iterație, adică cum va fi noua lansare. XP se referă la furnizarea de feedback continuu utilizatorilor.
  11. 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.
  12. Testare. Spre deosebire de majoritatea altor metodologii, testarea în XP este una dintre cele mai importante componente. Abordarea extremă presupune că testele sunt scrise înainte ca codul să fie scris . Fiecare modul trebuie să aibă un test unitar - un test al acestui modul. Astfel, în XP, se efectuează teste de regresie, „fără degradarea calității” atunci când se adaugă funcționalitate. Majoritatea erorilor sunt corectate în etapa de codare. Testele sunt scrise de programatori înșiși, oricare dintre ei are dreptul de a scrie un test pentru orice modul. O alta principiu important: testul determină codul, și nu invers (dezvoltare bazată pe teste), 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ă.

Procesul XP este informal, dar necesită nivel inalt auto-disciplina. 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 restructurarea echipei. 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 factorului uman; în XP.

Extreme Programming (XP) este una dintre metodologiile flexibile de dezvoltare software. Autorii metodologiei sunt Kent Beck, Ward Cunningham, Martin Fowler și alții.

Joc de planificare

Lumea noastră este prea schimbătoare și imprevizibilă pentru a ne baza pe constanța situației. Același lucru se întâmplă și în dezvoltarea de software: cu un sistem rar, puteți spune că forma sa finală a fost cunoscută dinainte în detaliu chiar de la începutul dezvoltării. De obicei, apetitul clientului vine în timp ce mănâncă: el dorește constant să schimbe ceva, să îmbunătățească ceva sau să arunce ceva din sistem. Aceasta este variabilitatea cerințelor de care toată lumea se teme atât de mult. Din fericire, omului i se oferă capacitatea de a prezice opțiuni posibileși astfel să țină situația sub control.
În Extreme Programming, planificarea este o parte integrantă a dezvoltării și faptul că planurile se pot schimba este luat în considerare încă de la început. Punctul de sprijin, tehnica care vă permite să preziceți situația și să suportați fără durere schimbările, este jocul de planificare. Acest joc vă permite să adunați rapid cerințele de sistem cunoscute, să le evaluați și să planificați dezvoltarea lor în funcție de priorități.
Ca orice alt joc, planificarea își are participanții și scopul său. Cifra cheie este, desigur, clientul. El este cel care comunică nevoia pentru cutare sau cutare funcționalitate. Programatorii oferă o evaluare aproximativă a fiecărei funcționalități. Frumusețea jocului de planificare constă în unitatea scopului și solidaritatea dintre dezvoltator și client: în caz de victorie, toată lumea câștigă, în caz de înfrângere, toată lumea pierde. Dar, în același timp, fiecare participant merge pe drumul său către victorie: clientul selectează cele mai importante sarcini în conformitate cu bugetul, iar programatorul evaluează sarcinile în conformitate cu capacitatea sa de a le implementa.
Programarea extremă presupune că dezvoltatorii sunt capabili să decidă ei înșiși cât timp le va dura să își îndeplinească sarcinile și care dintre ei ar fi mai dispus să rezolve o problemă și cine alta.
Într-o situație ideală, jocul de planificare dintre client și programator ar trebui să fie jucat la fiecare 3-6 săptămâni, până începe următoarea iterație de dezvoltare. Acest lucru face destul de ușor să faceți ajustări pe baza succeselor și eșecurilor iterației anterioare.

Planul de lansare

Planul de lansare definește datele de lansare și declarațiile utilizatorilor care vor fi implementate în fiecare dintre ele. Pe baza acestui lucru, puteți alege formulări pentru următoarea iterație. În timpul unei iterații, testele de acceptare sunt produse și rulate în cadrul acelei iterații și a tuturor celor ulterioare pentru a se asigura că programul funcționează corect. Planul poate fi revizuit dacă există o întârziere sau un avans semnificativ la sfârșitul uneia dintre iterații.
Iterații. Iterația face procesul de dezvoltare dinamic. Nu este nevoie să vă planificați sarcinile software cu mult timp înainte. În schimb, este mai bine să aveți o întâlnire de planificare la începutul fiecărei iterații. Nu are rost să încerci să implementezi ceva care nu a fost planificat. Veți avea în continuare timp să implementați aceste idei atunci când vor fi lansate conform planului de lansare.
Prin adoptarea obiceiului de a nu adăuga funcționalități în avans și folosind planificarea anticipată, vă puteți adapta cu ușurință la cerințele în schimbare ale clienților.

Planificarea iterației

Planificarea iterației începe cu o întâlnire la începutul fiecărei iterații pentru a dezvolta un plan de pași pentru rezolvarea problemelor software. Fiecare iterație ar trebui să dureze de la una până la trei săptămâni. Formulările din cadrul unei iterații sunt sortate în ordinea importanței lor pentru client. În plus, se adaugă sarcini care nu au putut trece testele de acceptare și necesită lucrări suplimentare. Declarațiile și rezultatele testelor sunt traduse în probleme software. Sarcinile sunt notate pe carduri care formează un plan detaliat de iterație. Este nevoie de una până la trei zile pentru a rezolva fiecare problemă. Sarcinile care necesită mai puțin de o zi pot fi grupate împreună, iar sarcinile mari pot fi împărțite în câteva mai mici. Dezvoltatorii estimează sarcinile și termenele limită pentru finalizarea acestora. Este foarte important ca un dezvoltator să determine cu exactitate timpul de execuție al unei sarcini. Poate fi necesar să se reevalueze o anumită limbă și să se revizuiască planul de lansare după fiecare trei sau cinci iterații - acest lucru este complet acceptabil. Daca implementezi mai intai cele mai importante domenii de lucru, atunci vei avea intotdeauna timp sa faci maxim posibil pentru clientii tai. Un stil de dezvoltare iterativ îmbunătățește procesul de dezvoltare.

Întâlnire în picioare

În fiecare dimineață are loc o întâlnire pentru a discuta problemele, soluțiile acestora și pentru a întări concentrarea echipei. Întâlnirea se ține în picioare pentru a evita discuțiile îndelungate care nu sunt interesante pentru toți membrii echipei.
Într-o întâlnire tipică, majoritatea participanților nu contribuie cu nimic, doar participă pentru a auzi ce au de spus alții. Un numar mare de Timpul oamenilor este pierdut pentru a obține o cantitate mică de comunicare. Prin urmare, a avea pe toată lumea la întâlniri ia resurse din proiect și creează haos în planificare.
Acest tip de comunicare necesită o întâlnire permanentă. Este mult mai bine să ai o întâlnire scurtă și obligatorie decât multe întâlniri lungi la care totuși trebuie să participe majoritatea dezvoltatorilor.
Dacă aveți întâlniri permanente zilnice, atunci la toate celelalte întâlniri ar trebui să participe numai acele persoane care sunt necesare și vor aduce ceva la masă. Mai mult, este chiar posibil să se evite unele întâlniri. Cu participanții limitati, majoritatea întâlnirilor pot fi ținute spontan în fața unui monitor, unde schimbul de idei este mult mai intens.
Întâlnirea zilnică de dimineață nu este o altă pierdere de timp. Vă va permite să evitați multe alte întâlniri și vă va economisi mai mult timp decât îl petreceți.

Simplitate

Un design simplu durează întotdeauna mai puțin timp decât unul complex. Așa că fă întotdeauna cele mai simple lucruri care vor funcționa. Este întotdeauna mai rapid și mai ieftin să înlocuiți codul complex imediat, înainte de a petrece mult timp lucrând la el. Păstrați lucrurile cât mai simple posibil, fără a adăuga funcționalități înainte de planificare. Rețineți: păstrarea unui design simplu este o muncă grea.

Sistem metaforic

Alegerea unui sistem de metafore este necesară pentru a menține echipa în același cadru atunci când se numesc clase și metode. Modul în care vă denumiți obiectele este foarte important pentru înțelegerea designului general al sistemului și reutilizarea codului. Dacă un dezvoltator este capabil să prezică corect cum ar putea fi numit un obiect existent, acest lucru duce la economii de timp. Utilizați un sistem de denumire pentru obiectele dvs. pe care oricine îl poate înțelege fără cunoștințe specifice de sistem.

Client la locul de muncă

Principala problemă în dezvoltarea software-ului este lipsa de cunoștințe a programatorilor în domeniul de studiu dezvoltat. Programarea extremă a găsit o cale de ieșire din această situație. Nu, acesta nu este un stagiu de dezvoltator la întreprinderea clientului - atunci el nu va dori să programeze. Dimpotrivă, este participarea clientului la procesul de dezvoltare.
Poate un programator, fără să înțeleagă temeinic esența problemei și fără a fi telepat, să ghicească ce vrea clientul? Răspunsul este evident. Cel mai într-un mod simplu depășiți astfel de inconveniente - iar programarea extremă ne învață să găsim cel mai mult solutii simple- va adresa clientului o întrebare directă. Abordări mai riguroase necesită o analiză preliminară cuprinzătoare a zonei în curs de dezvoltare. În anumite cazuri acest lucru este justificat, deși este mai scump. Experiența reală în derularea proiectelor banale arată că este imposibil să colectezi toate cerințele în avans. Mai mult, chiar dacă presupunem că toate cerințele sunt colectate în prezent, va exista totuși un singur blocaj: programele, ca tot ce este în natură, nu sunt create instantaneu, iar între timp procesele de afaceri se pot schimba. Acest lucru ar trebui luat în considerare.
Mulți se îndoiesc de posibilitatea implicării clientului în procesul de dezvoltare. Într-adevăr, clienții sunt diferiți. Dacă nu este posibilă atragerea clientului sau a reprezentantului acestuia, uneori este indicat să angajați temporar un specialist în domeniul în curs de dezvoltare. Acest pas va reduce ambiguitățile în lucru, va crește viteza de dezvoltare și va aduce proiectul mai aproape de ceea ce dorește clientul să primească. Acest lucru poate fi benefic și din punct de vedere financiar: la urma urmei, salariul unui programator este uneori semnificativ mai mare decât salariul specialiștilor din alte industrii.
Povestea utilizatorului. Povestea utilizatorului (ceva ca povestea unui utilizator) este o descriere a modului în care ar trebui să funcționeze sistemul. Fiecare poveste de utilizator este scrisă pe un card și reprezintă o parte din funcționalitatea sistemului care are sens logic din punctul de vedere al Clientului. Formularul este unul sau două paragrafe de text care este de înțeles de utilizator (nu foarte tehnic).
Povestea utilizatorului este scrisă de Client. Acestea sunt similare cu cazurile de utilizare a sistemului, dar nu se limitează la interfața cu utilizatorul. Pentru fiecare poveste sunt scrise teste funcționale pentru a confirma asta această poveste implementate corect - se mai numesc si teste de acceptare.

Testarea înainte de începerea dezvoltării

Testarea, în ea înțelegere clasică, este o procedură destul de plictisitoare. De obicei ei angajează un tester care efectuează periodic aceleași acțiuni și așteaptă ziua în care este transferat în sfârșit pe o altă funcție sau apare oportunitatea de a schimba locul de muncă.
În programarea extremă, rolul testării este mai interesant: acum testul vine pe primul loc, iar apoi codul. Cum să testezi ceva care încă nu există? Răspunsul este simplu și banal: testați-vă gândurile - la ce să vă așteptați de la o viitoare bucată de program sau funcționalitate. Acest lucru vă va permite să înțelegeți mai bine ce trebuie să facă programatorii și să verificați funcționalitatea codului imediat ce este scris.
Dar nici testul poate să nu funcționeze. Deci ce, scrie un test pentru un test? Și apoi test pentru test și așa mai departe la infinit? Deloc. Testul pentru test va înlocui codul. Cum așa? Dar uite: imaginați-vă că trebuie să fixați piulița în mijlocul șurubului, astfel încât să nu se rotească. Ce fac ei pentru asta? Înșurubați a doua piuliță aproape de prima, astfel încât fiecare piuliță să o împiedice pe cea adiacentă să se rotească. Este același lucru în programare: testul testează codul, iar codul testează testul.
Experiența arată că această abordare nu numai că nu încetinește, ci și accelerează dezvoltarea. La urma urmei, știind ce trebuie făcut și cantitatea necesară de muncă va economisi timp prin refuzul de a vinde piese care nu sunt în prezent solicitate.

Programarea perechilor

Tot codul pentru sistemul de producție este scris în perechi. Doi dezvoltatori stau unul lângă altul. Unul tastează, celălalt se uită. Se schimbă din când în când. Nu este permis să lucrezi singur. Dacă dintr-un motiv oarecare al doilea din pereche a omis ceva (bolnav, pensionar etc.), el este obligat să revizuiască toate modificările făcute de primul.
Sună neobișnuit, dar după o scurtă perioadă de adaptare, majoritatea oamenilor lucrează bine în perechi. Le place chiar și pentru că munca se realizează considerabil mai repede. Se aplică principiul „Un cap este bun, dar doi este mai bine”. De obicei, cuplurile găsesc mai multe solutii optime. În plus, calitatea codului crește semnificativ, numărul de erori scade și schimbul de cunoștințe între dezvoltatori este accelerat. În timp ce o persoană se concentrează pe viziunea strategică a obiectului, a doua pune în aplicare proprietățile și metodele acestuia.

Schimbarea pozițiilor

În timpul următoarei iterații, toți lucrătorii ar trebui să fie mutați în noi domenii de lucru. Astfel de mișcări sunt necesare pentru a evita izolarea cunoștințelor și pentru a elimina blocajele. Deosebit de fructuoasă este înlocuirea unuia dintre dezvoltatori în programarea în pereche.

Proprietatea codului colectiv

Proprietatea partajată a codului încurajează dezvoltatorii să trimită idei pentru toate părțile proiectului, nu doar pentru propriile module. Orice dezvoltator poate schimba orice cod pentru a extinde funcționalitatea și a remedia erorile.
La prima vedere pare un haos. Cu toate acestea, ținând cont de faptul că cel puțin orice cod a fost creat de câțiva dezvoltatori, testele vă permit să verificați corectitudinea modificărilor efectuate și că în viata reala Deși încă trebuie să înțelegeți codul altcuiva într-un fel sau altul, devine clar că proprietatea colectivă a codului simplifică foarte mult schimbările și reduce riscul asociat cu specializarea ridicată a unuia sau altuia membru al echipei.

Convenția de codificare

Sunteți într-o echipă care lucrează la acest proiect de mult timp. Oamenii vin și pleacă. Nimeni nu codifică singur și codul aparține tuturor. Întotdeauna vor exista momente când trebuie să înțelegeți și să ajustați codul altcuiva. Dezvoltatorii vor elimina sau vor schimba codul duplicat, vor analiza și îmbunătăți clasele altor persoane etc. În timp, va fi imposibil de spus cine este autorul unei anumite clase.
Prin urmare, toată lumea trebuie să se supună standardelor comune de codare - formatarea codului, denumirea claselor, variabilelor, constantelor, stilul de comentariu. În acest fel, vom fi siguri că atunci când vom face modificări în codul altcuiva (care este necesar pentru progrese agresive și extreme înainte), nu îl vom transforma în Babel Pandemonium.
Cele de mai sus înseamnă că toți membrii echipei trebuie să cadă de acord asupra standardelor comune de codare. Nu contează care dintre ele. Regula este că toată lumea le respectă. Cei care nu vor să le respecte părăsesc echipa.

Integrare frecventă

Dezvoltatorii ar trebui să-și integreze și să elibereze codul la fiecare câteva ore, dacă este posibil. În orice caz, nu trebuie să păstrați niciodată modificările mai mult de o zi. Integrarea frecventă evită alienarea și fragmentarea în dezvoltare, unde dezvoltatorii nu pot comunica în sensul împărtășirii ideilor sau al reutilizarii codului. Toată lumea trebuie să lucreze cu cel mai mult ultima versiune.
Fiecare pereche de dezvoltatori ar trebui să contribuie cu codul lor de îndată ce este posibil să facă acest lucru. Acest lucru se poate întâmpla atunci când toate UnitTests trec 100%. Prin trimiterea modificărilor de mai multe ori pe zi, reduceți problemele de integrare la aproape zero. Integrarea este o activitate „plătiți acum sau plătiți mai mult mai târziu”. Prin urmare, prin integrarea modificărilor în trepte mici în fiecare zi, nu veți fi nevoit să petreceți o săptămână încercând să legați sistemul înainte ca proiectul să fie livrat. Lucrați întotdeauna la cea mai recentă versiune a sistemului.

Săptămâna de lucru de patruzeci de ore

O persoană, mai ales dacă este programator, este capabilă să facă multe de dragul afacerii: să stea târziu la serviciu, să meargă la muncă în weekend, să renunțe la vacanță, să stea treaz câteva zile stând la tastatură... În general, ce poți face de dragul activității tale preferate. Dar programarea extremă este în mod categoric împotriva unui astfel de sacrificiu de sine și încălcarea standardelor acceptate ale legislației muncii.
Acest lucru este dictat nu numai de considerente de legalitate și umanitate, ci, în primul rând, de necesitatea creșterii eficienței muncii și a organizării stricte. La urma urmei, programarea extremă este un joc colectiv, conceput nu pentru indivizi, ci pentru întregul grup. Și un lucru precum, de exemplu, programarea în pereche este posibil doar atunci când bioritmurile participanților săi sunt sincronizate. Și este imposibil dacă o persoană vine la nouă la muncă, iar a doua la doisprezece, sau cineva decide că e mai bine să lucreze sâmbăta și duminica, în timp ce celălalt este incomod.
Dar cel mai important lucru este că, pentru a menține sănătatea și performanța, o persoană are nevoie de odihnă adecvată. Ziua de lucru de opt ore și săptămâna de lucru de cinci zile sunt stabilite tocmai din motive de productivitate maximă. În multe companii occidentale, părăsirea cu întârziere a serviciului este considerată ca fiind o performanță bună sau o incapacitate de a-și gestiona în mod corespunzător timpul de lucru. În cele mai multe cazuri, acest lucru este adevărat. Și din punct de vedere medical, întârzierile la locul de muncă duc la oboseală constantă, iritabilitate și scăderea activității creierului. Este acest lucru eficient? Cum putem organiza o comunicare constantă deschisă între dezvoltatorii dintr-o astfel de echipă și va fi posibilă programarea în pereche? Răspunsul este negativ. Standardele sunt standarde și trebuie respectate.

Concluzie

Aceste metode nu sunt puse împreună la întâmplare. Combinația lor consecventă poate aduce procesul de dezvoltare în rezonanță intelectuală, crescând semnificativ calitatea produsului și grăbindu-i timpul de lansare. Principala frumusețe a tuturor programărilor extreme este predictibilitatea și minimizarea costurilor de dezvoltare; furnizarea clientului cu produsul pe care dorește să-l primească în momentul eliberării; și, desigur, comunicarea și formarea dezvoltatorilor la locul de muncă.

Bibliografie:

Dezvoltare (dezvoltare condusă de funcțiile sistemului), etc.

Potrivit autorilor XP, această tehnică nu urmărește atât unele modele generale de acțiune, cât folosește o combinație a următoarelor tehnici. Cu toate acestea, fiecare tehnică este importantă și, fără utilizarea ei, dezvoltarea este considerată a nu fi XP, potrivit lui Kent Beck, unul dintre autorii acestei abordări împreună cu Ward Cunningham și Ron Jeffries.

  • Joc de planificare în direct

    Sarcina sa este de a determina cât mai repede posibil cantitatea de muncă care trebuie făcută înainte de următoarea versiune de software. Decizia este luată, în primul rând, pe baza priorităților clientului (adică, nevoile acestuia, de ce are nevoie de la sistem pentru a-și conduce afacerea cu mai mult succes) și, în al doilea rând, pe baza evaluărilor tehnice (adică estimări ale complexității). de dezvoltare, compatibilitate cu alte elemente ale sistemului etc.). Planurile sunt schimbate de îndată ce încep să se îndepărteze de realitate sau de dorințele clientului.

  • Modificări frecvente ale versiunii (versiuni mici)

    Prima versiune de lucru ar trebui să apară cât mai repede posibil și ar trebui să înceapă să fie utilizată imediat. Următoarele versiuni sunt pregătite la intervale destul de scurte (de la câteva ore cu modificări minore în program mic, până la o lună sau două cu procesare serioasă a unui sistem mare).

  • Metafora sistemului

    Metafora, într-o formă destul de simplă și de înțeles pentru echipă, ar trebui să descrie mecanismul de bază al sistemului. Acest concept amintește de arhitectură, dar ar trebui să descrie esența principală a deciziilor tehnice luate mult mai simplu, în doar una sau două fraze.

  • Soluții simple de proiectare

    În orice moment, sistemul ar trebui să fie proiectat cât mai simplu posibil. Nu este nevoie să adăugați funcții în avans - doar după o solicitare explicită pentru aceasta. Toată complexitatea inutilă este eliminată de îndată ce este descoperită.

  • Dezvoltare bazată pe teste

    Dezvoltatorii scriu mai întâi teste, apoi încearcă să-și implementeze modulele astfel încât testele să funcționeze. Clienții scriu în avans teste care demonstrează principalele capabilități ale sistemului, astfel încât să poată vedea că sistemul funcționează efectiv.

  • Refactorizare continuă

    Programatorii reproșează în mod constant sistemul pentru a elimina complexitatea inutilă, a crește înțelegerea codului, a crește flexibilitatea acestuia, dar fără a-i schimba comportamentul, care este verificat prin rularea după fiecare reluare a testelor. În același timp, se preferă soluțiile mai elegante și mai flexibile, față de cele care pur și simplu dau rezultatul dorit. Componentele reproiectate fără succes ar trebui identificate în timpul execuției testului și revenite la ultima stare intactă (împreună cu componentele care depind de ele).

  • Programarea perechilor

    Codarea este efectuată de doi programatori pe un computer. Asocierea este arbitrară și variază de la sarcină la sarcină. Cel în mâinile căruia încearcă tastatura în cel mai bun mod posibil rezolva problema actuala. Al doilea programator analizează munca primului și dă sfaturi, ia în considerare consecințele anumitor decizii, teste noi, soluții mai puțin directe, dar mai flexibile.

  • Proprietatea colectivă a codului

    În orice moment, orice membru al echipei poate schimba orice parte a codului. Nimeni nu ar trebui să aibă propria sa zonă de responsabilitate, întreaga echipă este responsabilă pentru tot codul.

  • Integrare continuă

    Sistemul este asamblat și este supus testării de integrare cât mai des posibil, de câteva ori pe zi, de fiecare dată când câțiva programatori termină de implementat următoarea funcție.

  • 40 de ore de lucru pe săptămână

    Orele suplimentare sunt văzute ca un semn al unor probleme mai mari în proiect. Nu este permisă munca suplimentară timp de 2 săptămâni la rând - aceasta îi epuizează pe programatori și le face munca mult mai puțin productivă.

  • Includerea clientului în echipă (client la fața locului)

    Echipa de dezvoltare include întotdeauna un reprezentant al clienților care este disponibil pe tot parcursul zilei de lucru și este capabil să răspundă la toate întrebările despre sistem. Responsabilitatea lui este să răspundă prompt întrebărilor de orice tip referitoare la funcțiile sistemului, interfața acestuia, performanța necesară, operatiune adecvata sisteme în situații complexe, necesitatea menținerii comunicării cu alte aplicații etc.

  • Utilizarea codului ca mijloc de comunicare

    Codul este văzut ca cel mai important mijloc de comunicare în cadrul unei echipe. Claritatea codului este una dintre prioritățile principale. Respectarea standardelor de codare care oferă această claritate este imperativă. Astfel de standarde, pe lângă claritatea codului, ar trebui să asigure un limbaj minim (fără duplicarea codului și a informațiilor) și ar trebui să fie acceptate de toți membrii echipei.

  • Deschideți spațiul de lucru

    Echipa este găzduită într-o cameră destul de spațioasă pentru a facilita comunicarea și a permite discuții de grup atunci când planificați și luați decizii tehnice importante.

  • Schimbarea regulilor după cum este necesar (doar reguli)

    Fiecare membru al echipei trebuie să accepte regulile enumerate, dar dacă este nevoie, echipa le poate schimba dacă toți membrii săi sunt de acord cu această modificare.

După cum se poate vedea din tehnicile utilizate, XP este conceput pentru a fi utilizat în cadrul unor echipe mici (nu mai mult de 10 programatori), ceea ce este subliniat de autorii acestei tehnici. Marime mai mare comanda distruge simplitatea comunicării necesară succesului și face imposibilă aplicarea multora dintre tehnicile enumerate.

Avantajele XP, dacă poate fi utilizat, sunt o mai mare flexibilitate, capacitatea de a face rapid și precis modificări software-ului ca răspuns la modificările cerințelor și dorințele individuale ale clienților, calitate superioară codul rezultat și nu este nevoie să convingi clienții că rezultatul corespunde așteptărilor lor.

Dezavantajele acestei abordări sunt imposibilitatea implementării unor proiecte suficient de mari și complexe în acest stil, incapacitatea de a planifica calendarul și intensitatea muncii a proiectului pe un termen suficient de lung și de a prezice clar rezultatele unui proiect pe termen lung în ceea ce privește raportul dintre calitatea rezultatului și costurile de timp și resurse. De asemenea, se poate observa că XP nu este potrivit pentru acele cazuri în care solutii posibile nu sunt găsite imediat pe baza experienței acumulate anterior, dar necesită cercetări preliminare.

XP, ca set de tehnici descrise, a fost utilizat pentru prima dată în timpul lucrului la proiectul C3 (Chrysler Comprehensive Compensation System, dezvoltarea unui sistem de contabilizare a beneficiilor angajaților la Daimler Chrysler). Din cei 20 de participanți la acest proiect, 5 (inclusiv cei 3 autori principali ai XP menționați mai sus) au publicat 3 cărți și o cantitate mare articole dedicate XP. Acest proiect este menționat în mod repetat în diverse surse ca exemplu de utilizare a acestei tehnici. Următoarele date sunt compilate din articolele menționate, minus dovezile anecdotice, și ilustrează problemele cu unele tehnici XP atunci când sunt aplicate la proiecte destul de complexe.

Proiectul a început în ianuarie 1995. Din martie 1996, după includerea lui Kent Beck, a fost rulat folosind XP. Până atunci, deja depășise bugetul și planurile pentru implementarea treptată a funcțiilor. Echipa de dezvoltare a fost redusă, iar timp de aproximativ șase luni după aceasta, proiectul s-a dezvoltat cu succes. În august 1998, a apărut un prototip care putea deservi aproximativ 10.000 de angajați. Proiectul era de așteptat inițial să fie finalizat la jumătatea anului 1999, iar software-ul rezultat va fi folosit pentru a gestiona beneficiile pentru cei 87.000 de angajați ai companiei. A fost oprit în februarie 2000, după 4 ani de rulare XP din cauza nerespectării termenelor și bugetului complet. Software-ul creat nu a fost niciodată folosit pentru a lucra cu date a peste 10.000 de angajați, deși s-a demonstrat că poate gestiona datele a 30.000 de angajați ai companiei. Persoana care a jucat rolul clientului inclus în echipa de proiect a renunțat după câteva luni de astfel de muncă, incapabil să suporte volumul de muncă și nu a primit niciodată o înlocuire adecvată până la sfârșitul proiectului.

Programarea extremă este o abatere de la procesul tradițional de creare a programelor - în loc de planificarea, analiza și proiectarea unică a unui sistem cu o perspectivă pe termen lung, programatorii implementează acum toate aceste operațiuni treptat în timpul dezvoltării.

La început a existat un model „cascada” (Fig. 1a): cerem utilizatorilor să-și formuleze clar cerințele; dezvoltăm un proiect de sistem care va face tot ce doresc utilizatorii; scriem cod; testăm programul pentru a ne asigura că face de fapt ceea ce ne dorim să facă. Totul iese grozav.

În realitate, lucrurile erau departe de a fi atât de roz. Înainte de începerea dezvoltării, utilizatorii nu sunt încă capabili să-și formuleze clar cerințele. Nu au știut întotdeauna ce vor, uneori s-au contrazis și și-au schimbat părerile asupra problemei. Dar nu este vorba doar de utilizatori. Noi, programatorii, după ce am parcurs trei sferturi din drum și am constatat că de fapt finalizasem doar o treime din lucrare, ne-am bucurat de acest lucru ca un succes extraordinar.

Deci, un ciclu lung de dezvoltare este rău pentru că nu se poate adapta la schimbare. Atunci poate că trebuie să scurtăm ciclul și toate problemele vor fi rezolvate? În fig. Figura 1b ilustrează transformarea modelului „cascada” într-un model iterativ.

Să vă reamintim că modelul cascadă nu a apărut de nicăieri - a fost o reacție firească la acele estimări șocante care au arătat: costul modificărilor programului crește foarte mult în timp. Dacă acesta este într-adevăr cazul, atunci este necesar să luați cele mai importante și de anvergură decizii în cea mai timpurie etapă a ciclului de viață al programului, astfel încât să nu fiți nevoit să plătiți scump pentru ele mai târziu.

Comunitatea academică de dezvoltare de software se angajează să rezolve problema cost ridicat schimbări și au creat noi tehnologii - baze de date relaționale, programare modulară, ascunderea informațiilor. Dar dacă toată această muncă și-a epuizat deja potențialul? Și vom putea găsi Metoda noua reduce costul modificărilor fără a tăia „cascada” în părți, ci pur și simplu amestecând toate componentele sale? Rezultatul este prezentat în Figura 1c. Am numit aceasta „Programare extremă” (XP).

Anatomia XP

XP se îndepărtează de procesul tradițional de creare sistem softwareși în loc de planificare, analiză și proiectare unică cu o viziune pe termen lung, XP implementează toate aceste activități treptat în timpul dezvoltării, obținând astfel reduceri semnificative ale costului modificărilor programului. Metodele XP au fost concepute pentru a fi folosite în combinație, așa că dacă înțelegeți una dintre ele, veți ajunge inevitabil să le înțelegeți pe celelalte (caseta). Bara laterală urmărește fundalul istoric al acestei abordări.)

Ciclul de dezvoltare XP

În fig. 2 procesul XP este legat de diferite axe ale timpului, unde unitățile de măsură sunt ani, luni, săptămâni și zile. Clientul determină următoarea versiune (lansare) a sistemului, alegând cele mai valoroase funcții (în XP se numesc povești) dintre toate posibile. Valoarea funcțiilor este determinată de costurile materiale și de timp pentru implementarea lor de către echipa de dezvoltare.

Clientul determină poveștile pentru următoarea iterație, selectând cele mai semnificative povești dintre cele rămase în versiune, din nou pe baza unei evaluări a costului și a vitezei de dezvoltare a acestora. Programatorii împart poveștile în sarcini locale și toată lumea își asumă responsabilitatea pentru una dintre ele. Programatorul își transformă apoi problema într-un set de cazuri de testare, a căror execuție cu succes va arăta că problema a fost complet rezolvată. Lucrând în tandem cu un partener, programatorul se asigură că testele funcționează corect, în timp ce dezvoltă în același timp întregul proiect. Astfel, este posibil să se implementeze cea mai simplă arhitectură a sistemului în ansamblu.

Povești

Din punct de vedere XP, perioada de până la prima lansare a unui sistem în producție reală este o anomalie periculoasă în ciclul de viață al proiectului și trebuie depășită cât mai repede posibil. Cu toate acestea, lucrul la orice proiect trebuie să înceapă cumva.

În primul rând, trebuie să decideți pentru ce este destinat sistemul și ce ar trebui să poată face în primul rând. De regulă, sunt necesare anumite analize pentru a lua astfel de decizii. Este simbolizat de dreptunghiul îngust albastru din Fig. 1s. Nu poți începe programarea până nu înțelegi ce trebuie de fapt să programezi.

Rezultatele analizei generale sunt prezentate sub formă de povești - indici care listează posibilele aplicații ale sistemului. Fiecare poveste trebuie să se concentreze pe obiective specifice de afaceri, astfel încât să poată fi testată și cuantificată. O lună este o perioadă rezonabilă de timp pentru a formula povești pentru un proiect de 10 persoane-an. Este clar că acest timp nu este suficient pentru un studiu detaliat al tuturor posibile probleme. Dar nu va fi niciodată suficient timp pentru a analiza toate problemele dacă chiar intenționați să treceți la implementarea sistemului.

Versiune

După cum se poate observa din fig. 2, nu implementăm toate poveștile deodată. Clientul selectează mai întâi un mic set de cele mai importante povești care sunt legate logic între ele. Și le programăm și le punem în funcțiune în primul rând. După aceasta, totul este implementat.

Alegerea poveștilor pentru o versiune a sistemului poate fi comparată cu cumpărăturile într-un supermarket. Te duci la magazin cu o sută de dolari în buzunar. Gândește-te mai întâi la ce ai nevoie. Uită-te la etichetele de preț. Și decideți ce să cumpărați. În etapa de planificare, produsele sunt povești, iar etichetele de preț sunt evaluări ale poveștilor. Bugetul dvs. este determinat de numărul de povești estimate implementate de echipa de dezvoltare într-o unitate de timp selectată.

Cumpărătorul (clientul) poate fie să-și completeze coșul (selectează un set de povești), după care programatorii vor calcula data finală pentru implementarea lor, fie să stabilească o dată pentru care programatorii vor calcula bugetul, iar clientul va colecta numărul necesar de povești pentru suma primită.

Repetare

Scopul fiecărei iterații este de a lansa mai multe povești noi care sunt testate și gata de executat. Acest proces începe cu crearea unui plan care definește ce povești vor fi implementate și modul în care echipa de dezvoltare va îndeplini această sarcină. În timp ce dezvoltarea este în curs, clientul vine cu teste funcționale. La sfârșitul unei iterații, testele ar trebui să ruleze, iar dezvoltatorii ar trebui să fie pregătiți pentru următoarea iterație.

Când încep să planifice o iterație, dezvoltatorii îi cer din nou clientului să selecteze cele mai valoroase povești, de data aceasta dintre cele rămase pentru implementare în această versiune. Dezvoltatorii despart poveștile în sarcini - module, a căror implementare poate fi finalizată de o persoană în câteva zile. Dacă există mai multe sarcini tehnice, cum ar fi trecerea la versiune noua baze de date, acestea sunt incluse și în lista generală.

Programatorii își asumă apoi responsabilitatea pentru implementarea anumitor sarcini. După ce toate sarcinile sunt alocate, programatorul responsabil cu sarcina o evaluează, de data aceasta după numărul de zile de programare ideale. Sunt apoi colectate estimările sarcinilor tuturor programatorilor din echipă, iar dacă unii dintre ei plănuiesc să petreacă mai mult timp implementării, iar alții mai puțin, volumul de muncă din echipă este redistribuit corespunzător.

În timpul iterației, programatorii își implementează sarcinile. Pe măsură ce sarcinile sunt finalizate, codul lor este integrat în sistem comunși testat cu el. Fie trec toate testele, fie codul nu poate fi integrat în sistem. În timpul iterației, testele funcționale furnizate de client sunt adăugate la seria generală de teste. La sfârșitul iterației, toate testele unitare și toate testele funcționale ar trebui să ruleze.

Sarcină

Pentru a implementa o sarcină, programatorul responsabil de aceasta caută în primul rând un partener, deoarece codul final este întotdeauna scris de două persoane pe aceeași mașină. Dacă apar întrebări cu privire la subiectul sau metodele de implementare, partenerii țin o scurtă întâlnire (de 15 minute) cu clientul și/sau programatorii cunoscători despre problemele de codificare care sunt cel mai probabil asociate cu codul pentru sarcina respectivă în timpul implementării.

Pe baza rezultatelor acestei întâlniri, programatorii creează o listă de cazuri de testare care trebuie rulate înainte de finalizarea implementării sarcinii. Din listă, este selectat un test pe care programatorii sunt complet încrezători în implementare și cu ajutorul căruia pot înțelege mai bine esența problemei. Este scris un program de testare. Dacă funcționează normal imediat, poți continua. Cu toate acestea, de regulă, nu este fără probleme. Dacă testul nu funcționează, este posibilă una dintre următoarele situații:

  • știm o modalitate simplă de a o face să funcționeze și acționăm astfel;
  • Cunoaștem un mod dificil și foarte neplăcut de a-l face să funcționeze, dar înțelegem cum să schimbăm arhitectura sistemului și să facem ca cazul de testare să funcționeze normal, fără efort suplimentar. Apoi decidem să reproiectăm sistemul;
  • știm modalitatea dificilă și neplăcută de a-l face să funcționeze și nu vedem nicio modalitate de a reproiecta sistemul, așa că luăm această cale dificilă.

După ce testul funcționează, este posibil să înțelegem din nou cum să îmbunătățim sistemul, ceea ce vom face.

Este probabil ca în timpul implementării unui caz de testare să găsim un alt caz de testare care ar trebui să funcționeze. Adăugăm un nou test pe lista noastră și continuăm dezvoltarea. Poate vom descoperi că amploarea restructurării sistemului depășește cerințele actualului test, apoi vom înregistra acest fapt și vom merge mai departe. La sfârșitul zilei, scopul nostru este să ne concentrăm asupra detaliilor și să rezolvăm cu succes o problemă specifică, dar, în același timp, să nu pierdem înțelegerea generală a sistemului care se formează în timpul lucrului intens asupra codurilor.

Test

Dacă vorbim despre metoda XP cheie, atunci aceasta este, desigur, testarea unitară. După cum s-ar putea să înțelegeți deja, testarea unitară este o parte integrantă a muncii zilnice a fiecărui programator. Două caracteristici fac ca procesul de testare XP să fie mult mai eficient decât metodele tradiționale: programatorii își scriu propriile teste și fac acest lucru înainte de a începe codarea. Desigur, dacă abordați programarea ca învățarea unei probleme în timp și învățarea despre problemă ca mijlocul cel mai eficient de a oferi feedback clientului, atunci veți beneficia cel mai mult de testele scrise de o terță parte la câteva zile sau săptămâni după codare. este gata. XP ține cont de opinia general acceptată conform căreia programatorii nu își pot testa propriul cod în mod corespunzător și, prin urmare, îi obligă să lucreze în perechi.

Unele metodologii, în special Cleanroom, interzic programatorilor să testeze și, în unele cazuri, chiar să le compile programele. De obicei, un programator scrie cod, îl compilează, se asigură că funcționează și apoi îl trimite unei organizații de testare. Metodele tradiționale de evaluare comparativă includ analiza pas cu pas a codului și a variabilelor, interpretarea declarațiilor de tipărire, testarea butoanelor de meniu etc.

XP nu introduce noi tehnici de testare în comparație cu metodele convenționale. Doar că testarea se face într-o formă diferită și, în loc să faci ceva care nu va rămâne în urmă după finalizarea testării, creezi teste pe termen lung. Aceste teste funcționează astăzi, vor funcționa în ziua în care este finalizată integrarea sistemului și a doua zi, o săptămână mai târziu și anul viitor. Incredere in operatie normala fiecare test individual construiește treptat încrederea în rândul dezvoltatorilor în funcționarea normală a sistemului în ansamblu.

După cum sa menționat deja, clienții vin și cu teste. La începutul iterației, clientul trebuie să găsească acei factori care îl vor convinge că poveștile pentru această iterație sunt pe deplin implementate. El își formalizează gândurile cu privire la această chestiune în teste pentru întregul sistem. Clientul poate scrie el însuși teste folosind limbaje de scripting text sau grafic sau le poate încredința unui programator care va folosi propriile instrumente de testare. Astfel de teste creează, de asemenea, încrederea, de data aceasta, încrederea clientului în funcționarea corectă a sistemului.

Ai probleme?

Nu este dificil să discutăm despre o anumită metodă de programare atunci când funcționează perfect. Este mult mai interesant să știi ce vei face dacă te trezești într-o situație neașteptată sau nedorită.

Reevaluarea propriilor capacități. Din când în când iei mai mult decât poți suporta. Este necesar să se minimizeze numărul de situatii similare, apelând cât mai des la evaluări cantitative ale muncii dvs. Dacă te simți supraîncărcat, mai întâi de toate caută în interiorul tău motivul. Analizează: poate ești prea distras de la rezolvarea problemelor practice. Testați complet, lucrați cu un partener și reproiectați sistemul și integrați? Faceți mai mult decât are nevoie clientul în prezent?

Dacă nu reușiți să găsiți resurse interne pentru a accelera dezvoltarea, atunci ar trebui să cereți clientului să vă ajute. Păstrarea răspunderii pentru un volum de muncă pe care nu-l poți garanta va însemna întreruperea planului, afectarea calității sistemului și, în final, pierderea completă a funcționalității acestuia. Nu lăsa să ți se întâmple asta. Reevaluați-vă capacitățile pe baza experienței dvs. și apoi cereți clientului să vă revizuiască cerințele. Dacă puteți implementa doar două dintre cele trei povești, lăsați-l să stabilească ce povești să abordeze mai întâi și pe care să le lase pentru următoarea iterație sau versiune. Există o poveste în care unele părți sunt mai importante decât altele? Apoi, veți putea să împărțiți implementarea sa în etape și să programați componente mai relevante fără întârziere și pe cele mai puțin importante puțin mai târziu.

Dacă clientul nu cooperează. Imaginează-ți o situație în care clientul nu acceptă regulile jocului tău. Nu vine cu teste, nu stabilește priorități, nu formulează povești. În primul rând, încercați să stabiliți o relație de încredere cu clientul. Prin creșterea funcționalității sistemului de la iterație la iterație, oferiți clientului oportunitatea de a controla procesul de dezvoltare. Dacă încrederea reciprocă eșuează, analizează dacă aceasta este vina ta. Faceți totul pentru a interacționa eficient cu clientul?

Dacă nu puteți rezolva singur această problemă, contactați clientul pentru ajutor. Principiile XP pur și simplu nu permit programatorilor să se dezvolte ghicind despre nevoile clienților lor. Explicați sau demonstrați clientului, folosind un exemplu, secvența de lucru în XP. Dacă nu își schimbă atitudinea față de tine, încearcă să-ți faci argumentele mai clare. Dacă se dovedește că, în esență, nimănui în afară de tine nu-i pasă de rezolvarea acestei probleme, poate că acest proiect are o prioritate scăzută în activitățile clientului și nu ar trebui să insisti deloc pe continuarea lui.

Schimbarea personalului. Să presupunem că unul dintre membrii echipei decide să părăsească echipa. Vă veți găsi într-o situație de fund din cauza lipsei documentelor sau rapoartelor necesare? În primul rând, să remarcăm că o anumită cifră de afaceri este bună pentru echipa de dezvoltare și membrii săi individuali. Desigur, mi-aș dori ca oamenii să fie ghidați de motive pozitive atunci când pleacă. Dacă, atunci când un programator pleacă acasă la sfârșitul săptămânii următoare, vede rezultate pozitive concrete ale activităților sale, probabilitatea dezamăgirii sale în muncă și dorința de a pleca este semnificativ redusă.

Dacă cineva părăsește un proiect XP, asta nu înseamnă că va lua cu el singur secretele cunoscute de el. Fiecare linie din sistem este întotdeauna controlată de două persoane. Și orice informații care părăsesc camera de lucru nu va cauza prea multe daune muncii echipei, deoarece dezvoltatorii vor putea rula teste și vor putea verifica dacă s-a întâmplat ceva neașteptat fără știrea lor.

În timpul lucrului la primele două iterații, noii membri ai echipei de HR se limitează la a oferi toată asistența posibilă unui partener mai experimentat într-o pereche, studiind teste și comunicând cu clientul. Simțindu-se mai încrezători în abilitățile lor, ei își vor putea asuma responsabilitatea pentru o anumită sarcină. În timpul dezvoltării următoarelor câteva iterații, performanța noilor veniți crește atât de mult încât aceștia sunt capabili să demonstreze tuturor implementarea sarcinilor specifice la timp. După câteva luni, nu se mai pot distinge de membrii echipei cu experiență.

Programatorii care nu sunt obișnuiți să lucreze în echipă pun o problemă dificilă. HR este o muncă intensă, colaborativă și nu toată lumea este capabilă să se adapteze acestui mod de lucru. S-ar putea să fii nevoit să renunți la vechile obiceiuri, iar acest lucru nu este deloc ușor, mai ales pentru programatorii care se prețuiesc foarte mult. Dar, la sfârșitul zilei, numeroasele forme de feedback oferite în XP fac posibilă determinarea cu exactitate cine poate lucra într-o echipă și cine nu. Dacă unul dintre voi nu reușește în mod constant să finalizeze o sarcină, integrarea modulelor sale provoacă întotdeauna probleme celorlalți membri ai echipei, nu încearcă niciodată să refacă sistemul, nu funcționează în perechi, nu efectuează teste etc. Toată lumea din echipă va înțelege ce este. Și va fi mai bine pentru întreaga echipă doar dacă o astfel de persoană pleacă, indiferent de aptitudinile și experiența sa.

Cerințe în schimbare. Problema problemelor pentru majoritatea sistemelor de dezvoltare nu este aceeași pentru XP. Creat astăzi pentru a rezolva probleme specifice, un proiect XP va face față oricăror modificări ale funcționalității în viitor cu aceeași eficiență. Va fi mai ușor să faci ceva similar cu ceea ce sa făcut deja, deoarece XP susține principiul „formulează fiecare gând o dată și o singură dată”. În o astfel de prelucrare apare cel mai des nevoia. Dar chiar și în cazul în care apare o cerință complet nouă pentru sistem, nu va trebui să construiți în grabă noi mecanisme pentru funcționarea acestuia.

La început, nu aveam o idee clară despre cât de adaptabil avea să se schimbe XP. În prima versiune de XP, procesul de selecție a poveștii a făcut parte din planificarea lansării, iar poveștile au fost atribuite tuturor iterațiilor din ediție. Apoi dezvoltatorii au descoperit că, cu un efort mai mic de planificare, se pot obține rezultate mai bune. Prin urmare, acum clientul este rugat să specifice doar acele povești care trebuie să fie prezente în următoarea iterație. Dacă apare poveste noua, îl pui în rezervă și nu amesteci restul iterației. După una sau două săptămâni, dacă noua poveste nu și-a pierdut încă relevanța, clientul o va alege.

Planificând o iterație de fiecare dată, obținem autodezvoltarea treptată și auto-asemănarea sistemului. Pe o scară de luni și ani, avem de-a face cu istoriile unei versiuni date a sistemului și apoi cu istoriile versiunilor viitoare. Pe o scară de săptămâni și luni, ne ocupăm de poveștile unei anumite iterații și apoi de poveștile rămase în această versiune. Pe o scară de zile și săptămâni, ne ocupăm de sarcina la care lucrăm în prezent și apoi de sarcinile care rămân în iterație. În cele din urmă, pe o scară de minute și zile, ne ocupăm de testul pe care îl rulăm în prezent și apoi de alte cazuri de testare care ne pot veni în minte.

Fără îndoială, XP este o idee elegantă, logică. Limitele aplicabilității sale nu sunt încă pe deplin clare. Adoptarea acestei abordări acum necesită un oarecare curaj, flexibilitate și dorința de a abandona proiectul dacă acesta eșuează. XP ar trebui mai întâi încercat în acele proiecte în care beneficiile acestei abordări sunt evidente: în dezvoltarea personalizată sau internă a sistemelor mici, cerințele pentru care nu sunt clar definite și se pot schimba.

Dacă doriți să experimentați XP, nu încercați să faceți totul deodată. Alegeți cea mai neplăcută problemă pentru dvs. și încercați să o rezolvați cu ajutorul XP. Când această problemă nu mai este cea mai enervantă, căutați-o pe următoarea și repetați procesul. Pe măsură ce continuați în acest mod, probabil veți descoperi că niciuna dintre metodele dvs. vechi nu mai este utilă. Atunci nu mai trebuie să-i contactați. Acest proces de adaptare treptată vă oferă șansa de a vă dezvolta propriul stil de dezvoltare - pe care îl veți folosi în orice situație - și, prin urmare, reduceți riscul problemelor cu XP.

Distincția strictă a XP între deciziile de afaceri și cele tehnice datează din munca arhitectului Christopher Alexander. Cartea sa, The Timeless Way of Building, notează că cei care operează o clădire ar trebui să li se permită să ia decizii importante în timpul construcției acesteia.

Principiile XP de a evolua rapid un plan ca răspuns la schimbările tehnice și de afaceri reflectă principiile metodologiei Scrum și limbajul șablon Episodes al lui Ward Canningham.

Ideea de a specifica și planifica un proiect în ceea ce privește capabilitățile realizabile datează din munca lui Ivar Jacobson.

Tom Gilb este un guru al designului evolutiv. Lucrarea sa cea mai recentă se concentrează pe introducerea software-ului în producție în câteva săptămâni și apoi pe dezvoltarea acestuia.

Modelul Spiral al lui Barry Boehm a fost primul răspuns la învechirea modelului cascadei. Multă vreme, nimeni nu i-a putut depăși pe Dave Thomas și pe colegii săi de la Object Technology International, care au creat metoda JIT, în stăpânirea tehnologiilor puternice.

Rădăcinile principiului metaforelor folosite în XP pot fi găsite în cărțile lui George Lakoff și Mark Johnson, în special cea mai recentă lucrare a lor, Philosophy in the Flesh. Acest principiu a fost propus și de Richard Coyne, care a legat metafora și dezvoltarea software-ului din perspectiva filozofiei postmoderne.

În cele din urmă, accentul semnificativ al XP asupra organizării biroului provine din munca lui Jim Coplien, Tom DeMarco și Tim Lister, care au remarcat influența condițiilor de mediu asupra muncii programatorilor.

Exemple de rulare a proiectelor folosind XP

Acxiom: pe calea atingerii unui scop comun

G Hannula

Echipă: manageri, analiști de afaceri, dezvoltatori, testeri, scriitori tehnici

Aplicație: baza de date de management al campaniilor

Perioada de implementare: 3 ani

Acxiom a creat o aplicație de management de afaceri bazată pe un depozit de date folosind instrumentele de dezvoltare orientate pe obiecte distribuite Forte. O echipă mică de dezvoltatori - doar 10 persoane - a aderat ferm la principiile programării orientate pe obiecte și dezvoltării colaborative atunci când a creat aplicația. Din cei trei ani petrecuți în dezvoltare, în ultimii doi echipa, care includea manageri, analiști de afaceri, dezvoltatori, testeri și scriitori tehnici, a folosit metode de programare extremă și a obținut succes prin aceasta.

Până de curând, Acxiom considera un proiect de succes dacă era simplu și unele dintre sistemele create anterior se puteau califica pentru a deveni parte a noii aplicații. Cu toate acestea, s-a dovedit că nu a ieșit nimic bun din asta. Reelaborarea sistemului a devenit un element critic al dezvoltării. Ne-am dat seama clar că dacă ne-ar fi frică să schimbăm părți ale programului ale căror funcții nu le cunoșteam încă, nu am fi considerați dezvoltatori buni. Lăsăm programul să ne controleze. Dacă nu am ști ce face acest cod, nu ne-a fost frică să intrăm în ea și să ne dăm seama. Este mai bine să implementați singur o anumită parte a codului decât să faceți întreaga aplicație ostatică la o bucată separată a acesteia.

A trebuit depus mult efort pentru a testa modulele, deoarece Forte nu oferă instrumente de testare de bază încorporate. A trebuit să ne creăm propriile noastre și să le folosim pentru a testa cu succes. Am trecut recent la limbajul de programare Java și acum folosim JUnit ca instrument de testare.

Când tocmai am început să lucrăm după principiile XP, printre noi erau programatori care nu voiau să folosească metodele lui. Ei au simțit că aceste metode nu sunt în concordanță cu stilul lor de programare și le-ar împiedica să fie productive. Ca urmare, cele mai multe probleme au apărut cu componentele sistemului scrise de aceste persoane. Acești dezvoltatori au ignorat lucrul în perechi și au devenit inferiori în abilitățile lor față de alți membri ai echipei care au profitat de șansa de a învăța unii de la alții. Doi programatori cu experiență care lucrează strâns împreună unul cu celălalt și cu restul echipei vor fi întotdeauna superioare ca abilități unui „conformist”, indiferent cât de strălucit este el.

Ne-am dat seama că fiecare membru al echipei trebuie să respecte principiile XP, altfel această abordare nu va funcționa. Acum îl avertizăm imediat pe potențialul dezvoltator că dacă nu este mulțumit de stilul adoptat de noi, mai bine își caută un loc de muncă în altă echipă. O persoană care nu este interesată de metoda de dezvoltare aleasă poate strica eforturile întregii echipe. Esența resurselor umane este dezvoltarea colectivă de idei noi în procesul de creare a unui sistem.

Există o concepție greșită cu privire la XP că această abordare suprimă activitatea creativă și dezvoltarea abilităților individuale ale dezvoltatorului. De fapt, contrariul este adevărat. XP stimulează creșterea creativă a programatorului și oferă membrilor echipei individuale șansa de a se exprima. Principalul lucru este să decideți și să aderați ferm la direcția aleasă.

„Programarea extremă” nu a pus echipa noastră în condiții extreme. Această metodă utilizează abordări de dezvoltare bine-cunoscute și în mare măsură familiare. Toți lucrează îndeaproape împreună și se îndreaptă spre obiectiv împreună.

DaimlerChrysler: cea mai bună echipă din lume

Chet Hendriksen

Echipă: 15 persoane, dintre care 10 programatori

Aplicație: automatizarea la scară completă a calculelor de salarizare

Perioada de implementare: 4 ani

Lucrările la proiectul C3 au început în ianuarie 1995. Chrysler Corporation a încheiat un contract cu companie partenera, conform căreia o echipă comună de dezvoltatori din ambele organizații a preluat implementarea proiectului. Partenerii noștri au urmat o metodologie de dezvoltare orientată spre utilizare GUIși a ignorat automatizarea testului. Rezultatul a fost un sistem plin de grafice blande și a calculat incorect salariile pentru majoritatea angajaților. Un astfel de sistem ar dura aproximativ 100 de zile pentru a genera un salariu lunar. Ne-am dat seama că programul pe care l-am scris nu va fi folosit niciodată.

Am apelat la Kent Beck pentru a ajuta la reglarea performanței sistemului. A găsit în noi aceleași fenomene pe care el însuși le întâmpină constant atunci când își asumă sarcina de reglare a performanței: cod prost conceput, teste care nu pot fi reluate, management care și-a pierdut încrederea în proiectul lor. Kent Beck a recomandat să aruncați tot codul scris și să începeți un proiect XP la scară largă.

Contractul anterior a fost reziliat, iar Chrysler a înlocuit aproape jumătate din echipa sa de dezvoltare. Din acel moment am acționat conform regulilor XP. Au fost atribuite responsabilități, au fost planificate iterații, au fost stabilite reguli de testare, iar programarea perechilor a fost testată și adoptată ca standard. Până la sfârșitul săptămânii 33, aveam un sistem în care puteam începe să depanăm performanța și să efectuăm teste paralele. Am putea începe să reglam performanța deoarece sistemul a fost bine gândit și susținut de o suită completă de teste unitare. Eram pregătiți pentru testarea paralelă, deoarece o serie de teste funcționale au demonstrat în mod clar clientului că sistemul are capabilitățile necesare.

Această etapă a implementării C3 a fost lansată în mai 1997, deși ne așteptam la o dată mai devreme. Eșecul planurilor noastre s-a datorat a doi factori. În primul rând, am decis să înlocuim doar componentele interne sistem de plata. Toate interfețele externe au rămas neatinse. Potriviți datele de ieșire sistem nou Componentele celui vechi s-au dovedit a fi o sarcină mult mai dificilă decât ne așteptam. În al doilea rând, am decis să nu declanșăm cerințe speciale, cum ar fi procesarea W-2, împărțirea profitului sau creșterile salariale generale, în orice perioadă de plată. Ca urmare, ceea ce ar fi trebuit făcut în noiembrie a fost amânat pentru aprilie.

După lansarea sistemului de calcul al plăților lunare, am adăugat câteva funcții noi și calcule automate de plată bisăptămânală. Grupul pilot este plătit din august 1998 și sperăm să avem un sistem de lucru pentru restul angajaților până în noiembrie 1999.

Analizând experiența acumulată pe parcursul acestei dezvoltări îndelungate, pot spune că nu am îndeplinit așteptările conducerii noastre și ale clienților noștri doar atunci când ne-am abătut de la principiile XP. Când procesul de testare a devenit factorul determinant în procesul de dezvoltare, când am scris cod în perechi, când au fost implementate cele mai simple funcții care sigur că vor funcționa, ne-am transformat în cea mai bună echipă care poate fi.

Ford Motor: o combinație unică de eficiență și calitate

Don Wells

Echipă: 17 persoane, dintre care 12 programatori

Aplicație: sistem de analiză a costurilor

Perioada de implementare: 6 ani

Departament sisteme financiare Ford Motor Company dezvoltă un sistem analitic, Vehicle Costing and Profit System (VCAPS), care generează rapoarte privind veniturile din producție, cheltuielile, venitul net și profitul. Intrările în sistem sunt specificațiile de inginerie ale produsului, costurile și cheltuielile fixe și costurile variabile, cum ar fi orele de muncă. VCAPS reunește toate aceste date și produce rapoarte detaliate de analiză a costurilor care permit previziuni eficiente și luarea deciziilor corporative. Lucrările la proiectul VCAPS au început în 1993. VisualWorks și GemStone Smalltalk au fost folosite în timpul dezvoltării. VCAPS este susținut în prezent de o echipă mică de specialiști și va fi înlocuit în curând cu o aplicație mai modernă.

La implementarea proiectului VCAPS a trebuit să rezolvăm două probleme serioase. În primul rând, analiștii doreau să facă modificări sistemului și, în același timp, să obțină noi funcții care deja funcționau. Cerințele se schimbau în mod constant și pur și simplu nu puteam ține pasul cu ele. În al doilea rând, au existat anumite restricții privind timpul de funcționare a sistemului. În același timp, sistemul a petrecut mult timp procesând datele și a necesitat introducerea manuală a secvențelor lungi. Orice eroare a dus la necesitatea repornirii și a pierdut timp prețios.

Cu ajutorul XP, am realizat o combinație unică de capabilități: am putut răspunde rapid cerințelor în continuă schimbare și am obținut o calitate a sistemului care ne-a permis să evităm repornirile periculoase.

Lucrarea la metodele XP a început cu etapa de planificare. Și s-a dovedit a fi o greșeală. Clienții și conducerea nu sunt obișnuiți să cadă de comun acord asupra unui program de lucru. Ceea ce a apărut a lipsit de plauzibilitate și aplicabilitate practică. A trebuit să trecem la planurile MS Project, care puteau fi modificate fără a avea adunări generale, și cu ajutorul cărora am primit planuri într-o formă familiară conducerii.

Apoi am făcut mai multe teste unitare și după un an a fost testat 40% din sistem, iar conducerea a observat o reducere a numărului de mesaje de eroare cu 40%. După aceea, au acordat o atenție deosebită XP-ului.

Am rezolvat problemele prin implementarea tuturor metodelor XP noi. Testele ne-au permis să trecem la integrarea continuă și la schimbări frecvente de versiune. Aceasta, la rândul său, a deschis ușa către proprietatea colectivă și reproiectarea sistemului. Ne-am propus să creăm un proiect simplu. In sfarsit a venit momentul in care am decis sa incercam programarea in perechi. Și a trebuit să muncim din greu pentru a obține succesul în acest sens. La început, dezvoltatorii noștri au găsit această metodă extrem de incomodă; A durat timp să te obișnuiești și să te simți suficient de confortabil în ea.

După un an și jumătate, numărul defecțiunilor sistemului a scăzut atât de mult încât clienții și conducerea noștri au putut observa o stabilitate semnificativ mai mare a sistemului. Pentru noi, acest lucru a simbolizat succesul principiilor XP.

Sistem tarifar: teste pe care le puteți citi

Rob Mee

Echipă: trei dezvoltatori

Aplicație: sistem de calcul al tarifului de transport

Perioada de implementare: 3 luni

Tarif System face parte dintr-un proiect de anvergură implementat cu ajutorul SmallTalk/GemStone într-una dintre marile companii internaționale specializate în transportul containerelor. Abordarea XP a permis trei persoane să finalizeze toate etapele de dezvoltare ale acestui subsistem, de la concept până la punere în funcțiune, în trei luni. Rezultatul a fost remarcabil de stabil și ușor de întreținut.

Când am început să lucrăm la proiect, am decis imediat să aderăm cu fermitate la câteva principii de bază XP: programați întotdeauna în perechi, folosiți o arhitectură cât mai simplă posibil, reelaborați activ sistemul și scrieți o mulțime de teste unitare. Toate aceste principii și-au dovedit eficiența. O idee XP ni s-a părut puțin exagerat la început - scrierea de teste pentru cod înainte ca codul în sine să fie scris. Am fost și mai surprinși să descoperim că acest principiu ne permite să identificăm problemele arhitecturale și să grăbim procesul de dezvoltare.

De la bun început am folosit o altă metodă XP - colectarea cerințelor utilizatorilor sub formă de povești. Rezultatele nu au fost complet clare. Suntem programatori și în primul rând programatori, așa că găsirea unui limbaj comun cu utilizatorii a fost o provocare pentru noi. A complica și mai mult lucrurile a fost faptul că am vrut să obținem povești de la utilizatori care să fie atât relevante, cât și lipsite de ambiguitate, iar pentru a face acest lucru a trebuit să îi ajutăm activ. În cele din urmă, am ajuns la concluzia că HR-ului lipsea un anumit rol. Aveam nevoie de o persoană a cărei sarcină principală să fie interacțiunea cu utilizatorii. Evident, el trebuie să aibă abilitățile adecvate.

În timpul creării și reelaborarii cazurilor de testare, ne-am dat seama că pentru scrierea obiectelor de domeniu de bază ar fi foarte utile limbaje mici special inventate pentru acestea, datorită cărora codul de testare devine mult mai concis și mai ușor de citit. În plus, am încetat să mai pierdem timpul cu găsirea unor modalități de definire a instanțelor obiectelor în timp ce scriem teste și, în schimb, am definit gramaticile pentru zece clase de domenii. Gramatica creează automat un parser, care este folosit de designer pentru a crea un obiect de domeniu. Codul pentru crearea unei instanțe de obiect folosind constructori standard va fi foarte lung, aproape imposibil de citit și se aseamănă puțin cu cazul de testare în sine.

Îmbrățișând schimbarea cu programarea extremă, Kent Beck. Computer, octombrie 1999, pp. 70-77, Retipărit cu permisiune, Copyright IEEE, 1999, Toate drepturile rezervate.