Come definire e creare un Release Planning in un progetto

Come definire e creare un Release Planning in un progetto

Release Planning

Il suggerimento della letteratura Agile per ottimizzare la consegna di valore e la realizzazione dei benefici utilizzando le metodologie Agile è quello di redigere un Release Plan (o piano di rilasci).

La fase di release planning vede il team (di solito in collaborazione con il Product Owner) preparare una pianificazione di alto livello del progetto identificando il numero degli Sprint (ad esempio da tre a dodici) e le date delle principali milestone (ad esempio le date previste per il rilascio di un batch di deliverable che identificano quando sarà formalmente accettato e rilasciato, in modo che inizi a generare benefici per l’impresa). Inoltre, serve come base per monitorare il progresso del progetto ed è una linea guida che riflette le aspettative a riguardo di quali feature saranno implementate una volta completate. Da notare, che i rilasci potrebbero avvenire man mano durante il progetto o in un’unica consegna finale.

Come definire e creare un Release Planning in un progetto

La letteratura riporta i passaggi fondamentali da seguire per adottare un approccio di realizzazione dei benefici durante la fase di release planning di un progetto Agile:

  1. Priorizzare la lista dei deliverable (Project Backlog): come primo step, lo sponsor di progetto (Product Owner) deve ordinare la lista delle attività da svolgere secondo un ordine che rifletta le priorità di business. Successivamente, il team può proporre modifiche all’ordinamento della lista delle attività sulla base di dipendenze strette o logiche e può suggerire raggruppamenti efficienti di attività al fine di incrementare la produttività. Tuttavia, l’ultima parola sul Product Backlog spetta al Product Owner, che può
    accogliere o meno i suggerimenti in base agli impatti che questi avrebbero sugli obiettivi di business;
  2. Stimare i deliverable: il team deve stimare la durata dei deliverable sia secondo gli Story Point delle User Story sia secondo giorni ideali. La letteratura sulla metodologia Agile ritiene che la stima realizzata utilizzando gli Story Point sia più veloce e non richieda un’analisi dettagliata di ogni elemento del backlog, a differenza della stima in giorni ideali;
  3. Scegliere la lunghezza appropriata delle iterazioni;
  4. Stimare la produttività del team: in Agile, la metrica della produttività è chiamata velocity17 e, di solito, si fa riferimento alla velocity media e mai alla velocity di una singola iterazione;
  5. Assegnare i deliverable alle iterazioni: l’assegnazione deve essere fatta sulla base delle stime per ogni deliverable e della velocity del team, facendo aggiustamenti alla priorizzazione per ottimizzare le iterazioni, se necessario. In questa fase bisogna assicurarsi che il totale delle stime per i deliverable in ogni iterazione non ecceda la velocity prevista;
  6. Assegnare delle date alle iterazioni;
  7. Fare aggiustamenti dovuti a vincoli di tempi e budget: questo significa che se non ci si può permettere il numero di iterazioni indicate è necessario rimuoverne alcune dal piano;
  8. Fare aggiustamenti della velocity prevista per le iterazioni laddove ci si aspetta periodi di bassa produttività dovuti a attività di avvio, vacanze, ecc.;
  9. Indicare le principali business milestone e dipendenze inter-progetti collaborando con lo sponsor;
  10. Adeguare l’assegnazione dei deliverable alle iterazioni collaborando con il team, per tenere conto di dipendenze rigide o logiche, delle milestone, di dipendenze inter-progetto e della disponibilità delle risorse. Secondo la letteratura, a questo punto la schedulazione del progetto dovrebbe essere ottimizzata a seconda di eventuali vincoli di business. Il Release Plan cerca di fornire il valore ottimale per il progetto entro i limiti di tempo e budget. Tuttavia, come anticipato prima, talvolta è necessario sub-ottimizzare un progetto per dare maggior supporto ad un altro più importante per l’impresa. Sarà, quindi, opportuno apportare delle modifiche al Release Plan. Questo aggiunge due ulteriori step al processo:
  11. Incontrarsi con il Product Owner e con ogni altra parte interessata per correggere l’assegnazione dei deliverable alle iterazioni per ottimizzare i benefici dell’impresa: le parti interessate possono includere project manager o Product Owner di altri progetti e altri stakeholder come gli utilizzatori finali. Scopo di questo incontro è quello di negoziare un accordo sul piano del progetto in modo da ottimizzare il valore per l’impresa e supportare la strategia aziendale;
  12. Rivedere il piano corretto (adjusted plan) per assicurarsi che siano rispettati le dipendenze, la disponibilità di risorse e i limiti di velocity.

Il risultato, secondo Aguanno, è un piano che si concentra sulla consegna dei benefici per l’impresa, andando oltre ciò che ci si sarebbe aspettati dal singolo progetto. Mettere insieme un ampio gruppo di stakeholder aiuta a identificare tutti gli interessi in competizione e assicura che tutti siano presi in considerazione.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *