Divisão horizontal x vertical

As fatias verticais geram valor; as fatias horizontais geram promessas. Por que a divisão por camada tecnológica adia a geração de valor e como dividir por resultado para o usuário, de modo que algo seja entregue a cada sprint.

A divisão vertical divide um story com base nos resultados para o usuário; a divisão horizontal divide-o com base nas camadas técnicas. Essa única escolha determina se cada fatia entrega algo ou nada. As fatias verticais entregam valor. As fatias horizontais entregam promessas.

Cortar horizontalmente é como quando se corta a massa com uma faca: você acaba com duas metades de nada.

A diferença

A divisão horizontal ocorre por camadas arquitetônicas: front-end neste sprint, back-end no próximo e banco de dados no sprint seguinte. O trabalho se encaixa nos sprints, mas nenhum sprint isolado produz algo que os usuários possam experimentar. Os índices de velocidade da equipe aumentam; o registro de alterações visíveis ao usuário permanece vazio.

A divisão vertical se baseia nos resultados para o usuário. Uma fatia fina que abrange todas as camadas: um único botão que realmente funciona de ponta a ponta, mesmo que lide apenas com um caso de entrada. A equipe lança menos por fatia, mas cada fatia é um produto real e pronto para lançamento. O registro de alterações vai se enchendo, os usuários veem o progresso e a equipe pode ajustar o rumo com base no uso real, em vez do uso 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
As fatias horizontais são enviadas uma camada por vez. As fatias verticais são enviadas em uma coluna ativa: um pouco de cada camada, já pronta para uso.

Quando o corte horizontal parece necessário

Normalmente não é assim. “Precisamos do esquema do banco de dados antes de podermos construir a interface do usuário” é a justificativa clássica, e quase sempre dá lugar a “podemos codificar a resposta manualmente, lançar a interface do usuário e construir o banco de dados na próxima etapa”. O desconforto de entregar um backend falso é real, mas é menor do que o desconforto de não entregar nada por três sprints.

A exceção: o trabalho fundamental em plataformas

Algumas infraestruturas não apresentam nenhuma parte visível ao usuário até que estejam concluídas: a migração para um novo provedor de autenticação, a troca de um backend de fila, a substituição do pipeline de implantação. Esses são projetos, não histórias. Trate-os como tal: não os divida horizontalmente e finja que são. Defina-os como um projeto, comunique o cronograma e aceite que a velocidade da equipe refletirá o investimento. Apresentar uma migração de três sprints como três “histórias” engana apenas o gráfico de burndown.

Se uma fatia não oferecer nada que o usuário possa usar, ela não é uma fatia.

Perguntas frequentes

O que é o “slicing vertical” no ágil?

O corte vertical divide uma funcionalidade de acordo com os resultados para o usuário, de modo que cada fatia seja um corte fino que atravessa todas as camadas (interface do usuário, lógica e dados) e que ofereça algo que o usuário possa realmente usar, mesmo que trate apenas de um caso. Cada fatia pode ser lançada de forma independente.

Qual é a diferença entre o corte horizontal e o corte vertical?

A divisão horizontal se baseia em camadas técnicas: um sprint para o front-end e o próximo para o back-end; portanto, nenhum sprint isolado produz algo que o usuário possa utilizar. A divisão vertical se baseia no resultado para o usuário; assim, cada parte entregue oferece um caminho funcional de ponta a ponta. As partes verticais entregam valor; as partes horizontais entregam promessas.

Por que o corte vertical é melhor?

Porque cada parte é algo concreto e pronto para ser entregue. O registro de alterações vai se enchendo, os usuários percebem o progresso e a equipe pode ajustar o rumo com base no uso real, em vez de no uso previsto. A divisão horizontal aumenta os índices de velocidade, enquanto o produto voltado para o usuário permanece inalterado durante os sprints.

Quando a divisão horizontal é aceitável?

Quando o trabalho consiste em tarefas fundamentais de plataforma, sem nenhuma parte visível ao usuário até que esteja concluído: migração de provedores de autenticação, troca de um backend de fila, substituição do pipeline de implantação. Esses são projetos, não histórias: avalie-os como tal e comunique o cronograma, em vez de fingir que eles podem ser divididos.

Leitura relacionada