Divisão horizontal x vertical

As divisões verticais geram valor; as divisões 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 uma história com base nos resultados para o usuário; a divisão horizontal divide-a com base nas camadas técnicas. Essa única escolha determina se cada parte entrega algo ou nada. As partes verticais entregam valor. As partes horizontais entregam promessas.

O corte horizontal é como quando se corta a massa com uma faca — você acaba com duas metades de nada.

A diferença

A divisão horizontal ocorre ao longo das 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ível aos usuários permanece vazio.

O corte vertical divide-se de acordo com os 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 de trabalho — um pouco de cada camada, já prontas para uso.

Quando a divisão horizontal parece necessária

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 fase”. 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 têm uma parte visível ao usuário até que estejam totalmente concluídas — como a migração para um novo provedor de autenticação, a troca de um backend de fila ou 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. Avalie-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” na metodologia ágil?

O corte vertical divide uma história de acordo com os resultados para o usuário, de modo que cada fatia é um corte fino que atravessa todas as camadas — interface do usuário, lógica e dados — e oferece algo que o usuário possa realmente usar, mesmo que trate apenas de um caso específico. 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 separa por camada técnica — front-end em um sprint, back-end no seguinte —, de modo que nenhum sprint isolado produz algo que o usuário possa utilizar. A divisão vertical separa por resultado para o usuário, de modo que cada parte entregue ofereça 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 em previsões. 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 — como migrar provedores de autenticação, trocar um backend de fila ou substituir o 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.

Leituras relacionadas