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

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

Utilizarea arhitecturii componente.

Prototipări, dezvoltare incrementală și testare.

Evaluări regulate ale stării actuale.

Managementul schimbarii, dezvoltarea constanta a schimbarilor din afara proiectului.

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

Concentrați-vă pe calitate.

Adaptarea procesului la nevoile proiectului.

Programare extremă

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

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

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

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

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

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

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

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

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

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

Joc de planificare în direct

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

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

Soluții de „aruncare”.

Figura 15. Diagrama fluxului de lucru în XP.

Modificări frecvente ale versiunii (versiuni mici)

Prima versiune de lucru ar trebui să apară cât mai repede posibil și ar trebui să înceapă imediat să fie utilizată. Versiunile ulterioare sunt pregătite la intervale destul de scurte (de la câteva ore pentru modificări mici într-un program mic, până la o lună sau două pentru o reluare majoră a unui sistem mare).

Metafora sistemului

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

Soluții simple de proiectare

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

Dezvoltare bazată pe teste(dezvoltare bazată pe teste)

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

Refactorizare continuă

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

Programare pereche

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

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

Proprietatea colectivă a codului

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

Integrare continuă

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

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

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

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

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

Utilizarea codului ca mijloc de comunicare

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

Deschideți spațiul de lucru

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

Schimbarea regulilor după cum este necesar (doar reguli)

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

După cum se poate observa din tehnicile utilizate, XP este conceput pentru a fi utilizat în cadrul unor echipe mici (nu mai mult de 10 programatori), ceea ce este subliniat de autorii acestei tehnici. O echipă mai mare distruge ușurința de comunicare necesară pentru succes și face imposibilă implementarea multor tehnici enumerate.

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

Dezavantajele acestei abordări sunt impracticabilitatea unor proiecte suficient de mari și complexe în acest stil, incapacitatea 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. a calitatii rezultatului si a costurilor de timp si resurse. De asemenea, se poate observa că XP nu este potrivit pentru acele cazuri în care solutii posibile nu sunt găsite imediat pe baza experienței acumulate anterior, dar necesită cercetări preliminare

XP ca set de tehnici descrise a fost utilizat pentru prima dată în timpul lucrului la proiectul C3 (Chrysler Comprehensive Compensation System, dezvoltarea unui sistem de contabilitate a plăților

angajații Daimler Chrysler). Din cei 20 de participanți la acest proiect, 5 (inclusiv cei 3 autori principali ai XP menționați mai sus) au publicat 3 cărți și un număr mare de articole dedicate XP în timpul proiectului în sine și ulterior. Acest proiect este menționat în mod repetat în diverse surse ca exemplu de utilizare a acestei tehnici. Următoarele date sunt compilate din articolele menționate, minus dovezile anecdotice, și ilustrează problemele cu unele tehnici XP atunci când sunt aplicate la proiecte destul de complexe.

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

Literatura pentru curs 3

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

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

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

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

http://www.agilemanifesto.org/

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

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

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

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

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

Trimis de la Miercuri, 25.01.2012 - 02:28

7. Modele de procese de dezvoltare adaptive: Scrum

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

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

Principiile dezvoltării vii

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

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

Programare extremă

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

Procesul XP (programare extremă)

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

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

Principiile XP

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

1. comunicare continuă cu clientul,
2. simplitatea soluțiilor alese,
3. rapid Părere pe baza testelor operaționale,
4. prevenirea riscurilor

Practici de dezvoltare XP

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

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

Diagrama de dezvoltare XP

Imagine XP (diagrama de dezvoltare XP):

Model Scrum

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

Ideea principală a modelului Scrum

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

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

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

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

Roluri

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

Etape de dezvoltare

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

Planificarea sprintului

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

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

Executarea unui sprint

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

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

Diagrama Scrum =

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

Programare extremă

Tehnici XP de bază

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

o Dezvoltare bazată pe teste

o Joc de planificare

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

o Programare cu perechi

Proces continuu, mai degrabă decât pe lot

o Integrare continuă

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

o Lansări mici frecvente

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

o Simplitate (design simplu)

o Metafora sistemului

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

o Standard de codare sau convenții de codare

· Bunăstarea programatorului:

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

Testare

XP pune un accent deosebit pe două tipuri de testare:

· testarea unitară;

· testarea de acceptare.

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

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

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

Joc de planificare

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

Clientul este mereu acolo

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

Programare pereche

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

Integrare continuă

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

Refactorizarea

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

Lansări mici frecvente

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

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

Simplitatea designului

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

Metafora sistemului

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

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

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

Standarde de codificare

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

· membrii echipei nu pierd timpul cu argumente stupide despre lucruri care de fapt nu afectează viteza de lucru la proiect;

· asigură implementarea eficientă a altor practici.

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

Proprietatea colectivă

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

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

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

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

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

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

• Conectați-vă pentru a posta comentarii

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

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

Principiile XP

Principiile principale sunt:

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

Tehnici XP (practici)

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

1. Planificarea procesului.Întreaga echipă de dezvoltare se reunește și se ia o decizie colectivă cu privire la ce proprietăți ale sistemului vor fi implementate în următoarea iterație. Complexitatea implementării fiecărei proprietăți este determinată de programatori înșiși.
2. Interacțiune strânsă cu clientul. Reprezentantul clientului trebuie să fie membru al echipei XP. El scrie interfața de utilizare, selectează poveștile care vor fi implementate într-o anumită iterație și răspunde la întrebările legate de afaceri. Reprezentantul clientului trebuie să fie expert într-un domeniu automatizat. Este necesar să aveți un feedback constant cu reprezentantul clienților.
3. Reguli de denumire la nivel de sistem. Convențiile bune de denumire a sistemului sugerează ușurința de a numi clase si variabile. Echipa de dezvoltare trebuie să aibă reguli uniforme denumire.
4. Arhitectură simplă. Orice proprietate a sistemului ar trebui implementată cât mai simplu posibil. Programatorii din echipa XP lucrează sub motto-ul: „Nimic de prisos!” Este adoptată prima soluție de lucru cea mai simplă, este implementat nivelul necesar de funcționalitate acest moment. Acest lucru economisește timpul programatorului.
5. Refactorizarea. Aceasta este optimizarea codului existent pentru a-l simplifica.Această muncă ar trebui efectuată în mod constant. Păstrând codul transparent și definind elementele de cod o singură dată, programatorii reduc numărul de erori pe care trebuie să le remedieze mai târziu. La implementarea fiecărei caracteristici noi a sistemului, programatorul trebuie să ia în considerare dacă este posibilă simplificarea codului existent și modul în care aceasta va ajuta la implementarea noii caracteristici. În plus, refactorizarea nu trebuie combinată cu proiectarea: dacă se creează un cod nou, refactorizarea ar trebui amânată.
6. Programare pereche. Toți programatorii trebuie să lucreze în perechi: unul scrie codul, celălalt urmărește. Astfel, este necesar să plasați un grup de programatori într-un singur loc. XP funcționează cel mai bine în echipe nedistribuite de programatori și utilizatori.
7. 40 de ore de lucru pe săptămână. Un programator nu ar trebui să lucreze mai mult de 8 ore pe zi. Nevoia de ore suplimentare este un indicator clar al unei probleme în acel domeniu special de dezvoltare. Găsirea motivelor orelor suplimentare și eliminarea lor cât mai rapidă este una dintre regulile de bază.
8. Proprietatea codului colectiv. Fiecare programator din echipă trebuie să aibă acces la codul oricărei părți a sistemului și dreptul de a face modificări la orice cod. Regula obligatorie: dacă un programator face modificări și după aceea sistemul nu funcționează corect, atunci acest programator este cel care trebuie să corecteze erorile.
9. Standarde de codificare unificate. Sunt necesare standarde de codare pentru a sprijini alte practici: proprietatea partajată a codului, programarea perechilor și refactorizarea. Fără un standard unificat, este cel puțin mai dificil de realizat aceste practici, iar în realitate este complet imposibil: grupul va lucra într-o lipsă constantă de timp. Echipa lucrează la proiect de mult timp. Oamenii vin și pleacă. Nimeni nu codifică singur și codul aparține tuturor. Întotdeauna vor exista momente când trebuie să înțelegeți și să ajustați codul altcuiva. Dezvoltatorii vor elimina codul duplicat, vor analiza și îmbunătăți clasele altor persoane etc. În timp, va fi imposibil de spus cine este autorul unei anumite clase. Prin urmare, toată lumea trebuie să se supună standardelor comune de codare - formatarea codului, denumirea claselor, variabilelor, constantelor, stilul de comentariu. Cele de mai sus înseamnă că toți membrii echipei trebuie să cadă de acord asupra standardelor comune de codare. Nu contează care dintre ele, dar toată lumea este obligată să le asculte.
10. Lansări mici. Iterația minimă este o zi, cea maximă este o lună; Cu cât se fac mai des lansări, cu atât vor fi identificate mai multe defecte ale sistemului. Primele versiuni ajută la identificarea deficiențelor în primele etape, apoi funcționalitatea sistemului este extinsă pe baza interfeței de utilizare. Deoarece utilizatorul este implicat în procesul de dezvoltare de la prima versiune, el evaluează sistemul și oferă istoricul utilizatorului și comentarii. Pe baza acesteia, se determină următoarea iterație, adică cum va fi noua lansare. XP se referă la furnizarea de feedback continuu utilizatorilor.
11. Integrare continuă. Integrarea noilor părți ale sistemului ar trebui să aibă loc cât mai des posibil, cel puțin o dată la câteva ore. Regula de bază a integrării este următoarea: integrarea poate fi efectuată dacă toate testele trec cu succes. Dacă testele eșuează, programatorul trebuie fie să facă corecții și apoi să integreze componentele sistemului, fie să nu le integreze deloc. Această regulă este strictă și lipsită de ambiguitate. Dacă există cel puțin o eroare în partea creată a sistemului, atunci integrarea nu poate fi efectuată. Integrarea frecventă vă permite să obțineți un sistem finit mai rapid, în loc să petreceți o săptămână pe asamblare.
12. Testare. Spre deosebire de majoritatea celorlalte metodologii, testarea în XP este una dintre cele mai importante componente. Abordarea extremă presupune că testele sunt scrise înainte ca codul să fie scris . Fiecare modul trebuie să aibă un test unitar - un test al acestui modul. Astfel, în XP, se efectuează teste de regresie, „fără degradarea calității” atunci când se adaugă funcționalitate. Majoritatea erorilor sunt corectate în etapa de codare. Testele sunt scrise de programatori înșiși; oricare dintre ei are dreptul de a scrie un test pentru orice modul. O alta principiu important: testul determină codul, și nu invers (dezvoltare bazată pe teste), adică o bucată de cod este introdusă în depozit dacă și numai dacă toate testele trec cu succes, altfel această modificare a codului este respinsă.

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

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

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

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

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

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

1. Întreaga echipă

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

2. Joc de planificare

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

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

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

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

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

3. Lansări frecvente de versiuni

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

4. Teste utilizator

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

5. Proprietatea codului colectiv

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

6. Integrarea continuă a codului

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

7. Standarde de codare

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

8. Metafora sistemului

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

9. Ritm constant

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

10. Dezvoltare bazată pe teste

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

11. Programarea perechilor

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

12. Design simplu

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

13. Refactorizare

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

Avantaje și dezavantaje XP

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

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

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

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

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

Principiile XP

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

1. Simplitate

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

2. Comunicare

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

3. Feedback

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

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

4. Curaj

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

5. Respect

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

Algoritm pentru implementarea metodologiei XP și a procesului de lucru

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

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

• testarea
• proiecta
• planificare
• management
• dezvoltare

Testare.

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

Proiecta.

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

Planificare.

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

management.

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

Dezvoltare.

Transformările în dezvoltare încep cu organizarea stațiilor de lucru pentru programare în perechi. Următoarea sarcină— programați în perechi cea mai mare parte a timpului de lucru, oricât de dificil este pentru dezvoltatori.

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

Cine folosește XP

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

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

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

Pivotal Software, Inc.

Companie americană de software care dezvoltă software pentru analiza afacerilor pe baza Date mareși oferă servicii de consultanță. Produsele pivot sunt folosite de Ford, Mercedes, BMW, GAP, Humana, bănci mari, agenții guvernamentale, companii de asigurări etc.

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

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

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

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

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

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

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

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

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

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

Jira

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

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

Verdict

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

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

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

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

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

Extreme Programming 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 combinație, optimizarea procesului de dezvoltare. Această abordare reglementează și drepturile dezvoltatorilor și clienților.

Drepturi și roluri

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

Client

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

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

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

Dezvoltator

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

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

Roluri în cadrul unui rol

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

Partea clientului

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

Receptor- o persoană care monitorizează funcționarea corectă a sistemului. Buna comanda domeniul subiectului. Responsabilitățile includ redactarea testelor de acceptare.

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

Partea dezvoltatorului

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

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

Observator- un membru al echipei de dezvoltare, de încredere de către întregul grup, care monitorizează progresul dezvoltării. Acesta compară estimările preliminare ale costurilor cu forța de muncă cu cele cheltuite efectiv, obținând indicatori cantitativi ai performanței echipei. Acestea sunt ca viteza medieși procentul sarcinilor finalizate și planificate. Aceasta informatie furnizate clientului pentru controlul în timp util al situației. Unele dintre aceste informații sunt furnizate în mod discret dezvoltatorilor, astfel încât aceștia să cunoască stadiul proiectului, unde apar dificultăți și ce altceva se poate face.

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

Roluri externe

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

Regulile de programare extremă

Convenția de codificare

Faceți parte dintr-o echipă care lucrează de mult timp la acest proiect. Oamenii vin și pleacă. Nimeni nu codifică singur și codul aparține tuturor. Întotdeauna vor exista momente când trebuie să înțelegeți și să ajustați codul altcuiva. Dezvoltatorii vor elimina sau vor schimba codul duplicat, vor analiza și îmbunătăți clasele altor persoane etc. În timp, va fi imposibil de spus cine este autorul unei anumite clase.

Prin urmare, toată lumea trebuie să se supună standardelor comune de codare - formatarea codului, denumirea claselor, variabilelor, constantelor, stilul de comentariu. În acest fel, vom fi siguri că atunci când vom face modificări în codul altcuiva (care este necesar pentru progrese agresive și extreme înainte), nu îl vom transforma în Babel Pandemonium.

Cele de mai sus înseamnă că toți membrii echipei trebuie să cadă de acord asupra standardelor comune de codare. Nu contează care dintre ele. Regula este că toată lumea le respectă. Cei care nu vor să le respecte părăsesc echipa.

Proprietatea codului colectiv

Proprietatea partajată a codului încurajează dezvoltatorii să trimită idei pentru toate părțile proiectului, nu doar pentru propriile module. Orice dezvoltator poate schimba orice cod pentru a extinde funcționalitatea, a remedia erori sau a refactoriza.

La prima vedere pare un haos. Cu toate acestea, ținând cont de faptul că cel puțin orice cod a fost creat de câțiva dezvoltatori, că testele unitare vă permit să verificați corectitudinea modificărilor efectuate și că viata reala oricum, într-un fel sau altul trebuie să înțelegi codul altcuiva, devine clar că proprietatea colectivă a codului simplifică foarte mult efectuarea de modificări și reduce riscul asociat cu specializarea ridicată a unuia sau altuia membru al echipei.

Sesiunea CRC

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

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

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

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

Client

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

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

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

Alege cea mai simplă soluție

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

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

Teste funcționale

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

Integrare frecventă

Dezvoltatorii ar trebui să-și integreze și să elibereze codul la fiecare câteva ore, dacă este posibil. În orice caz, nu trebuie să păstrați niciodată modificările mai mult de o zi. Integrarea frecventă evită alienarea și fragmentarea în dezvoltare, unde dezvoltatorii nu pot comunica în sensul schimbului de idei sau reutilizare cod. Toată lumea ar trebui să ruleze cea mai recentă versiune.

Fiecare pereche de dezvoltatori ar trebui să contribuie cu codul lor cât mai curând posibil. Acest lucru se poate întâmpla atunci când toate UnitTests trec 100%. Prin trimiterea modificărilor de mai multe ori pe zi, reduceți problemele de integrare la aproape zero. Integrarea este o activitate „plătiți acum sau plătiți mai mult mai târziu”. Prin urmare, prin integrarea zilnică a modificărilor în porțiuni mici, nu va trebui să petreceți o săptămână pentru a conecta sistemul într-un întreg chiar î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ă-ți dai seama imediat ce se întâmplă. Întreaga experiență a echipelor XP spune că motivul întârzierii este întotdeauna designul slab și trebuie să fie refăcut mai târziu.

Planificarea iterației

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

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

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

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

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

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

Iterații

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

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

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

Concentrați-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 sarcini

Este necesar să se schimbe periodic sarcinile dezvoltatorilor pentru a reduce riscul concentrării cunoștințelor și blocajelor în cod. Dacă doar o singură persoană din echipa ta poate lucra într-o anumită zonă și acea persoană pleacă, sau pur și simplu ai multe de făcut într-un anumit 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 într-o singură persoană. Mutarea oamenilor prin cod în combinație cu programarea perechilor face în liniște Cross Training pentru tine. În loc ca o singură persoană să știe totul despre o anumită bucată de cod, toată lumea din echipa ta știe multe despre codul din fiecare modul.

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

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

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

Lăsați optimizarea pentru mai târziu

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

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

Programare pereche

Tot codul pentru sistemul de producție (și asta înseamnă, cu excepția soluțiilor de probă) este scris în perechi. Doi dezvoltatori stau unul lângă altul. Unul tastează, celălalt se uită. Se schimbă din când în când. Nu este permis să lucrezi singur. Dacă dintr-un motiv oarecare al doilea din pereche a omis ceva (bolnav, pensionar etc.), el este obligat să revizuiască toate modificările făcute de primul.

Sună neobișnuit, dar XP susține că, după o perioadă scurtă de adaptare, majoritatea oamenilor lucrează bine în perechi. Le place chiar și pentru că munca se realizează considerabil mai repede. Se aplică principiul „Un cap este bun, dar doi este mai bine”. De obicei, cuplurile găsesc mai multe solutii optime. În plus, calitatea codului crește semnificativ, numărul de erori scade și schimbul de cunoștințe între dezvoltatori este accelerat.

Refactorizează fără milă!

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

Examinați fără milă orice cod pentru a vă menține designul simplu pe măsură ce îl dezvoltați. Păstrați codul clar și ușor de înțeles, astfel încât să fie ușor de înțeles, modificat și extins. Asigurați-vă că totul este scris o dată și o singură dată. În cele din urmă, durează mai puțin timp decât lustruirea unui sistem 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 ulterior utilizate 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 tuturor să ia decizii. Aceste reguli definesc metoda de elaborare a unui plan de lucru care mulțumește pe toată lumea.

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

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

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

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

Lansări frecvente

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

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

Soluție de probă

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

Realizați un program care reproduce problema investigată și ignoră orice altceva. Majoritatea soluțiilor de probă nu sunt menite să fie folosite, așa că așteptați-vă să fie aruncate. Scopul creării lor este de a reduce riscul de a lua o decizie tehnică greșită sau de a estima cu mai multă acuratețe timpul de implementare a unui User Story.

Întâlnire în picioare

În fiecare dimineață are loc o întâlnire pentru a discuta problemele, soluțiile acestora și pentru a întări concentrarea echipei. Întâlnirea se ține în picioare pentru a evita discuțiile îndelungate care nu sunt interesante pentru toți membrii echipei.

Într-o întâlnire tipică, majoritatea participanților nu contribuie cu nimic, doar participă pentru a auzi ce au de spus alții. O mare parte din timpul oamenilor este pierdut pentru a primi o cantitate mică de comunicare. Prin urmare, a avea pe toată lumea la întâlniri ia resurse din proiect și creează haos în planificare.

Acest tip de comunicare necesită o întâlnire permanentă. Este mult mai bine să ai o întâlnire scurtă și obligatorie decât multe întâlniri lungi la care totuși trebuie să participe majoritatea dezvoltatorilor.

Dacă aveți întâlniri permanente zilnice, atunci la toate celelalte întâlniri ar trebui să participe numai acele persoane care sunt necesare și vor aduce ceva la masă. Mai mult, este chiar posibil să se evite unele întâlniri. Cu participanții limitati, majoritatea întâlnirilor pot fi ținute spontan în fața unui monitor, unde schimbul de idei este mult mai intens.

Întâlnirea zilnică de dimineață nu este o altă pierdere de timp. Vă va permite să evitați multe alte întâlniri și vă va economisi mai mult timp decât îl petreceți.

Metafora sistemului

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

Teste unitare

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

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

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

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

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

Povestea utilizatorului

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

Povestea utilizatorului este scrisă de Client. Acestea sunt similare, dar nu se limitează la, scenariile de utilizare a sistemului interfața cu utilizatorul. Pentru fiecare poveste sunt scrise teste funcționale pentru a confirma că această poveste este implementată corect - ele se mai numesc și teste de acceptare.

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

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

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

Viteza proiectului

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

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

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

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

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

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

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

Când este detectată o eroare

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

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

Nu vei avea nevoie

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

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