Parafrasando un concetto ben noto nella gestione del progetto, si potrebbe dire: “La pianificazione è indispensabile, ma i piani sono inutili. Quindi, ispezionare e adattare.”
I piani tradizionali sono guidati da date-molto probabilmente con una data di fine che è il fattore trainante principale. Nella gestione tradizionale del progetto, raccogli i requisiti dai tuoi stakeholder, costruisci l’ambito del progetto e suddividi il progetto in pezzi di lavoro gestibili. Questo, a sua volta, crea una struttura di ripartizione del lavoro (WBS). Successivamente, il livello più basso di WBS, cioè i pacchetti di lavoro, vengono ulteriormente scomposti in attività. Le attività vengono quindi collegate alle dipendenze e le risorse vengono stimate e applicate alle attività per creare una pianificazione end-to-end per il progetto. Questo programma viene quindi monitorato e controllato con l’aiuto di un piano di gestione del programma, che di solito è un piano sussidiario del piano di gestione del progetto consolidato.
Ma quante volte è successo che ciò che hai pianificato e ciò che è realmente accaduto sul terreno, corrispondessero? Conosci già la risposta! La citazione di apertura significa che la pianificazione è essenziale, ma aspettarsi che possiamo seguire esattamente il piano non è una cosa saggia da fare. Quando ci sono alti zangoli nei requisiti e un’elevata incertezza nella tecnologia o nella piattaforma, i PMS di solito vanno con cicli di vita adattivi (o agili).
Infatti, il quarto valore del Manifesto Agile dice: “Rispondere al cambiamento seguendo un piano.”Agile è guidato dal cambiamento e, molto probabilmente, questi cambiamenti saranno guidati dai clienti. Questo porta a un concetto chiamato Agile Release Planning.
La pianificazione del rilascio è diversa dalla pianificazione tradizionale, in cui il piano completo è considerato in anticipo, elaborato in dettaglio e può essere modificato solo con richieste di modifica formali. Un piano di rilascio può essere aggiornato molte volte in base al feedback delle iterazioni precedenti.
Poiché i cicli di vita adattivi sono di natura incrementale, le organizzazioni possono rilasciare alla fine di ogni iterazione. Possono anche scegliere di rilasciare dopo alcune iterazioni o anche continuamente. Ciò richiede una pianificazione a lungo termine, ma può essere efficacemente facilitata utilizzando la tecnica di pianificazione del rilascio, che è stata recentemente introdotta nella 6a edizione della Guida PMBOK.
Per gli aspiranti professionisti del Project Management (PMP) e gli associati certificati in Project Management (CAPM) , la pianificazione del rilascio agile è un concetto chiave da conoscere. La Guida PMBOK 6th edition ha introdotto considerazioni agili per ogni area della conoscenza. Questo è utile anche per gli aspiranti Agili Certified Practitioners (ACP).
Mentre entriamo in questo più, vediamo prima come i piani di rilascio sono sviluppati ad un livello elevato.
Dalla visione alla roadmap per rilasciare i piani
Nei progetti Agile, il lavoro inizia con una visione del prodotto. La visione si traduce quindi in una roadmap di prodotto. La tabella di marcia contiene le caratteristiche da sviluppare in un periodo di tempo. Si può anche dire che una roadmap rappresenta l’ambito del prodotto, che viene consegnato in varie versioni. Questo porta ai piani di rilascio ed è mostrato nella figura seguente.
Roadmap e Product Backlog
Un componente nella sequenza di cui sopra è roadmap di prodotto, e per capire roadmap di prodotto, in primo luogo abbiamo bisogno di capire product backlog. Negli approcci Agili, tutti i requisiti-sia i requisiti di progetto che i requisiti di prodotto-fanno parte del product backlog (PB). Ogni articolo nel product backlog è chiamato product backlog item (o PBI). Oltre alle caratteristiche (requisiti), un elemento del product backlog può essere una richiesta di modifica, un difetto, un bug, un problema o anche un lavoro tecnico specifico.
Come sappiamo, nei progetti Agili, i requisiti sono in continua evoluzione e ci sono notevoli incertezze/rischi. Di conseguenza, di solito diamo la priorità ai PBI. I PBI con priorità vengono prelevati dalla parte superiore del backlog e consegnati ai clienti. Gli elementi ad alta priorità rimangono in cima al backlog e sono a grana fine, mentre gli elementi a bassa priorità sono in fondo al backlog e a grana grossa. La priorità degli articoli nel PB determina il livello di dettaglio per tale articolo nel product backlog. Questo è raffigurato nella figura sottostante.
Se si utilizzano strumenti Agili come Microsoft Project, è possibile sviluppare rapidamente il product backlog. Un esempio di product backlog, disegnato con MS Project, è mostrato di seguito.
Qui, abbiamo un product backlog che mostra gli elementi del product backlog (PBI) di “Crea un nuovo utente”, “Accedi al sistema di trading online”, “Trasferisci uno stock”, ecc. Se si desidera aggiungere qualsiasi altro elemento backlog, è sufficiente fare clic sull’icona ” + “della casella di comando” Nuova attività”.
Gli elementi di primo livello nel product backlog possono essere scritti in storie utente, che sono stimati in punti storia, una misura relativa senza unità.
Ora, venendo alla roadmap del prodotto, puoi semplicemente dire che è un product backlog con una timeline. Una tabella di marcia descrive il futuro pianificato del progetto (cioè le versioni di prodotto pianificate e/o proposte) o i temi di rilascio, elencando le funzionalità di alto livello del prodotto. La roadmap indica quali caratteristiche o epopee (un’epopea, semplicemente parlando, è una grande storia utente) verranno consegnate in ogni versione.
Piano di rilascio
La roadmap del prodotto guida i piani di rilascio. Un piano di rilascio fornisce il programma di rilascio-ogni rilascio in genere da tre a sei mesi. Una versione contiene molte iterazioni, dall’iterazione 0 (iterazione zero) all’iterazione N. L’iterazione 0 può essere utilizzata per le approvazioni del progetto, l’impostazione dell’ambiente per il progetto, la panoramica iniziale e le discussioni di progettazione, ecc. Alcuni professionisti Agili utilizzano Iteration-H (hardening iteration), che è l’iterazione finale alla fine del rilascio per prepararsi alla consegna. Questa iterazione può includere elementi di lavoro finali come materiali di formazione e marketing, note di rilascio finali,guide di installazione, guide di sistema / utente, ecc. Questo è raffigurato di seguito.
Come mostrato, il piano di rilascio ha iterazioni-da ” Iterazione-0 “a” Iterazione – N. ” Puoi decidere di avere una versione dopo alcune iterazioni e/o una versione finale dopo l’ultima iterazione.
Il piano di rilascio presenta una roadmap di come il team intende raggiungere la visione del progetto nell’ambito degli obiettivi e dei vincoli del progetto. Aiuta il proprietario del prodotto e l’intero team a decidere quanto deve essere sviluppato e quanto tempo ci vorrà prima di avere un prodotto rilasciabile. Trasmette aspettative su ciò che è probabile che venga sviluppato e in quale lasso di tempo. Il piano di rilascio può anche servire da guida verso il quale il team può progredire. Il piano di rilascio può essere aggiornato alla fine di un’iterazione e riflette le aspettative correnti che verranno incluse, in modo che possano essere consegnate nelle iterazioni successive.
Pianificazione del rilascio con Product Backlog
Per avere una migliore comprensione della pianificazione del rilascio, è possibile visualizzare i piani di rilascio con l’aiuto di product backlog.
Sappiamo già che gli articoli nel product backlog sono ordinati o ordinati, in base alla loro priorità. Gli elementi di primo livello che sono a grana fine, saranno pronti per il consumo nella prossima iterazione (sotto l’immediata prossima release). Il backlog con priorità, con caratteristiche e altri elementi, è mostrato sul lato sinistro della figura sottostante.
 |
 |
All’interno di MS Project, è sufficiente selezionare, trascinare e rilasciare gli elementi backlog e disporli secondo il vostro bisogno di dare loro la priorità. Questo è mostrato sul lato destro della figura sopra. Considerando l’esempio precedente che mostra il product backlog all’interno di MS Project, abbiamo questa classifica relativa: prima “Accedi al sistema di trading online”, quindi” Crea un nuovo utente”, quindi” Acquista un titolo”, ecc.
Come mostrato sopra, ho selezionato e trascinato l’elemento di funzionalità “Accedi al sistema di trading online” e l’ho lasciato cadere prima dell’elemento di funzionalità precedente “Crea un nuovo utente.”L’elemento selezionato è stato leggermente disattivato mentre l’ho trascinato e lasciato cadere.
Utilizzando il backlog, è possibile decidere quali degli elementi del backlog devono essere consegnati nelle prossime versioni. Di seguito, vediamo che gli elementi nella prossima release (cioè Release 1) sono per lo più prioritari. Anche gli elementi per la Release 2 potrebbero avere la priorità, ma vediamo che gli elementi per la Release 3 non hanno la priorità in quanto sono elementi a bassa priorità.
È possibile visualizzare questa pianificazione del rilascio anche con MS Project. Guarda la figura qui sotto. Ci sono PBI dimostrato di essere preso in varie versioni. Ricorda che una versione contiene iterazioni? Nel nostro caso, per la prima versione, abbiamo tre iterazioni e tutti gli elementi dovrebbero essere consegnati in queste iterazioni. Un’iterazione è chiamata sprint nel framework Scrum, che è un framework popolare utilizzato da Agile PMs. Per le prossime due versioni (cioè Release 2 e Release 3), abbiamo i PBI, ma non abbiamo ancora deciso le iterazioni (o sprint).
Iteration Planning
Se hai seguito, il piano di rilascio consiste nell’iterazione da 0 a Iterazione N e possiamo decidere di rilasciare alla fine di ogni poche iterazioni o ogni iterazione. Ma cosa succede all’interno di un’iterazione? Semplicemente parlando, l’ambito di un insieme di funzionalità all’interno dell’iterazione è confermato all’inizio dell’iterazione e consegnato alla fine dell’iterazione.
Le funzionalità confermate e prese per l’iterazione sono suddivise in attività (o attività) e stimate in ore dai membri del team. La sequenza di passaggi dalla roadmap del prodotto al piano di rilascio al piano di iterazione è mostrata nello schema seguente.
Riassumendo la figura sopra, questi saranno i punti chiave:
- Il prodotto e la visione di unità roadmap di prodotto
- roadmap di Prodotto unità ai piani di rilascio di
- Un piano di rilascio avrà iterazioni
- Caratteristiche, che sono stimati in storia punti, sono sviluppate in un’iterazione
- Caratteristiche sono suddivisi i compiti, che sono stimati in ore
Utilizzo di MS Project 2016, si può costruire un piano di rilascio rapido. Considerando il nostro precedente esempio di backlog, abbiamo tre iterazioni / sprint per la prima versione (cioè Sprint 1, Sprint 2 e Sprint 3). Ogni sprint ha una serie di caratteristiche da consegnare. Questo è mostrato di seguito nella vista” Sprint Planning Board”.
Puoi anche eseguire il drill-down per vedere cosa succede a livello di iterazione / sprint e scoprire su quali PBI si sta lavorando. MS Project mostra questo nella vista “Current Sprint Board”. Vedi la figura qui sotto.
Per Sprint 1, abbiamo tre elementi da consegnare: “Accedi al sistema di trading online”, “Crea un nuovo utente” e ” Acquista uno stock.”Questi stanno passando attraverso tre stati del flusso di lavoro di “Next Up”, “In Progress” e ” Done.”Naturalmente, puoi aggiungere, rimuovere o personalizzare questi stati del flusso di lavoro secondo le tue necessità.
Piano di rilascio vs. Piano di iterazione
Se stai sostenendo l’esame, devi anche conoscere le differenze tra Piano di rilascio e Piano di iterazione. Sono annotati nella tabella seguente. In genere, le iterazioni sono timeboxed per due o quattro settimane. Tuttavia, in alcuni casi, come XP (un altro framework Agile), le iterazioni possono durare una settimana.
Project Management Body of Knowledge (PMBOK) Guida, 6a Edizione, dal Project Management Institute (PMI)
Voglio Essere UN PMP: Il puro e Semplice Modo Per Essere UN PMP, 2 ° edizione, da Satya Narayan Dash
Voglio Essere Un ACP: Il puro e Semplice Modo Per Essere Un ACP, da Satya Narayan Dash
Microsoft Project 2016 Lezioni dal Vivo, da Satya Narayan Dash
Agile Guida Pratica, dal Project Management Institute (PMI)