8 mituri despre metodologiile AGILE

Care sunt cele mai  comune erori in intelegerea principiilor AGILE, o abordare din ce in ce mai populara si controversata in managementul de proiect ?

Un articol publicat in Wall Street Journal, in martie 2014 demonteaza o serie de prejudecati asociate cu folosirea acestei metodologii.

Agile a aparut in 2001, cand un grup de programatori cu experienta au propus acesta metoda ca o reactie la abordarea „waterfall”, pe care au perceput-o ca lenta si disfunctionala. Spre deosebire de metoda „waterfall”, Agile incurajeaza raspunsul rapid si flexibil la schimbarea nevoilor clientului si cerintelor utilizatorului.

Unele comunitati, atat in sectorul IT, cat si in alte industrii au imbratisat cu entuziasm aceasta metoda, in dorinta de a atinge rezultatele vizate mai rapid si s-au indepartat de abordarile traditionale. Altii, se opun in mod vehement abordarii Agile, considerand ca provoaca schimbari care dezechilibreaza procesele existente si adauga neplaceri suplimentare clientului. Realitatea este, probabil, undeva la mijloc.

Iata cateva mituri asociate cu utilizarea metodologiilor Agile:

Mitul nr. 1: Agile inseamna zero planificare
Realitatea: Planificarea in detaliu este la fel de importanta in Agile, ca si in Waterfall.

Mitul nr. 2: Cu Agile, nu va exista nici o documentatie de proiect
Realitatea: In orice efort de dezvoltare a unui proiect, documentatia functioneaza ca o harta, ajutand la intelegerea sistemului si aliniind obiectivele stakeholderilor. In Agile, spre deosebire de metodologiile clasice, in locul unui document stufos in care se listeaza toate cerintele proiectului, managerii de proiect compileaza o colectie de cerinte ale clientului. Acestea pot fi actualizate in mod activ cu ajutorul software-ului, prioritizate pe parcurs si utilizate pentru a asigura o vizibilitate in timp real a progresului in dezvoltarea proiectului.

Mitul nr. 3: Agile functioneaza doar in proiectele mici
Realitatea: Modelul echipei Agile – grupuri mici, inter-departamentale care colaboreaza in procesul de dezvoltare – se dovedeste eficient atat in proiecte mici, punctuale, cat si in eforturile mai ample, cu mai multe fatete de dezvoltare a unor sisteme complexe.
Mitul nr. 4: In Agile e necesar ca stakeholderii si dezvoltatorii sa lucreze intr-o singura locatie
Realitatea: Agile presupune ca stakeholderii sa se implice activ si sustinut in efortul de dezvoltare. Ca rezultat, multi presupun ca membri echipei trebuie sa se afle intr-o singura locatie pentru a-si atinge rezultatele. Cu tehnologia moderna, acest lucru nu mai este valabil. Sistemele de teleconferinta, instrumentele de „screen sharing” pot functiona la fel de bine pentru a asigura comunicarea si colaborarea in timp real, chiar si de la distanta.

Mitul nr. 5: Cu Agile, produsul final ramane o necunoscuta pana se finalizeaza dezvoltarea lui
Realitatea: In proiectele waterfall, produsul final e clar definit de la inceput de cerintele proiectului. Aceasta abordare este utila, insa orice schimbare neanticipata poate produce intarzieri costisitoare. In Agile, pe de alta parte, exista doar un plan de ansamblu, in fazele initiale ale dezvoltarii proiectului, iar detaliile sunt rafinate progresiv pe masura ce sistemul se construieste.

Mitul nr. 6: Procesele in Agile sunt mai putin disciplinate si structurate decat cele din waterfall.
Realitatea: Implementarea proiectului conform Agile presupune mai multa disciplina, intrucat proiectul este condus in mod activ de la planificare la lansare; stakeholderii monitorizeaza progresul la intervale prestabilite si ofera feedback in fiecare etapa a proiectului.

Mitul nr. 7: Agile = Scrum
Realitatea: Agile nu este asociat doar cu Scrum, chiar daca aceasta metoda este cea mai populara printre dezvoltatorii software. Lean programming, Kanban si alte abordari au adeptii lor, important fiind ca utilizatorii sa o aleaga pe cea care se potriveste cel mai bine tipului de proiect pe cae il dezvolta.

Mitul nr. 8: Agile nu este un panaceu universal
Realitatea: Agile nu este intotdeauna o abordare potrivita in proiectele care nu pot fi sparte in unitati de lucru mai mici. Se bazeaza, de asemenea, pe implicarea activa a stakeholderilor si pe deschiderea lor de a adopta rapid schimbarile, ceea ce nu e aplicabil in toate organizatiile.
— un articol tradus si adaptat dupa Eric Bristow, director, Deloitte Consulting LLP