parafrazând un concept binecunoscut în managementul proiectelor, s-ar putea spune: „Planificarea este indispensabilă, dar planurile sunt inutile. Prin urmare, inspectați și adaptați.”
planurile tradiționale sunt determinate de date – cel mai probabil, o dată de încheiere fiind factorul principal de conducere. În managementul tradițional de proiect, adunați cerințele de la părțile interesate, construiți domeniul de aplicare al proiectului și împărțiți proiectul în bucăți de lucru gestionabile. Aceasta, la rândul său, creează o structură de defalcare a muncii (WBS). Apoi, cel mai scăzut nivel al WBS, adică pachetele de lucru, sunt descompuse în continuare în activități. Activitățile sunt apoi legate de dependențe, iar resursele sunt estimate și aplicate activităților pentru a crea un program end-to-end pentru proiect. Acest program este apoi monitorizat și controlat cu ajutorul unui plan de gestionare a programului, care este de obicei un plan subsidiar al planului consolidat de gestionare a proiectului.
dar, de câte ori s-a întâmplat ca ceea ce ați planificat și ceea ce s-a întâmplat de fapt pe teren să se potrivească? Știți deja răspunsul! Citatul de deschidere înseamnă că planificarea este esențială, dar așteptarea că putem urma planul exact nu este un lucru înțelept de făcut. Atunci când există cerințe ridicate și incertitudine ridicată în tehnologie sau platformă, PMs merge de obicei cu cicluri de viață adaptive (sau Agile).
de fapt, a patra valoare din manifestul Agile spune: „răspunsul la schimbare în urma unui plan.”Agile este condus de schimbare și, cel mai probabil, aceste schimbări vor fi conduse de clienți. Acest lucru duce la un concept numit Agile Release Planning.
planificarea lansării este diferită de planificarea tradițională, unde planul complet este considerat în avans, elaborat în detaliu și poate fi modificat numai cu cereri formale de schimbare. Un plan de lansare poate fi actualizat de mai multe ori pe baza feedback-ului din iterațiile anterioare.
deoarece ciclurile de viață adaptive sunt incrementale în natură, organizațiile pot elibera la sfârșitul fiecărei iterații. De asemenea, pot alege să elibereze după câteva iterații sau chiar continuu. Acest lucru necesită o planificare pe termen lung, dar poate fi facilitat în mod eficient prin utilizarea tehnicii de planificare a lansării, care a fost recent introdusă în ediția a 6-a a Ghidului PMBOK.
pentru profesioniștii aspiranți în managementul proiectelor (PMP) și Asociații certificați în managementul proiectelor (CAPM) , planificarea lansării Agile este un concept cheie de știut. Ghidul PMBOK ediția a 6-A a introdus considerații Agile pentru fiecare domeniu de cunoaștere. Acest lucru este util și pentru aspiranții la Agile Certified Practitioners (ACP).
pe măsură ce intrăm mai mult în acest sens, să vedem mai întâi cum sunt dezvoltate planurile de lansare la un nivel înalt.
de la viziune la foaie de parcurs pentru a lansa planuri
în proiectele Agile, munca începe cu o viziune a produsului. Viziunea se traduce apoi într-o foaie de parcurs a produsului. Foaia de parcurs conține caracteristicile care urmează să fie dezvoltate pe o perioadă de timp. De asemenea, puteți spune că o foaie de parcurs reprezintă domeniul de aplicare al produsului, care este livrat în diferite versiuni. Acest lucru duce la planurile de lansare și este prezentat în figura de mai jos.
foaie de parcurs și produs restante
o componentă în secvența de mai sus este foaie de parcurs produs, și pentru a înțelege foaie de parcurs produs, în primul rând trebuie să înțelegem restante produs. În abordările Agile, toate cerințele – atât cerințele proiectului, cât și cerințele produsului – fac parte din Product backlog (PB). Fiecare element din product backlog se numește element product backlog (sau PBI). În afară de caracteristici (cerințe), un element din lista de produse poate fi o cerere de modificare, defect, eroare, problemă sau chiar o lucrare tehnică specifică.
după cum știm, în proiectele Agile, cerințele sunt în continuă evoluție și există incertitudini/riscuri semnificative. Ca urmare, de obicei, prioritizăm PBI-urile. PBI-urile prioritare sunt preluate din partea de sus a restanțelor și livrate clientului(clienților). Elementele cu prioritate ridicată rămân în partea de sus a restanțelor și sunt cu granulație fină, în timp ce elementele cu prioritate scăzută se află în partea de jos a restanțelor și cu granulație grosieră. Prioritizarea elementelor din PB determină nivelul de detaliu pentru acel element din jurnalul de produse. Acest lucru este descris în figura de mai jos.
dacă utilizați instrumente Agile, cum ar fi Microsoft Project, puteți dezvolta rapid backlog-ul produsului. Un exemplu de produs backlog, desenat cu MS Project, este prezentat mai jos.
aici, avem un Product backlog care arată elementele product backlog (PBI) din „creați un utilizator nou”, „Conectați-vă la sistemul de tranzacționare online”, „transferați un stoc” etc. Dacă doriți să adăugați orice alt element de întârziere, trebuie doar să faceți clic pe pictograma „+” din caseta de comandă „sarcină nouă”.
elementele de nivel superior din jurnalul de produse pot fi scrise în povești de utilizator, care sunt estimate în puncte de poveste-o măsură relativă fără unitate.
acum, venind la foaia de parcurs a produsului, puteți spune pur și simplu că este o întârziere a produsului cu o cronologie. O foaie de parcurs descrie viitorul planificat al proiectului (adică lansări de produse planificate și/sau propuse) sau teme de lansare, enumerând funcționalitățile la nivel înalt ale produsului. Foaia de parcurs spune ce caracteristici sau epopee (o epopee, pur și simplu vorbind, este o poveste mare de utilizator) vor fi livrate în fiecare versiune.
planul de lansare
foaia de parcurs a produsului conduce planurile de lansare. Un plan de lansare oferă programul de lansare – fiecare lansare fiind de obicei de trei până la șase luni. O versiune conține multe iterații-de la iterația 0 (iterația zero) la iterația N. iterația 0 poate fi utilizată pentru aprobările proiectului, configurarea mediului pentru proiect, prezentarea generală inițială și discuțiile de proiectare etc. Unii practicieni agili folosesc iterația – H (iterația de întărire), care este iterația finală la sfârșitul lansării pentru a se pregăti pentru livrare. Această iterație poate include elemente de lucru finale, cum ar fi materiale de instruire și marketing, note de lansare finale, ghiduri de instalare, ghiduri de sistem/utilizator etc. Acest lucru este descris mai jos.
după cum se arată, planul de lansare are iterații – de la „iterație – 0” la „iterație – N.” puteți decide să aveți o versiune după câteva iterații și/sau o versiune finală după ultima iterație.
planul de lansare prezintă o foaie de parcurs a modului în care echipa intenționează să realizeze viziunea proiectului în cadrul obiectivelor și constrângerilor proiectului. Ajută proprietarul produsului și întreaga echipă să decidă cât de mult trebuie dezvoltat și cât timp va dura înainte de a avea un produs eliberabil. Acesta transmite așteptări cu privire la ceea ce este probabil să fie dezvoltat și în ce interval de timp. Planul de lansare poate servi, de asemenea, ca un ghid către care echipa poate progresa. Planul de lansare poate fi actualizat la sfârșitul unei iterații și reflectă așteptările actuale care vor fi incluse, astfel încât acestea să poată fi livrate în iterații ulterioare.
planificarea lansării cu Product Backlog
pentru a înțelege mai bine planificarea lansării, puteți vizualiza planurile de lansare cu ajutorul Product backlog.
știm deja că articolele din product backlog sunt clasate sau ordonate, în funcție de prioritatea lor. Elementele de nivel superior, care sunt cu granulație fină, va fi gata pentru consum în următoarea iterație (sub următoarea versiune imediată). Restanțele prioritare, cu caracteristici și alte elemente, sunt afișate în partea stângă a figurii de mai jos.
 |
 |
în cadrul MS Project, trebuie pur și simplu să selectați, să trageți și să fixați elementele restante și să le aranjați conform nevoii dvs. de a le acorda prioritate. Acest lucru este prezentat în partea dreaptă a figurii de mai sus. Având în vedere exemplul anterior care arată product backlog în cadrul MS Project, avem acest clasament relativ: mai întâi” conectați-vă la sistemul de tranzacționare online”, apoi” creați un utilizator nou”, apoi” cumpărați un stoc ” etc.
după cum se arată mai sus, am selectat și am tras elementul de caracteristică „Conectați-vă la sistemul de tranzacționare online” și l-am aruncat înainte de elementul de caracteristică anterior „creați un utilizator nou.”Elementul selectat a fost ușor gri în timp ce l-am târât și l-am scăpat.
folosind backlog, puteți decide care dintre elementele backlog ar trebui livrate în următoarele versiuni. Mai jos, vedem că elementele din următoarea versiune (adică versiunea 1) sunt în mare parte prioritizate. Elementele pentru versiunea 2 pot fi, de asemenea, prioritizate, dar vedem că elementele pentru versiunea 3 nu sunt prioritizate, deoarece sunt elemente cu prioritate redusă.
puteți vizualiza această planificare de lansare cu MS Project, de asemenea. Uită-te la figura de mai jos. Există PBI-uri dovedit a fi luate în diferite versiuni. Amintiți-vă o versiune conține iterații? În cazul nostru, pentru prima versiune, avem trei iterații și se așteaptă ca toate articolele să fie livrate în aceste iterații. O iterație se numește sprint în cadrul Scrum, care este un cadru popular folosit de Agile PMs. Pentru următoarele două versiuni (adică versiunea 2 și versiunea 3), Avem PBI-urile, dar nu am decis încă iterațiile (sau sprinturile).
planificarea iterației
dacă ați urmat, planul de lansare constă din iterația 0 până la iterația N și putem decide să lansăm la sfârșitul fiecărei iterații sau a fiecărei iterații. Dar, ce se întâmplă în cadrul unei iterații? Pur și simplu vorbind, domeniul de aplicare pentru un set de caracteristici din cadrul iterației este confirmat la începutul iterației și livrat la sfârșitul iterației.
caracteristicile care sunt confirmate și luate pentru iterație sunt defalcate pe sarcini (sau activități) și estimate în ore de către membrii echipei. Secvența pașilor de la foaia de parcurs a produsului la planul de lansare la planul de iterație este prezentată în diagrama de mai jos.
rezumând figura de mai sus, acestea vor fi punctele cheie:
- vision drives produs foaie de parcurs
- foaie de parcurs produs unități planuri de lansare
- un plan de lansare va avea iterații
- caracteristici, care sunt estimate în puncte de poveste, sunt dezvoltate într-o iterație
- caracteristici sunt defalcate pe sarcini, care sunt estimate în ore
folosind MS Project 2016, puteți construi rapid un plan de lansare. Având în vedere exemplul nostru anterior de backlog, avem trei iterații/sprinturi pentru prima versiune (adică Sprint 1, Sprint 2 și Sprint 3). Fiecare sprint are un set de caracteristici care trebuie livrate. Acest lucru este prezentat în vizualizarea „sprint Planning Board” de mai jos.
de asemenea, puteți detalia pentru a vedea ce se întâmplă la nivelul iterației/sprintului și pentru a afla la ce PBI se lucrează. MS Project arată acest lucru în vizualizarea „Current Sprint Board”. Vezi figura de mai jos.
pentru Sprint 1, avem trei articole de livrat – „Conectați-vă la sistemul de tranzacționare online”, „Creați un utilizator nou” și „cumpărați un stoc.”Acestea trec prin trei stări de flux de lucru ale „Next Up”, „In Progress” și „Done.”Desigur, puteți adăuga, elimina sau personaliza aceste stări de flux de lucru conform nevoilor dvs.
planul de lansare Vs. planul de iterație
dacă susțineți examenul, trebuie să cunoașteți și diferențele dintre planul de lansare și planul de iterație. Acestea sunt notate în tabelul de mai jos. De obicei, iterațiile sunt timeboxed timp de două până la patru săptămâni. Cu toate acestea, în unele cazuri, cum ar fi XP (un alt cadru agil), iterațiile pot dura o săptămână.
Project Management Body Of Knowledge (PMBOK) Guide, ediția a 6-A, by Project Management Institute (PMI)
I Want To Be a PMP: the Plain and Simple Way To Be a PMP, ediția a 2-A, by Satya Narayan Dash
I Want To Be a ACP: the Plain and Simple Way To Be a ACP, by Satya Narayan Dash
Microsoft Project 2016 Live Lessons, by Satya Narayan Dash
Agile Practice Guide, by Project Management Institute (PMI)