Framework per la gestione delle release di prodotto

Il controsenso nello sviluppo di una piattaforma IT a supporto del business: è rischioso lasciare i dettagli di implementazione per un secondo momento, eppure devono essere pensate e costruite in modo incrementale con un occhio attento al rilascio di valore. La soluzione è in un corretto Release Management.

Sviluppate un prodotto con N clienti (A, B e C nell'esempio).

Ogni X mesi (4 nell'esempio) rilasciate una major release, contenente evolutive (nuove funzioni o modifiche alle esistenti) e bug fix (non bloccanti e/o a bassa priorità).

Le emergency release sono rilasciate se e quando necessario, contenenti solo bug fix (bloccanti e/o ad alta priorità).

Ogni ciclo di release ha 4 fasi: raccolta delle change request e dei bug (tipicamente le change arrivano dal business e i bug dalle operations), analisi e pianificazione (decidere lo scope e il timing), sviluppo, test e preparazione del deployment.

I cicli si sovrappongono: in particolare la finestra di raccolta per una release si apre in parallelo allo sviluppo/test della release precedente.

Le change sono gestite dai processi di evolution management, i bug dai processi di incident management: i due set di processi sono diversi per persone coinvolte, tempi di gestione ecc.

Evolutive e incident approvate finiscono nella shopping list, da cui i processi di release management attingono per la pianificazione di ogni singola release.

Vediamo un possibile workflow per la gestione delle evolutive:

I clienti sottopongono le richieste che vengono valutate dal team di prodotto: se necessario vengono chiesti approfondimenti.

Per ogni richiesta vengono quindi preparati i requisiti funzionali che alimentano la shopping list delle richieste fatte, da cui il CAB sceglie le evolutive che saranno oggetto di analisi tecnica e stima dell’effort.

Viene quindi preparato un business case per ogni richiesta che alimentano la shopping list delle richieste approvate e stimate: da qui il CAB attinge per la pianificazione delle prossime release andando ad alimentare la shopping list delle evolutive pianificate.

Quindi il team di sviluppo sviluppa la release come da piano.

Da notare come il workflow non esclude la possibilità di rivedere lo scope di una release (sia essa in sviluppo o solamente pianificata) se arrivano richieste ad alta priorità.

Vediamo ora un possibile workflow per la gestione dei bug:

I clienti sottopongono gli indicent che vengono valutati dal team di prodotto (tipicamente dal service manager): se necessario vengono chiesti approfondimenti.

Dalla shopping list delle richieste fatte il team di prodotto sceglie (sulla base della priorità) gli incident che saranno oggetto di analisi tecnica e stima dell’effort: notare come in caso di bug il CAB viene coinvolto solo de dalla analisi risulta che la fix richiede una evolutiva funzionale.

Se esiste un workaround temporaneo, viene notificato al cliente.

Dalla shopping list delle richieste approvate e stimate il team di prodotto attinge per la pianificazione delle prossime release (potrebbe essere richiesta una emergency altrimenti la fix viene inserita o nella release attualmente in sviluppo o in una futura).

Dalla shopping list degli incident pianificati il team di sviluppo sceglie quindi le fix da implementare nella release concordata.

È chiaro come per i bug, a differenza delle evolutive, il processo sia più snello.

Alcune considerazioni sull'evoluzione del numero di bug con l’evolvere delle release di prodotto.

La seguente figura mostra, per una specifica release di prodotto, il trend dei bug individuati in funzione del tempo a partire dal rilascio:

All’inizio il numero di bug è dovuto alle nuove funzionalità e alle regressioni.

Con il fix dei bug la curva cala rapidamente ma all'improvviso si impenna: gli utenti raggiungono un grado di familiarità tale del prodotto da mettere sotto pressione tutte le funzionalità, stanando i bug più subdoli.

La seguente figura mostra invece come, per ogni nuova release di prodotto, il numero di moduli cresce linearmente mentre il numero di moduli affetti da bug cresce esponenzialmente:

Questo accade perché ogni fix impatta l’architettura originale e aumenta l’entropia, per un motivo (brutta pratica, direi) molto semplice: si cerca di risolvere il difetto localmente e con il minimo sforzo, senza valutare gli effetti collaterali sul resto del prodotto.

Spesso poi il team di manutenzione è diverso da quello di sviluppo.

Invece di risolvere gli errori originali nella progettazione, si continua a risolvere problemi localmente.

L’entropia aumenta, debiti tecnici vengono introdotti, il bug fixing diventa sempre meno efficace, fino al punto in cui un passo avanti costringe a due passi indietro.

È tempo di una re-ingegnerizzazione del prodotto.

O forse di un prodotto nuovo.