Stabilire iterazioni e piani di rilascio

Le metodologie agile e altre iterative si basano sui concetti delle iterazioni e delle versioni. Questo articolo descrive l'assegnazione di iterazioni e versioni durante la pianificazione. Queste assegnazioni determinano la visibilità della sequenza temporale per semplificare le conversazioni tra i membri del team di strategia del cloud. Le assegnazioni allineano anche le attività tecniche in modo che il team di adozione del cloud possa gestire durante l'implementazione.

Stabilire iterazioni

In un approccio iterativo all'implementazione tecnica, si pianificano le attività tecniche relative ai blocchi temporali ricorrenti. Le iterazioni tendono a essere blocchi di tempo da una settimana a sei settimane. Il consenso suggerisce che due settimane è la durata media dell'iterazione per la maggior parte dei team di adozione del cloud. Ma la scelta della durata dell'iterazione dipende dal tipo di lavoro tecnico, dal sovraccarico amministrativo e dalla preferenza del team.

Per iniziare ad allineare gli sforzi a una sequenza temporale, è consigliabile definire un set di iterazioni che durano da 6 a 12 mesi.

Comprendere la velocità

L'allineamento delle attività alle iterazioni e alle versioni richiede una comprensione della velocità. La velocità è la quantità di lavoro che può essere completata in qualsiasi iterazione specificata. Durante la pianificazione anticipata, la velocità è una stima. Dopo diverse iterazioni, la velocità diventa un indicatore estremamente prezioso degli impegni che il team può fare in modo sicuro.

È possibile misurare la velocità in termini astratti come i punti di storia. È anche possibile misurarla in termini più tangibili, ad esempio ore. Per la maggior parte dei framework iterativi, è consigliabile usare misurazioni astratte per evitare problemi di precisione e percezione. Gli esempi in questo articolo rappresentano la velocità in ore per sprint. Questa rappresentazione rende l'argomento più comprensibile universalmente.

Esempio: Un team di adozione del cloud di cinque persone si è impegnato in sprint di due settimane. Considerati gli attuali obblighi come riunioni e supporto di altri processi, ogni membro del team può contribuire in modo coerente a 20 ore alla settimana allo sforzo di adozione. Per questo team, la stima della velocità iniziale è di 100 ore per sprint.

Pianificazione dell'iterazione

Inizialmente, si pianificano le iterazioni valutando le attività tecniche in base al backlog prioritizzato. I team di adozione del cloud stimano lo sforzo necessario per completare varie attività. Tali attività vengono quindi assegnate alla prima iterazione disponibile.

Durante la pianificazione dell'iterazione, i team di adozione del cloud convalidano e affinano le stime. Lo fanno fino a quando non hanno allineato tutta la velocità disponibile a attività specifiche. Questo processo continua per ogni carico di lavoro con priorità fino a quando tutte le attività non sono allineate a un'iterazione prevista.

In questo processo, il team convalida le attività assegnate allo sprint successivo. Il team aggiorna le stime in base alla conversazione del team su ogni attività. Il team aggiunge quindi ogni attività stimata allo sprint successivo fino a quando non viene raggiunta la velocità disponibile. Infine, il team stima attività aggiuntive e le aggiunge all'iterazione successiva. Il team esegue questi passaggi fino a quando non viene esaurita anche la velocità di tale iterazione.

Il processo precedente continua fino a quando tutte le attività non vengono assegnate a un'iterazione.

Esempio: Si baserà ora sull'esempio precedente. Si supponga che ogni migrazione del carico di lavoro richieda 40 attività. Si supponga inoltre di stimare che ogni attività richieda in media un'ora. La stima combinata è di circa 40 ore per ogni migrazione del carico di lavoro. Se queste stime rimangono coerenti per tutti i 10 carichi di lavoro con priorità, questi carichi di lavoro richiederanno 400 ore.

La velocità definita nell'esempio precedente suggerisce che la migrazione dei primi 10 carichi di lavoro richiederà quattro iterazioni, ovvero due mesi di tempo di calendario. La prima iterazione sarà costituita da 100 attività che comportano la migrazione di due carichi di lavoro. Nell'iterazione successiva, una raccolta simile di 100 attività comporterà la migrazione di tre carichi di lavoro.

Avvertimento

I numeri precedenti di attività e stime vengono usati esclusivamente come esempio. Le attività tecniche sono raramente coerenti. Questo esempio non dovrebbe essere visualizzato come riflesso della quantità di tempo necessaria per eseguire la migrazione di un carico di lavoro.

Pianificazione delle release

All'interno dell'adozione del cloud, una versione viene definita come una raccolta di risultati finali che producono un valore aziendale sufficiente per giustificare il rischio di interruzione dei processi aziendali.

Il rilascio di eventuali modifiche correlate al carico di lavoro in un ambiente di produzione crea alcune modifiche ai processi aziendali. Idealmente, queste modifiche sono semplici e l'azienda vede il valore delle modifiche senza interruzioni significative del servizio. Ma il rischio di interruzione delle attività è presente con qualsiasi cambiamento e non dovrebbe essere preso alla leggera.

Per garantire che una modifica sia giustificata dal potenziale ritorno, il team di strategia del cloud deve partecipare alla pianificazione del rilascio. Una volta allineate le attività agli sprint, il team può determinare una sequenza temporale approssimativa di quando ogni carico di lavoro sarà pronto per il rilascio di produzione. Il team di strategia cloud valuterebbe il programma di ciascun rilascio. Il team identifica quindi il punto di inflessione tra il rischio e il valore aziendale.

Esempio: Continuando l'esempio precedente, il team di strategia del cloud ha esaminato il piano di iterazione. La revisione ha identificato due punti di rilascio. Durante la seconda iterazione, un totale di cinque carichi di lavoro sarà pronto per la migrazione. Questi cinque carichi di lavoro forniranno un valore aziendale significativo e attiveranno la prima versione. La versione successiva sarà disponibile in due iterazioni, quando i cinque carichi di lavoro successivi sono pronti per il rilascio.

Assegnare percorsi e tag di iterazione

Per i clienti che gestiscono i piani di adozione del cloud in Azure DevOps, i processi precedenti vengono riflessi assegnando un percorso di iterazione a ogni attività e storia utente. È anche consigliabile contrassegnare ogni carico di lavoro con una versione specifica. L'etichettatura e l'assegnazione alimentano il popolamento automatico dei report della cronologia.

Passaggi successivi

Stimare le tempistiche per comunicare correttamente le aspettative.

Stimare le tempistiche