by La inceput au fost intrebarile:
- Ce inseamna Agile?
- Ce avantaje ne aduc aceste metode de lucru?
- In ce proiecte se potrivesc?
- Care sunt recomandarile de adoptare?
- Care sunt pasii de adoptare?
- Cum se pot mapa practicile Agile pe procesele de management de proiect?
Am aflat, ca si multi dintre voi ca un grup de “entuziasti” ai dezvoltarii software neconventionale s-au reunit in anul 2001 si au declarat intr-un “manifest” valorile care primeaza in opinia lor pentru o cale mai buna de a crea produse software.
Ei aseaza oamenii si interactiunile inaintea proceselor si instrumentelor de lucru.
Software-ul functional inaintea documentatiei exhaustive.
Colaborarea cu clientii inaintea negocierilor contractuale.
Reactiile la schimbare inaintea urmarii unui plan prestabilit.
Asadar semnatarii pretuiesc mai mult efectul primelor valori enuntate desi recunosc si beneficiul celor din urma. Precizarea merita facuta, pentru a nu-i indeparta prea mult pe cei obisnuiti cu abordarea “traditionala” de dezvoltare care pare a fi in mod obligatoriu conditionata de rigorile planificarii, specificatiilor si negocierilor contractuale.
Am continuat sa caut
fiind interesat de beneficiile promise de dezvoltarea Agile:
- Eficienta in livrarea “valorii de business”
- Cresterea “vizibilitatii” asupra procesului de dezvoltare
- Reducerea riscului asociat proiectelor de dezvoltare software
- Raspuns rapid la schimbarile pietei si ale competitiei
- Adaptarea usoara la schimbarea cerintelor
- Livrabile care raspund mai bine nevoilor reale ale clientilor
Am aflat ca toate acestea se obtin prin cicluri scurte (tipic 1-4 saptamani) de planificare, dezvoltare si feedback, prin lucrul in echipe multifunctionale (preferabil localizate in aceeasi incinta), prin masurarea statusului (nu prin diagrame Gantt ci prin demonstrarea unor functionalitati implementate), prin cicluri zilnice de monitorizare si control (carora agilistii le spun”inspect and adapt” pentru ca nu le place cuvantul “control”) la care participa intreaga echipa, prin estimari neconventionale in “story points” sau “T-shirt sizes”, prin modificari frecvente in abordarea rezolvarii unei probleme, chiar si cu cateva zile inainte de termen, prin reprioritizari nelimitate la nivel de “scope” dar anuntate cel putin cu un ciclu de dezvoltare inainte.
Si prin inca ceva: prin respect. Prin respectul pe care fiecare membru al echipei il poarta pentru munca lui, pentru a celorlalti si pentru client.
Metodele Agile nu se limiteaza la indeplinirea unor cerinte scrise ci merg mai departe, indeplinesc cerintele oamenilor implicati, fie ca sunt clienti, membri de echipa sau manageri. Si le indeplinesc intr-un mod firesc. Pentru ca toti se afla in continua colaborare si comunicare.
Frecventa cu care se succed evenimentele e atat de mare, incat toti acestia sunt pusi fata in fata sa defineasca functionalitati, sa gaseasca metode de implementare, sa le valideze, sa le imbunatateasca, incat foarte curand ajung sa pretuiasca si sa inteleaga munca celorlalti. Si sa isi schimbe propriile pareri – un lucru rar in aceasta ramura de activitate – trebuie sa recunosc.
Si am mai aflat ca rolul unui Project Manager se divide – intre un “sef” de proces, un “sef” de produs si Echipa care e propriul ei “sef” – un concept interesant, de “self-management” care permite echipei sa ia deciziile de “cum” se organizeaza, “cum” imparte sarcinile, “cum” rezolva tehnic o problema. Nu si “ce” se implementeaza. Dar in schimb, “cat” si “cum”.
Am practicat
Am reusit sa depasesc granitele celor 42 de procese din PMBOK Guide, desi nu le-am folosit chiar pe toate.
Am lucrat impreuna cu colegii, am modificat specificatii, am modificat asteptari, am gasit in ambitia de a face un lucru bun un aliat mai de nadejde decat intr-o specificatie functionala detaliata.
La sfarsitul fiecarei iteratii care includea dezvoltarea testarea si documentarea unui set de functionalitati am analizat rezultatele: atat cele masurabile in produs (software functional) cat si cele interpretabile (modul nostru de organizare, practicile, punctele de imbunatatit). Si a doua zi am pornit din nou cu un nou set de functionalitati. Fara pauze.
Am inceput sa privesc Agile nu ca un mod de lucru sau ca un cadru pentru proiectele de dezvoltare in care lucrez ci ca pe un mod de relationare.
Am cunoscut mai bine oamenii cu care lucrez. Si am inteles nu “Ce?” e Agile ci “Cine?”.
