Continuous Discovery in Scrum / Agile
Ho già scritto di come i team di prodotto agili o Scrum gestiscano in parallelo Product Discovery e Product Delivery. Ho anche scritto del fatto che i team nella Product Discovery a volte amano lavorare con il Timeboxing.
In questo articolo vorrei parlare della crescente tendenza verso la Continuous Delivery e la Continuous Discovery.
L'idea della Continuous Delivery (consegna continua) si sta diffondendo sempre di più. Molti team ne hanno parlato negli ultimi anni, ma ormai ci sono anche team che ci lavorano davvero.
Quasi tutti i team di prodotto oggi lavorano con build continui. Il principio alla base è che è meglio trovare i problemi che si presentano presto piuttosto che tardi. Pertanto, i build vengono normalmente avviati non appena vengono apportate modifiche.
Alcuni team di prodotto hanno portato questo principio a un livello completamente nuovo. Hanno imparato che i problemi di integrazione richiedono molto tempo e che, attraverso un'integrazione anticipata e frequente (invece di un'unica fase prima del testing), possono migliorare significativamente il loro throughput complessivo minimizzando il tempo in cui lavorano in isolamento.
Allo stesso modo, è meglio eseguire continuamente suite di test di regressione automatizzati per rilevare i nuovi problemi il prima possibile (riducendo notevolmente il numero di fonti di errore e il tempo per la risoluzione dei bug), piuttosto che testare tutto in una fase alla fine di un ciclo di release (anche di un ciclo di due settimane) e scoprire tutti i problemi in una volta sola.
La logica conseguenza è che alcuni team ora rilasciano regolarmente (noto come Continuous Deployment). Ciò significa che ogni modifica logica (o anche gruppo di modifiche) viene consegnata direttamente in piccoli "micro-release". Questo ha diversi grandi vantaggi. Il primo vantaggio è che questa è la strategia definitiva per i release incrementali e quindi il meccanismo principale per il Gentle Deployment – positivo per i nostri clienti e positivo per noi. Il secondo vantaggio è che la ricerca e la risoluzione di problemi in produzione è molto più facile quando si cambia sempre solo una o poche cose alla volta.
Tuttavia, tutto ciò che ho descritto finora riguarda la Product Delivery. Ma che dire della Product Discovery?
Sostengo già da tempo lo stesso principio quando si tratta di trovare Product Backlog Item. Invece di una "fase di Product Discovery" di diverse settimane, in cui si creano Product Backlog Item, si validano e poi si passano allo sviluppo, vorrei incoraggiare i team a una Product Discovery continua, in cui identifichiamo, validiamo e descriviamo permanentemente nuovi Product Backlog Item. Alcuni lavori di Discovery richiedono solo qualche ora, altri di più, ma è un processo permanente di generazione di idee, validazione e descrizione.
Nel Dual-Track Scrum, nel Discovery Track vengono generati continuamente Product Backlog Item e nel Delivery Track questi item vengono continuamente costruiti, testati e deployati.
Con riferimento alla tendenza della Continuous Discovery e Continuous Delivery, molti team trovano il processo Scrum un po' limitante e ritengono il modello Kanban più adatto in questo caso.
Anche se non tutti i team sono necessariamente passati a Kanban, ne ho visti molti che hanno adattato Scrum in direzione di Kanban proprio per questo motivo. L'adattamento più comune è che, invece di rilasciare dopo ogni Sprint di ad esempio due settimane, le feature e altre modifiche vengono rilasciate direttamente quando sono pronte – spesso si tratta di diversi micro-release a settimana. In questo caso i team utilizzano il Timeboxing di Scrum come possibilità per strutturare il proprio lavoro e promuovere Retrospettive regolari.
Fondamentalmente, la transizione verso Continuous Discovery e Continuous Delivery è davvero una buona cosa e molti dei migliori team che ho conosciuto ci lavorano; anche se qui, come ovunque, potrebbero essere necessari dei compromessi.
Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano.
