Corte horizontal frente a corte vertical
Las divisiones verticales aportan valor; las divisiones horizontales, promesas. Por qué la división por capas tecnológicas retrasa la obtención de valor, y cómo dividir por resultados para el usuario para que se entregue algo en cada sprint.
La división vertical segmenta una historia en función de los resultados para el usuario; la división horizontal, en función de las capas técnicas. Esa única decisió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 sprint posterior. 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 «vertical slicing» se divide en función de los resultados para el usuario. Una segmentación reducida que abarca todas las capas: un único botón que funciona realmente de principio a fin, aunque solo gestione un caso de entrada. El equipo lanza menos por segmentación, pero cada segmentación 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 cuentan con 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 lo son. Valórelos como un proyecto, comunique el calendario y acepte que la velocidad del equipo reflejará la inversión. Presentar una migración de tres sprints como tres «historias» solo engaña al gráfico de avance.
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 segmentación vertical divide una función en función de los resultados para el usuario, de modo que cada segmento constituye un corte delgado que atraviesa todas las capas (interfaz de usuario, lógica y datos) y que ofrece algo que el usuario puede utilizar realmente, aunque solo aborde 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 y otro 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 que ven los usuarios permanece sin cambios durante varios sprints seguidos.
¿En qué casos es aceptable el corte horizontal?
Cuando se trata de tareas fundamentales relacionadas con la plataforma, sin ninguna parte visible para el usuario hasta que se haya completado: migrar proveedores de autenticación, cambiar el backend de una cola o sustituir el 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
- La división de historias de usuario: el conjunto completo de herramientas y cómo distinguir una división auténtica de una falsa.
- División de historias en SPIDR: cinco cortes verticales fiables.
- Estimación ágil: la guía completa: aquí encontrará toda la información al respecto.