Agile sub umbrela PMI

Postat la august 20, 2013 de ThePMJournal

Astazi am purtat o discutie aprinsa cu unul din cei mai fanatici sustinatori ai „Agile”, pe care eu i-am cunoscut vreodata. Totul a pornit de la doua cuvinte: PMI si Agile. In viziunea colegului meu, managementul de proiecte „traditional”, asa cum este prezentat in PMBoK de catre Institutul Managementului de Proiecte (PMI), este total diferit de managementul de proiecte de tip „Agile”. Pentru a-si sustine punctul de vedere, el mi-a facut prezentat despre beneficiile „Agile” in comparatie cu project managementul „traditional”.  Trebuie sa recunosc ca prezentarea lui a fost exceptionala, insa in ciuda lucrarii sale foarte bine argumentate, nu am fost acord in cu concluziile lui. De aici a reiesit un adevarat scandal:

-Cum poti sa afirmi o asemenea ineptie ca Project Managementul clasic definit de PMI este aproximatix acelasi lucru managementul proiectelor in stil „Agile”? ma intreaba el… 

In ciuda argumentelor pe care i le-am adus, discutia s-a desfasurat in contradictoriu timp de cateva ore. La un moment dat, eram atat de aprinsi fiecare cu argumentele lui aproape ca ne-am luat la bataie. Concluzia colegul meu a fost:

-Clar ca buna ziua: Tu nu ai mind-set-ul de Agile! Iti trebuie sa mai citesti carti!

Discutia, in ciuda faptului ca a am considerat-o constructiva, mi-a lasat un gust amar. Impresia generala pe care i-o lasasem colegului meu a fost ca eu de fapt urasc Agile, cand in realitate eu sunt un mare sustinator al curentului Agile. M-am intrebat: Ce anume am gresit in felul in care am purtat discutia? De ce m-am facut gresit inteles?

Dupa ce am reanalizat punctele de divergenta ale discutiei noastre, mi-am dat seama ca motivul principal pentru care nu ne-am inteles a fost datorat in principal folosirii eronate a termenilor de specialitate: de exemplu cand ne refeream la conceptul „PMI-PMBoK” foloseam „Waterfall”(„dezvoltarii in cascada”) iar atunci cand faceam referire la „Agile” atunci cand foloseam termenul de „Scrum”. Desi este mai mult decat evident ca aceste cuvinte nu desemneaza unul si aceleasi lucru, folosirea lor gresita in viata noastra de zi cu zi ne-a facut sa uitam adevarata lor semnificatie.

De unde vine conceptia gresita ca PMI=Waterfall?

In cartea PMP Exam Prep de R.Mulcahy, cand se ajunge la capitolul Project Life Cycle, este prezentata o schema mare si frumoasa de genul:

Imaginea reprezinta ciclul unui proiect din industria IT. Imaginea ne duce cu gandul in mod spontan la o insuruire de faze secventiale gen „Waterfall”. Ceea ce se spune printre randuri, insa nu se subliniaza, este ca Project Life Cycle nu este un proces intotdeuna in cascada: Idee, Planificare, Executie, Testare, Release ci poate fi o suma de stari foarte amestecate. Ceea ce trebuie remarcat este ca standardul managementului de proiecte descris de PMI in PMBoK este un framework si nu o metodologie. Un Framework este un set generic de procese, tooluri, practici care sa serveasc rezolvarii unei probleme particulare (descrie un model care arata ce sa faci, dar nu si cum). O Metodologie este un set de metode, concepte, practici care product rezultate concrete intr-un mod repetabil (iti spune exact cum sa obtii un rezultat, iar de fiecare data metodele sunt aceiasi). Pornind de la aceasta definitie, putem spune despre Agile, compus eventua din mai multe sub-framework-uri (exemplu: Scrum, etc) poate fi pus in practica folosind metodologii Agile (i.e: XP, Lean, Kanban, etc.). Deoarece Agile este folosit in general in industria software (mai multe detalii privind metodologiile software pot fi gasite pe wiki), in ce timp ce PMI-MBoK este un stadard pentru toate industriile (nu neaparat IT), putem spune ca PMI este „fratele mai mare” al Agile-ului.

Mai mult, PMBoK este un framework care pot fi puse in practica de mai multe tipuri de metodologii: cascada, iterativa, incrementala, spirala, „prototip” sau arte combinatii de iterativa si incerementala ca si XP (din Agile).

PMBoK-ul vede un proiect ca o suma de procese. Un proiect, este o insiruire logica de 5 grupuri de procese (I, P, E, M & C, C) care pot fi reprezentate ideal in felul urmator:

Ordinea de aplicare a acestor grupuri de procese este la latitudinea organizatiei si a project managerului, care pot decide daca procesele se aplica in cascada, iterativ sau in alta ordine. Desi in teorie, ordinea grupurilor de proceselor este: 1-Initiere (I), 2-Planificare (P), 3-Executie (E), 4-Monitorizare si Control (M & C), 5-Inchidere (C), daca ar fi sa afisam timpul alocat fiecarui grup de procese in cadrul unui proiect oarecare, imaginea ar arata cam asa:

Ce este de retinut in legatura cu grupurile de procese:

• procesele de Monitorizare si Control este prezent in timp inca de la inceputul proiectului (incepe odata cu faza Initiere) pana la sfarsitul proiectului (se termina odata cu faza de Inchidere)
• toate grupele de procese (I, P, E, M&C, C) sunt intercalate in timp.

In cadrul unui proiect complex, vizualizarea in timp a proceselor ar arata ca o „tesatura” de procese:

Fiecare proiect are o asemenea „tesatura” de procese, care reprezinta „semnatura” proiectului. O semnatura este o insuruire de litere reprezentand initialele grupurilor de procese; exemplul: (I, P, E, C) M&C, (I, P, I, C ) M&C. Tipurile de „tesaturi” care pot exista in cadrul proiectelor, teoretic este infinita, intrucat procesele se pot suprapune, se pot intercala, pot fi eliminate (termenul „eliminat” ar trebui interpretat in acest context ca „timpul petrecut in proces este redus la zero”) sau se pot repeta ori de cate ori e nevoie. In exemplul de mai sus, este prezentata semnatura unui proiect devoltata cu o metodologie iterativa. Iata cum ar putea arata „semnatura” unui proiect „Agile”:

„Ciclul de proiect” si Procesele

Unul din conceptele intelese gresit este faptul ca procesele sunt aceleasi lucruri cu etapele din ciclul de proiect (Project Life Cycle). Intrucat anumite grupuri de procese pot fi eliminate, un proiect poate avea urmatura semnatura redusa (I, P, M & C, I): vezi exemplul de mai jos.

In acest caz, nu a mai fost nevoie de Executie(E) si nici de Inchidere(I), intrucat in procesul de planning (P), unde, in urma unui risk assessment, s-a decis (deciziile se iau de obicei in procesele de Monitorizare si Control – M&C) ca obiectivele din project charter nu pot fi atinse si a fost nevoie redefinirea intregului business case; proiectul nu s-a terminat si nici nu a fost Inchis (I), ci a fost pus „on hold” pe termen nedefinit.

Denumirea phaselor unui proiect si numarul de faze ale unui ciclu de proiect este dependent de domeniu/industrie, pe cand denumirile grupurilor de procese si numarul de grupuri de procese este independent de industrie si e intotdeuna acelasi (teoretic intotdeuna sunt 5 grupuri de procese, chiar daca organizatia decide la un moment dat sa „reduca la zero” sau sa „elimine” anumite grupuri de procese). Un ciclu de proiect poate avea un numar mare de faze si doar anumite faze pot contine procese (in exemplul de mai jos, organizatia a decis ca din faza de „Design” sa fie eliminate toate grupurile de procese, intrucat nu erau necesare):

Cine spune ca Waterfall trebuie sa fie o „cascada”?

Sa luam de exemplu un proiect realizat cu metodologia Waterfall, dar planificat in mai multe Release-uri. Release-urile se realizeaza unul dupa altul ca intr-o cascada. Dar asta inseamna ca Releaseul 2 poate fi incrementul Releaseului 1, cu alte cuvinte un proiect dezvoltat cu Waterfall (Iterative Waterfall). Daca pe deasupra ne planificam livrabile suficient de mici (gen work package-uri), atunci dezvoltarea unui proces Waterfall poate fi similara cu dezvoltarea Agile (care este iterativa si incrementala).

Agile sub umbrela PMI

Cum putem obtine din framework-ul PMI o metodologie iterativa? Plecand de la „semnatura” unui proiect (o insiruire oarecare de procese: I, P, E, M&C, C), printr-o succesiune potrivita de procese (procese PMI), se poate obtine o metodologie iterativa. Exemplu: [(I, P, E, C) M&C], [(I, P, I, C ) M&C]. Cum se poate obtine din framework-ul PMI o metodologie incrementala? In PMBoK se sugereaza obtinerea unei metodologii incrementale folosind tehnica „planificarii in valuri” (Role Wave Planning – planificare pe masura ce specificatiile sunt clare).

PMI nu iti spune exact cum sa gestionezi un proiect, ci mai degraba iti ofera o un cadru generi a ceea ce poti face. Project Manager-ul decode ce process sa aplice si in ce ordine. Putem trage concluzia ca dintr-o combinatie potrivita de procese de project management (procese intercalate, suprapuse, iterate, intr-o anume ordine, erc) se poate obtine orice metodologie iterativa si incrementala (methodologie Agile). Intr-un anume sens, Agile se afla sub umbrela PMI.

Urmeaza: Cat de importante sunt diplomele si certificarile?

Recomandari: Agile Earned Value Management