Programare extremă- metodologie dezvoltare rapida software. Constă dintr-un set de tehnici și principii care permit, atât individual, cât și în combinație, optimizarea procesului de dezvoltare. Această abordare reglementează și drepturile dezvoltatorilor și clienților.

Drepturi și roluri

În Extreme Programming, toate rolurile sunt descrise clar. Fiecare rol vine cu un set caracteristic de drepturi și responsabilități. Există două roluri cheie aici: clientul și dezvoltatorul.

Client

O persoană sau un grup de persoane interesate să creeze un anumit produs software. Are următoarele drepturi și obligații:

• stabiliți datele de lansare pentru versiunile de produs;
• ia decizii cu privire la componentele planificate ale programului;
• cunoașteți costul estimat al fiecărei componente funcționale;
• ia decizii importante de afaceri;
• cunoașteți starea actuală a sistemului;
• schimba cerințele de sistem atunci când contează cu adevărat.

Pentru utilizare cu succes din drepturile sale, clientul trebuie să se bazeze pe datele furnizate de dezvoltatori.

Dezvoltator

Unul sau un grup de doi până la zece persoane direct implicate în programare și probleme de inginerie conexe. Dezvoltatorul are următoarele drepturi și responsabilități:

• să obțină cunoștințe suficiente despre problemele de programat;
• să poată clarifica detaliile în timpul procesului de dezvoltare;
• furnizați estimări orientative, dar sincere ale efortului necesar pentru fiecare caracteristică sau poveste de utilizator;
• ajusta estimările în favoarea unora mai precise în timpul procesului de dezvoltare;
• să ofere o evaluare a riscurilor asociate cu utilizarea unor tehnologii specifice.

Roluri în cadrul unui rol

Fiecare dintre rolurile de bază de programare extremă poate fi rafinat prin roluri mai mici. XP permite combinarea rolurilor într-o singură persoană.

Partea clientului

Compilator de povești- un specialist în domeniu, cu capacitatea de a afirma și descrie în mod clar cerințele pentru sistemul în curs de dezvoltare. Această persoană sau grup de persoane este responsabilă pentru scrierea poveștilor utilizatorilor și înlăturarea neînțelegerilor din partea programatorilor.

Receptor- o persoană care monitorizează funcționarea corectă a sistemului. Are o bună cunoaștere a materiei. Responsabilitățile includ redactarea testelor de acceptare.

Mare sef- monitorizează activitatea la toate nivelurile, de la dezvoltatori până la utilizatorii finali. El controlează implementarea sistemului și problemele organizatorice conexe. Poate fi și investitor în proiect.

Partea dezvoltatorului

Programator- o persoană implicată în codificare și design de nivel scăzut. Este suficient de competent pentru a rezolva problemele actuale de dezvoltare și pentru a oferi estimări oneste ale sarcinilor planificate.

Instructor - dezvoltator cu experiență, fluent în întregul proces de dezvoltare și tehnicile acestuia. Responsabil de instruirea echipei în aspectele procesului de dezvoltare. Implementează și monitorizează implementarea corectă a metodelor de proces utilizate. Atrage atenția echipei asupra unor puncte de dezvoltare importante, dar din anumite motive, ratate. În același timp, instructorul, ca orice altă persoană, nu este atotștiutor și acordă atenție ideilor celorlalți membri ai echipei.

Observator- un membru al echipei de dezvoltare, de încredere de către întregul grup, care monitorizează progresul dezvoltării. El compară estimări preliminare costurile forței de muncă și efectiv cheltuite, afișând indicatori cantitativi ai muncii echipei. Acestea sunt precum viteza medie și procent sarcinile finalizate și planificate. Aceasta informatie furnizate clientului pentru controlul în timp util al situației. Unele dintre aceste informații sunt furnizate în mod discret dezvoltatorilor, astfel încât aceștia să cunoască stadiul proiectului, unde apar dificultăți și ce altceva se poate face.

Diplomat- o persoana sociabila care initiaza comunicarea intre membrii echipei. Deoarece fluxul de documente este minimizat, comunicarea constantă și transferul de experiență în cadrul echipei, o mai bună înțelegere a cerințelor pentru sistem, sunt importante. Diplomatul reglementează și simplifică comunicarea dintre clienți și dezvoltatori. Este o verigă importantă în întâlniri. Previne omisiunile, pasiunile accentuate și certurile inutile. Un diplomat nu poate să-și impună părerea celor care discută.

Roluri externe

Consultant- un specialist cu aptitudini tehnice specifice pentru a ajuta dezvoltatorii cu probleme greu de rezolvat. De obicei adus din exterior.

Regulile de programare extremă

Convenția de codificare

Sunteți în echipa care lucrează la acest 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 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.

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, a remedia erori sau a refactoriza.

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, că testele unitare vă permit să verificați corectitudinea modificărilor efectuate și că viata reala oricum, într-un fel sau altul trebuie să înțelegi codul altcuiva, devine clar că proprietatea colectivă a codului simplifică foarte mult efectuarea de modificări și reduce riscul asociat cu specializarea ridicată a unuia sau altuia membru al echipei.

Sesiunea CRC

Utilizați carduri de clasă, responsabilități, colaborare (CRC) pentru a proiecta un sistem ca o echipă. Folosind carduri, este mai ușor să înveți să gândești în termeni de obiecte și nu de funcții și proceduri. Cardurile permit, de asemenea Mai mult oamenii să participe la procesul de proiectare (în mod ideal, întreaga echipă) și cu cât mai mulți oameni fac proiectarea, cu atât vor fi aduse mai multe idei interesante.

Fiecare card CRC reprezintă o instanță a unui obiect. Clasa unui obiect poate fi scrisă deasupra, responsabilitățile în stânga, interacțiunile în dreapta. Spunem „poate fi scris” deoarece, atunci când o sesiune CRC este în desfășurare, participanții au nevoie de obicei de un număr mic de carduri cu numele clasei și nu au neapărat nevoie de ele completate complet.

O sesiune CRC decurge astfel: fiecare participant reproduce sistemul spunând ce mesaje trimite către ce obiecte. Acesta parcurge întregul proces mesaj cu mesaj. Punctele slabe și problemele sunt identificate imediat. Alternativele de proiectare sunt, de asemenea, clar vizibile în simularea procesului.

Pentru a restabili ordinea, se folosește adesea limitarea la două a numărului de interacțiuni simultane.

Client

Una dintre cerințele XP este ca clientul să fie întotdeauna disponibil. El nu ar trebui doar să ajute echipa de dezvoltare, ci să fie un membru al acesteia. Toate fazele unui proiect XP necesită comunicare cu clientul, de preferință față în față - la fața locului. Cel mai bine este să atribuiți pur și simplu unul sau mai mulți clienți echipei de dezvoltare. Atenție, clientul va trebui perioadă lungă de timp, iar biroul clientului poate încerca să vă ofere un stagiar ca expert. Ai nevoie de un expert.

Poveștile utilizatorilor scris de client cu ajutorul dezvoltatorilor. Clientul vă ajută să vă asigurați că majoritatea funcțiilor de sistem dorite sunt acoperite de Povestea utilizatorului.

În timpul planificării lansării, clientul trebuie să discute despre alegerea poveștilor de utilizator care vor fi incluse în lansarea planificată. De asemenea, poate fi necesar să se convină asupra perioadei de eliberare în sine. Clientul ia decizii legate de obiectivele de afaceri.

Alege cea mai simplă soluție

Un design simplu este întotdeauna mai ușor de implementat decât unul complex. Așa că alegeți întotdeauna cea mai simplă soluție care poate funcționa. Dacă găsești ceva complicat, înlocuiește-l cu ceva simplu. Se dovedește întotdeauna a fi mai rapid și mai ieftin de înlocuit cod complex simplu înainte de a începe să înțelegeți codul complex.

Refactorizare codul altcuiva dacă vi se pare complicat. Dacă ceva pare complicat, este semn sigur probleme în cod.

Păstrați soluțiile cât mai simple posibil cât mai mult timp posibil. Nu adăugați niciodată funcționalități pentru viitor - înainte de a fi necesare. Cu toate acestea, rețineți: păstrarea unui design simplu este o muncă grea.

Teste funcționale

Testele de acceptare (denumite anterior și teste funcționale) sunt scrise pe baza User Story. Ei văd sistemul ca pe o cutie neagră. Clientul este responsabil pentru verificarea corectitudinii testelor functionale. Aceste teste sunt utilizate pentru a verifica funcționalitatea sistemului înainte de a-l lansa în producție. Testele funcționale sunt automatizate, astfel încât să poată fi executate frecvent. Rezultatul este raportat echipei, iar echipa este responsabilă de planificarea remedierii testelor funcționale.

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 schimbului de idei sau reutilizare cod. Toată lumea trebuie să lucreze cu cel mai mult ultima versiune.

Fiecare pereche de dezvoltatori ar trebui să contribuie cu codul lor cât mai curând posibil. 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 zilnică a modificărilor în porțiuni mici, nu va trebui să petreceți o săptămână pentru a conecta sistemul într-un singur întreg chiar înainte ca proiectul să fie livrat. Lucrați întotdeauna la cea mai recentă versiune a sistemului.

Pentru manager. Dacă un dezvoltator nu trimite modificări mai mult de o zi, acesta este un indicator clar al unei probleme grave. Trebuie să-ți dai seama imediat ce se întâmplă. Întreaga experiență a echipelor XP spune că motivul întârzierii este întotdeauna designul slab și trebuie să fie refăcut mai târziu.

Planificarea iterației

O întâlnire de planificare a iterației este convocată înainte de începerea fiecărei iterații pentru a planifica sarcinile care vor fi efectuate în acea iterație. Pentru iterare, sunt selectate poveștile utilizator care au fost selectate de client în planul de lansareîncepând cu cel mai important pentru client și cel mai rău (care implică risc) pentru dezvoltatori. De asemenea, testele funcționale rupte sunt incluse în iterație.

Poveștile utilizatorilor și întârzierile Testele funcționale sunt împărțite în sarcini. Sarcinile sunt scrise pe cartonașe. Aceste cărți sunt planul detaliat pentru iterație. Fiecare sarcină ar trebui să aibă o durată ideală între 1 și 3 zile.

Dezvoltatorii descompun sarcinile și estimează durata de timp necesară pentru a le îndeplini. Astfel, fiecare dezvoltator estimează cât timp îi va lua sarcina. Este important ca evaluarea finală a domeniului de activitate să fie făcută de dezvoltatorul însuși.

Viteza proiectului determină dacă sarcinile dvs. se încadrează într-o iterație sau nu. Durata totală a sarcinilor planificate pentru o iterație nu trebuie să depășească viteza atinsă în iterația anterioară. Dacă ați introdus prea multe, atunci clientul trebuie să decidă ce povești de utilizator să amâne pentru următoarea iterație. Dacă ați tastat prea puțin, atunci trebuie să adăugați următoarea poveste de utilizator. În unele cazuri, puteți cere clientului să împartă una dintre Povestea utilizatorului în două pentru a include o parte în iterația curentă.

Amânarea unei povești de utilizator pentru următoarea iterație poate părea înfricoșătoare, dar nu vă lăsați să sacrificați refactorizările și testele unitare pentru a face mai mult. Datoria din aceste categorii vă va încetini rapid viteza. Nu faceți ceea ce credeți că va fi necesar în următoarele iterații - faceți doar ceea ce este necesar pentru a finaliza poveștile curente ale utilizatorilor.

Monitorizați viteza proiectului și poveștile utilizatorilor în așteptare. Este posibil ca planul de lansare să fie refăcut la fiecare trei până la cinci iterații. Este în regulă. La urma urmei, un plan de lansare este o privire în viitor și este firesc să te aștepți că previziunile tale vor trebui ajustate.

Iterații

Dezvoltarea iterativă crește flexibilitatea procesului. Împărțiți-vă planul în iterații de 2 până la 3 săptămâni. Mențineți o lungime constantă de iterație pe toată durata proiectului. Lasă iterația să fie pulsul proiectului tău. Acesta este ritmul care va face ca măsurarea progresului și planificarea să fie simple și fiabile.

Nu planifica sarcinile în avans. Adună în schimb Planificarea iterației la începutul fiecărei iterații pentru a planifica ceea ce se va face. De asemenea, este considerată o încălcare a regulilor să te devansezi și să faci ceva care nu este planificat în această iterație. Astfel, devine posibil să ținem sub control cerințele în schimbare ale Clientului.

Luați în serios termenele limită de finalizare a iterațiilor. Măsurați progresul pe măsură ce lucrați. Dacă este clar că nu veți putea finaliza toate sarcinile planificate până la termenul limită, atunci colectați din nou Planificarea iterației și reevaluați sarcinile și amânați unele dintre sarcini.

Concentrați eforturile pe finalizarea celor mai importante sarcini selectate de Client, în loc să aveți câteva sarcini neterminate selectate de dezvoltator.

Schimbați sarcini

Este necesar să se schimbe periodic sarcinile dezvoltatorilor pentru a reduce riscul concentrării cunoștințelor și blocajelor în cod. Dacă doar o singură persoană din echipa ta poate lucra într-o anumită zonă și acea persoană pleacă sau pur și simplu ai multe de făcut acest segment program, veți constata că proiectul dvs. abia merge înainte.

Cross Training-ul este de obicei un aspect important în companiile care încearcă să evite concentrarea cunoștințelor într-o singură persoană. Mutarea oamenilor prin cod în combinație cu programarea perechilor face în liniște Cross Training pentru tine. În loc ca o singură persoană să știe totul despre o anumită bucată de cod, toată lumea din echipa ta știe multe despre codul din fiecare modul.

Echipa devine mult mai flexibilă dacă toată lumea știe suficient despre fiecare parte a sistemului pentru a începe să lucreze la ea. În loc să aștepte ca „guru” să termine de lucru la o bucată critică de cod, mai mulți programatori pot lucra la ea simultan.

Când începeți un nou iterații fiecare dezvoltator trebuie să treacă la o nouă sarcină. Programarea perechilor ajută la depășirea problemei de adaptare (aceasta înseamnă că nou dezvoltator poate începe să lucreze în tandem cu un dezvoltator cu experiență în domeniu).

Această practică încurajează, de asemenea, idei noi și cod îmbunătățit.

Lăsați optimizarea pentru mai târziu

Nu optimizați niciodată nimic până când codarea este completă. Nu încercați niciodată să ghiciți unde vor fi blocajele de performanță. Măsura!

Faceți-l să funcționeze, apoi faceți-l să funcționeze corect, apoi faceți-l să funcționeze rapid.

Programare pereche

Tot codul pentru sistemul de producție (și asta înseamnă, cu excepția soluțiilor de probă) 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 XP susține că, după o perioadă scurtă 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.

Refactorizează fără milă!

Noi, programatorii, avem tendința de a rămâne cu un design mult timp după ce acesta devine greoi. Continuăm să reutilizam cod care nu poate fi întreținut, deoarece încă funcționează cumva și ne este frică să nu-l spargem. Dar este chiar benefic? XP consideră că acest lucru nu este profitabil. Când eliminăm redundanța, îmbunătățim un design învechit, eliminăm piesele neutilizate - facem refactorizare. În cele din urmă, refactorizarea economisește timp și îmbunătățește calitatea produsului.

Examinați orice cod fără milă pentru a vă menține designul simplu pe măsură ce îl dezvoltați. Păstrați codul clar și ușor de înțeles, astfel încât să fie ușor de înțeles, modificat și extins. Asigurați-vă că totul este scris o dată și o singură dată. În cele din urmă, durează mai puțin timp decât lustruirea unui sistem complex.

Planul de lansare

Planul de lansare este dezvoltat la întâlnirea de planificare a lansării. Planurile de lansare descriu o vedere a întregului proiect și sunt ulterior utilizate pentru a planifica iterații.

Este important ca oameni tehnici au făcut soluții tehnice și oamenii de afaceri au luat decizii de afaceri. Release Planning definește un set de reguli care permit tuturor să ia decizii. Aceste reguli definesc metoda de elaborare a unui plan de lucru care mulțumește pe toată lumea.

Esența întâlnirii de planificare a lansării pentru echipa de dezvoltare este estimarea fiecărei povești de utilizator în săptămâni ideale. O săptămână ideală este cât timp credeți că va dura pentru a finaliza o sarcină dacă nimic altceva nu vă distrage atenția. Fără dependențe, fără sarcini suplimentare, dar inclusiv teste. Clientul decide apoi care sarcini sunt cele mai importante sau care au o prioritate mai mare.

Poveștile utilizatorilor sunt scrise pe carduri. Dezvoltatorii și Clientul amestecă împreună cărțile de pe masă până când obțin un set de Povești utilizator care împreună vor alcătui prima (sau următoarea) Lansare. Toată lumea vrea să elibereze cât mai curând posibil sistem util care poate fi testat.

Lansarea poate fi planificată în funcție de timp sau volum. Pentru a determina câte povești de utilizator pot fi implementate până la o anumită dată sau cât timp real va dura un anumit set de sarcini, utilizați viteza proiectului. Dacă planificați în funcție de timp, înmulțiți numărul de iterații cu viteza proiectului pentru a afla câte povești de utilizator pot fi implementate. Când planificați în funcție de volum, împărțiți numărul total de săptămâni ideale necesare pentru toate poveștile utilizatorului la viteza proiectului și veți obține numărul de iterații necesare pentru a finaliza lansarea.

Dacă conducerea nu este mulțumită de data finalizării, poate fi tentant să reducă estimările domeniului de aplicare. Nu ar trebui să faci asta niciodată. Estimările scăzute vor crea cu siguranță o mulțime de probleme mai târziu. În schimb, negociați cu managerii, dezvoltatorii și clienții până când veți găsi un plan de lansare asupra căruia toată lumea poate fi de acord.

Lansări frecvente

Dezvoltatorii ar trebui să lanseze versiuni ale sistemului utilizatorilor (sau testerilor beta) cât mai des posibil.

Planificarea lansării folosit pentru a găsi mici piese de funcționalitate care au o semnificație comercială semnificativă și care pot fi eliberate în mediul real în stadiile incipiente de dezvoltare. Acest lucru este esențial pentru a obține feedback util în timp util pentru a influența procesul de dezvoltare. Cu cât amânați mai mult eliberarea unei părți importante a sistemului, cu atât mai puțin timp veți avea pentru a o repara.

Soluție de probă

Creați soluții de dovadă a conceptului pentru a răspunde la întrebări complexe probleme tehnice, pentru a justifica anumite soluții tehnologice. Există riscuri implicate în orice decizie privind tehnologia și soluțiile de încercare sunt concepute pentru a atenua acest risc.

Realizați un program care reproduce problema investigată și ignoră orice altceva. Cele mai multe soluții de probă nu sunt menite să fie folosite, așa că așteptați-vă să fie aruncate. Scopul creării lor este de a reduce riscul de a greși solutie tehnica sau o estimare mai precisă a timpului pentru implementarea unei povești de utilizator.

Î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. O mare parte din timpul oamenilor este pierdut pentru a primi 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.

Metafora sistemului

Alegeți întotdeauna System Metaphor - un concept simplu și clar, astfel încât membrii echipei să numească totul cu același nume. Pentru a înțelege sistemul și a elimina codul duplicat, este extrem de important cum denumești obiectele. Dacă poți ghici cum se numește un obiect din sistem (dacă știi ce face) și cu adevărat se numește așa, vei economisi mult timp și efort. Creați un sistem de denumire pentru obiectele dvs., astfel încât fiecare membru al echipei să îl poată folosi fără cunoștințe speciale despre sistem.

Teste unitare

Testele unitare joacă un rol cheie în XP. Acestea vă permit să schimbați rapid codul fără teama de a face noi greșeli. Un test unitar este scris pentru fiecare clasă, testul ar trebui să verifice toate aspectele clasei - testați tot ceea ce ar putea să nu funcționeze.

Trucul aici este că testul pentru clasă trebuie scris înaintea clasei în sine. Aceasta înseamnă că de îndată ce eliberați primul rezultat de lucru, acesta va fi susținut de sistemul de testare. Pentru a efectua teste, este scris un sistem special de testare cu propria interfață.

Testul unitar pentru o clasă este stocat într-un depozit comun împreună cu codul clasei. Niciun cod nu poate fi lansat fără un test unitar. Înainte de a lansa codul, dezvoltatorul trebuie să se asigure că toate testele trec fără erori. Nimeni nu poate da codul decât dacă toată lumea trece 100%. Cu alte cuvinte, deoarece toate testele au trecut înainte de modificările dvs., dacă aveți erori, acesta este rezultatul modificărilor dvs. Depinde de tine să o repari. Uneori, codul de testare este incorect sau incomplet. În acest caz, trebuie să-l corectați.

O tentație uriașă este să economisiți bani la testele unitare atunci când timpul este scurt. Dar făcând asta nu faci decât să te înșeli pe tine însuți. Cu cât este mai dificil să scrii un test, cu atât mai mult timp se va economisi mai târziu. Acest lucru a fost dovedit prin practică.

Testele unitare permit proprietatea colectivă a codului. Ele fac relativ ușor să revizuiți codul prost. Testele unitare vă permit, de asemenea, să aveți un sistem de lucru stabil în orice moment.

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. Formular - unul sau două paragrafe de text care sunt 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.

Fiecare User Story i se acordă o prioritate din partea afacerii (utilizator, client, departament de marketing) și o estimare a timpului de execuție din partea dezvoltatorilor. Fiecare poveste este împărțită în sarcini și i se atribuie un moment în care va începe să fie implementată.

User Stories sunt folosite în XP în loc de cerințele tradiționale. Principala diferență dintre o poveste de utilizator și cerințe este nivelul de detaliu. Povestea utilizatorului conține informațiile minime necesare pentru a face o estimare rezonabilă a cât timp va dura implementarea acesteia.

O poveste tipică de utilizator durează 1-3 săptămâni de timp ideal. O poveste care necesită mai puțin de 1 săptămână este prea detaliată. O poveste care necesită mai mult de 3 săptămâni poate fi împărțită în părți - povești separate.

Viteza proiectului

Viteza proiectului (sau pur și simplu viteza) este o măsură a cât de repede este finalizată munca la proiectul dvs.

Pentru a măsura viteza unui proiect, trebuie pur și simplu să numărați volumul de povești de utilizator sau câte sarcini (în timp) au fost finalizate per iterație. Doar calculați timpul total pentru estimarea volumului de muncă (timpul ideal).

În timpul planificării lansării, viteza proiectului este utilizată pentru a estima câte povești de utilizator pot fi produse.

În timpul planificării iterației, viteza proiectului în iterația anterioară este utilizată pentru a determina câte povești de utilizator să planifice în iterația curentă.

Acest mecanism simplu permite dezvoltatorilor să revină după o iterație dificilă. Dacă mai aveți timp liber după recuperare, mergeți la client și cereți o altă poveste de utilizator. Ca urmare, viteza va crește din nou.

Nu este nevoie să utilizați acest parametru ca parametru absolut. Nu este potrivit pentru compararea productivității a două proiecte, deoarece fiecare echipă are propriile sale caracteristici. Acest parametru este important doar pentru ca echipa să-l mențină pe o chilă uniformă.

Ar trebui să vă așteptați la modificări ușoare ale vitezei proiectului pe măsură ce lucrați. Dar dacă viteza se schimbă semnificativ, este necesar să reprogramați lansarea. De îndată ce noul sistem ajunge la utilizatori, așteptați-vă la o schimbare a vitezei proiectului, deoarece aveți sarcini de asistență.

Când este detectată o eroare

Dacă se găsește o eroare, se creează un test pentru a preveni să se repete. O eroare care apare pe un sistem de producție (deja instalat) necesită scrierea unui test funcțional. Crearea unui test funcțional imediat înainte de diagnosticarea unei erori permite clienților să descrie în mod clar problema și să comunice problema dezvoltatorilor.

Un test funcțional eșuat necesită creare Test unitar. Acest lucru ajută la concentrarea eforturilor de depanare și indică clar când a fost remediată o eroare.

Nu vei avea nevoie

Evitați să umpleți sistemul cu lucruri de care veți avea nevoie în viitor. Doar 10% din ceea ce te așteptai va fi de fapt necesar în forma sa originală, ceea ce înseamnă că 90% din timpul tău va fi pierdut.

Există întotdeauna o tentație de a adăuga funcționalitate acum și nu mai târziu, pentru că vedem cum să o adăugăm acum și simțim că sistemul va fi mult mai bun. Dar trebuie să ne reamintim mereu că nu vom avea nevoie niciodată. Funcționalitatea suplimentară doar încetinește progresul și consumă resurse. Uitați de cerințele viitoare și de flexibilitatea suplimentară. Concentrează-te pe ceea ce trebuie făcut acum.

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 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. În timpul unui astfel de joc, cerințele de sistem cunoscute pot fi rapid colectate, evaluate și planificate în funcție de prioritate.
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 sarcini software multă vreme de acum î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 un limbaj ș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. O mare parte din timpul oamenilor este pierdut pentru a primi 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 de metafore

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 simplu mod de a depăși acest inconvenient – ​​iar Programarea Extremă ne învață să găsim cele mai simple soluții – este să punem 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. Daca nu se poate atrage clientul sau reprezentantul acestuia, uneori este indicat sa se angajeze temporar un specialist in domeniul in 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 ușor de înțeles pentru 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 că această poveste este implementată corect - se mai numesc și teste de acceptare.

Testarea înainte de începerea dezvoltării

Testarea, în sensul său 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 poți testa 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, 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 articole nerevendicate. acest moment Detalii.

Programare pereche

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 soluții mai bune. Î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 este creat de câțiva dezvoltatori, testele vă permit să verificați corectitudinea modificărilor efectuate și că, în viața reală, încă trebuie să înțelegeți codul altcuiva într-un fel sau altul, devine clar că proprietatea colectivă a codului face mult mai ușoară efectuarea modificărilor ș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 ar trebui să ruleze cea mai recentă 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 se poate organiza o astfel de echipă permanent comunicare deschisaîntre dezvoltatori ș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, bineînțeles, comunicarea și instruirea dezvoltatorilor la locul de muncă.

Bibliografie:

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 valori de simplitate, comunicare, feedback, curaj și respect.

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ă este real Utilizator final produs, cunoștințe de afaceri. 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 examinează 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 buget, 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ătoarei funcție a produsului. 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. Programare perechi

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, dar doi este mai bine” 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 conform standard unificatși refactorizează constant
• ritm rapid de dezvoltare datorită programării perechilor, lipsei de reluare, prezenței clientului în echipă
• calitate superioară cod
• 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 multe schimbări culturale
• 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, a adăugat un al cincilea principiu - respectul.

1. Simplitate

În XP, dezvoltarea începe de la bun început. solutie simpla, 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 cod și design de cea mai înaltă calitate.

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

Conform unui studiu din 2016 realizat de 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ă exact 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 a colabora la 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 produse software și nu poate fi adaptat pentru o altă afacere.

Aceasta este una dintre cele mai dificil de implementat, 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.

Programare extremă: Dezvoltare bazată pe teste

Dedicat lui Cindy: aripile sufletului meu

Drepturile de publicare au fost obținute în baza unui acord cu Addison-Wesley Longman. Toate drepturile rezervate. Nicio parte a acestei cărți nu poate fi reprodusă sub nicio formă fără permisiunea scrisă a deținătorilor drepturilor de autor.

Informațiile conținute în această carte au fost obținute din surse considerate de încredere de către editor. Totuși, ținând cont de posibilele erori umane sau tehnice, editorul nu poate garanta acuratețea și caracterul complet al informațiilor furnizate și nu este responsabil pentru eventualele erori asociate cu utilizarea cărții.

ISBN 978-0321146533 engleză

ISBN 978-5-496-02570-6

© 2003 de către Pearson Education, Inc.

© Traducere în rusă Editura LLC „Piter”, 2017

© Ediție în limba rusă, proiectată de Peter Publishing House LLC, 2017

© Seria „Biblioteca Programatorului”, 2017

Prefaţă

Cod curat care funcționează„Cod curat care funcționează”, această expresie scurtă, dar semnificativă, inventată de Ron Jeffries, încapsulează întregul sens al dezvoltării bazate pe teste (TDD). Codul curat care funcționează este un obiectiv pentru care merită să ne străduim pentru că

Acesta este un mod previzibil de a dezvolta programe. Știți când un loc de muncă poate fi considerat complet fără a vă face griji pentru o serie lungă de greșeli;

Vă oferă șansa de a învăța lecțiile pe care le învață codul. Dacă folosești prima idee care îți vine în minte, nu vei avea șansa să implementezi a doua idee, mai bună;

Îmbunătățește viața utilizatorilor programelor tale;

Permite colegilor tăi să conteze pe tine, iar tu să contezi pe ei;

Este mai plăcut să scrii un astfel de cod.

Dar cum obții un cod curat care funcționează? Multe forțe ne împiedică să obținem cod curat și, uneori, nici măcar nu putem obține cod care funcționează. Pentru a scăpa de multe probleme, vom dezvolta codul pe baza testării automate. Acest stil de programare se numește dezvoltare bazată pe teste. Conform acestei tehnici

Codul nou este scris numai după ce a fost scris un test automat care eșuează;

Orice duplicare este eliminată.

Două reguli simple, nu? Cu toate acestea, ele generează un comportament individual și de grup complex, cu multe consecințe tehnice:

În timpul procesului de proiectare, rulăm în mod constant codul și ne facem o idee despre cum funcționează, acest lucru ne ajută să luăm deciziile corecte;

Ne scriem propriile teste pentru că abia așteptăm ca altcineva să ne scrie teste;

Mediul nostru de dezvoltare trebuie să răspundă rapid la mici modificări ale codului;

Proiectarea programului ar trebui să se bazeze pe utilizarea multor componente autonome, slab cuplate, pentru a face codul mai ușor de testat.

Cele două reguli TDD menționate determină ordinea pașilor de programare.

1. Roșu - Scrieți un mic test care nu funcționează și poate nici nu se compilează.

2. Verde - faceți testul să ruleze cât mai repede posibil, fără să vă faceți griji pentru corectitudinea designului și curățenia codului. Scrieți suficient cod pentru ca testul să funcționeze.

3. Refactoring – elimina orice duplicare din codul scris.

Roșu – verde – refactorizarea este mantra TDD.

Dacă presupunem că acest stil de programare este posibil, putem presupune că, datorită utilizării sale, codul va conține semnificativ mai puține defecte, în plus, scopul lucrării va fi clar pentru toți cei care participă la el. Dacă da, atunci dezvoltarea numai a codului necesar pentru a trece testele are și consecințe sociale:

Dacă densitatea defectelor este suficient de scăzută, echipa de Asigurare a Calității (QA) va putea trece de la reacția la erori la prevenirea acestora;

Cu cantitatea în scădere surprize neplacute managerii de proiect vor putea să estimeze mai precis costurile cu forța de muncă și să implice clienții în procesul de dezvoltare;

Dacă subiectele discuțiilor tehnice sunt clar definite, programatorii vor putea interacționa între ei în mod constant, mai degrabă decât o dată pe zi sau o dată pe săptămână;

Încă o dată, cu o densitate a defectelor suficient de scăzută, vom putea produce în fiecare zi un produs de lucru integrat cu o nouă funcționalitate adăugată, permițându-ne să intrăm într-un tip complet nou de relație de afaceri cu clienții noștri.

Deci ideea este simplă, dar care este interesul nostru? De ce ar trebui un programator să-și asume responsabilitatea suplimentară de a scrie teste automate? De ce ar merge un programator în pași mici, când creierul său este capabil să gândească la o structură de design mult mai complexă? Vitejie.

Vitejie

TDD este o modalitate de a gestiona frica în procesul de programare. Nu mă refer la frica de a cădea de pe scaun sau la frica de a fi în fața șefului tău. Mă refer la teama de a te confrunta cu o problemă „atât de dificilă încât nu am nicio idee cum să o rezolv”. Durerea este atunci când natura ne spune: „Opriți!”, iar frica este atunci când natura ne spune: „Fiți atenți!” Prudența nu este deloc un lucru rău, dar pe lângă beneficiile sale, frica are și unele efecte negative asupra noastră:

Frica ne obligă să gândim înainte și cu atenție la ce ar putea duce cutare sau cutare acțiune;

Frica ne face să comunicăm mai puțin;

Frica ne face să ne fie frică de recenziile muncii noastre;

Frica ne face iritabili.

Nimic din toate acestea nu este de ajutor pentru procesul de programare, mai ales dacă lucrați la o problemă complexă. Așadar, ne confruntăm cu întrebarea cum să ieșim dintr-o situație dificilă și

Nu încercați să preziceți viitorul, ci începeți imediat un studiu practic al problemei;

Nu te izola de restul lumii, ci crește nivelul de comunicare;

Nu evita răspunsurile, ci, dimpotrivă, stabilește un feedback de încredere și, cu ajutorul acestuia, monitorizează cu atenție rezultatele acțiunilor tale;

(trebuie să te confrunți singur cu iritația).

Să comparăm programarea cu ridicarea unei găleți dintr-o fântână. Găleata este umplută cu apă, rotiți pârghia, înfășurând lanțul în jurul gulerului și ridicând găleata în sus. Dacă găleata este mică, o poartă obișnuită, care se rotește liber, se va descurca bine. Dar dacă găleata este mare și grea, vei fi obosit înainte de a o ridica. Pentru a putea să vă odihniți între rotațiile pârghiei, este necesar un mecanism de clichet care să permită blocarea pârghiei. Cu cât găleata este mai grea, cu atât mai repede ar trebui să urmeze dinții angrenajului cu clichet.

Testele în TDD sunt ca dinții unui angrenaj cu clichet. După ce testul funcționează, știm că testul funcționează acum, acum și pentru totdeauna. Suntem cu un pas mai aproape de finalizare decât eram înainte de lansarea testului. După aceea, facem ca al doilea test să funcționeze, apoi al treilea, al patrulea etc. Cu cât problema cu care se confruntă programatorul este mai complexă, cu atât mai puțin funcţionalitate ar trebui să acopere fiecare test.

Cititoare de cărți Programarea extremă Explicați Este posibil să fi observat diferența de ton între Extreme Programming (XP) și Test-Driven Development (TDD). Spre deosebire de XP, metodologia TDD nu este absolută. XP spune: „Pentru a merge mai departe, trebuie să stăpânești asta și asta.” TDD este o tehnică mai puțin specifică. TDD presupune că există un interval între luarea deciziilor și rezultate și oferă instrumente pentru gestionarea duratei acestui interval. „Dar dacă mi-aș petrece o săptămână proiectând un algoritm pe hârtie și apoi scriind cod folosind o abordare bazată pe testare? Va fi acesta conform TDD?” Bineînțeles că va fi. Cunoașteți dimensiunea intervalului dintre luarea unei decizii și evaluarea rezultatelor și controlați în mod conștient acest interval.

Majoritatea oamenilor care au stăpânit TDD spun că practicile lor de programare s-au schimbat în bine. Infectat de teste(test infectat) - aceasta este definiția creată de Erich Gamma pentru a descrie această schimbare. Odată ce stăpânești TDD, te trezești că scrii mult mai multe teste decât înainte și mergi mai departe în pași mici care anterior ți-ar fi părut inutil. Pe de altă parte, unii programatori, familiarizați cu TDD, decid să revină la vechile practici, rezervând TDD pentru cazuri speciale când programarea convențională nu duce la progresul dorit.

Există cu siguranță probleme care nu pot fi rezolvate (cel puțin în acest moment) doar folosind teste. În special, TDD nu permite să se demonstreze mecanic caracterul adecvat al codului dezvoltat în ceea ce privește securitatea datelor și fiabilitatea operațiunilor paralele. Desigur, securitatea se bazează pe un cod care trebuie să fie lipsit de defecte, dar se bazează și pe participarea omului la procedurile de protecție a datelor. Problemele subtile de concurență nu pot fi reproduse cu siguranță prin simpla rulare a unui cod.

O justificare economică temeinică pentru toate acțiunile - se face doar ceea ce are nevoie clientul și nu duce la neprofitabilitatea proiectului.

Formarea cât mai devreme a arhitecturii de bază.

Utilizarea arhitecturii componente.

Prototipări, dezvoltare incrementală și testare.

Evaluări regulate ale stării actuale.

Managementul schimbarii, dezvoltarea constanta a schimbarilor din afara proiectului.

Concentrați-vă pe crearea unui produs care funcționează într-un mediu real.

Concentrați-vă pe calitate.

Adaptarea procesului la nevoile proiectului.

Programare extremă

Programare extremă (XP) a apărut ca o metodă evolutivă de dezvoltare software"jos sus". Această abordare este un exemplu al așa-numitei metode dezvoltare „în direct” (Metoda de dezvoltare agilă) . Grupul de metode „live” include, pe lângă programarea extremă, metodele SCRUM, DSDM (Dynamic Systems Development Method, metoda de dezvoltare a sistemelor dinamice), Bazat pe caracteristici Dezvoltare (dezvoltare condusă de funcțiile sistemului), etc.

Principiile de bază ale dezvoltării software live sunt consacrate în manifestul de dezvoltare live, care a apărut în 2000.

Oamenii implicați într-un proiect și comunicarea lor sunt mai importante decât procesele și instrumentele.

Un program de lucru este mai important decât o documentare cuprinzătoare.

Cooperarea cu clientul este mai importantă decât discutarea detaliilor contractului.

Lucrul la schimbări este mai important decât respectarea planurilor.

Metodele „vii” au apărut ca un protest împotriva birocratizării excesive a dezvoltării software, a abundenței documentelor secundare care nu sunt necesare pentru a obține rezultatul final, care trebuie întocmite atunci când se realizează un proiect în conformitate cu majoritatea proceselor „grele” , muncă suplimentară pentru a sprijini procesul fix al organizației, așa cum este necesar în, de exemplu, CMM. Majoritatea acestor lucrări și documente nu au legătură directă cu dezvoltarea software-ului și asigurarea calității, ci sunt destinate să respecte clauzele formale ale contractelor de dezvoltare, să obțină și să confirme certificate de conformitate cu diferite standarde.

Metodele „live” permit dezvoltatorilor să-și concentreze majoritatea eforturilor pe sarcini de dezvoltare și pe satisfacerea nevoilor reale ale utilizatorilor. Absența grămezilor de documente și nevoia de a le menține într-o stare coerentă vă permite să răspundeți mai rapid și mai eficient la schimbările de cerințe și de mediul în care va trebui să funcționeze viitorul program.

Cu toate acestea, XP are propria diagramă a procesului de dezvoltare (deși, în general, înțelegerea pe scară largă a „procesului de dezvoltare” ca schemă de acțiuni destul de rigidă contrazice însăși ideea de dezvoltare „vici”), prezentată în Fig. 15.

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, alături de 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, ceea ce are nevoie de la sistem pentru mai mult succes).

gestionarea afacerii dvs.) și, în al doilea rând, pe baza evaluărilor tehnice (adică evaluări ale complexității dezvoltării, compatibilitatea cu alte elemente ale sistemului etc.). Planurile sunt schimbate de îndată ce încep să se îndepărteze de realitate sau de dorințele clientului.

				Test
		utilizare		scenarii
			Poveste noua
	Cerințe		utilizare
			Viteza proiectului
	Metaforă		Planul de versiuni
		Planificare		Repetare	Acceptare	Mic
arhitectură				Ultimul
						Bine
						utilizatorii
Nesigur			Încrezător	Nouă iterație

Soluții de „aruncare”.

Figura 15. Diagrama fluxului de lucru în XP.

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ă imediat să fie utilizată. Versiunile ulterioare sunt pregătite la intervale destul de scurte (de la câteva ore pentru modificări minore într-un program mic, până la o lună sau două pentru o reluare majoră a unui sistem mare).

Metafora sistemului

Metafora, într-o formă destul de simplă și de înțeles pentru echipă, ar trebui să descrie mecanismul principal 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.

Simplu solutii de proiectare(design simplu)

Î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(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 oferă 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 acestea).

Programare pereche

Codarea este efectuată de doi programatori pe un singur 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

mai întâi ș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 membru al echipei poate schimba orice parte a codului în orice moment. 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 - acest lucru epuizează programatorii și le face munca semnificativ mai puțin productivă.

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

ÎN 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 sa este de a răspunde prompt întrebărilor de orice tip referitoare la funcțiile sistemului, interfața acestuia, performanța necesară, funcționarea corectă a sistemului în situații dificile, 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 observa din tehnicile utilizate, XP este conceput pentru a fi utilizat în echipe mici (nu mai mult de 10 programatori), lucru subliniat de autorii acestei tehnici. O echipă mai mare distruge ușurința de comunicare necesară pentru succes și face imposibilă implementarea multor tehnici enumerate.

Avantajele XP, dacă poate fi implementat, sunt o mai mare flexibilitate, capacitatea de a face modificări rapide și precise la software ca răspuns la cerințele în schimbare și la dorințele individuale ale clienților, calitatea înaltă a codului rezultat și absența necesității de a convinge clienții că rezultatul corespunde așteptărilor lor.

Dezavantajele acestei abordări sunt infezabilitatea în acest stil de suficient de mare și proiecte complexe, 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 costul timpului și al resurselor. De asemenea, se poate observa că XP nu este potrivit pentru acele cazuri în care posibilele soluții 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 contabilitate a plăților

angajații 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 un număr mare de articole dedicate XP în timpul proiectului în sine și ulterior. Acest proiect este menționat de mai multe ori î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 tăiată, iar timp de aproximativ șase luni după aceea, 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 mijlocul 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.

Literatura pentru curs 3

W. Royce. Managementul proiectelor software. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Proces unificat de dezvoltare software. Sankt Petersburg: Peter, 2002.

Kroll, Spiritul RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

K. Beck. Programare extremă. Sankt Petersburg: Peter, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler merge la „Extreme”. Calcul distribuit, 10/1998.

A. Cockburn. Selectarea metodologiei unui proiect. Software IEEE, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Consolidarea cazului pentru programarea în pereche. Software IEEE 4/2000.

G. Keefer. Programarea extremă considerată dăunătoare pentru dezvoltarea software-ului de încredere. Raport tehnic AVOCA, 2002.

Disponibil ca http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.