Toţi cei care au interacţionat, indiferent cât de puţin cu Microsoft Project sunt unanim de acord că este o foarte puternică unealtă de scheduling. Altfel spus, dacă îi definim şi detaliem task-urile, se pricepe foarte bine să construiască un plan (mai corect spus un schedule) mai bine ca oricine. Dar, pentru a putea defini clar task-urile, este nevoie să ştim cu exactitate ce dorim de la proiect. Ce anume trebuie el să livreze, în ce condiţii, respectând ce criterii, etc. Pare simplu, nu-i aşa? În practică, ştim cu toţii cât de complicat (imposibil?) este să definim încă de la început scopul proiectului şi livrabilul. Şi atunci, cum mă poate ajuta Microsoft Project dacă eu (sau clientul meu) nu ştiu ce vreau de la proiect?
Acesta este motivul principal pentru care au apărut metodologiile sau mişcările Agile. Pentru că, în foarte multe domenii, în software în special, este foarte greu să ştii de la început ce anume trebuie să livrezi. Este suficient să ne gândim la un site web a cărui dezvoltare durează câteva luni şi deja este evident că este imposibil să îl putem planifica minuţios încă de la început. Pe scurt, Agile (şi bineînţeles derivaţiile sale Scrum, XP, FDD, etc.) propovăduieşte faptul că schimbarea este binevenită, că este în regulă să începi proiectul fără să ştii prea multe despre ce anume urmează să livrezi şi, foarte important, că produsul sau livrabilul proiectului se defineşte pe parcurs. Pare magie dar, în realitate, este doar o schimbare de paradigmă care introduce noţiunea de planificare iterativă. În imaginea de mai jos este exprimat grafic acest concept.
Lucrurile par mai simple acum, nu? Planificăm puţin, atât cât ştim, executăm ce am planificat, apoi o luam de la capăt. Şi aşa până terminăm ce avem de făcut sau până când clientul nostru nu mai are idei. Într-adevăr, Agile reprezintă o soluţie la îndemâna companiilor de software pentru a putea pune puţină ordine în proiectele care altfel par fără cap şi coadă. Ajută la scop management, care este definit incremental, funcţionalitate cu funcţionalitate, ajută la planificare care este şi ea un întreg compus din bucăţele, dar este util mai ales în implementarea a ceea ce a fost planificat. Aşadar, Agile ne oferă un cadru ca să definim scopul proiectului, să planificăm, să urmărim progresul şi să o luăm de la capăt.
Pentru a ne face o idee şi mai bună despre Agile îi putem opune o altă metodologie. Opusul Agile se numeşte waterfall. O metodologie waterfall este una în care, încă de la început ştim foarte clar ce trebuie să livram (scopul proiectului), ce termene trebuie să respectăm (un scheduling foarte precis) şi, bineînţeles, care sunt limitele de buget în care ne putem încadra. Desigur, sunt multe proiecte din multe domenii de activitate în care o abordare waterfall este foarte potrivită. În special acolo unde este nevoie de acurateţea aceasta încă de la început iar sponsorul proiectului sau condiţiile mediului impun o asemenea stricteţe. Doar că în software lucrurile nu stau chiar aşa şi deci aici intervine Agile.
Acum, că am definit procesele, este nevoie să trecem la nivelul următor să standardizăm şi automatizăm aceste procese. Aici intră din nou în scenă Microsoft Project.
Cum spuneam şi mai sus, acest software este folosit şi apreciat, în primul rând, pentru capabilităţile sale de scheduling. Bineînţeles că mai ştie şi alte lucuri cum ar fi managementul resurselor sau rapoarte dar principala sa utilitate este să gestionze şi automatizeze complexitatea task-urilor dintr-un proiect. Nu vom intra în detalii legate de portofolii sau lucru colaborativ, caracteristici mai degrabă de Project Server ci ne vom limita la funcţionalităţile unei Project Professional.
Ce face un project manager în momentul în care deschide un Microsoft Project? Experienţa arată că 90% dintre ei se apucă să scrie o listă de task-uri pe care apoi le pun într-o secvenţă ca să arate frumos într-un grafic Gantt. Doar că pentru acest lucru este nevoie să ştim lista de task-uri care derivă din scopul proiectului cunoscut în prealabil în detaliu. Ceea ce, aşa cum am argumentat mai sus, într-un proiect software nu prea este cazul şi de aceea folosim abordări Agile. Şi totuşi, cum putem folosi Microsoft Project în acest scenariu.
Planificarea iterativă a fost întotdeauna parte din project management indiferent de cât de agilă a fost metodologia folosită. Aşadar, în orice proiect putem avea o abordare de planificare, execuţie şi apoi iar planificare. Ideea de a folosi o aplicaţie software specializată de project management nu schimbă cu nimic incertitudinea, și nici nu impune o anume rigurozitate care, în mod normal nu caracterizează proiectele noastre. Imaginea de mai jos exemplifică, în Microsoft Project acest ciclu de planificare şi execuţie iterativă. După cum se vede din imagine, după ce am planificat, atât cât a fost posibil, trecem mai departe la execuţie, după care revenim la planificare. Acest ciclu de planificare este ceea ce PMI numeşte rolling wave planning.
A ne impune o planificare riguroasă în condiţiile în care nu avem suficiente date nu face decât să aducă în proiectul nostru un element de risc dat de nişte estimări nerealiste. Din imaginea de mai sus, totuşi, nu reiese foarte clar că ar fi un ciclu de planificare-execuţie. Aşa cum şi pare din graficul Gantt, replanificare pare o întoarcere în timp. Ceea ce nu este posibil! Şi atunci, pentru a putea reflecta cât mai fidel realitatea, putem crea task-urile pe iteraţii, aşa cum este ilustrat mai jos.
Practic, se definesc în Microsoft Project task-uri pentru fiecare iteraţie atât pentru planificare cât şi pentru execuţie. În exemplul de mai sus se pot adăuga oricâte iteraţii sunt necesare proiectului. Acest lucru îl pot face înserând un set de task-uri pentru planificare şi execuţie legând noua iteraţie de ultima pe care o avem definită anterior.
Urmărind această secvenţialitate, se poate planifica un proiect Agile folosind o unealtă care tradiţional a fost privită ca fiind una destinată proiectelor waterfall. Mai departe, Microsoft Project permite alocarea de resurse şi monitorizarea progresul acestor task-uri. Este extrem de important ca după ce s-adefinit acest plan (sau schedule) să nu se renunţe şi să continuie cu monitorizarea proiectului. Este foarte posibil ca în timpul execuţiei să mai apară alte elemente necunoscute care să ducă către replanificare sau modificarea unor task-uri existente. Este suficient să ne gândim la modificarea unui task dintr-un proiect care are sute de asemenea task-uri ca să vedem importanţa Microsoft Project pentru planificarea şi urmărirea proiectelor. Dacă asta nu v-a convins, mai trebuie să ştiţi că se integrează nativ cu suita Visual Studio, astfel încât echipele de dezvoltare îşi regăsesc task-urile asignate direct în mediul de dezvoltare.