Taglio orizzontale vs taglio 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 farebbe con un coltello: si ottengono due metà di nulla.

La differenza

La suddivisione orizzontale prevede una separazione in base ai livelli architetturali: il front-end in questo sprint, il back-end in quello successivo e il database nello sprint successivo a quello. 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 anziché a quello previsto.

Quando sembra necessario ricorrere al “slicing” 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 che si proverebbe nel non rilasciare nulla per tre sprint.

L’eccezione: il lavoro di base sulla piattaforma

Alcune infrastrutture non presentano una porzione accessibile agli utenti 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. Dimensionateli come un progetto, comunicate la tempistica e accettate che la velocità del team rifletterà l’investimento. Mascherare una migrazione di 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 un’interruzione sottile 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” è 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 piuttosto che a quello previsto. La suddivisione orizzontale aumenta i valori di velocità, mentre il prodotto rivolto 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

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