Modelul Agile Software Development

În februarie 2001, un grup de 17 persoane implicate în dezvoltarea de software au mers la schi într-o cabană din Utah. Ceea ce a rezultat este, cum se spune, istorie: Manifestul Agile Software Development.

Documentul a pus bazele unei mișcări internaționale pentru modificarea din temelii a modului în care se dezvoltă software. După 10 ani, comunități de practică Agile sunt prezente în toată lumea, inclusiv în România (Agile Works România, agileworks.ro), și principiile Agile au început să fie aplicate și în alte domenii: marketing, arhitectură, business și chiar și la nivel personal. Cum a fost posibil așa ceva? Cum ar putea un set de principii să se aplice la domenii atât de diverse, deși a pornit dintr-un domeniu renumit pentru a fi închis celor din afara lui? Prima cauză principală este că manifestul Agile enunță o filozofie, prin patru enunțuri de valori:

 „Indivizii şi interacţiunile sunt mai importante decât procesele şi uneltele folosite.Software-ul funcţional este mai important decât o documentaţie vastă.Colaborarea cu clientul este mai importantă decât negocierea contractului.Adaptarea la schimbare este mai importantă decât urmărirea unui plan”.

Și prin 12 principii:

1.  „Simplitatea – arta de a maximiza cantitatea de muncă nerealizată – este esenţială.“ (notă: munca ce nu aduce valoare).

2.  „Cele mai bune arhitecturi, cerinţe şi tipuri de design provin din echipe care se auto-organizează“.

3. „Construieşte proiecte în jurul oamenilor motivaţi. Oferă-le mediul propice şi suportul necesar şi ai încredere că obiectivele vor fi atinse“.

4. A doua cauză este că mișcarea Agile își are rădăcinile în lean manufacturing și modelul Toyota. Aceleași rădăcini le au și alte mișcari moderne din management, în special familia Lean: Lean Software Development, Lean Startup sau Lean Business.

5. Este însă foarte clar că în practică nu putem folosi doar acest set de principii și valori, ci ele sunt doar un punct de pornire. De aceea au apărut diverse practici, care pot fi clasificate în două categorii: de organizare și tehnice.

6. Practicile de organizare se referă la structurarea interacțiunilor în echipă, între membrii echipei și între echipă și restul lumii: manageri, clienți, oameni de business, responsabili de produs etc. De exemplu:

7. Modelul iterativ și incremental: echipa lucrează în iterații cât mai scurte (două săptămâni sau mai puțin, ajungând chiar și la patru ore), cu un obiectiv foarte clar. La finalul iterației, echipa trebuie să demonstreze că a implementat software utilizabil și fără defecte, care conține un nou „increment“ de funcționalitate care aduce valoare de business.

8. Backlog: crearea și menținerea unei liste de „lucruri de făcut“ (funcționalități, configurări, kit-uri de instalare ș.a.m.d.) pentru a finaliza produsul sau iterația. Această listă este prioritizată în principal în funcție de valoarea de business pe care o creează fiecare lucru.

9. Lista de impedimente: se consideră impediment orice stă în calea echipei pentru a performa mai bine. Poate fi vorba de echipamente, aplicații, mediul de lucru, dar și mai important, despre practici noi care pot fi adoptate sau despre îmbunătățirea skill-urilor membrilor echipei în anumite direcții.

10. Retrospectiva: o întâlnire periodică la care participă toți membrii echipei și unde echipa discută impedimentele descoperite și alege o modalitate de a le înlătura. Decizia se transformă într-un lucru de făcut inclus în backlog și va face parte din incrementul următor.

11. Planificare și estimare pe termen lung: întreaga echipă împreună cu responsabilii de produs și de business stabilesc viziunea, obiectivele, creează backlog-ul inițial și definesc conținutul primei versiuni care va fi livrată către utilizatori. Toți participanții la această întâlnire sunt conștienți că acest plan se va modifica în viitor, dar la final toată lumea implicată în proiect înțelege același lucru.

12. Planificare și estimare pe termen scurt: înainte de fiecare iterație, echipa extrage primele lucruri din backlog-ul produsului și planifică următoarea iterație, ajungând inclusiv la detalii tehnice.

Practicile tehnice se referă la discipline specifice pe care trebuie să le urmeze fiecare membru al echipei în parte. Dintre ele putem aminti: programarea în pereche (pair programming), Test Driven Development (o disciplină care impune scrierea de teste automate înainte de a scrie codul și curățarea continuă a codului), refactoring (îmbunătățirea codului existent fără a modifica funcționalitatea), Clean Code (principii de scriere a codului care permit reducerea complexității).

Este evident că practicile tehnice sunt specifice dezvoltării de software și, ca atare, nu pot fi aplicate în alte domenii. Domenii precum arhitectură, marketing, business au, prin urmare, propriile practici specifice, care le înlocuiesc pe cele din software.

Ar mai fi multe de discutat despre modelul Agile și adaptarea lui în alte domenii. Pentru cei interesați, întâlnirile din cadrul comunității AgileWorks Romania (agileworks.ro) sunt gratis și oricine este bine-venit să pună întrebări sau să găsească răspunsuri. Sper să ne întâlnim acolo!

Documentul a pus bazele unei mișcări internaționale pentru modificarea din temelii a modului în care se dezvoltă software. După 10 ani, comunități de practică Agile sunt prezente în toată lumea, inclusiv în România (Agile Works România, http://agileworks.ro), și principiile Agile au început să fie aplicate și în alte domenii: marketing, arhitectură, business și chiar și la nivel personal. Cum a fost posibil așa ceva? Cum ar putea un set de principii să se aplice la domenii atât de diverse, deși a pornit dintr-un domeniu renumit pentru a fi închis celor din afara lui? Prima cauză principală este că manifestul Agile enunță o filozofie, prin patru enunțuri de valori:

 „Indivizii şi interacţiunile sunt mai importante decât procesele şi uneltele folosite.

 Software-ul funcţional este mai important decât o documentaţie vastă.

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

 Adaptarea la schimbare este mai importantă decât urmărirea unui plan”.