Stabilire iterazioni e piani di rilascio
Le metodologie Agile e altre metodologie iterative si basano sui concetti di iterazioni e rilasci. Questo articolo descrive l'assegnazione di iterazioni e rilasci durante la pianificazione. Queste assegnazioni guidano 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 gestirle durante l'implementazione.
Stabilire iterazioni
In un approccio iterativo all'implementazione tecnica, è possibile pianificare gli impegni tecnici in base a blocchi di tempo 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. La scelta della durata dell'iterazione dipende tuttavia dal tipo di impegno tecnico, dal sovraccarico amministrativo e dalle preferenze del team.
Per iniziare ad allineare gli impegni a una sequenza temporale, è consigliabile definire un set di iterazioni che durano da 6 a 12 mesi.
Comprendere la velocità
Per allineare gli impegni alle iterazioni e ai rilasci, è necessario conoscere la velocità. La velocità è la quantità di lavoro che può essere completata in una determinata iterazione. Durante la pianificazione iniziale, la velocità è una stima. Dopo diverse iterazioni, la velocità diventa un indicatore estremamente utile degli impegni che il team può assumere in modo sicuro.
È possibile misurare la velocità in termini astratti come i punti della storia. È anche possibile misurarla in termini più tangibili come le 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ù universalmente comprensibile.
Esempio: un team di adozione del cloud di cinque persone si è impegnato in sprint di due settimane. Dati gli obblighi attuali, come le riunioni e il supporto di altri processi, ogni membro del team può contribuire costantemente con 20 ore alla settimana al lavoro richiesto per l'adozione. Per questo team, la stima della velocità iniziale è di 100 ore per sprint.
Pianificazione dell'iterazione
Inizialmente, è possibile pianificare le iterazioni valutando le attività tecniche in base al backlog classificato in ordine di priorità. I team di adozione del cloud stimano il lavoro richiesto per completare varie attività. Tali attività vengono quindi assegnate alla prima iterazione disponibile.
Durante la pianificazione delle iterazioni, i team di adozione del cloud convalidano e perfezionano le stime. Lo fanno fino a quando non hanno allineato tutta la velocità disponibile ad attività specifiche. Questo processo continua per ogni carico di lavoro con priorità fino a quando tutti gli impegni non sono allineati 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 soddisfatta la velocità disponibile. Infine, il team stima le attività aggiuntive e le aggiunge all'iterazione successiva. Il team esegue questi passaggi fino a esaurire anche la velocità di tale iterazione.
Il processo precedente continua fino a quando tutte le attività non vengono assegnate a un'iterazione.
Esempio: Basarsi sull'esempio precedente. Si supponga che la migrazione di ogni carico di lavoro richieda 40 attività. Si supponga anche 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 e 10 i carichi di lavoro classificati in ordine di priorità, tali 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 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.
Avviso
I numeri precedenti di attività e stime vengono usati esclusivamente come esempio. Le attività tecniche sono raramente così coerenti. Questo esempio non deve essere visto come un riflesso della quantità di tempo necessaria per eseguire la migrazione di un carico di lavoro.
Pianificazione del rilascio
Nell'ambito dell'adozione del cloud, un rilascio è definito come una raccolta di risultati finali che producono un valore aziendale sufficiente a 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. Tuttavia, il rischio di interruzione dell'attività è presente con qualsiasi modifica e non deve essere preso alla leggera.
Per garantire che una modifica sia giustificata da un potenziale rendimento, 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 in produzione. Il team di strategia del cloud esaminerà la tempistica di ogni rilascio. Il team identificherà quindi il punto di flesso tra rischio e valore aziendale.
Esempio: continuando con 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 il prima rilascio. Il rilascio successivo avverrà due iterazioni dopo, quando i cinque carichi di lavoro successivi saranno 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 si riflettono assegnando un percorso di iterazione a ogni attività e storia utente. È anche consigliabile assegnare a ogni carico di lavoro un tag con un rilascio specifico. L'assegnazione di percorsi e tag generano il popolamento automatico dei report della sequenza temporale.
Passaggi successivi
Stimare le sequenze temporali per comunicare correttamente le aspettative.