Suddivisione orizzontale vs verticale

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 nel prossimo, database nello sprint successivo. Il lavoro rientra negli 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.

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 alcuna parte visibile all’utente finché non sono completate: 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. Spacciare una migrazione che richiede tre sprint come tre «storie» inganna solo il grafico burndown.

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 ogni livello — 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 lo “slicing” orizzontale e quello verticale?

La suddivisione orizzontale opera per livelli tecnici — uno sprint dedicato al front-end, il successivo al back-end — pertanto nessun singolo sprint produce nulla che l’utente possa utilizzare. La suddivisione verticale opera in base al risultato per l’utente, pertanto ogni fase consegna un percorso end-to-end funzionante. Le fasi verticali offrono valore; quelle orizzontali offrono promesse.

Perché il “vertical slicing” è preferibile?

Poiché ogni “slice” è un elemento concreto e pronto per la consegna. 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 — come la migrazione dei provider di autenticazione, la sostituzione del backend delle code o la sostituzione della pipeline di distribuzione — si tratta di progetti, non di storie: classifichateli come tali e comunicatene la tempistica, anziché fingere che siano suddivisi in parti.

Letture correlate

• Suddivisione delle user story — il kit completo di strumenti e come distinguere una suddivisione autentica da una fittizia.
• Suddivisione della storia di SPIDR — cinque sezioni verticali precise.
• Stima agile: la guida completa — il punto di riferimento per tutto ciò che riguarda questo argomento.