Metodologie agilă

Ingineria software a lui Nell, expresia metodologiei agile (sau dezvoltarea software-ului agile, în engleză agile development, ASD software abreviat ) se referă la un set de metode de dezvoltare software care au apărut de la începutul anilor 2000 și se bazează pe un set de principii comune, direct sau indirect derivat din principiile „Manifestului pentru dezvoltarea software agilă ” (în mod necorespunzător ^[1] numit și „Manifest Agile”) publicat în 2001 de Kent Beck , Robert C. Martin , Martin Fowler și alții. ^{[2] [3]} Metodele Agile se opun modelul cascadă și alte tradiționale modele de dezvoltare , propunând o abordare mai puțin structurată axată pe obiectivul de a oferi clientului, rapid și în mod frecvent ( de livrare timpurie / livrare frecventă) ^[4] , de lucru și software de calitate.

Practicile promovate prin metode agile includ formarea unor echipe de dezvoltare mici, multifuncționale și auto-organizate, dezvoltarea iterativă și incrementală , planificarea adaptativă și implicarea directă și continuă a clienților în procesul de dezvoltare.

Introducere

Utilizarea termenului agil ^[5] pentru a se referi la metodele de dezvoltare software a fost introdusă prin Manifestul Agil publicat în 2001. ^[6]

Majoritatea metodelor agile încearcă să reducă riscul de eșec prin dezvoltarea software-ului în ferestre de timp limitat numite iterații care durează de obicei câteva săptămâni. Fiecare iterație este un proiect mic în sine și trebuie să conțină tot ceea ce este necesar pentru a elibera o mică creștere a funcționalității software-ului: planificare (planificare), analiza cerințelor , proiectare, implementare, testare și documentare.

Chiar dacă rezultatul fiecărei iterații nu are suficientă funcționalitate pentru a fi considerat complet, trebuie publicat și, în succesiunea iterațiilor, trebuie să se apropie din ce în ce mai mult de solicitările clientului. La sfârșitul fiecărei iterații, echipa trebuie să reevalueze prioritățile proiectului.

Metodele agile preferă comunicarea în timp real, de preferință față în față, scrisă (documentare). Echipa agilă este formată din toți oamenii necesari pentru a finaliza proiectul software. Cel puțin, echipa trebuie să includă programatorii și clienții acestora (prin clienți ne referim la persoanele care definesc modul în care ar trebui să fie produs produsul: pot fi manageri de produs , analiști de afaceri sau cu adevărat clienți).

Posterul

Formalizarea principiilor pe care se bazează metodologiile agile a făcut obiectul activității unui grup de designeri de software și guru IT care s-au adunat spontan în Alianța Agilă . Documentul final al acestei lucrări a fost apoi semnat de un grup mare de profesioniști, dintre care mulți au dezvoltat și unele dintre cele mai faimoase metodologii agile.

Semnatarii Manifestului Agil sunt (în ordine alfabetică): Kent Beck , Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham (inventator Wiki ), Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern , Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas .

Obiective

Scopul este satisfacția deplină a clienților și nu doar îndeplinirea unui contract. În plus, utilizarea corectă a acestor metodologii poate permite reducerea costurilor și a timpului de dezvoltare a software-ului, sporind calitatea acestuia.

A explodat tocmai coroborat cu criza care a urmat boom-ului Internetului, luându-și reperul din metodele aplicate în casele mici de software .

Valori

Valorile pe care se bazează o metodologie agilă care urmează punctele indicate de Manifestul Agil sunt patru.

Ei consideră că este important:

• Persoane și interacțiuni mai mult decât procese și instrumente
• Software de lucru mai mult decât documentație exhaustivă
• Colaborarea cu clientul mai degrabă decât negocierea contractelor
• Răspunsul la schimbare mai degrabă decât urmarea unui plan

Adică, fără a aduce atingere valorii articolelor din dreapta, articolele din stânga sunt considerate mai importante. ^[6]

Practici

Practicile individuale aplicabile în cadrul unei metodologii agile sunt zeci și depind în esență de nevoile companiei și de abordarea managerului de proiect . Totuși, la alegere, trebuie luate în considerare caracteristicile fiecărei practici pentru beneficiile pe care le aduce și consecințele pe care le implică. De exemplu, în programarea extremă , lipsa absolută a oricărei forme de proiectare și documentare este compensată prin implicarea foarte strânsă a clientului în dezvoltare și programare în perechi.

Cele mai frecvente practici pentru a alege sunt similare și pot fi grupate în categorii:

• Automatizare - Dacă obiectivul metodologiilor agile este să ne concentrăm pe programare fără a ne dedica activităților secundare, atunci acestea din urmă pot fi eliminate sau automatizate; a doua soluție este mai bună deoarece puteți, de exemplu, elimina documentația prin creșterea testării, dar nu puteți elimina ambele; apoi alegeți calea pe care doriți să o parcurgeți și vă asigurați că utilizați instrumente pentru a automatiza cât mai multe activități colaterale posibil;
• Implicarea clienților - Implicarea clienților este indicată aici individual, deoarece există diferite grade de implicare posibilă; de exemplu în programarea extremă implicarea este totală, clientul chiar participă la întâlnirile săptămânale ale programatorilor; în alte cazuri, clientul este implicat într-o fază inițială de proiectare și apoi nu mai este; în altele, clientul participă indirect și este folosit ca tester al versiunii lansate;
• Comunicare strânsă - Potrivit lui Alistair Cockburn, probabil primul teoretician al metodologiilor agile, acesta este singurul aspect cheie real care face o metodologie agilă . Prin comunicare strânsă înțelegem comunicarea interpersonală, între toți actorii proiectului, inclusiv clientul. Acest lucru servește pentru a avea o bună analiză a cerințelor și o colaborare fructuoasă între programatori chiar și într-o zonă cu absență aproape totală a documentației;
• Livrări frecvente - Efectuarea de versiuni frecvente de versiuni intermediare ale software-ului vă permite să obțineți mai multe rezultate în același timp: reporniți iterația având deja disponibil un bloc de cod care funcționează în toate aspectele sale, oferiți clientului „ceva de lucru cu "și astfel este distras de orice întârziere în livrarea proiectului complet, clientul este folosit ca și cum ar fi un test, deoarece va folosi software-ul și va găsi orice anomalii, se obțin informații mai precise de la client pe cerințe pe care, probabil, nu le-ar fi putut exprima fără a fi nevoit să furnizeze utilități și neajunsurile proiectului;
• Cultura echipei ( culturi cu o singură echipă) - Fundamental pentru a urmări abordările Agile este cooperarea și abordarea mentală și practică a echipei de dezvoltare în sine. Cel mai potrivit criteriu de lucru ar fi abandonarea culturii tradiționale de blamare (care prevede penalizarea sau recompensarea individului care face o greșeală sau care se distinge de ceilalți pentru merite), în loc să se deplaseze către un mod de operare „grup” , în transparență și onestitate, care va recompensa (sau invers) grupul însuși numai pe baza realizării obiectivelor echipei (prevăzute pentru acel interval de timp);
• Atelier facilitat - O practică în sprijinul principiilor comunicării și colaborării, împreună cu menținerea concentrării pe obiectivele de afaceri. Această tehnică constă în furnizarea de întâlniri facilitate (ateliere) în timpul proiectului: prezența unui facilitator neutru (facilitator) va garanta succesul întâlnirii, menținând constant întâlnirea în conformitate cu obiectivele sale, menținând contextul adecvat (libertatea de exprimare, absența presiunii între participanți, decizii neforțate etc.) și asigurarea transmiterii tuturor informațiilor necesare, atât anterioare, cât și derivate (urmărire) din atelier, tuturor părților interesate;
• Formarea unei echipe și proprietatea codului - Formarea echipei de dezvoltare este condiționată de alegerea ierarhiei interne, dar respectă reguli precise care permit obținerea unei echipe de producție în cadrul metodologiei alese; alegerea membrilor echipei este condiționată și de alegerea dreptului de proprietate asupra codului, care poate fi individual sau colectiv; în primul caz responsabilitatea pentru dezvoltare este individuală, în al doilea depinde de întreaga echipă și, prin urmare, de managerul de proiect;
• Ierarhia - Alegerea de a crea o structură ierarhică în cadrul echipei de dezvoltare depinde foarte mult de abordarea managerului de proiect, în orice caz există o consecință nu secundară prin efectuarea acestei alegeri; dacă vă decideți pentru o structură ierarhică asemănătoare copacului, aveți posibilitatea să gestionați un număr foarte mare de programatori și să lucrați la diferite aspecte ale proiectului în paralel; dacă vă decideți pentru o absență totală a ierarhiei, veți avea o echipă de dezvoltare foarte compactă și motivată, dar neapărat mică în ceea ce privește numărul de programatori;
• Dezvoltare iterativă - O practică importantă prin care soluția care trebuie livrată evoluează din ceea ce a fost doar o „idee” (un concept, o propunere, un set de nevoi) pentru a deveni un produs de valoare pentru client. Dezvoltarea iterativă funcționează prin cicluri de acțiuni / activități care nu se schimbă, dar care, repetând ciclic, conduc soluția „brută” să fie rafinată până devine produsul final;
• Prioritizarea (a se vedea: Prioritizarea )
• Îmbunătățirea cunoștințelor - Născut odată cu apariția programării orientate pe obiecte, nu este altceva decât conștientizarea producției de cunoștințe care se face într-o companie pe măsură ce se produce cod; aceste cunoștințe produse nu trebuie pierdute și tocmai în acest sens sunt exploatate adesea alte practici, cum ar fi comunicarea strânsă sau partajarea dreptului de proprietate asupra codului;
• Modelare (Modelare) - Utilizarea de modele, reprezentări vizuale de probleme sau soluții, machete, prototipuri sau modele la scară (în general) susține metodologii agile;
• Programare în perechi - Dezvoltarea este realizată de perechi de programatori care se alternează la tastatură;
• Prioritizarea - Dezvoltarea soluției poate începe numai după ce a prioritizat obiectivele, din care vor deriva cerințele și caracteristicile (caracteristicile sau funcționalitatea produsului) care urmează să fie livrate prin proiect; o practică bine cunoscută este tehnica MoSCoW (Must - Should - Could - Won't have)
• Proiectare și documentare - Gândirea că metodologiile ușoare elimină proiectarea și documentarea este o greșeală, de fapt nu este așa, metodologiile ușoare introduc o iterație în ciclul de viață al proiectului; cât design trebuie făcut și câtă documentație de produs, cu excepția cazurilor extreme, este o alegere lăsată celor care gestionează proiectul și adesea teoreticienii Alianței Agile avertizează că este o greșeală să neglijăm sau chiar să omitem aceste două faze;
• Refactoring - Restructurarea părților de cod păstrând neschimbate aspectul și comportamentul extern;
• Retroinginerie - Cu alte cuvinte, obținerea, adesea în mod automat, a documentației pornind de la codul deja produs; este una dintre cele mai răspândite și controversate practici, răspândită deoarece permite un câștig uriaș în termeni de timp, dar controversată pentru că adesea documentația produsă este inutilizabilă sau este produsă doar pentru o cerere birocratică din partea clientului și nu va fi niciodată folosită cu adevărat;
• Simplitate - Unul dintre punctele cheie ale metodologiilor ușoare, împrumutat direct din programarea orientată pe obiecte, este simplitatea; simplitate în cod, simplitate în documentare, simplitate în proiectare, simplitate în modelare; rezultatele astfel obținute sunt o mai bună lizibilitate a întregului proiect și o facilitare consecventă în fazele de corectare și modificare;
• Test - Practică extrem de răspândită chiar înainte de nașterea metodologiilor ușoare, a produs o vastă literatură și o serie de abordări diferite, cum ar fi Testarea rapidă sau Testarea în perechi ; în contextul metodologiilor ușoare, trei tipuri diferite de teste sunt adesea utilizate împreună: teste funcționale , utilizate pentru a verifica dacă software-ul face efectiv ceea ce ar trebui să facă, teste unitare , utilizate pentru a verifica dacă fiecare bucată de cod funcționează corect și teste indirecte efectuate inconștient de către client de fiecare dată când este livrată o versiune;
• Test Driven Development - Un tip de abordare a testării care urmează să fie efectuat în timpul proiectului nostru, care implică alegerea și definirea testelor efective care trebuie trecute de produs (adică soluția și caracteristicile sale) înainte de a dezvolta soluția în sine. Conceptul, pe scurt, este foarte simplu: doriți să evitați riscul de a continua să dezvoltați ceva pe care nu îl puteți testa apoi;
• Timeboxing - Practică fundamentală a metodelor Agile care constă în împărțirea proiectului în intervale de timp precise, care durează câteva zile sau săptămâni - de exemplu Sprint ( SCRUM ) sau Structured Timebox ( AGILEPM ) - în cadrul cărora să livreze caracteristici, în paralel la intervale de timp de durată mai lungă (săptămâni sau luni) numită Incrementări, la sfârșitul căreia are loc livrarea efectivă a soluției finale sau a unei părți a acesteia, care poate fi utilizată de fapt de către client (care va obține valoarea așteptată);
• Versionare - Una dintre consecințele directe ale iterației în producție este necesitatea introducerii unui model, o metodă, un instrument, pentru controlul versiunilor software-ului produs și lansat; unul dintre cele mai răspândite și mai sugerate instrumente pentru respectarea automată a acestei practici este CVS .

Metodologii

În sens larg, termenul „agil” indică toate acele metodologii de dezvoltare ușoare și flexibile, care încalcă tradiția anterioară a ingineriei software ( model cascadă , model spiral etc.) bazată pe o colecție de specificații și pe un software secvențial structurat. dezvoltare. Metodologiile agile, pe de altă parte, fac posibilă revizuirea continuă a specificațiilor, adaptându-le în timpul dezvoltării software-ului, printr-un cadru iterativ și incremental, și un schimb puternic de informații și opinii între dezvoltatori și cu clientul. Exemple de metodologii și cadre agile:

• Proces unificat agil ,
• Dezvoltare software adaptivă ,
• Cristal (familie),
• Metoda de dezvoltare a sistemelor dinamice ,
• Programare extremă ,
• Dezvoltare bazată pe funcții ,
• Dezvoltare software Lean ,
• Scrum .

Notă

Elemente conexe

• AGILEPM (Agile Project Management) [DSDM]
• Abordări de management de proiect
• Dezvoltare software adaptiv
• Ardeți graficul
• Sistem de versiuni simultane
• Testare bazată pe context
• Cristal (informatică)
• Metoda de dezvoltare a sistemelor dinamice
• Programare extremă
• Dezvoltare bazată pe funcții
• Proiectarea interacțiunii
• Just in time (producție)
• Lean Startup
• Sursa deschisa
• Management de proiect
• Scrum (informatică)
• Dezvoltare de software

Alte proiecte

• Wikinews conține articolul Francesco Cirillo: programatori agili, o nouă filozofie de dezvoltare software , 27 ianuarie 2008

linkuri externe

• (EN) Agile Alliance , pe agilealliance.com.
• Mișcarea italiană Agile , pe agilemovement.it .
• Italian Agile Day , pe agileday.it .
• ( EN ) ESSAP European Summer School on Agile Programming , pe essap.dicom.uninsubria.it .
• Manifest Agile , pe agilemanifesto.org .

Portal IT : accesați intrările Wikipedia care se ocupă cu IT