Proces de dezvoltare unificat și programare extremă. Dezvoltare accelerată și colaborativă de aplicații. Aplicații pentru implementarea XP într-o echipă

17.09.2020

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: =

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

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:=

codificare,
testare,
ascultarea clientului,
proiecta

Principiile XP

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

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

Practici de dezvoltare XP

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

Metaforă– toată dezvoltarea se bazează pe o poveste simplă, disponibilă public, despre cum funcționează sistemul
Design simplu– se adoptă cele mai simple soluții de proiectare posibile
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
Reorganizare(Refactoring) - îmbunătățirea structurii sistemului menținând în același timp comportamentul acestuia
Programarea perechilor e – codul este scris de doi programatori pe un singur computer
Proprietatea codului colectiv– orice dezvoltator poate îmbunătăți codul oricărui modul de sistem
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ă
Client local– un reprezentant competent al clientului trebuie să fie tot timpul în grup
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

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

Etape de dezvoltare

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

Planificarea sprintului

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

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

Executarea unui sprint

În timpul unui sprint, echipa completează o listă fixă specifică de sarcini - articole în restanță, 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 părere(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 absolut toate testele modulelor sistemului pe care îl dezvoltă nu au eșuat. 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.

Programarea perechilor

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 acele bucăți de cod - întreaga echipă lucrează unitar, ca o singură persoană. Echipa trebuie să formeze un set de reguli, iar apoi fiecare membru al echipei trebuie să respecte acele reguli în timpul procesului de codificare. Lista de reguli nu trebuie să fie exhaustivă sau prea lungă. Scopul este de a oferi linii directoare generale care să facă codul ușor de înțeles pentru toată lumea din echipă. Standardul de codificare ar trebui să înceapă simplu și apoi să evolueze pe măsură ce echipa câștigă experiență. Nu ar trebui să petreceți prea mult timp dezvoltării preliminare a standardului.

Proprietatea colectivă

Proprietatea echipei înseamnă că fiecare membru al echipei este responsabil pentru întreg 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. Avantaj important Proprietatea colectivă a codului este că accelerează procesul de dezvoltare, deoarece dacă apare o eroare, orice programator o poate remedia.

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

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

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

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

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

Conectați-vă pentru a posta comentarii

Extreme Programming (XP) a apărut ca o metodă evolutivă de dezvoltare de software de jos în sus. Această abordare este un exemplu al așa-numitei metode de dezvoltare agilă. Grupul de metode „live” include, pe lângă programarea extremă, metodele SCRUM, DSDM (Dynamic Systems Development Method, o metodă de dezvoltare a sistemelor dinamice), Feature-Driven Development (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.
· Lucrarea prin 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ă în plus 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 vorbind, î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. 1. .

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

· Trăi planificare joc)

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

Fig.1

· Frecvent Schimbare versiuni (mici lansări)

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

· 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.

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

· Simplu proiecta soluții (simple proiecta)

Î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 pe bază testare (condusă de teste dezvoltare)

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.

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

ь testarea unitară;

b testarea de acceptare.

software de programare extremă

Pentru XP, o prioritate mai mare este abordarea 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.

· Constant refactorizarea

Nu este un secret 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 prin îmbunătățirea codului. Aceasta este procesarea 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ă 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).

Refactorizarea 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.

· Programare perechi programare)

Dezvoltatorii cu experiență au observat că revizuirea periodică a codului altor persoane are un efect pozitiv asupra calității acestuia. Maeștrii programării extreme au dezvoltat această abordare prin revizuirea constantă a codului în timpul dezvoltării printr-o tehnică numită programare în perechi.

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

· Colectiv deţinere cod (colectiv proprietate)

Colectiv deţinereî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.

· Constant integrare (continuă integrare)

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.

Î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 vă permite să minimizați riscul unor consecințe nedorite ale integrării.

· 40 de ore lucru o 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ă.

O persoană, mai ales dacă este programator, este capabilă să facă multe de dragul afacerii: să stea târziu la serviciu, să meargă la muncă în weekend, să renunțe la vacanțe, să stea treaz câteva zile stând la tastatură... În general, ce poți face de dragul activității tale preferate. Dar programarea extremă este în mod categoric împotriva unui astfel de sacrificiu de sine și încălcarea standardelor acceptate ale legislației muncii.

Acest lucru este dictat nu numai de considerente de legalitate și umanitate, ci, în primul rând, de necesitatea creșterii eficienței muncii și a organizării stricte. La urma urmei, programarea extremă este un joc colectiv, conceput nu pentru indivizi, ci pentru întregul grup. Și un lucru precum, de exemplu, programarea în pereche este posibil doar atunci când bioritmurile participanților săi sunt sincronizate. Și este imposibil dacă o persoană vine la nouă la muncă, iar a doua la doisprezece, sau cineva decide că e mai bine să lucreze sâmbăta și duminica, în timp ce celălalt este incomod.

Dar cel mai important lucru este că, pentru a menține sănătatea și performanța, o persoană are nevoie de odihnă adecvată. Ziua de lucru de opt ore și săptămâna de lucru de cinci zile sunt stabilite tocmai din motive de productivitate maximă. În multe companii occidentale, părăsirea cu întârziere a serviciului este considerată ca fiind o performanță bună sau o incapacitate de a-și gestiona în mod corespunzător timpul de lucru. În cele mai multe cazuri, acest lucru este adevărat. Și din punct de vedere medical, întârzierile la locul de muncă duc la oboseală constantă, iritabilitate și scăderea activității creierului. Este acest lucru eficient? Cum putem organiza o comunicare constantă deschisă între dezvoltatorii dintr-o astfel de echipă și va fi posibilă programarea în pereche? Răspunsul este negativ. Standardele sunt standarde și trebuie respectate.

· Includere client V echipa (la fața locului client)

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

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.

Mulți se îndoiesc de posibilitatea implicării clientului în procesul de dezvoltare. Într-adevăr, clienții sunt diferiți. Dacă nu este posibilă atragerea clientului sau a reprezentantului acestuia, uneori este indicat să angajați temporar un specialist în domeniul în curs de dezvoltare. Acest pas va reduce ambiguitățile în lucru, va crește viteza de dezvoltare și va aduce proiectul mai aproape de ceea ce dorește clientul să primească. Acest lucru poate fi benefic și din punct de vedere financiar: la urma urmei, salariul unui programator este uneori semnificativ mai mare decât salariul specialiștilor din alte industrii.

· Utilizare cod Cum facilităţi comunicatii

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.

· Deschis lucru spațiu (deschis spațiu 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.

· Schimbare reguli De necesar (doar reguli)

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

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

Acest lucru poate suna ciudat, dar aproximativ 75% din software nu ajunge deloc la oameni. Pe de altă parte, există multe companii care produc software în cantități uriașe. Toate acestea și multe altele obligă programatorii să reducă costurile de dezvoltare. Și pentru a face acest lucru, trebuie să înțelegeți interesele clientului, să cooperați constant cu el, pentru a crea în cele din urmă exact ceea ce are nevoie.

Metodologia de dezvoltare software Programare extremă(inventatorul - Kent Beck) este din ce în ce mai recunoscut pentru maximizarea simplificării proiectării și dezvoltării efective a produselor software într-un mediu cu cerințe în schimbare rapidă.

Există doar 5 valori ale Extreme Programming: simplitate, comunicare, feedback, curaj și respect („respectul” a fost adăugat în ultima ediție de XP). Cele 12 practici XP au ca scop realizarea acestor valori de bază. Să le privim puțin mai de aproape. Pe lângă adevărurile cunoscute de mulți, voi adăuga comentariile mele despre practici, bazate pe experiența mea practică.

Proces de planificare (joc de planificare).În XP, planificarea este o parte esențială a dezvoltării. Faptul că planurile se pot schimba brusc este luat în considerare chiar de la început. Apetitul clientului vine în timpul meselor și situația trebuie ținută mereu sub control. Comunicarea cu clientul ar trebui să aibă loc cât mai des posibil. Acest lucru vă va permite să estimați mai precis termenele limită pentru finalizarea sarcinilor și să faceți ajustările necesare, dacă este necesar.

Versiuni rapide (versiuni mici). Indiferent cât de frumos este descris produsul, toate deliciile utilizării sale pot fi înțelese doar lucrând cu el. Metodologia de lansare rapidă vă permite să înțelegeți ce dorește clientul, asigurând lansarea timpurie a versiunilor de lucru ale produsului.

Comentariu: După cum arată practica, primul versiunea anterioară poate fi finalizat in 2-8 saptamani, indiferent de complexitatea asteptata a produsului. Este recomandabil ca prima versiune a produsului (cel puțin primele câteva iterații) să fie realizată de 2 persoane la un singur computer. În acest caz, designul sistemului apare foarte repede. Apoi puteți atrage mai mulți oameni redistribuind perechi.

Metaforă. Este mult mai ușor pentru o persoană să-și amintească diferențele dintre două obiecte similare decât să cunoască întreaga structură a obiectului. Tehnica metaforei sugerează compararea unui sistem (sau a unuia dintre modulele sale) cu analogii săi pentru o comunicare ușoară în cadrul echipei și o înțelegere mai profundă a sistemului ca întreg.

Comentariu: O practică destul de complexă, deși la prima vedere pare simplă. A veni cu metafore pentru modulele principale ale sistemului nu este ușor, dar este foarte util. Mulți programatori atribuie „metafora sistemului” practicilor de management, dar mi se pare că dezvoltatorii au mai multă nevoie de ea. Alegerea corectă a metaforelor îi va ajuta în cele din urmă pe programatori să vină cu nume bune pentru clase și metode, ceea ce are întotdeauna un efect pozitiv asupra designului sistemului în ansamblu.

Ușurință de implementare (design simplu). XP încurajează păstrarea codului programului simplu. De ce să-ți complici viața dacă un program simplu mai ușor de înțeles și întreținut și mai puțin predispus la erori.

Dezvoltare bazată pe teste. Extreme Programming recomandă testarea codului existent cât mai des posibil. De aceea se practică această tehnică. Testele sunt scrise înainte ca o bucată de cod să fie scrisă. Acest lucru vă permite să înțelegeți mai bine sarcinile la îndemână și oferă posibilitatea de a verifica codul imediat ce este scris.

Comentariu: Această abordare are multe avantaje.

În primul rând, scrierea testelor înainte de scrierea codului este una dintre cele mai bune modalități de a vă asigura că acele teste sunt la locul lor.

În al doilea rând, elimină reticența de a testa unele ramuri „evidente” de execuție a programului, fie și doar pentru că încă nu există cod :). Ei bine, atunci, cu programarea perechilor, testele vor fi într-adevăr concise și de înaltă calitate.

În al treilea rând, testele cresc încrederea în sine a programatorilor atunci când doresc să refactoreze.

Refactorizarea (îmbunătățirea designului). Adăugarea de noi funcționalități și creșterea cantității de cod complică dezvoltarea și depanarea. Soluția la această problemă este refactorizarea constantă a codului. Refactorizarea este un lucru foarte puternic și util și merită nu doar un articol separat, ci cărți întregi.

Comentariu: Nu uitați de valoarea „curajului” și nu vă fie teamă să spargeți sistemul în timpul refactorizării. Testele vor arăta ce este stricat și veți remedia rapid erorile. Chiar dacă testele nu au acoperit unele aspecte și nu observați probleme potențiale, e în regulă, totul poate fi întotdeauna reparat. Principalul lucru este că proiectarea sistemului a devenit mai simplă și mai clară, iar un sistem complex este o sursă de erori mult mai teribile decât erorile rezultate din refactorizare.

Programarea perechilor. Revizuirea periodică a codului altcuiva are un efect pozitiv asupra calității acestuia. Acest principiu stă la baza programării perechilor. Constă în faptul că doi programatori lucrează simultan pe un singur computer. În mod ciudat, costurile de dezvoltare nu se dublează, ci rămân aproximativ la același nivel. Pe de altă parte, programarea în pereche îmbunătățește calitatea codului, transferul implicit și explicit de cunoștințe și comunicarea constantă între dezvoltatori.

Proprietatea codului colectiv. Cel mai adesea, atunci când se dezvoltă produse software, o persoană este responsabilă pentru o anumită parte a codului. O vacanță, concediere sau boală (iartă-mă, Doamne) a unuia dintre programatori poate încetini foarte mult dezvoltarea unui produs. De aceea, în XP, cel puțin două persoane sunt responsabile pentru o bucată de cod și orice programator poate face modificări orice parte a codului programului.

Integrare continuă. Echipele de programare XP creează noi versiuni de produse de mai multe ori pe zi. Acest lucru permite tuturor programatorilor să fie conștienți de ceea ce se întâmplă și să prevină problemele de integrare cu alte produse și părți ale codului.

Comentariu: În zilele noastre, această practică provoacă un zâmbet sau chiar neînțelegeri în rândul tinerilor profesioniști, deoarece există svn, perforce, cvs și multe altele. Anterior, doi tipi s-au așezat lângă computerul principal și au fuzionat manual cu ramura principală a proiectului.

Cu toate acestea, această practică este încă relevantă. Nimeni nu a anulat proprietatea comună a codului: dacă nu doriți să pierdeți timpul cu o fuziune uriașă și complexă, petreceți timp cu mai multe mici :).

Săptămâna de 40 de ore (săptămână de patruzeci de ore). Oamenii sunt capabili de multe lucruri de dragul unei cauze, dar programarea extremă este categoric împotriva sacrificiului de sine al dezvoltatorilor. O persoană trebuie să se odihnească, atunci când va atinge productivitatea maximă în timpul orelor de lucru.

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 periodice 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.

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

Joc de planificare în direct

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

				Test
		utilizare		scenarii
			Poveste noua
	Cerințe		utilizare
	Cerințe		Viteza proiectului

	Metaforă		Planul de versiuni
		Planificare	Planul de versiuni	Repetare	Acceptare	Mic
arhitectură				Ultimul
						Bine
						utilizatorii
Nesigur			Încrezător	Nouă iterație

Soluții de „aruncare”.

Figura 15. Diagrama fluxului de lucru în XP.

Modificări frecvente ale versiunii (versiuni mici)

Prima versiune de lucru ar trebui să apară cât mai repede posibil și ar trebui să înceapă să fie utilizată imediat. 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

Soluții simple de proiectare

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

Refactorizare continuă

Programarea perechilor

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

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

Proprietatea colectivă a codului

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

Integrare continuă

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

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

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

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

Utilizarea codului ca mijloc de comunicare

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

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

Schimbarea regulilor după cum este necesar (doar reguli)

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

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

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

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

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

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

Proiectul a început în ianuarie 1995. Din martie 1996, după includerea lui Kent Beck, a fost rulat folosind XP. Până atunci, deja depășise bugetul și planurile pentru implementarea treptată a funcțiilor. Echipa de dezvoltare a fost 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 a peste 10.000 de angajați, deși s-a demonstrat că poate gestiona datele a 30.000 de angajați ai companiei. Persoana care a jucat rolul clientului inclus în echipa de proiect a renunțat după câteva luni de astfel de muncă, incapabil să suporte volumul de muncă și nu a primit niciodată o înlocuire adecvată până la sfârșitul proiectului.

Literatură pentru cursul 3

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

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

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

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

http://www.agilemanifesto.org/

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

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

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

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

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

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

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

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

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

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

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

Anatomia XP

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

Ciclul de dezvoltare XP

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

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

Povești

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

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

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

Versiune

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

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

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

Repetare

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

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

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

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

Sarcină

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

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

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

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

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

Test

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

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

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

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

Ai probleme?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemple de rulare a proiectelor folosind XP

Acxiom: pe calea atingerii unui scop comun

G Hannula

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

Aplicație: baza de date de management al campaniilor

Perioada de implementare: 3 ani

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

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

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

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

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

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

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

DaimlerChrysler: cea mai bună echipă din lume

Chet Hendriksen

Echipă: 15 persoane, dintre care 10 programatori

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

Perioada de implementare: 4 ani

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

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

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

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

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

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

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

Don Wells

Echipă: 17 persoane, dintre care 12 programatori

Aplicație: sistem de analiză a costurilor

Perioada de implementare: 6 ani

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

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

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

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

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

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

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

Sistem tarifar: teste pe care le puteți citi

Rob Mee

Echipă: trei dezvoltatori

Aplicație: sistem de calcul al tarifului de transport

Perioada de implementare: 3 luni

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

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

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

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

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