La suddivisione verticale articola una storia in base ai risultati per l’utente; la suddivisione orizzontale la articola in base ai livelli tecnici. Quella singola scelta determina se ogni sezione produca un risultato concreto o nulla. Le sezioni verticali producono valore. Le sezioni orizzontali producono promesse.

Il taglio orizzontale consiste nel dividere l’impasto proprio come si fa con un coltello: si ottengono due metà di nulla.

La differenza

La suddivisione orizzontale prevede una separazione per livelli architetturali: front-end in questo sprint, back-end in quello successivo, database nello sprint successivo ancora. Il lavoro si articola in sprint, ma nessun singolo sprint produce nulla di tangibile per gli utenti. I dati relativi alla velocità del team aumentano; il registro delle modifiche visibili agli utenti rimane vuoto.

Il “vertical slicing” prevede una suddivisione in base ai risultati per l’utente. Una sezione snella che tocca ogni livello: un singolo pulsante che funziona effettivamente dall’inizio alla fine, anche se gestisce un solo caso di input. Il team rilascia meno per ogni sezione, ma ciascuna sezione è un prodotto reale e pronto per il rilascio. Il registro delle modifiche si arricchisce, gli utenti vedono i progressi e il team può adeguare la rotta in base all’utilizzo effettivo piuttosto che a quello previsto.

A layered cake split horizontally versus the same cake split vertically Horizontal Vertical UI Logic Data → shipped nothing for users until all three land UI Logic Data slice 1 ships end-to-end, on its own sprint 1: nothing usable sprint 1: working slice
Le sezioni orizzontali vengono fornite un livello alla volta. Le sezioni verticali vengono fornite sotto forma di colonna operativa: una piccola parte di ogni livello, immediatamente utilizzabile.

Quando sembra necessario ricorrere alla suddivisione orizzontale

Di solito non è così. «Abbiamo bisogno dello schema del database prima di poter realizzare l’interfaccia utente» è la classica giustificazione, che quasi sempre cede il passo a «possiamo codificare la risposta in modo statico, rilasciare l’interfaccia utente e realizzare il database nella fase successiva». Il disagio derivante dal rilasciare un backend fittizio è reale, ma è minore rispetto a quello di non rilasciare nulla per tre sprint.

L’eccezione: il lavoro di base sulla piattaforma

Alcune infrastrutture non presentano una fase visibile all’utente fino al loro completamento: la migrazione verso un nuovo provider di autenticazione, la sostituzione del backend di una coda, la sostituzione della pipeline di distribuzione. Si tratta di progetti, non di storie. Trattateli come tali: non suddivideteli orizzontalmente fingendo che lo siano. Valutatene la portata come progetto, comunicate la tempistica e accettate che la velocità del team rifletterà l’investimento. Presentare una migrazione che richiede tre sprint come tre «storie» inganna solo il grafico di avanzamento.

Se una “slice” non fornisce nulla che un utente possa utilizzare, non è una “slice”.

Domande frequenti

Che cos’è il “vertical slicing” nell’agile?

Il “vertical slicing” suddivide una funzionalità in base ai risultati per l’utente, in modo che ogni “slice” rappresenti una sezione snella che attraversa tutti i livelli (interfaccia utente, logica e dati) e che fornisca qualcosa che l’utente possa effettivamente utilizzare, anche se gestisce un solo caso. Ogni “slice” è rilasciabile autonomamente.

Qual è la differenza tra il taglio orizzontale e quello verticale?

La suddivisione orizzontale opera per livelli tecnici: uno sprint è dedicato al front-end e il successivo al back-end; pertanto, nessun singolo sprint produce nulla di utilizzabile da parte dell’utente. La suddivisione verticale opera in base al risultato per l’utente, pertanto ogni fase di sviluppo fornisce un percorso end-to-end funzionante. Le suddivisioni verticali forniscono valore; quelle orizzontali forniscono promesse.

Perché il “vertical slicing” è preferibile?

Poiché ogni “slice” rappresenta un elemento concreto e pronto per la distribuzione. Il registro delle modifiche si arricchisce, gli utenti vedono i progressi e il team può adeguare la rotta in base all’utilizzo effettivo anziché a quello previsto. La suddivisione orizzontale aumenta i valori di velocità, mentre il prodotto visibile agli utenti rimane invariato per uno sprint alla volta.

In quali casi è accettabile il “slicing” orizzontale?

Quando si tratta di attività fondamentali relative alla piattaforma, prive di una componente visibile all’utente fino al completamento: migrazione dei provider di autenticazione, sostituzione del backend delle code, sostituzione della pipeline di distribuzione. Si tratta di progetti, non di storie: valutatene la portata di conseguenza e comunicate la tempistica, anziché fingere che si tratti di attività suddivise.

Approfondimenti