Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos

Buna treaba către site-ul „>

Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Postat pe http://www.allbest.ru/

Conţinut

• Introducere
• 1. Ce este XP?
• 3.1 Tehnici de bazăXP
• 4. Avantaje și dezavantaje
• 5. Istoricul utilizării
• Concluzie

Introducere

Programarea extremă, denumită adesea XP, este o disciplină de inginerie software și software de afaceri care se concentrează atât pe programatori, cât și pe oamenii de afaceri pe obiective comune, realizabile. Echipele XP produc software de calitate la mare viteză. Tehnicile care fac parte din disciplina XP sunt alese deoarece se bazează pe creativitatea umană și pe acceptarea faptului că o persoană este o creatură instabilă și predispusă la erori.

XP este adesea prezentat ca o colecție de tehnici, dar XP în sine nu este o linie de sosire. Nu este necesar să exersați și să dezvoltați XP din ce în ce mai bine pentru a obține stea de aur mult așteptată la sfârșitul acestui proces. Dimpotrivă, XP este linia de plecare. XP pune întrebarea: „Cât de minime pot fi eforturile noastre pentru a putea continua să producem software de calitate?”

Extreme Programming este o metodologie de producție simplificată pentru echipele mici și mijlocii de profesioniști implicați în dezvoltarea de software într-un mediu cu cerințe neclare sau în schimbare rapidă.

1. Ce este XP?

Extremminprogrammraționalizarea(ing. Extrem Programare, XP) este una dintre metodologiile agile de dezvoltare software. Autorii metodologiei sunt Kent Beck, Ward Cunningham, Martin Fowler și alții.

XP este o modalitate simplificată, eficientă, flexibilă, previzibilă, solidă din punct de vedere științific și foarte plăcută, cu risc scăzut de dezvoltare a software-ului. XP diferă de alte tehnici în următoarele moduri:

Prin utilizarea ciclurilor de dezvoltare extrem de scurte, XP oferă feedback rapid, real și permanent.

XP folosește planificarea incrementală, rezultând un plan general de proiect care apare destul de rapid, dar acest lucru implică faptul că acest plan evoluează pe toată durata de viață a proiectului.

XP folosește o cronologie flexibilă pentru furnizarea de funcționalități care să îmbunătățească receptivitatea la afaceri în schimbare și la cerințele în schimbare ale clienților.

XP se bazează pe teste automate dezvoltate atât de programatori, cât și de clienți. Datorită acestor teste, este posibilă monitorizarea procesului de dezvoltare, asigurarea evoluției corecte a sistemului și detectarea imediată a defectelor existente în sistem.

XP se bazează pe comunicare orală, teste și cod sursă. Aceste trei instrumente sunt folosite pentru a face schimb de informații despre structura sistemului și comportamentul acestuia.

XP se bazează pe un proces de proiectare în evoluție, care durează atâta timp cât sistemul în sine.

XP se bazează pe interacțiunea strânsă a programatorilor cu cele mai comune abilități și capacități.

XP se bazează pe tehnici care satisfac atât instinctele pe termen scurt ale programatorilor individuali, cât și interesele pe termen lung ale proiectului în ansamblu.

XP este o disciplină de dezvoltare software. Aceasta este o disciplină deoarece există anumite lucruri în XP pe care trebuie să le faceți dacă intenționați să utilizați XP. Nu trebuie să alegi dacă să scrii sau nu teste, pentru că dacă nu o faci, programarea pe care o faci nu este extremă.

Tehnica XP este concepută pentru a lucra la proiecte la care pot fi lucrate doi până la zece programatori care nu sunt strânși în cadrul rigid al mediului de calculator existent și în care toate munca necesara asociate cu testarea poate fi finalizată într-o zi.

2. Cum să începeți programarea extremă

De unde începe programarea extremă? Înțelegând că poziția tipică a unui dezvoltator de software autohton obligă să reducă costul de dezvoltare cât mai mult posibil. Și pentru aceasta este necesar să cooperăm intens cu clientul, să-i înțelegem interesele și, în final, să facem exact ce își dorește: nici mai mult, nici mai puțin.

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, Părere si curaj. Cu ei trebuie să începi.

Programarea extremă oferă o soluție gata făcută: păstrați totul cât mai simplu posibil, țineți clientul cu dvs. sau rămâneți singur cu clientul, lăsați-l să urmărească în mod activ procesul de dezvoltare, salutați schimbările - iar succesul este aproape garantat.

În echipele XP, comunicarea este întotdeauna binevenită - cel mai rapid mijloc de a împărtăși informații și experiență. Acest lucru este foarte important atunci când este necesar viteza maxima 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ă, se lucrează la simplificare din ce în ce mai mult până se realizează obiectivul principal- inteligibilitate maximă a codului pentru alți dezvoltatori.

Indiferent ce facem - fie că trecem un ac sau mergem la o petrecere - ne străduim întotdeauna să atingem un anumit obiectiv. Dacă observăm că ne abatem de la el, atunci ne ajustam acțiunile în consecință. Acum imaginați-vă cât de greu este să loviți un ac cu un fir. ochi inchisi sau imbraca-te frumos fara oglinda! Dar atunci când dezvoltăm programe, acest lucru se întâmplă adesea: facem ceva, al cărui rezultat nu ne este vizibil. Prin urmare, în programarea extremă, este o regulă să vezi rezultatul acțiunilor tale cât mai repede posibil. Sau, din punct de vedere tehnic, oferiți cel mai rapid feedback posibil.

Programarea extremă ne întreabă: de ce să nu cultivăm curajul? La urma urmei, este foarte important în muncă. Este posibil, fără curaj, să vă asumați responsabilitatea pentru implementarea unei sarcini și chiar într-un anumit interval de timp? Este posibil, fără curaj, să realizezi că ai ajuns într-o fundătură, să faci un pas înapoi și să cauți o soluție? Și, în sfârșit, ce îi va permite dezvoltatorului să-și recunoască greșeala în evaluarea sarcinii și să-i avertizeze pe alții despre aceasta la timp, în loc să îi confrunte cu un fapt când toate termenele au expirat? Beneficiile curajului sunt evidente și fiecare succes, chiar și în cea mai mică sarcină, este capabil să dezvolte acest curaj.

3. Tehnici XP

Extreme Programming (XP) a apărut ca o metodă evolutivă de jos în sus de dezvoltare a software-ului. Această abordare este un exemplu al așa-numitei metode de dezvoltare agilă. Grupul metodelor „vii” include, pe lângă programarea extremă, metodele SCRUM, DSDM (Dynamic Systems Development Method), Feature-Driven Development (dezvoltare controlată de funcțiile sistemului) etc.

Principiile de bază ale dezvoltării software „în direct” sunt consemnate în manifestul de dezvoltare „în direct”, care a apărut în 2000.

· Oamenii implicați în 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 negocierea detaliilor contractului.

· Elaborarea schimbărilor este mai importantă decât respectarea planurilor.

Metodele „vii” au apărut ca un protest împotriva birocratizării excesive a dezvoltării software, o abundență de documente secundare care nu sunt necesare pentru a obține rezultatul final, care trebuie întocmite în timpul unui proiect în conformitate cu majoritatea proceselor „grele”, suplimentare lucrează pentru a susține un proces de organizare fix, așa cum este necesar, de exemplu, în CMM. Majoritatea acestor lucrări și documente nu au legătură directă cu dezvoltarea software-ului și asigurarea calității, ci are ca scop respectarea clauzelor formale ale contractelor de dezvoltare, obținerea și confirmarea certificatelor de conformitate cu diverse standarde.

Metodele live permit celor mai multe dintre eforturile dezvoltatorilor să se concentreze pe sarcinile reale de dezvoltare și pe satisfacerea nevoilor reale ale utilizatorilor. Absența unui morman 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 vorbind, înțelegerea pe scară largă a „procesului de dezvoltare” ca o schemă destul de rigidă de acțiuni contrazice însăși ideea de „viciozitate” a dezvoltării), prezentată în Figura 1. .

Potrivit autorilor XP, această tehnică nu se referă atât la urmărirea unora scheme generale acțiuni, câte aplicare a unei combinații a următoarelor tehnici. Cu toate acestea, fiecare tehnică este importantă și, fără ea, dezvoltarea este considerată non-XP, potrivit lui Kent Beck, unul dintre autorii acestei abordări alături de Ward Cunningham și Ron Jeffries.

· Trăiplanificare (planificarejoc)

Sarcina lui este să determine cât mai repede posibil cantitatea de muncă care trebuie făcută înainte de următoarea versiune a software-ului. 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ări tehnice(adică estimări ale complexității dezvoltării, compatibilitatea cu restul sistemului etc.). Planurile se schimbă de îndată ce încep să nu fie de acord cu realitatea sau cu dorințele clientului.

Orez.1 Diagrama fluxului de lucru XP

· FrecventSchimbarevversiune (miceliberează)

Prima versiune de lucru ar trebui să fie disponibilă cât mai curând posibil și trebuie utilizată imediat. Versiunile următoare sunt pregătite în perioade destul de scurte de timp (de la câteva ore cu mici modificări într-un program mic, până la o lună sau două cu procesare serioasă a unui sistem mare). Lansările unui produs ar trebui să fie lansate cât mai des posibil. Lucrarea la fiecare versiune ar trebui să dureze cât mai puțin timp posibil. Mai mult, fiecare versiune ar trebui să fie suficient de semnificativă din punct de vedere al utilității pentru afacere.

· Metaforă (metaforă) sisteme

Metafora într-o formă destul de simplă și de înțeles pentru comandă ar trebui să descrie mecanismul de bază al sistemului. Acest concept seamănă cu arhitectura, dar ar trebui să fie mult mai simplu, doar sub formă de una sau două fraze, să descrie esența principală a soluțiilor tehnice adoptate.

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

Metafora sistemului este analogă cu ceea ce majoritatea tehnicilor numesc arhitectură. Metafora sistemului oferă echipei o idee despre cum funcționează sistemul în prezent, unde sunt adăugate noi componente și ce formă ar trebui să ia.

· Simpluproiectasolutii (simpluproiecta)

Î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ă ce le-ați solicitat în mod explicit. Toată complexitatea inutilă este eliminată imediat ce este găsită.

XP pornește de la faptul că, în timpul procesului de lucru, condițiile problemei se pot schimba în mod repetat, ceea ce înseamnă că produsul în curs de dezvoltare nu trebuie proiectat complet și complet în avans. Dacă chiar la începutul lucrării dvs. încercați să proiectați sistemul în detaliu de la început până la sfârșit, pierdeți timpul. XP presupune că designul este atât de mult proces important că trebuie efectuată în mod constant pe toată durata lucrărilor la proiect. Proiectarea trebuie realizată în pași mici, ținând cont de cerințele în continuă schimbare. În fiecare moment, încercăm să folosim cel mai simplu design care se potrivește sarcinii curente. În același timp, îl schimbăm pe măsură ce condițiile problemei se schimbă.

· Dezvoltareapebazătestarea (Test- condusdezvoltare)

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ă capacitățile de bază ale sistemului, astfel încât să poată vedea că sistemul funcționează efectiv.

În XP Atentie speciala se concentrează pe două tipuri de testare:

testarea unitară;

b testarea de acceptare.

software de programare extremă

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

Testele de acceptare asigură că sistemul funcționează într-adevăr așa cum este anunțat. În plus, testele de acceptare vă permit să verificați funcționarea corectă a produsului în curs de dezvoltare.

Pentru XP, o abordare numită TDD (Test Driven Development) este mai prioritară, mai întâi se scrie un test care nu trece, apoi se scrie codul pentru a trece testul, iar după aceea codul este refactorizat.

· Constantprelucrare (refactorizarea)

Nu este un secret pentru nimeni că adăugarea fiecărei funcționalități noi și creșterea codului complică dezvoltarea, identificarea erorilor și efectuarea modificărilor ulterioare. Unul dintre trucurile programării extreme este de a compensa adăugarea de funcționalități cu îmbunătățiri ale codului. Aceasta este reluarea codului sau refactorizarea.

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ă modificări în comportamentul său, care este verificat printr-o rulare după fiecare reluare a testului. În același timp, se preferă soluțiile mai elegante și mai flexibile, față de simpla dăruire rezultatul dorit... Componentele reprelucrate fără succes ar trebui detectate în timpul execuției testului și revenite la ultima stare consistentă (împreună cu componentele lor dependente).

Refactorizarea este o tehnică de îmbunătățire a codului fără a-i schimba funcționalitatea. XP implică faptul că, odată scris, codul va fi aproape sigur rescris de mai multe ori în cursul unui proiect. Dezvoltatorii XP lucrează neîncetat cu codul scris anterior pentru a-l îmbunătăți. Acest proces se numește refactorizare. Lipsa acoperirii testelor provoacă refuzul refactorizării, din cauza fricii de a rupe sistemul, ceea ce duce la degradarea treptată a codului.

· Programarein perechi (perecheprogramare)

Dezvoltatorii experimentați au observat că revizuirea periodică a codului altcuiva are un efect pozitiv asupra calității acestuia. Maeștrii extremi de programare au dezvoltat această abordare: în timpul dezvoltării, codul este revizuit constant printr-o tehnică numită programare în perechi.

Codarea este realizată 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 cel mai bun mod rezolva problema actuala. Al doilea programator analizează munca primului și dă sfaturi, meditează la consecințele anumitor decizii, teste noi, soluții mai puțin directe, dar mai flexibile. Dacă este necesar, tastatura este transferată liber de la una la alta. În timpul lucrului la proiect, perechile nu sunt fixe: este recomandat să le amestecați astfel încât fiecare programator din echipă să aibă o bună înțelegere a întregului sistem. Astfel, programarea în pereche îmbunătățește comunicarea în echipă.

· Colectivdeţinerecod (colectivproprietate)

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

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

· Constantintegrare (continuuintegrare)

Sistemul este asamblat și testat pentru 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.

Dacă integrați suficient de des sistemul în curs de dezvoltare, puteți evita majoritatea problemelor asociate. În metodele tradiționale, integrarea se realizează de obicei chiar la sfârșitul lucrării asupra produsului, când se consideră că toate părțile constitutive ale sistemului în curs de dezvoltare sunt complet gata. În XP, integrarea codului la nivel de sistem se realizează de mai multe ori pe zi, după ce dezvoltatorii s-au asigurat că toate testele unitare funcționează corect.

În ciuda simplității sale, această tehnică are propriile reguli de utilizare, cum ar fi succesul testelor unitare existente pentru funcționalitatea integrată, prezența testelor funcționale sau de acceptare și, desigur, capacitatea de a reveni la starea anterioară... De obicei, integrarea și rezolvarea dificultăților asociate sunt efectuate pe un computer separat de către câțiva programatori. Acest lucru reduce la minimum riscul unor consecințe nedorite ale integrării.

· 40 de orelucruo săptămână

Orele suplimentare sunt considerate un semn mari problemeî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ă.

O persoană, mai ales dacă este programator, este capabilă de 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 nu poți face de dragul activității tale preferate. Dar programarea extremă este în mod categoric împotriva unui astfel de sacrificiu de sine și a încălcării legislației muncii acceptate.

Acest lucru este dictat nu numai de considerente de legalitate și umanitate, ci, în primul rând, de necesitatea îmbunătățirii 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 în ansamblu. Ș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 muncă până la nouă, iar a doua până la douăsprezece sau o persoană decide că este mai bine pentru el să lucreze sâmbăta și duminica, în timp ce celălalt este incomod.

Dar cel mai important lucru este că o persoană are nevoie de odihnă bună pentru a-și menține sănătatea și performanța. 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 firme occidentale, plecarea târziu de la serviciu este considerată un progres slab sau incapacitatea de a-și gestiona corect timpul de lucru. În cele mai multe cazuri, acesta este cazul. Și din punct de vedere medical, întârzierile la locul de muncă duc la oboseală constantă, iritabilitate și scăderea activității creierului. Este eficient? Cum să organizezi o comunicare deschisă constantă între dezvoltatorii dintr-o astfel de echipă și va fi posibilă programarea în pereche? Raspunsul este negativ. Normele sunt norme și trebuie respectate.

· Pornireclientvcomanda (pe- site-ulclient)

Principala problemă a dezvoltării software este lipsa de cunoștințe a programatorilor în domeniul dezvoltat. Programarea extremă a găsit și o cale de ieșire din această situație. Nu, acesta nu este un stagiu pentru un dezvoltator la întreprinderea clientului - atunci nu va dori să programeze. Dimpotrivă, este participarea clientului la procesul de dezvoltare.

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 oferi răspunsuri prompte la întrebări de orice tip referitoare la funcțiile sistemului, interfața acestuia, performanța necesară, lucru corect sisteme în situații dificile, nevoia de a comunica cu alte aplicații etc.

Mulți oameni se îndoiesc de posibilitatea de a implica clientul în procesul de dezvoltare. Într-adevăr, clienții sunt diferiți. Daca nu se poate atrage un client sau reprezentantul acestuia, uneori este indicat sa se angajeze temporar un specialist in zona in curs de dezvoltare. Un astfel de pas va reduce confuzia în lucru, va crește viteza de dezvoltare și va aduce proiectul mai aproape de ceea ce dorește clientul să obțină. Acest lucru poate fi benefic și din punct de vedere financiar: la urma urmei, salariul unui programator depășește uneori semnificativ salariul specialiștilor din alte industrii.

· UtilizarecodCumfacilităţicomunicatii

Codul este văzut ca cel mai important mijloc de comunicare în cadrul unei echipe. Claritatea codului este una dintre prioritățile noastre principale. Respectarea standardelor de codificare care oferă această claritate este imperativă. Astfel de standarde, pe lângă claritatea codului, trebuie să asigure că expresiile sunt menținute la minimum (fără duplicarea codului și a informațiilor) și trebuie acceptate de toți membrii echipei.

· Deschislucruspaţiu (deschisspațiu de lucru)

Echipa este găzduită într-o cameră suficient de mare pentru a facilita comunicarea și brainstormingul atunci când planificați și luați decizii tehnice importante.

· Schimbarearegulipenecesitatea (doarreguli)

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ă schimbare.

După cum puteți 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 și de autorii acestei tehnici. Dimensiunea mai mare a echipei distruge ușurința de comunicare necesară pentru succes și face multe dintre aceste tehnici imposibile.

3.1 Trucuri de bază XP

Douăsprezece tehnici de bază de programare extremă (bazate pe prima ediție a cărții Extrem programare explicat) pot fi combinate în patru grupe:

Feedback la scară fină

o Dezvoltare bazată pe teste

o Joc de planificare

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

o Programare cu perechi

Proces continuu, nu pe lot

o Integrare continuă

o Refactorizare (îmbunătățirea designului, refactorizare)

o Lansări mici frecvente

O înțelegere împărtășită de toți

o Simplitate (design simplu)

o Metafora sistemului

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

o Standard de codare sau convenții de codare

Bunăstarea programatorului:

o săptămână de lucru de 40 de ore (ritm sustenabil, săptămână de patruzeci de ore)

Joculvplanificare

Lumea noastră este prea volatilă și imprevizibilă pentru a ne baza pe constanța situației. La fel se întâmplă și cu dezvoltarea de software: o sistem rar putem spune că forma sa finală era cunoscută dinainte în detaliu chiar la începutul dezvoltării. De obicei, apetitul clientului vine odată cu mâncatul: el dorește constant să schimbe ceva, să îmbunătățească ceva și să arunce cu totul ceva din sistem. Aceasta este volatilitatea cererilor de care toată lumea se teme atât de mult. Din fericire, unei persoane i se oferă capacitatea de a prezice opțiuni posibileși astfel să țină situația sub control.

În programarea extremă, planificarea este o parte integrantă a dezvoltării și faptul că planurile se pot schimba este luat în considerare încă de la început. Jocul planificării este acel punct de sprijin, o tehnică care îți permite să prezici situația și să suporti fără durere schimbările. Într-un astfel de joc, puteți colecta rapid cerințele de sistem cunoscute, puteți evalua și planifica dezvoltarea lor în funcție de priorități.

Ca orice alt joc, planificarea are participanții și scopul său. Jucătorul cheie este, desigur, clientul. El este cel care informează despre necesitatea acestei sau acelea funcționalități. Programatorii, pe de altă parte, oferă o estimare aproximativă a fiecărei funcționalități. Frumusețea jocului de planificare constă în unitatea scopului și solidaritatea dintre dezvoltator și client: dacă câștigă, toată lumea câștigă, dacă pierde, toată lumea pierde. Dar, în același timp, fiecare participant merge pe drumul său către victorie: clientul alege cele mai importante sarcini în conformitate cu bugetul, iar programatorul evaluează sarcinile în conformitate cu capacitățile sale pentru implementarea lor.

Programarea extremă presupune că dezvoltatorii sunt capabili să decidă singuri cât timp le va lua pentru a-și îndeplini sarcinile și care dintre ei ar fi mai dispus să rezolve o sarcină și cine ar fi mai dispus să rezolve o alta.

Într-o situație ideală, un joc de planificare care implică un client și un programator ar trebui să fie desfășurat la fiecare 3-6 săptămâni, înainte de a începe următoarea iterație de dezvoltare. Acest lucru facilitează efectuarea de ajustări pe baza succeselor și eșecurilor iterației anterioare.

4. Avantaje și dezavantaje

Virtuțile XP, dacă poate fi aplicat, sunt o mare flexibilitate, capacitatea de a face rapid și precis modificări software-ului ca răspuns la cerințele în schimbare și dorințele individuale ale clienților, calitatea înaltă a codului rezultat și lipsa trebuie să convingă clienții că rezultatul corespunde așteptărilor lor.

Dezavantajele acestei abordări sunt imposibilitatea unor proiecte destul de mari și complexe în acest stil, imposibilitatea de a planifica calendarul și complexitatea proiectului pe un termen suficient de lung și de a prezice clar rezultatele unui proiect pe termen lung în ceea ce privește raportul. de calitatea rezultatului și costul timpului și al resurselor. De asemenea, se poate observa că XP nu este potrivit pentru acele cazuri în care solutii posibile nu se bazează imediat pe experiența anterioară, dar necesită cercetări preliminare.

5. Istoricul utilizării

XP, ca o colecție a tehnicilor 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 pentru 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 în timpul proiectului în sine și ulterior 3 cărți și o cantitate mare articole despre XP. Datele de mai jos ilustrează provocările unor 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 rulat folosind XP. Până atunci, el depășise deja bugetul și planurile pentru implementarea treptată a funcțiilor. Echipa de dezvoltare a fost redusă, iar timp de aproximativ o jumătate de an 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 jumătatea anului 1999, iar software-ul rezultat va fi folosit pentru a gestiona plățile către cei 87.000 de angajați ai companiei. A fost oprit în februarie 2000 după 4 ani de rulare XP din cauza nerespectării complete a termenelor și bugetului. Software-ul nu a fost niciodată folosit pentru a lucra cu datele a peste 10.000 de angajați, deși s-a demonstrat că face față datelor a 30.000 de angajați ai companiei. Persoana care a jucat rolul clientului inclus în echipa în proiect a renunțat după câteva luni de astfel de muncă, neputând suporta sarcina, și nu a primit o înlocuire adecvată până la finalul proiectului.

Concluzie

Toate metodele de mai sus sunt reunite dintr-un motiv. Combinația lor consistentă este capabilă să introducă procesul de dezvoltare în rezonanță intelectuală, crescând semnificativ calitatea produsului și apropiind momentul lansării acestuia. Farmecul principal al tuturor programărilor extreme este predictibilitatea și minimizarea costurilor de dezvoltare; furnizarea clientului cu produsul pe care dorește să-l primească în momentul lansării; și, desigur, comunicarea și formarea dezvoltatorilor la locul de muncă.

Opiniile despre tehnica propusă pot varia. Este important să înțelegeți că programarea extremă nu are ca scop înlocuirea tehnologiile existente dezvoltare. Dimpotrivă, XP vă permite să oferiți un impuls suplimentar echipelor care folosesc abordări tradiționale. Nu ar trebui să cauți răspunsuri la toate întrebările care apar aici. Aceasta nu este o tehnologie de programare, dar mai degrabă tehnologie organizarea muncii și tocmai în această formă are dreptul la viață.

Postat pe Allbest.ru

Documente similare

Analiza etapelor și caracteristicilor dezvoltării unui model ARIS optim și funcțional - un produs software de la IDS Scheer pentru modelarea proceselor de afaceri ale companiei. Studiul conceptelor, metodologiilor și abordărilor de bază ale programării extreme.

test, adaugat 06.04.2011


Principalele etape ale dezvoltării software (pachet software), analiza cerințelor de sistem. Metoda de detaliere pas cu pas. Limbaje de programare de nivel scăzut și de nivel înalt (imperative, orientate pe obiecte, funcționale, logice).

prezentare adaugata la 13.10.2013


Limbajul de dezvoltare, mediul de implementare, instrumente de dezvoltare. Particularități mediu virtual implementarea programelor și contabilitatea acestora în dezvoltarea unui produs software. Macro-urile de sistem și utilizarea lor în textele de dezvoltare. Instrumente de programare vizuală.

tutorial, adăugat 26.10.2013


Problema fiabilității software-ului, indicatorii săi și factorii de suport. Metode de control al procesului de elaborare a programelor și documentației, prevenirea erorilor. Etapele procesului de depanare software, tehnici de programare structurată și principiul modularității.

prezentare adaugata la 30.04.2014


Coduri de mașină și asamblator. Primele limbaje de programare de nivel înalt. limbaj de programare FORTRAN. Avantaje și dezavantaje ale ALGOL. Software științific și contabil. Principiile de bază care au fost urmate la crearea limbajului de programare Basic.

lucrare de termen adăugată 21.06.2014


Conceptul și diferența cheie a dezvoltării software distribuite, avantajele și dezavantajele sale. Soluția conceptuală și alegerea tipului de dezvoltare. Caracteristici ale software-ului open source. Idee și dezvoltare Open Source.

lucrare de termen adăugată 14.12.2012


Concept ciclu de viață software. Două tipuri de activități se disting în proiecte tehnice: proiectare și producție. Principiile principale ale manifestului agil. Principiile de bază ale programării extreme.

prezentare adaugata la 14.08.2013


Standard international la limbajul de programare Pascal. Tehnici de programare orientată pe obiecte în Turbo Pascal. Simboluri ale limbii, alfabetul ei. Etapele dezvoltării programului. Conceptul de algoritmi și algoritmi. Structura programelor în Pascal.

lucrare de termen, adăugată 28.02.2010


Instrumente moderne de dezvoltare software pentru SUTP. Limbaje de programare universale și compararea lor cu sistemele SCADA. Dezvoltare software folosind multicanal traductoare de măsurareШ9327.

teză, adăugată 13.07.2011


Tehnici de bază pentru lucrul în mediu Programare Delphi... Caracteristici ale tehnologiei pentru crearea celor mai simple aplicații. Lucrul cu componente ale mediului de dezvoltare a aplicațiilor. Introducerea, editarea, selectarea și ieșirea informațiilor. Aspecte de utilizare a structurii de ramificare.

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

Jocul de planificare

Lumea noastră este prea volatilă și imprevizibilă pentru a ne baza pe constanța situației. La fel se întâmplă și în dezvoltarea de software: despre un sistem rar, putem spune că aspectul său final a fost cunoscut dinainte în detaliu chiar de la începutul dezvoltării. De obicei, apetitul clientului vine odată cu mâncatul: el dorește constant să schimbe ceva, să îmbunătățească ceva și să arunce cu totul ceva din sistem. Aceasta este volatilitatea cererilor de care toată lumea se teme atât de mult. Din fericire, unei persoane i se oferă capacitatea de a prezice posibile opțiuni și, astfel, de a menține situația sub control.
În programarea extremă, planificarea este o parte integrantă a dezvoltării și faptul că planurile se pot schimba este luat în considerare încă de la început. Jocul planificării este acel punct de sprijin, o tehnică care îți permite să prezici situația și să suporti fără durere schimbările. Într-un astfel de joc, puteți colecta rapid cerințele de sistem cunoscute, puteți evalua și planifica dezvoltarea lor în funcție de priorități.
Ca orice alt joc, planificarea are participanții și scopul său. Jucătorul cheie este, desigur, clientul. El este cel care informează despre necesitatea acestei sau acelea funcționalități. Programatorii, pe de altă parte, oferă o estimare aproximativă a fiecărei funcționalități. Frumusețea jocului de planificare constă în unitatea scopului și solidaritatea dintre dezvoltator și client: dacă câștigă, toată lumea câștigă, dacă pierde, toată lumea pierde. Dar, în același timp, fiecare participant merge pe drumul său către victorie: clientul alege cele mai importante sarcini în conformitate cu bugetul, iar programatorul evaluează sarcinile în conformitate cu capacitățile sale pentru implementarea lor.
Programarea extremă presupune că dezvoltatorii sunt capabili să decidă singuri cât timp le va lua pentru a-și îndeplini sarcinile și care dintre ei ar fi mai dispus să rezolve o sarcină și cine ar fi mai dispus să rezolve o alta.
Într-o situație ideală, un joc de planificare care implică un client și un programator ar trebui să fie desfășurat la fiecare 3-6 săptămâni, înainte de a începe următoarea iterație de dezvoltare. Acest lucru facilitează efectuarea de ajustări pe baza succeselor și eșecurilor iterației anterioare.

Planul de lansare

Planul de lansare definește datele de lansare și limba utilizatorului care vor fi încorporate în fiecare lansare. Pe baza acestui lucru, puteți alege formularea pentru următoarea iterație. Testele de acceptare sunt produse în timpul unei iterații și rulează în cadrul acelei iterații și în toate iterațiile ulterioare pentru a se asigura că programul funcționează corect. Planul poate fi revizuit în cazul unui întârziere sau avans semnificativ în urma rezultatelor uneia dintre iterații.
Iterații. Iterația face procesul de dezvoltare dinamic. Nu trebuie să vă planificați sarcinile de programare cu mult timp înainte. În schimb, cel mai bine este să aveți o întâlnire de planificare la începutul fiecărei iterații. Nici nu ar trebui să încerci să implementezi ceea ce nu a fost planificat. Veți avea în continuare timp să implementați aceste idei când vine vorba de ele conform planului de lansare.
Obișnuindu-vă să nu adăugați funcționalități în avans și folosind planificarea directă, 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 veni cu un plan de pași pentru a aborda problema de programare. Fiecare iterație ar trebui să dureze între una și trei săptămâni. Declarațiile din cadrul iterației sunt sortate în ordinea importanței lor pentru client. În plus, se adaugă sarcini care nu au putut trece testele de acceptare și necesită revizuire. Formulările și rezultatele testelor sunt traduse în sarcini software. Sarcinile sunt înregistrate pe carduri care formează un plan de iterație detaliat. Pentru a rezolva fiecare dintre sarcini, este nevoie de una până la trei zile. Sarcinile care durează mai puțin de o zi pot fi grupate împreună, iar sarcinile mari pot fi împărțite în altele mai mici. Dezvoltatorii estimează sarcinile și termenele limită pentru a le îndeplini. Este foarte important ca dezvoltator să stabilească ora exactă de execuție a sarcinii. Poate fi necesar să se reevalueze o parte din formulare și să se revizuiască planul de lansare după fiecare trei sau cinci iterații - acest lucru este perfect acceptabil. Daca implementezi cele mai importante domenii de lucru in primul rand, atunci vei avea intotdeauna timp sa faci maxim posibil pentru clientii tai. Un stil de dezvoltare bazat pe o secvență de iterații î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 crește 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, participarea tuturor oamenilor la întâlniri preia resurse din proiect și creează haos în planificare.
Pentru acest tip de comunicare este nevoie de o întâlnire permanentă. Este mult mai bine să aveți o întâlnire scurtă, obligatorie, decât multe întâlniri lungi la care majoritatea dezvoltatorilor trebuie să participe oricum.
Dacă aveți întâlniri permanente zilnice, atunci la toate celelalte întâlniri ar trebui să participe doar acele persoane care sunt necesare și care vor aduce ceva. 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 economisi multe alte întâlniri și vă va economisi mai mult timp decât ați pierdut.

Simplitate

Modelele simple necesită întotdeauna mai puțin timp decât modelele complexe. Așa că fă întotdeauna cele mai simple lucruri care pot funcționa. Este întotdeauna mai rapid și mai ieftin să înlocuiți codul complex imediat înainte de a petrece mult timp lucrând cu el. Păstrați lucrurile cât mai simple posibil, fără a adăuga funcționalitate înainte de a fi planificat. Rețineți: menținerea 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 denumești obiectele este foarte important pentru înțelegerea designului general al sistemului și reutilizarea codului. Dacă dezvoltatorul este capabil să prezică corect cum facilitate existenta, 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 despre sistem.

Client pe site

Principala problemă a dezvoltării software este lipsa de cunoștințe a programatorilor în domeniul dezvoltat. Programarea extremă a găsit și o cale de ieșire din această situație. Nu, acesta nu este un stagiu pentru un dezvoltator la întreprinderea clientului - atunci nu va dori să programeze. Dimpotrivă, este participarea clientului la procesul de dezvoltare.
Cum poate un programator, fără să înțeleagă temeinic esența problemei și să nu fie un 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ările mai riguroase necesită o analiză preliminară cuprinzătoare a zonei în curs de dezvoltare. V anumite cazuri este justificat, desi este mai scump. Experiența de viață 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 au fost colectate în acest moment, va exista totuși un blocaj: programele, ca orice altceva în natură, nu sunt create instantaneu și, între timp, procesele de afaceri se pot schimba. Acest lucru ar trebui luat în considerare.
Mulți oameni se îndoiesc de posibilitatea de a implica clientul în procesul de dezvoltare. Într-adevăr, clienții sunt diferiți. Daca nu se poate atrage un client sau reprezentantul acestuia, uneori este indicat sa se angajeze temporar un specialist in zona in curs de dezvoltare. Un astfel de pas va reduce confuzia în lucru, va crește viteza de dezvoltare și va aduce proiectul mai aproape de ceea ce dorește clientul să obțină. Acest lucru poate fi benefic și din punct de vedere financiar: la urma urmei, salariul unui programator depășește uneori semnificativ salariul specialiștilor din alte industrii.
Povestea utilizatorului. Povestea utilizatorului (ceva ca o poveste a utilizatorului) este o descriere a modului în care ar trebui să funcționeze sistemul. Fiecare User Story este scrisă pe un card și reprezintă o piesă a funcționalității sistemului care are sens logic din punctul de vedere al Clientului. Formați unul sau două paragrafe de text care să fie înțeles de utilizator (nu foarte tehnic).
Povestea utilizatorului este scrisă de Client. 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 care să confirme că povestea este corect implementată - se mai numesc și teste de acceptare.

Testarea înainte de dezvoltare

Testarea, în sensul său clasic, este o procedură destul de plictisitoare. De obicei, se 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: testează-ți gândurile - la ce să te aștepți de la o viitoare bucată de software 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. Ce, scriind 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? Fixați a doua piuliță aproape de prima, astfel încât fiecare piuliță să împiedice rotirea piuliței vecine. Așa este și î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 implementării nerevendicate în acest moment Detalii.

Programare pereche

Tot codul pentru un sistem de producție este scris în perechi. Doi dezvoltatori stau unul lângă altul. Unul formează, celălalt arată. 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 (s-a îmbolnăvit, a plecat 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ă grozav în perechi. Le place chiar și pentru că munca se face mult mai repede. Principiul „Un cap este bun, dar doi este mai bine”. De obicei, cuplurile găsesc soluții mai bune. În plus, calitatea codului este crescută semnificativ, numărul de erori este redus și schimbul de cunoștințe între dezvoltatori este accelerat. În timp ce o persoană se concentrează pe vederea strategică a obiectului, a doua pune în aplicare proprietățile și metodele acestuia.

Schimbarea posturilor

Î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 " locuri înguste". 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 modulele lor. Orice dezvoltator poate modifica 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, că testele vă permit să verificați corectitudinea modificărilor efectuate și că în viata reala tot la fel, într-un fel sau altul, trebuie să înțelegi codul altcuiva, devine clar că proprietatea colectivă a codului simplifică foarte mult 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ă de mult timp la acest proiect. Oamenii vin și pleacă. Nimeni nu codifică singur și codul aparține tuturor. Vor exista întotdeauna momente când va fi necesar să înțelegeți și să corectați codul altcuiva. Dezvoltatorii vor elimina sau vor modifica codul duplicat, vor analiza și îmbunătăți clasele altor persoane etc. În timp, nu se va putea spune 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. Astfel, vom fi siguri că făcând modificări codului altcuiva (care este necesar pentru o mișcare înainte agresivă și extremă), nu îl vom transforma în Pandemoniu Babilonian.
Cele de mai sus înseamnă că toți membrii echipei trebuie să cadă de acord asupra standardelor comune de codare. Nu contează ce. 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 ori de câte ori este posibil. În orice caz, modificările nu trebuie păstrate niciodată mai mult de o zi. Integrarea frecventă evită înstrăinarea și fragmentarea în dezvoltare, unde dezvoltatorii nu pot comunica în sensul împărtășirii ideilor sau al reutilizarii codului. Toată lumea ar trebui să lucreze din cel mai mult ultima versiune.
Fiecare pereche de dezvoltatori ar trebui să-și elibereze codul de îndată ce apare o oportunitate rezonabilă. Poate fi atunci când toate UnitTest 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 târziu. Așadar, integrând modificările în fiecare zi în bucăți mici, nu va trebui să petreceți o săptămână legând sistemul înainte ca proiectul să fie predat. Lucrați întotdeauna la cea mai recentă versiune a sistemului.

Patruzeci de ore pe săptămână

O persoană, mai ales dacă este programator, este capabilă de multe lucruri de dragul afacerilor: să stea târziu la serviciu, să meargă la muncă în weekend, să renunțe la vacanță, să stea treaz câteva zile, să stea la tastatură... În general, ce nu poți face de dragul activității tale preferate. Dar programarea extremă este în mod categoric împotriva unui astfel de sacrificiu de sine și a încălcării legislației muncii acceptate.
Acest lucru este dictat nu numai de considerente de legalitate și umanitate, ci, în primul rând, de necesitatea îmbunătățirii 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 în ansamblu. Ș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 muncă până la nouă, iar a doua până la douăsprezece sau o persoană decide că este mai bine pentru el să lucreze sâmbăta și duminica, în timp ce celălalt este incomod.
Dar cel mai important lucru este că o persoană are nevoie de odihnă bună pentru a-și menține sănătatea și performanța. 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 firme occidentale, plecarea târziu de la serviciu este considerată un progres slab sau incapacitatea de a-și gestiona corect timpul de lucru. În cele mai multe cazuri, acesta este cazul. Și din punct de vedere medical, întârzierile la locul de muncă duc la oboseală constantă, iritabilitate și scăderea activității creierului. Este eficient? Cum să organizezi o comunicare deschisă constantă între dezvoltatorii dintr-o astfel de echipă și va fi posibilă programarea în pereche? Raspunsul este negativ. Normele sunt norme și trebuie respectate.

Concluzie

Aceste tehnici sunt reunite dintr-un motiv. Combinația lor consistentă este capabilă să introducă procesul de dezvoltare în rezonanță intelectuală, crescând semnificativ calitatea produsului și apropiind momentul lansării acestuia. Farmecul principal al tuturor programărilor extreme este predictibilitatea și minimizarea costurilor de dezvoltare; furnizarea clientului cu produsul pe care dorește să-l primească în momentul lansării; și, desigur, comunicarea și formarea dezvoltatorilor la locul de muncă.

Bibliografie:

Extreme Programming - sau XP (eXtreme Programming) pe scurt - este răspunsul comunității de programare la atacul abordărilor formale ale dezvoltării software și este conceput pentru a aduce creativitatea înapoi comunității dezvoltatorilor.

Orice idee adusă până la absurd degenerează în propriul ei opus. Aceasta este exact situația în industria de software RAD din America de Nord. La un moment dat, instrumentele concepute pentru dezvoltarea rapidă a aplicațiilor au început să înlocuiască orice altceva în mintea managerilor, inclusiv dezvoltatorii, clienții și proiectul în sine. Atenția nejustificată, exagerată a Procesului în detrimentul altor factori de dezvoltare a dat naștere la o mulțime de proceduri formale - dar calitatea produselor primite și numărul de proiecte de succes s-au dovedit a fi dezamăgitoare.

Pentru a rezista presiunii formalismului în munca programatorilor este chemată inițiativa unui grup de dezvoltatori, uniți sub sloganul Extreme Programming, sau XP.

La baza programării extreme se află câteva principii foarte specifice, adesea cuantificate, care definesc ce, când și cum se face. Deși nu percepem aceste numere ca dogme, trebuie totuși să ținem cont de faptul că ele au apărut ca urmare a analizei a numeroase proiecte de succes și nereușite, astfel încât cel puțin ar trebui să existe motive întemeiate pentru a face propriile modificări.

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

Programarea extremă oferă o soluție gata făcută: păstrați totul cât mai simplu posibil, țineți clientul cu dvs. sau rămâneți singur cu clientul, lăsați-l să urmărească în mod activ procesul de dezvoltare, salutați schimbările - iar succesul este aproape garantat.

În echipele XP, comunicarea este întotdeauna binevenită - cel mai rapid mijloc 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ă, se lucrează la simplificare din nou și din nou până când obiectivul principal este atins - inteligibilitatea maximă a codului pentru alți dezvoltatori.

Ciclu extrem

Programarea extremă se bazează pe un ciclu de dezvoltare foarte scurt și repetitiv 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 ar trebui să fie repetitive și neîntrerupte pe tot parcursul proiectului.

O condiție prealabilă pentru un astfel de mod de operare este faptul dovedit că cerințele sunt rareori complete, oportune și corecte. Cu alte cuvinte, indiferent cât de bine este planificată aplicația, va trebui să fie reproiectată 100%. Mai mult, poate fi necesar să fie refăcut chiar și în etapa finală. Nu ar trebui să amânați repetarea până la sfârșitul lucrării, trebuie să le faceți în mod regulat.

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

Programarea extremă este o metodologie pentru dezvoltarea rapidă a software-ului. Constă dintr-un set de tehnici și principii care permit, atât individual, cât și în complex, optimizarea procesului de dezvoltare. Această abordare guvernează și drepturile dezvoltatorilor și clienților.

Drepturi și roluri

În programarea extremă, toate rolurile sunt descrise clar. Fiecare rol are un set distinct de drepturi și responsabilități. Există două roluri cheie aici: client și dezvoltator.

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;
• stiu Starea curenta sisteme;
• modifica cerințele de sistem atunci când contează cu adevărat.

Pentru a-și exercita cu succes drepturile, clientul trebuie să se bazeze pe datele furnizate de dezvoltatori.

Dezvoltator

Unul sau un grup de două până la zece persoane direct implicate în programare și probleme de inginerie conexe. Dezvoltatorul este dotat cu următoarele drepturi si responsabilitati:

• să obțină cunoștințe suficiente despre problemele care urmează să fie programate;
• să poată clarifica detaliile în timpul procesului de dezvoltare;
• furnizați estimări orientative, dar sincere ale costurilor forței de muncă pentru fiecare parte funcțională sau poveste de utilizator;
• ajusta estimările în favoarea unora mai precise în procesul de dezvoltare;
• să ofere o evaluare a riscurilor asociate cu utilizarea unor tehnologii specifice.

Roluri în cadrul unui rol

Fiecare dintre rolurile de bază ale programării extreme poate fi rafinat prin roluri mai mici. În XP, este permisă combinarea rolurilor în cadrul aceleiași persoane.

Partea clientului

Creator de povești- un specialist în domeniu, care are 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 controlează funcționarea corectă a sistemului. Buna comanda domeniul subiectului... Responsabilitățile includ redactarea testelor de acceptare.

Mare sef- monitorizează activitatea tuturor legăturilor, de la dezvoltatori până la utilizatori finali... El supraveghează implementarea sistemului și a problemelor organizaționale conexe. Poate fi și investitor într-un proiect.

Partea dezvoltatorului

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

Instructor- un dezvoltator cu experiență, care stăpânește bine întregul proces de dezvoltare și metodele acestuia. Responsabil de predarea echipei aspecte ale procesului de dezvoltare. Implementează și controlează implementarea corectă a metodologiilor procesului utilizat. Atrage atenția echipei asupra unor puncte de dezvoltare importante, dar ratate din anumite motive. În același timp, instructorul, ca orice altă persoană, nu este omniscient și atent la ideile celorlalți membri ai echipei.

Observator este un membru al echipei de dezvoltare care are încredere de către întregul grup și 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 viteza medie și procentul de sarcini finalizate și programate. Aceasta informatie furnizate clientului pentru controlul în timp util asupra situației. Unele dintre aceste informații sunt furnizate în mod discret dezvoltatorilor, pentru a cunoaște starea proiectului, locurile în care apar dificultăți și ce se mai poate face.

Diplomat- personalitate comunicativă, iniţierea comunicării între membrii echipei. Deoarece fluxul de lucru este minimizat, este importantă comunicarea constantă și transferul de experiență în cadrul echipei, precum și o mai bună înțelegere a cerințelor sistemului. Diplomatul reglementează și simplifică comunicarea dintre clienți și dezvoltatori. Este o verigă importantă în întâlniri. El previne neînțelegerile, culmea pasiunilor și certurile inutile. Un diplomat nu poate să-și impună părerea celui care dezbate.

Roluri externe

Consultant- un specialist cu abilități tehnice specifice pentru a ajuta dezvoltatorii cu sarcini dificile. De obicei atras din exterior.

Reguli de programare extreme

Convenția de codificare

Sunteți într-o echipă care lucrează de mult timp la acest proiect. Oamenii vin și pleacă. Nimeni nu codifică singur și codul aparține tuturor. Vor exista întotdeauna momente când va fi necesar să înțelegeți și să corectați codul altcuiva. Dezvoltatorii vor elimina sau vor modifica codul duplicat, vor analiza și îmbunătăți clasele altor persoane etc. În timp, nu se va putea spune 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. Astfel, vom fi siguri că făcând modificări codului altcuiva (care este necesar pentru o mișcare înainte agresivă și extremă), nu îl vom transforma în Pandemoniu Babilonian.

Cele de mai sus înseamnă că toți membrii echipei trebuie să cadă de acord asupra standardelor comune de codare. Nu contează ce. 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 modulele lor. Orice dezvoltator poate schimba orice cod pentru a extinde funcționalitatea, a remedia erori sau a refactoriza.

La prima vedere, pare un haos. Totuși, ț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ă în viața reală mai trebuie să înțelegeți codul altcuiva într-un fel sau altul, devine clar că proprietatea colectivă a codului simplifică foarte mult efectuarea modificărilor și reduce riscul asociat cu specializarea ridicată a unuia sau altuia membru al echipei.

Sesiunea CRC

Utilizați cardurile de clasă, responsabilități, colaborare (CRC) pentru a proiecta sistemul ca o echipă. Folosind carduri, este mai ușor să vă obișnuiți să gândiți în obiecte, mai degrabă decât în ​​funcții și proceduri. De asemenea, cardurile permit Mai mult oamenii participă la procesul de proiectare (în mod ideal, întreaga echipă) și cu cât mai mulți oameni realizează designul, cu atât mai mult idei interesante vor fi aduse.

Fiecare card CRC este o instanță de obiect. Clasa de obiecte 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 de obicei trebuie să o facă numar mic carduri cu nume de clasă și nu trebuie să fie completate complet.

Sesiunea CRC decurge astfel: fiecare dintre participanți reproduce sistemul spunând ce mesaje trimite către ce obiecte. Parcurge întregul proces mesaj cu mesaj. Puncte slabe iar problemele sunt imediat identificate. Alternativele de proiectare sunt, de asemenea, clar vizibile în simularea procesului.

Pentru a pune lucrurile în ordine, este adesea folosită limitarea numărului de doi care interacționează simultan.

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ă comunicarea cu clientul, cel mai bine față în față - la fața locului. Cel mai bine este să atribuiți 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 ajută să se asigure că majoritatea funcțiilor de sistem dorite sunt acoperite de Povestea utilizatorului.

Atunci când planifică o lansare, 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 eliberării în sine. Clientul ia decizii legate de obiectivele afacerii.

Alege cea mai simplă soluție

Proiectele simple sunt întotdeauna mai ușor de implementat decât modelele complexe. Deci, faceți întotdeauna cea mai simplă soluție care poate funcționa. Dacă găsești ceva dificil, înlocuiește-l cu ceva simplu. Este întotdeauna mai rapid și mai ieftin să înlocuiți codul complex cu cod simplu înainte de a începe să înțelegeți codul complex.

Refactorizare codul altcuiva dacă vi se pare complicat. Dacă ceva pare complicat, acesta este un semn sigur al unei probleme în codul tău.

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 să apară nevoia. Cu toate acestea, rețineți: păstrarea designului simplu este o muncă grea.

Teste funcționale

Testele de acceptare (denumite anterior și teste funcționale) sunt scrise pe baza poveștii utilizatorului. Ei văd sistemul ca pe o cutie neagră. Clientul este responsabil pentru verificarea corectitudinii testelor functionale. Aceste teste sunt utilizate pentru a verifica starea de sănătate a sistemului înainte de a fi lansat în producție. Testele funcționale sunt automatizate, astfel încât să le puteți rula frecvent. Rezultatul este comunicat echipei, iar echipa este responsabilă de programarea remedierii testelor funcționale.

Integrare frecventă

Dezvoltatorii ar trebui să-și integreze și să elibereze codul la fiecare câteva ore ori de câte ori este posibil. În orice caz, modificările nu trebuie păstrate niciodată mai mult de o zi. Integrarea frecventă evită înstrăinarea și fragmentarea în dezvoltare, unde dezvoltatorii nu pot comunica în sensul împărtășirii ideilor sau al reutilizarii codului. Toată lumea ar trebui să lucreze cu cea mai recentă versiune.

Fiecare pereche de dezvoltatori ar trebui să-și elibereze codul de îndată ce există o oportunitate rezonabilă de a face 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 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 lega sistemul într-un întreg, imediat înainte de livrarea proiectului. 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ă vă dați seama imediat care este problema. Toată experiența echipelor XP spune că motivul întârzierii este întotdeauna designul prost și întotdeauna trebuie refăcut ulterior.

Planificarea unei iterații

O întâlnire de planificare a iterației este convocată înainte de începerea fiecărei iterații pentru a programa sarcinile care urmează să fie efectuate în acea iterație. Pentru iterare, sunt selectate poveștile utilizatorului pe care le-a selectat clientul planul de lansareîncepând cu cel mai important pentru client și cel mai rău (asociat cu riscul) pentru dezvoltatori. Testele funcționale nefuncționale sunt de asemenea incluse în iterație.

Poveștile utilizatorilor și testele funcționale eșuate sunt împărțite în sarcini. Sarcinile sunt înregistrate pe carduri. 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 dezasambla 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 dezvoltatorul însuși să facă estimarea finală a domeniului de activitate.

Viteza proiectului determină dacă sarcinile dvs. se potrivesc sau nu în iterație. Durata totală a sarcinilor programate 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 la 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 poveștile utilizatorului în două pentru a include partea în iterația curentă.

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

Urmăriț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, planul de lansare este o privire în viitor și este firesc să te aștepți că previziunile tale vor trebui ajustate.

Repetare

Dezvoltarea iterativă crește flexibilitatea procesului. Împărțiți-vă planul în iterații cu o durată de 2 până la 3 săptămâni. Mențineți o durată 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 programați sarcini în avans. Adună în schimb Planificarea unei iterații la începutul fiecărei iterații pentru a planifica ceea ce se va face. De asemenea, este considerat o încălcare a regulilor să alergi înainte și să faci ceea ce 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ă puteți vedea că nu puteți finaliza toate sarcinile programate 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-vă eforturile pe finalizarea celor mai importante sarcini selectate de Client, în loc să aveți câteva sarcini neterminate selectate de dezvoltator.

Schimbați sarcinile

Este necesar să se schimbe periodic sarcinile dezvoltatorilor pentru a reduce riscul de concentrare a 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 doar ai multe de făcut în acest segment al programului, vei descoperi că proiectul tău abia merge înainte.

Cross Training-ul este de obicei un aspect important în companiile care încearcă să evite concentrarea cunoștințelor asupra unei singure persoane. Mutarea oamenilor prin cod în combinație cu programarea perechilor face în mod discret Cross Training pentru tine. În loc de o persoană care ș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 în același timp.

Când începeți un nou iterații fiecare dezvoltator ar trebui să meargă la sarcina noua... Asocierea ajută la depășirea problemei de adaptare (ceea ce înseamnă că un nou dezvoltator se poate asocia cu un dezvoltator cu experiență în domeniu).

Această practică stimulează, de asemenea, idei noi și îmbunătățiri ale codului.

Salvați optimizarea pentru mai târziu

Nu optimizați niciodată nimic înainte de a termina codificarea. 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 corect, apoi faceți-l rapid.

Programare pereche

Tot codul pentru un sistem de producție (ceea ce înseamnă excluderea soluțiilor de probă) este scris în perechi. Doi dezvoltatori stau unul lângă altul. Unul formează, celălalt arată. 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 (s-a îmbolnăvit, a plecat etc.), el este obligat să revizuiască toate modificările făcute de primul.

Sună neobișnuit, dar XP susține că, după o scurtă perioadă de adaptare, majoritatea oamenilor lucrează bine în perechi. Le place chiar și pentru că munca se face mult 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 este crescută semnificativ, numărul de erori este redus și schimbul de cunoștințe între dezvoltatori este accelerat.

Refactorizează fără milă!

Noi, programatorii, avem tendința să rămânem la un design mult timp după ce acesta devine incomodă. Continuăm să reutilizam codul greu de manevrat pentru că încă funcționează cumva și ne este teamă să-l încurcăm. Dar este chiar benefic? XP consideră că nu este profitabil. Când eliminăm redundanța, îmbunătățim designul învechit, eliminăm bucățile neutilizate - refactorăm. În cele din urmă, refactorizarea economisește timp și îmbunătățește calitatea produsului.

Revizuiți fără milă orice cod pentru a menține designul simplu pe măsură ce 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 modificarea unui sistem complicat.

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 utilizate ulterior pentru a planifica iterații.

Este important ca oamenii tehnici să ia decizii tehnice, iar oamenii de afaceri să ia decizii de afaceri. Release Planning definește un set de reguli care permit fiecăruia să ia propriile decizii. Aceste reguli definesc metoda de elaborare a unui plan de lucru care ii satisface pe toti.

Esența întâlnirii de planificare a lansării pentru echipa de dezvoltare este evaluarea 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 nu vă mai 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 înregistrate pe carduri. Dezvoltatorii și Clientul amestecă cărțile împreună 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ă lanseze un sistem util care poate fi testat cât mai curând posibil.

O lansare poate fi programată în funcție de timp sau de volum. Pentru a determina câte povești de utilizator pot fi implementate până la o anumită dată sau cât timp va dura un anumit set de sarcini în timp real, se folosește viteza proiectului. Dacă planificați la 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 termenul limită pentru finalizare, poate fi tentant să reducă estimările de aplicare. Nu ar trebui să faci asta niciodată. Evaluările subestimate vor crea o mulțime de probleme mai târziu. În schimb, negociați cu managerii, dezvoltatorii și clienții până când aveți un plan de lansare acceptabil pentru toată lumea.

Lansări frecvente

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

Planificarea lansării este folosit pentru a găsi mici fragmente funcționale care au un sens semnificativ de afaceri și care pot fi eliberate în mediul real în stadiile incipiente de dezvoltare. Este esențial să primiți la timp recenzii utile pentru a putea influenţa procesul de dezvoltare. Cu cât amânați mai mult lansarea 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 probă pentru a răspunde la complex probleme tehnice, pentru a justifica anumite soluții tehnologice. Există un risc în orice decizie de tehnologie, iar deciziile de încercare sunt concepute pentru a-l atenua.

Realizați un program care reproduce problema investigată și ignoră orice altceva. Majoritatea soluțiilor de probă nu sunt destinate utilizării viitoare, așa că așteptați-vă să fie aruncate. Scopul creării lor este de a reduce riscul de a accepta greșeala solutie tehnica sau o estimare mai precisă a timpului pentru implementarea Povestea utilizatorului.

Întâlnire în picioare

În fiecare dimineață are loc o întâlnire pentru a discuta problemele, soluțiile acestora și pentru a crește 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. Mulți oameni alocă timp pentru a obține o cantitate mică de comunicare. Prin urmare, participarea tuturor oamenilor la întâlniri preia resurse din proiect și creează haos în planificare.

Pentru acest tip de comunicare este nevoie de o întâlnire permanentă. Este mult mai bine să aveți o întâlnire scurtă, obligatorie, decât multe întâlniri lungi la care majoritatea dezvoltatorilor trebuie să participe oricum.

Dacă aveți întâlniri permanente zilnice, atunci la toate celelalte întâlniri ar trebui să participe doar acele persoane care sunt necesare și care vor aduce ceva. 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 economisi multe alte întâlniri și vă va economisi mai mult timp decât ați pierdut.

Metafora sistemului

Alegeți întotdeauna System Metaphor - un concept simplu și direct pentru ca membrii echipei să numească toate lucrurile cu același nume. Pentru înțelegerea sistemului și evitarea codului duplicat, este extrem de important cum denumești obiectele. Dacă poți ghici care este numele oricărui obiect din sistem (dacă știi ce face) și chiar se numește așa - vei economisi mult timp și efort. Creați un sistem de denumire pentru obiectele dvs., astfel încât toată lumea din echipă 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. Testul unitar este scris pentru fiecare clasă, testul ar trebui să verifice toate aspectele muncii clasei - testați tot 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, scrieți sistem special testarea cu propria interfață.

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

Este o tentație uriașă să economisiți bani la testele unitare atunci când timpul este scurt. Dar prin aceasta 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. De asemenea, testele unitare vă permit să aveți un sistem de lucru stabil în orice moment.

Povestea utilizatorului

Povestea utilizatorului (ceva ca o poveste a utilizatorului) este o descriere a modului în care ar trebui să funcționeze sistemul. Fiecare User Story este scrisă pe un card și reprezintă o piesă a funcționalității sistemului care are sens logic din punctul de vedere al Clientului. Formă - unul sau două paragrafe de text care sunt de înțeles de către utilizator (nu foarte tehnic).

Povestea utilizatorului este scrisă de Client. Sunt similare cu cazurile de utilizare ale sistemului, dar nu se limitează la interfața cu utilizatorul. Pentru fiecare poveste sunt scrise teste funcționale care să confirme că povestea este corect implementată - se mai numesc și teste de acceptare.

Fiecare poveste de utilizator i se acordă o prioritate de către afacere (utilizator, client, marketing) și o estimare a timpului de livrare de către dezvoltatori. Fiecare poveste este împărțită în sarcini și îi este alocat un moment când va începe să fie implementată.

User Stories sunt folosite în XP în loc de cerințele tradiționale. Principala diferență dintre User Story ș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 se realizează munca în proiectul dvs.

Pentru a măsura viteza unui proiect, trebuie pur și simplu să calculați dimensiunea User Stories sau câte sarcini (în timp) au fost finalizate într-o iterație. Doar calculați timpul total pentru a estima volumul 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 programării iterației, viteza proiectului din 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ă aveți timp liber după recuperare, mergeți la client și cereți mai multă poveste de utilizator. Ca urmare, viteza va crește din nou.

Nu utilizați acest parametru ca 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 mici schimbări în viteza proiectului pe măsură ce lucrați. Dar dacă viteza se schimbă mult, trebuie să reprogramați lansarea. O singura data sistem nou merge la utilizatori, așteptați-vă la o schimbare a vitezei proiectului, deoarece veți avea sarcini de asistență.

Când se găsește o eroare

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

Testul funcțional eșuat necesită creare Test unitar... Acest lucru ajută la concentrarea eforturilor de depanare și arată clar când eroarea a fost remediată.

Nu ai nevoie de el

Evitați să umpleți sistemul cu lucruri de care veți avea nevoie în viitor. Doar 10% din ceea ce vă așteptați va fi de fapt necesar în forma sa originală, adică 90% din timpul dumneavoastră 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ă de el. Funcționalitatea suplimentară doar încetinește progresul și consumă resurse. Uitați de cerințele viitoare și de flexibilitate suplimentară. Concentrează-te pe ceea ce trebuie făcut acum.

Justificare economică temeinică a tuturor acțiunilor - se face doar ceea ce are nevoie clientul și nu duce la dezavantajul 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 continua a schimbarilor din afara proiectului.

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

Angajamentul față de calitate.

Adaptarea procesului la nevoile proiectului.

Programare extremă

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

Principiile de bază ale dezvoltării software „în direct” sunt consemnate în manifestul de dezvoltare „în direct”, care a apărut în 2000.

Oamenii implicați în 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.

Colaborarea cu clientul este mai importantă decât negocierea detaliilor contractului.

Elaborarea schimbărilor este mai importantă decât respectarea planurilor.

Metodele „vii” au apărut ca un protest împotriva birocratizării excesive a dezvoltării software, o abundență de documente secundare care nu sunt necesare pentru a obține rezultatul final, care trebuie întocmite în timpul unui proiect în conformitate cu majoritatea proceselor „grele”, suplimentare lucrează pentru a susține un proces de organizare fix, așa cum este necesar, de exemplu, în CMM. Majoritatea acestor lucrări și documente nu au legătură directă cu dezvoltarea software-ului și asigurarea calității, ci are ca scop respectarea clauzelor formale ale contractelor de dezvoltare, obținerea și confirmarea certificatelor de conformitate cu diverse standarde.

Metodele live permit celor mai multe dintre eforturile dezvoltatorilor să se concentreze pe sarcinile reale de dezvoltare și pe satisfacerea nevoilor reale ale utilizatorilor. Absența unui morman 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 sa schemă a procesului de dezvoltare (deși, în general, înțelegerea pe scară largă a procesului de dezvoltare ca o schemă destul de rigidă de acțiuni contrazice însăși ideea de „viciozitate”) de dezvoltare, prezentată în Fig. 15.

Potrivit autorilor XP, această tehnică nu urmează atât o schemă generală de acțiuni, cât folosește o combinație a următoarelor tehnici. Cu toate acestea, fiecare tehnică este importantă și, fără ea, dezvoltarea este considerată non-XP, potrivit lui Kent Beck, unul dintre autorii acestei abordări, alături de Ward Cunningham și Ron Jeffries.

Joc de planificare

Sarcina lui este să determine cât mai repede posibil cantitatea de muncă care trebuie făcută înainte de următoarea versiune a software-ului. Decizia este luată, în primul rând, pe baza priorităților clientului (adică nevoile acestuia, ce are nevoie de la sistem pentru un succes mai mare).

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

				Test
		utilizarea de		scenarii
			Poveste noua
	Cerințe		utilizarea de
			Viteza proiectului
	Metaforă		Planul de versiuni
		Planificare		Repetare	Primirea	Mic
arhitectură				Ultimul
						O.K
						utilizatorii
Nesigur			Încrezător	Nouă iterație

„Aruncarea” soluției

Figura 15. Diagrama fluxului de lucru în XP.

Modificări frecvente ale versiunii (versiuni mici)

Prima versiune de lucru ar trebui să fie disponibilă cât mai curând posibil și trebuie utilizată imediat. Următoarele versiuni sunt pregătite la intervale destul de scurte (de la câteva ore cu mici modificări într-un program mic, până la o lună sau două cu o revizie majoră a unui sistem mare).

Metafora sistemului

Metafora într-o formă destul de simplă și de înțeles pentru comandă ar trebui să descrie mecanismul de bază al sistemului. Acest concept seamănă cu arhitectura, dar ar trebui să fie mult mai simplu, doar sub formă de una sau două fraze, să descrie esența principală a soluțiilor tehnice adoptate.

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ă ce le-ați solicitat în mod explicit. Toată complexitatea inutilă este eliminată imediat ce este găsită.

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ă capacitățile de bază ale sistemului, astfel încât să poată vedea că sistemul funcționează efectiv.

Refactorizarea

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ă modificări în comportamentul său, care este verificat printr-o rulare după fiecare reluare a testului. În același timp, se preferă soluțiile mai elegante și mai flexibile, în comparație cu a oferi pur și simplu rezultatul dorit. Componentele reprelucrate fără succes ar trebui detectate în timpul execuției testului și revenite la ultima stare consistentă (împreună cu componentele lor dependente).

Programare pereche

Codarea este realizată de doi programatori pe un singur computer. Asocierea este arbitrară și variază de la sarcină la sarcină. Cel în mâinile căruia tastatura încearcă să rezolve problema actuală în cel mai bun mod. Al doilea programator analizează munca

mai întâi și dă sfaturi, meditează la consecințele anumitor decizii, teste noi, soluții mai puțin directe, dar mai flexibile.

Proprietatea colectivă

V oricând orice membru al echipei poate schimba orice parte a codului. Nimeni nu ar trebui să aibă propria zonă de responsabilitate, întreaga echipă este în general responsabilă pentru tot codul.

Integrare continuă

Sistemul este asamblat și testat pentru 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 mari probleme î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)

V Echipa de dezvoltare are î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 oferi răspunsuri prompte la întrebări 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 noastre principale. Respectarea standardelor de codificare care oferă această claritate este imperativă. Astfel de standarde, pe lângă claritatea codului, trebuie să asigure că expresiile sunt menținute la minimum (fără duplicarea codului și a informațiilor) și trebuie acceptate de toți membrii echipei.

Deschis spatiu de lucru(spațiu de lucru deschis)

Echipa este găzduită într-o cameră suficient de mare pentru a facilita comunicarea și brainstormingul 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 puteți 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 și de autorii acestei tehnici. Dimensiunea mai mare a echipei distruge ușurința de comunicare necesară pentru succes și face multe dintre aceste tehnici imposibile.

Virtuțile XP, dacă poate fi aplicat, sunt o mare flexibilitate, capacitatea de a face rapid și precis modificări software-ului ca răspuns la cerințele în schimbare și dorințele individuale ale clienților, calitatea înaltă a codului rezultat și lipsa trebuie să convingă clienții că rezultatul corespunde așteptărilor lor.

Dezavantajele acestei abordări sunt imposibilitatea unor proiecte destul de mari și complexe în acest stil, imposibilitatea de a planifica calendarul și complexitatea proiectului pe un termen suficient de lung și de a prezice clar rezultatele unui proiect pe termen lung în ceea ce privește raportul. de 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 anterioare, dar necesită cercetări preliminare.

XP ca o combinație a tehnicilor descrise a fost utilizat pentru prima dată în timpul lucrărilor 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 despre XP în timpul proiectului în sine și mai târziu. Acest proiect a fost menționat în mod repetat în diverse surse ca exemplu de utilizare a acestei tehnici. Datele de mai jos sunt compilate din articolele la care se face referire, minus dovezile anecdotice, și ilustrează problemele unor 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 rulat folosind XP. Până atunci, el depășise deja bugetul și planurile pentru implementarea treptată a funcțiilor. Echipa de dezvoltare a fost redusă, iar timp de aproximativ o jumătate de an 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 jumătatea anului 1999, iar software-ul rezultat va fi folosit pentru a gestiona plățile către cei 87.000 de angajați ai companiei. A fost oprit în februarie 2000 după 4 ani de rulare XP din cauza nerespectării complete a termenelor și bugetului. Software-ul nu a fost niciodată folosit pentru a lucra cu datele a peste 10.000 de angajați, deși s-a demonstrat că face față datelor a 30.000 de angajați ai companiei. Persoana care a jucat rolul clientului inclus în echipa în proiect a renunțat după câteva luni de astfel de muncă, neputând suporta sarcina, și nu a primit o înlocuire adecvată până la finalul proiectului.

Literatura pentru curs 3

W. Royce. Management de proiect pentru dezvoltare software. M .: Lori, 2002.

A. Jacobson, G. Booch, J. Rambeau. Proces unificat de dezvoltare software. SPb.: Peter, 2002.

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

K. Beck. Programare extremă. SPb.: 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.