Este curios faptul că azi, la o căutare rapidă a cuvântului Agile pe internet, primești două categorii de răspunsuri: o primă categorie ce conține explicații cu privire la ce este și cum funcționează Agile și o a doua categorie care argumentează de ce Agile nu funcționează.
Există în mod evident două "tabere", una care se oferă să te introducă în tainele Agile și cealaltă, mai redusă numeric dar care se face tot mai tare auzită, care consideră că practicile Agile sunt nocive și pot afecta negativ dezvoltarea de aplicații software.
Personal consider valorile și principiile Agile ca fiind foarte naturale, firești. De fiecare dată am considerat că o bună parte a practicilor Agile sunt de bun-simț și că ele se potrivesc ca o mănușă echipelor de dezvoltare a proiectelor software. Desigur că argumente de acest gen (firesc, natural, bun-simț) nu au darul să satisfacă o persoană obișnuită cu demonstrațiile specifice științelor exacte. Prin urmare am început să investighez mai îndeaproape beneficiile aduse de Agile echipelor de dezvoltare.
Concluzia la care am ajuns este aceea ca paradigma Agile adaptează procesele la natura umană, acest lucru venind în contrast cu abordarea clasică din management care impune adaptarea membrilor echipei la un proces particular de dezvoltare.
În cele ce urmează voi da câteva exemple în sprijinul afirmației mele, încheind cu câteva sfaturi pentru ce ar fi bine de făcut atunci când lucrurile nu funcționează așa cum ne dorim într-un proiect.
Există o serie de situații de care ne-am lovit cu toții în proiectele pe care am lucrat, situații care transcend tehnologiile utilizate sau gradul de experiență. Unul dintre aceste exemple este nivelul efortului pe care o echipă îl depune atunci când trebuie să ducă la bun sfârșit un lucru și care pare să respecte legea lui Paretto, cunoscută și sub numele de regula 20/80. Mai precis se pare că echipa depune un efort (aproximativ) constant în 80% din timpul pe care îl are la dispoziție. În general, după ce s-a scurs această perioadă de timp, echipa conștientizează uneori brutal că nu este posibil să finalizeze ceea ce și-a propus în timpul alocat și nivelul efortului crește considerabil (Figura 1). Se pare că acest șablon se repetă iar și iar în diverse contexte, pentru echipe de diverse dimensiuni și configurații, dar care au de realizat o activitate creativă. Și dezvoltarea unei aplicații software este o activitate creativă.
Una dintre abordările acestei situații este căutarea unei metode prin care echipa să lucreze constant pe întreaga durată a timpului avut la dispoziție, însă se pare că acest lucru nu este în natura umană (v. legea lui Parkinson)
Figura 1. Distribuția efortului unei echipe în procesul de dezvoltare
Pe de altă parte multe din metodologiile Agile ne propun o dezvoltare iterativă, unde fiecare dintre iterații durează între 2-4 săptămâni, iar la finalul acestora trebuie să rezulte o aplicație funcțională. Deși această abordare nu schimbă regula distribuției efortului, spre finalul unei iterații, acesta este mult mai redus decât în cazul în care perioada de dezvoltare ar fi fost una de trei luni, de exemplu, făcând astfel procesul de producție mai lin, cu nivele minime și maxime ale efortului mai apropiate.
Rămânând în sfera gestionării timpului, de data aceasta la nivel personal, merită menționat aici un alt obicei uman considerat până la un anumit grad normal, numit procrastinare. Procrastinarea reprezintă un comportament caracterizat prin amânarea nejustificată a acțiunilor sau a sarcinilor pentru mai târziu și care este privit ca o reacție la anxietatea asociată cu începerea sau finalizarea unei sarcini sau a unei decizii. Acest lucru pare a se regăsi întocmai în strategia "last responsible moment", întâlnită în special în metodologiile Scrum și Lean, care presupune amânarea unor decizii ireversibile până în momentul în care costul neluării deciziei este mai mare decât costul adoptării acesteia. Aceasta strategie este considerată benefică deoarece eficientizează procesul de dezvoltare, el nefiind blocat de luarea unor decizii care pot fi luate mai târziu. Așa cum se subliniază în multe lucrări, strategia "last responsible moment" nu trebuie să fie o justificare a procrastinării, ci mai degrabă o modalitate de eliminare a ei.
Estimarea task-urilor pe care le avem de realizat reprezintă, din punctul meu de vedere, un alt exemplu potrivit pentru a demonstra faptul ca paradigma Agile e orientată pe extragerea lucrurilor bune din acele comportamente pe care, în alt context, le consideram defecte. Așa cum scriam într-unul din primele mele articole din Today Software Magazine, "Particularitățile proiectelor informatice", activitatea de dezvoltare a softului este una creativă neexistând un nomenclator care să precizeze care este timpul uzual necesar pentru implementarea unei anumite funcționalități. Unul dintre lucrurile pe care le-am observat coordonând diverse echipe angajate în dezvoltarea de aplicații software este acela că motivațiile și percepțiile pe baza cărora se face o estimare diferă foarte mult de la o persoană la alta. Pe de altă parte am constatat că acuratețea estimărilor nu se îmbunătățește foarte mult odată cu creșterea experienței, acest lucru datorându-se în special complexității caracteristice proiectelor software.
Ce îmbunătățiri aduce Agile în estimare? În primul rând, estimarea colectivă. În loc ca estimarea să fie făcută individual, de fiecare persoană pentru task-urile proprii, întreaga echipă participă la estimarea tuturor task-urilor. Acest lucru reduce substanțial erorile de estimare și face ca diferențele de percepție să fie discutate și lămurite în grup. În plus, mutarea atenției de la estimarea timpului la estimarea efortului necesar folosindu-se un sistem particular de punctare, duce la obținerea unei viteze de estimare mărite fără a se reduce acuratețea estimării. Prin aceste abordări experiența în domeniu este mult mai bine valorificată și efortul de estimare mult redus.
Întorcându-mă la ideea amintită anterior, și anume că activitatea de dezvoltare a softului este una creativă, nu pot să nu fac o corelație între felul în care este dezvoltată o aplicație și cum sunt realizate multe din lucrările artistice. După cum se poate observa din Figura 3 unde este prezentată o pictură nefinalizată, pictorul nu a împărțit pânza în 6 sau 9 zone distincte pe care să le picteze succesiv (carecteristic abordării plan-driven, unde se presupune că cel care îndeplinește o activitate are foarte clar și detaliat în minte felul în care rezultatul acestei activități trebuie să arate) ci a schițat o primă versiune a întregului tablou, pe care a îmbunătățit-o ulterior, ajungând în final să folosească culori pentru a finaliza (caracteristic abordării evolutive, ce presupune că produsul final este realizat printr-o serie de versiuni îmbunătățite succesiv). Observați că și în această fază, departe de a fi terminată, avem o idee despre cum va arăta tabloul în totalitatea lui și, foarte important, acesta este încă într-o fază în care se pot face îmbunătățiri substanțiale cu un efort redus.
În toate metodologiile Agile avem suport pentru abordarea evolutivă a creării produselor, ciclul de dezvoltare impus are pe lângă calitatea de a fi iterativ și pe aceea de a fi incremental. Astfel activitatea de dezvoltare de soft este susținută la nivel de metodologie, fiind abordată așa cum sunt abordate majoritatea activităților creative.
Figura 3. Paul Gauguin - Tahitieni odihnindu-se (1891, nefinalizat)
Un ultim exemplu pe care aș dori să îl dau este cel legat de fascinația pe care o avem pentru complexitate. În multe situații îmbrățișăm soluțiile mai complicate la problemele pe care le avem, și atunci când nu o facem din cauza lipsei de timp sau a altor resurse, le apreciem oricum mai mult, fiind deseori nemulțumiți de soluția simplă pe care am ales-o în loc. Această fascinație pentru complexitate se regăsește deseori și în activitatea de dezvoltare a proiectelor software: deseori preferăm implementarea unui framework care să rezolve mult mai mult decât problema pe care o aveam de rezolvat, fără a lua în calcul costurile foarte mari de întreținere pe care le derivă. Și exemplele ar putea continua.
Un experiment interesant. Experimentul Bavelas ne arată că atunci când sunt mai multe soluții la o problemă, cea care este cea mai complicată și sofisticată atrage de obicei cele mai multe aprecieri. Conștient de acest fapt Stefan Roock, un consultant, speaker și autor cunoscut în special pentru expertiza sa în Extreme Programming, spunea la un moment dat că "În software, soluțiile complicate sunt greșite, chiar dacă ele sunt corecte".
Agile introduce conceptul de "just enough". De la definirea user story-urilor sau scrierea documentației până la proiectarea arhitecturii și planificare, totul este realizat în abordarea "atât cât trebuie". De data aceasta Agile nu se mai așază atât de bine pe natura umană, ci dimpotrivă: caută strategii prin care să diminueze efectele negative ale unui comportament uman obișnuit. Procesele sunt astfel ajustate încât să nu dea prea des ocazia echipei de proiect să gândească prea complicat.
Ar mai fi multe alte exemple, de la structura și importanța dată ședințelor retrospective în Agile ("omul din greșeli învață") până la ideea de user story, care are la bază faptul că atenția și capacitatea de înțelegere a oamenilor sunt mult influențate de modul în care este prezentat un lucru. Dar acestea vor face probabil obiectul unui viitor articol. Ce este mai important de înțeles acum este ce am putea face atunci...
Unul dintre lucrurile pe care Agile încă nu le-a putut trata este tendința oamenilor de a gândi în șabloane. Gândirea în șabloane reprezintă de cele mai multe ori un avantaj, pentru că ne ajută să observăm, să analizăm și să reacționăm corect și mai repede în multe situații. Este modul prin care am reușit să învățăm multe din lucrurile pe care le cunoaștem azi. Totuși, în anumite contexte gândirea în șabloane poate să ne abată atenția de la detalii importante.
Cineva spunea că în dezvoltarea softului singurul lucru cert este schimbarea. Într-un astfel de context să încerci să aplici anumite practici și procese care au funcționat în trecut este deseori periculos, iar de multe ori când lucrurile nu merg nu spunem că procesele sau practicile nu sunt corespunzătoare ci suntem tentați să dăm vina pe oameni, pe context, pe lipsa de resurse etc. . Acum în final de articol, sfatul meu este ca atunci când ceva nu merge în proiectul nostru și acest lucru persistă o bucată de timp să încercăm să analizăm și, eventual, să adaptăm procesele pe care le utilizăm. S-ar putea ca acestea să nu fie deloc potrivite contextului și persistența noastră în a schimba contextul să atragă după sine și mai multe probleme.