ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 4
Abonament PDF

Microsoft Project şi proiectele Agile

Florian Ivan
Managing Partner, PMI-ACP, CSM, PMP, Prince2 Practitioner, MVP, MCTS
@Rolf Consulting Germany



PROGRAMARE

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.

img10_1.jpg

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.

img10_2.jpg

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.

img10_3.jpg

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.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects