Framework per la pianificazione del rilascio Agile
La pianificazione del rilascio agile richiede più di date su un calendario. Hai bisogno di un forte backlog di prodotti e di una visione condivisa del prodotto. In questa guida how-to forniamo una revisione completa del processo e framework utili per ottenere il lavoro fatto.
La mia manager, Celia, occasionalmente si fermava alla mia scrivania e chiedeva: “Quando hai intenzione di finire?”Dietro il suo contegno casuale stava davvero chiedendo,” Così Kevin, ti ho dato tre squadre Scrum per costruire questa applicazione. Quando avro ‘ i miei soldi da loro?
Un product manager alle prime armi potrebbe aver risposto: “Siamo agili. Rilasciamo quando siamo pronti.”Per fortuna, non ero un novizio e ho risposto a Celia”, sulla base dei dati degli ultimi Sprint — e di ciò che rimane nel Product Backlog — il mio piano di rilascio punta, con grande fiducia, al rilascio in sei settimane, con il potenziale di rilasciare presto in appena quattro settimane.”
La mia fiducia ha soddisfatto Celia ed è stata sostenuta da tutto il lavoro che ho fatto con i miei team per sviluppare e mantenere un solido piano di rilascio per il mio prodotto. Mentre nei miei primi anni come product manager la costruzione di un piano di rilascio è stato un compito arduo. Una volta che ho capito meglio la meccanica e i ritmi dei piani di rilascio, costruirli e mantenerli sono diventati molto più facili. Per quelli di voi che hanno una “Celia” nella tua vita (lo facciamo tutti), sappi che tutto il duro lavoro speso per costruire e mantenere un piano di rilascio è assolutamente valsa la pena.
Che cos’è un piano di rilascio?
Un piano di rilascio è una previsione di alto livello, in genere su più Sprint, che descrive come si intende fornire valore rilasciando il prodotto. Un piano di rilascio è uno strumento prezioso perché risponde a queste domande:
- Quali elementi del Product Backlog saranno affrontati in quale Sprint?
- Cosa c’è nella prossima versione?
- Quando hai finito?
I piani di rilascio sono tattiche di medio livello nell’orizzonte temporale della pianificazione agile che danno vita alle roadmap e aggiungono una preziosa dimensione temporale al Product Backlog. Un piano di rilascio coprirà più sprint e spesso include più team Scrum e / o team in più posizioni. Indipendentemente dall’ambito, la creazione di un piano di rilascio è una collaborazione tra product manager, Product Owner, ScrumMaster, team Scrum e stakeholder. In genere, mi piace usare un orizzonte temporale da due a quattro mesi per i piani di rilascio. I piani di rilascio che prevedono troppo in futuro includono troppa variabilità e rischio di pianificazione intrinseco. Più brevi sono i piani, più velocemente rilasci il valore e maggiore è la fiducia che avrai nelle tue date di rilascio.
Le versioni possono avere una cadenza fissa o un ambito fisso, ma non entrambe. Se l’ambito della release è fisso, il piano produrrà il numero previsto di Sprint necessari per consegnare gli elementi del Product Backlog pianificati per la release. In alternativa, se la data è fissa, il piano di rilascio indicherà cosa sarà probabilmente nella prossima versione a data fissa. La cosa buona è che gli ultimi elementi da consegnare nel rilascio — e più probabilità di essere tagliato, se necessario — dovrebbero essere gli elementi meno più importanti.
Inizia con la visione del prodotto& Backlog di prodotto
Per avere un buon piano di rilascio, è necessario un backlog di prodotto forte. Parte integrante di un forte Product Backlog è una visione di prodotto condivisa tra i product manager, i Product owner e i team Scrum. La visione del prodotto ti aiuterà a mantenere il quadro generale a fuoco mentre costruisci il tuo piano di rilascio e a dare la priorità alle cose che contano davvero per i tuoi clienti e l’azienda.
Ci sono due framework che uso per sviluppare e comunicare una visione del prodotto tra i team Scrum. Quale si sceglie di solito si basa sul fatto che i team Scrum siano co-localizzati o distribuiti. Per un team Scrum co-localizzato, Product Box è la scelta migliore. Se distribuito, mi piace usare il nostro modello Shark Tank Vision, influenzato da McKenna e Moore Elevator Pitch framework e mostrato di seguito.
Suggerimento: Oltre alla visione del prodotto, considerare lo sviluppo di una visione per la prossima release. Una visione di rilascio è particolarmente utile se la versione affronta un nuovo mercato, una nuova persona o un nuovo set di funzionalità.
Oltre a una visione del prodotto, il Product Backlog dovrebbe includere tre elementi critici per il piano di rilascio:
- Gli articoli sono ben raffinati (es., soddisfacendo i criteri di prontezza del team Scrum).
- Gli articoli sono dimensionati in modo appropriato a più piccoli di uno Sprint. Più piccolo è meglio.
- Gli articoli sono prioritari in base al valore.
Suggerimento: ci sono due framework altamente collaborativi che uso con clienti e stakeholder per dare la priorità al Product Backlog in base al valore: Potare l’albero del prodotto e la visione 20/20.
L’evento di pianificazione del rilascio Agile
Una volta stabilita la visione del prodotto, una visione del rilascio e un backlog di prodotto pronto, è necessario pianificare un evento di pianificazione del rilascio. Gli eventi di pianificazione del rilascio agile sono eventi collaborativi in cui sia i membri del team Scrum che le parti interessate si rimboccano le maniche e fanno scelte su cosa sviluppare come parte della prossima release. Di solito si verificano dopo lo sviluppo della tabella di marcia.
Un evento di pianificazione del rilascio può durare uno o più giorni. Poiché la pianificazione agile del rilascio può essere un grande investimento di tempo e persone, assicurati di ritagliarti abbastanza tempo per prepararti adeguatamente a questa attività. Questo tipo di pianificazione collaborativa è un duro lavoro, quindi pianifica di divertirti durante l’evento e ricorda di festeggiare quando è tutto finito!
Inoltre, indipendentemente dal fatto che tu stia pianificando con uno Scrum Team o dieci, la struttura di un buon evento di pianificazione del rilascio rimane la stessa:
-
- Condividi la visione per la prossima versione. Il product manager, Product Owner o Chief Product Owner ricorderà al team Scrum gli obiettivi del rilascio, condividerà la visione del rilascio e spiegherà in che modo questa versione progredisce verso la visione generale del prodotto.
- Decidi la data fissa o l’ambito fisso Entrambi gli approcci vanno bene, ma è importante decidere per la tua attività ciò che è più importante: rilasciando in una data specifica (la necessità di colpire un ritmo di mercato come una fiera) o con una serie di funzionalità (tutto incluso in un flusso di lavoro del cliente).
- Rivedere gli elementi principali nel backlog del prodotto e stabilire una linea di taglio. Una linea di taglio stabilisce quanto in profondità nel backlog di prodotto ci si aspetta di consegnare in questa versione.
- Mappa ogni Sprint. Quando si lavora con più team Scrum, ognuno estrae dal singolo Product Backlog il proprio elenco “locale” di elementi. Utilizzando i dati di velocità per ogni squadra Scrum, pianificare quali elementi saranno probabilmente consegnati in ogni Sprint.
- Cattura rischi e dipendenze. Trovare il tempo per evidenziare eventuali ipotesi significative, rischi e dipendenze che potrebbero avere un impatto sulla consegna del rilascio. La trasparenza è essenziale e sarà utile nel modo in cui comunichi la finestra di rilascio.
Rispondendo alla domanda ” Quando sarà fatto?”
Ora che hai fatto tutto il duro lavoro, è il momento di rispondere alla domanda di Celia stimando la finestra di rilascio. Una finestra di rilascio è un intervallo di possibili date di consegna basate su alcuni tipi di dati empirici.
Ci sono una moltitudine di motivi per cui vorresti offrire una finestra di rilascio invece di una data specifica. Le velocità cambiano nel tempo. Una finestra di rilascio illustra tale incertezza e riconosce che il piano è una previsione, non un impegno preciso. Man mano che fornisci valore a ogni Sprint, la finestra di rilascio si restringe man mano che le incognite diventano note e i rischi vengono mitigati o eliminati.
Per calcolare una finestra di rilascio, attenersi alla seguente procedura:
-
- Stimare un’alta velocità di “steady-state”. Questo stabilirà la prima data di consegna prevista.
- Rivalutare utilizzando una bassa velocità di “steady-state”. Questo stabilirà l’ultima data di consegna prevista.
- Calcola la finestra di rilascio. Questa è la differenza tra velocità elevate e basse allo stato stazionario.
- Aggiungere un buffer appropriato. Questa è una funzione dei vari rischi e dipendenze all’interno del tuo piano. Può essere espresso nel tempo o un fattore di fiducia. Raccomando un buffer commisurato ai rischi e alle dipendenze identificati. Ad esempio, se hai molti rischi e dipendenze, hai più buffer. Se ci sono meno rischi e dipendenze, utilizzare meno buffer.
Infine, fai un passo indietro e analizza il tuo piano di rilascio rispetto alla tua roadmap. Ricordiamo che una buona tabella di marcia includerà la considerazione delle finestre di mercato, dei ritmi o dei segmenti che stai cercando di indirizzare. In base alla tabella di marcia, potrebbe essere necessario regolare il Product Backlog di conseguenza per garantire che il rilascio si allinei con i vincoli o gli obiettivi della tabella di marcia.
Fare il passo successivo
Costruire quel primo piano di rilascio può essere un duro lavoro. Ma una volta nel ritmo di sviluppo e mantenimento del piano di rilascio del prodotto, lo troverai presto un artefatto inestimabile nella tua casella degli strumenti di gestione del prodotto. Se desideri saperne di più sullo sviluppo di un piano di rilascio per il tuo prodotto, contattaci per assistenza. Siamo felici di parlare con voi ulteriormente e consigliarvi su come integrare i piani di rilascio per il vostro business.