Lector, PhD @ Facultatea de matematică și informatică, UBB
Retrospective Agile este singurul podcast din România dedicat exclusiv abordărilor Agile în managementul proiectelor. Ajuns la al 9-lea episod, podcastul tratează diverse teme legate de agilitate într-o manieră relaxată și informală.
Un proiect reprezintă un efort temporar asumat în vederea obținerii unui produs, serviciu sau rezultat unic [1]. Caracteristica aceasta de unicitate a rezultatului implică un anumit grad de incertitudine în ceea ce privește derularea activităților și, inclusiv, un anumit nivel de risc. Cu cât gradul de incertitudine este mai mare, cu atât proiectul este mai fragil, mai predispus la eșec. De aceea, în managementul clasic, o bună parte din activitatea de management al unui proiect se focusează pe identificarea, măsurarea, monitorizarea, diminuarea și eliminarea riscurilor. Pe de altă parte, metodologiile Agile folosesc mecanisme ce conduc indirect la controlul riscurilor fără însă a propune practici explicite de eliminare a incertitudinii. Cu toate acestea (sau poate tocmai din această cauză), simțim de multe ori că ne aflăm constant pe nisipuri mișcătoare și că proiectul pare scăpat de sub control. Sunt acestea semne ale fragilității proiectului? Părerea mea este că nu și voi încerca să demonstrez acest lucru de-a lungul următoarelor secțiuni.
Preocuparea în ceea ce privește studiul dinamicii și al performanțelor echipelor este una constantă și de lungă durată. Interesant este faptul că cele mai relevante teorii din acest domeniu rămân în continuare unele dezvoltate în urmă cu mai bine de 50 de ani. Modelul lui Tuckman de evoluție a unei echipe este unul dintre aceste modele și, pentru mulți dintre noi, a avut efectul unei revelații atunci când l-am descoperit. Cu toate acestea, ne punem pe bună dreptate întrebarea dacă toate celelalte modificări ce au survenit stilului de lucru în ultimele decenii (de la echipe virtuale, distribuite până la aplicarea unui orar flexibil și munca de acasă) nu au influențat cu nimic relevanța acestei teorii.
Fără doar și poate, metodologiile Agile utilizate în acest moment de către tot mai multe echipe ce dezvoltă proiecte software, nu reprezintă un capăt de drum. Dezbaterile despre eficiența acestor metodologii duc la concluzia că ne aflăm într-un proces de evoluție și maturizare care va mai continua o perioadă . #NoAgile reprezintă, după părerea mea, doar o etapă intermediară a acestui proces și este rezultatul unor dezamăgiri și frustrări acumulate de-a lungul unor experiențe nefericite de implementare a agilității dar și a unei dorințe de progres, de transformare și îmbunătățire continuă.
Schimbarea reprezintă una dintre temele cel mai des abordate în ultimul timp într-o multitudine de studii, cărți, articole sau conferințe indiferent de domeniu. Fără doar și poate viața noastră personală și profesională este mai dinamică decât oricând, confruntându-ne zilnic cu situații noi, greu de prevăzut. Lumea din jurul nostru se schimbă cu o viteză tot mai mare, într-un complex tot mai accentuat de (mega)evoluții și (mini)revoluții pe cele mai diverse planuri. Agile este la rândul său despre schimbare, mai precis despre schimbările cu care se confruntă echipele de proiect. Valorile și principiile Agile vorbesc despre beneficiile schimbării și despre adaptarea rapidă la schimbare. Agile în sine reprezintă o schimbare majoră, atât pentru echipele ce doresc să implementeze o metodologie agilă particulară cât și pentru cele care evoluează continuu.
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.
Imagine Cup este o competiţie anuală IT care se adresează studenţilor și elevilor din întreaga lume. Competiţia este organizată de Microsoft şi are ca scop dezvoltarea de soluţii software care să vizeze cele mai importante probleme ale omenirii şi care au şanse reale de a deveni produse soft comerciale.
Ideea acestui articol mi-a venit cu mai multe luni în urmă, atunci când pregăteam o prezentare pentru conferința “…și mamuții sunt Agile” ce a avut loc la Cluj-Napoca în această primăvară. Se întâmplă uneori ca anumite lucruri să pară a fi foarte clare și evidente la un moment dat, însă atunci când le studiezi mai îndeaproape ai surpriza să constați contrariul. Așa s-a întâmplat și atunci, când dorind să studiez eficiența și beneficiile aderării la bunele practici Agile adoptate în anumite organizații sau echipe de proiect, am ajuns la concluzii ce sunt departe de a le considera optimiste.
Potrivit specialiştilor în resurse umane, în România IT-ul este unul dintre puţinele domenii în care numărul de poziţii disponibile a crescut după izbucnirea crizei economice şi unul în care companiile se află în competiţie pentru cei mai buni specialişti. Se aude tot mai pregnant ideea că, în competiţia cu costurile reduse ale salariaţilor din alte zone geografice (cum ar fi, de exemplu, Asia) soluţia este să se migreze de la outsourcing la produse proprii, sau, într-un poces mai puţin radical, să se petreacă o schimbare în ceea ce priveşte relaţia cu clienţii şi să se transforme statutul de simplu executant
Unul dintre primele lucruri pe care le afli atunci când citeşti un articol sau o carte despre gestiunea proiectelor din IT este acela că proiectele informatice se deosebesc foarte mult de toate celelalte proiecte. Chiar și atunci când subiectul principal este legat de gestiunea proiectelor în general, se fac referiri directe cu privire la ineficienţa anumitor metode atunci când avem de-a face cu proiecte software. Din păcate nu este întotdeauna explicat în ce costau acele deosebiri şi se insistă mai degrabă pe a descrie soluţii, mai mult sau mai puţin eficiente.
