División horizontal frente a división vertical

La segmentación vertical divide una historia en función de los resultados para el usuario; la segmentación horizontal la divide en función de las capas técnicas. Esa única elección determina si cada segmento aporta algo o nada. Los segmentos verticales aportan valor. Los segmentos horizontales aportan promesas.

El corte horizontal consiste en dividir la masa del mismo modo que lo hace un cuchillo: se obtienen dos mitades de nada.

La diferencia

La división horizontal se realiza por capas arquitectónicas: el front-end en este sprint, el back-end en el siguiente y la base de datos en el siguiente sprint. El trabajo se adapta a los sprints, pero ningún sprint por sí solo produce nada que los usuarios puedan ver o utilizar. Las cifras de velocidad del equipo aumentan; sin embargo, el registro de cambios visible para los usuarios permanece vacío.

El «slicing» vertical se divide en función de los resultados para el usuario. Una «porción» reducida que abarca todas las capas: un único botón que realmente funciona de principio a fin, aunque solo gestione un caso de entrada. El equipo lanza menos por cada «porción», pero cada una de ellas es un producto real y listo para su lanzamiento. El registro de cambios se va completando, los usuarios ven el progreso y el equipo puede ajustar el rumbo basándose en el uso real, en lugar de en el uso previsto.

Cuando parece necesario realizar un corte horizontal

Normalmente no es así. «Necesitamos el esquema de la base de datos antes de poder desarrollar la interfaz de usuario» es la justificación clásica, y casi siempre da paso a «podemos codificar la respuesta de forma estática, lanzar la interfaz de usuario y crear la base de datos en la siguiente fase». La incomodidad que supone entregar un backend ficticio es real, pero es menor que la incomodidad de no entregar nada durante tres sprints.

La excepción: el trabajo fundamental en las plataformas

Algunas infraestructuras no tienen una parte visible para el usuario hasta que se completan: la migración a un nuevo proveedor de autenticación, el cambio del backend de una cola o la sustitución del proceso de implementación. Se trata de proyectos, no de historias. Trátelos como tales: no los divida horizontalmente ni finja que son lo que no son. Defina su alcance como un proyecto, comunique el calendario y acepte que la velocidad del equipo reflejará la inversión realizada. Presentar una migración de tres sprints como tres «historias» solo engaña al gráfico de burndown.

Si una «slice» no ofrece nada que el usuario pueda utilizar, no es una «slice».

Preguntas frecuentes

¿En qué consiste el «vertical slicing» en el método ágil?

La división vertical segmenta una función en función de los resultados para el usuario, de modo que cada segmento constituye un corte fino que atraviesa todas las capas —interfaz de usuario, lógica y datos— y que ofrece algo que el usuario puede utilizar realmente, aunque solo resuelva un caso concreto. Cada segmento puede lanzarse de forma independiente.

¿Cuál es la diferencia entre el corte horizontal y el vertical?

La división horizontal se realiza por capas técnicas —un sprint para el front-end, el siguiente para el back-end—, por lo que ningún sprint por sí solo produce nada que el usuario pueda utilizar. La división vertical se realiza en función del resultado para el usuario, de modo que cada parte entregada ofrece una ruta funcional de principio a fin. Las partes verticales aportan valor; las horizontales, promesas.

¿Por qué es mejor la segmentación vertical?

Porque cada «slice» es un elemento real y entregable. El registro de cambios se va completando, los usuarios ven el progreso y el equipo puede ajustar el rumbo basándose en el uso real, en lugar de en el uso previsto. La división horizontal aumenta las cifras de velocidad, mientras que el producto visible para el usuario permanece inalterado durante varios sprints seguidos.

¿En qué casos es aceptable el «slicing» horizontal?

Cuando se trata de tareas fundamentales relacionadas con la plataforma, sin ninguna parte visible para el usuario que esté lista hasta su finalización —como la migración de proveedores de autenticación, el cambio del backend de una cola o la sustitución del proceso de implementación—, se trata de proyectos, no de historias: evalúen su alcance como tales y comuniquen el calendario previsto, en lugar de fingir que se pueden dividir.

Lecturas relacionadas

• División de historias de usuario — el conjunto completo de herramientas y cómo distinguir una división real de una falsa.
• División de la historia de SPIDR — cinco cortes verticales fiables.
• Estimación ágil: la guía completa — el centro de referencia para todo lo relacionado con este tema.