Vertical Slicing (IV) — Desarrollo iterativo e incremental como modelo mental (al igual que en TDD)

Abraham Vallez
4 min readNov 14, 2021

Vertical Slicing y TDD

Hacer crecer una solución desde una versión básica hasta la solución completa, a partir de pequeños incrementos que van aportando feedback y te guian para descubrir cual es el siguiente paso.

Esta descripción bien podría ser del desarrollo iterativo e incremental como de TDD. Cuanto más indago en el vertical slicing, más parecido encuentro con TDD.

TDD: “is a mental model (discipline) which relies on a very short feedback loop”. Encontré esta frase que creo que describe bien lo que significa TDD y de la misma manera, el desarrollo iterativo incremental se basa en el mismo tipo de feedback loops.

Pensad en cada baby step como un pequeño incremento para enseñarte y guiarte en la construcción de la solución. De hecho, creo que TDD es la continuación de vertical slicing. Incluso en algún momento se cruzan y se llegan a mezclar.

Photo by Tim Johnson on Unsplash

Ventajas comunes de TDD y Vertical Slicing

Permite desarrollar con confianza de forma consistente.
Avanzar con pasos más simples, pequeños y seguros, nos da la posibilidad de seguir adelante o corregir decisiones más rápido. De forma que nos genera mucha más confianza y esta confianza se traduce en velocidad y consistencia en el desarrollo.

Nos hace poder olvidarnos de eternos debates y sesiones de refinamiento o dudas sobre teorías, modas y el sexo de los ángeles tecnológicos. Avanza en una decisión con el baby step más simple posible que te dé feedback, si el camino es incorrecto, pivota rápido y prueba la siguiente opción. No haces apuestas de gran riesgo ni hipotecas tu desarrollo a decisiones que no sean fáciles de cambiar.

Ayuda a un diseño simple

YAGNI, DRY, KISS, No sobre-ingeniería… Todo esto es lo que vas a encontrar de manera inherente si logras un desarrollo iterativo e incremental.

No vas a desarrollar nada que no necesites en el momento y te facilitará mantener un diseño y una solución simple. Sobre todo, no te va a permitir plantear un diseño de la NASA para un problema que no lo requiere.

Recordando el modelo de Cynefin que comenté en el primer post, asumimos que la gran mayoría de problemas a resolver en el desarrollo del software son complejos. Con este tipo de problemas, es imposible plantear una solución de antemano, ya que desconocemos gran parte de las relaciones causa-efecto.

Para estos problemas no son válidas las soluciones “Big Design Up Front”. El vertical slicing te va a ayudar a crear una solución con un diseño flexible y ágil que te permita modificarlo a partir del aprendizaje durante el desarrollo.

Foco en un incremento cada vez

Mantener el foco es uno de los grandes objetivos de Lean — One piece flow. Sabemos las bondades de poder desarrollar centrados en un paso cada vez: velocidad, menos errores, mayor calidad…

Enfocarnos en dar un solo paso cada vez es parte intrínseca del Vertical Slicing

Facilita prácticas ágiles y XP

Si logramos ir incremento a incremento, mucha de las prácticas que tanto escuchamos en el desarrollo de software se verán mucho más fáciles.

CI/CD: Si tus incrementos son pequeños y funcionales, podrás integrar y entregar de forma continua, con menos riesgo de romper el sistema y con un ritmo alto.

Trunk based development: Del mismo modo, desarrollar incrementos muy pequeños nos permite lanzarnos a integrar en nuestra rama main de manera frecuente y constante.

Release/Iteration plan: Si cada incremento es software funcionando, nos permitirá tener un plan tanto para cada iteración como para las posibles releases del producto mucho más realista y explícita de que vamos a poder entregar en cada paso.

Ritmo sostenible: Pequeños baby steps, nos permiten mantener un ritmo constante y detectar cuando estamos pasándonos de vueltas o cuando estamos bajando el ritmo de entrega por intentar tener un incremento mayor de la cuenta.

Whole Team: Tener varios baby steps posibles y diseñar una solución vertical a todo el sistema, hará que la frase “El equipo no pueden estar todos en lo mismo” sea falsa. Ahora todo el equipo va a poder enfocarse en el mismo problema, trabajando el problema al completo y entendiendo el contexto al completo. Con lo que ello conlleva, facilitación del pairing, del mob programming

Genera un entendimiento más profundo del problema: Segun vayamos avanzando en la creación de la solución, mucho mayor conocimiento habremos descubierto y poco a poco tendremos un gran expertise en el problema que estemos tratando.

Ayuda a mostrar progreso con Working Software: Si cada incremento es funcional, se acabó la frase de “esto está al 80%”. Podremos demostrar realmente cuanto de cerca estamos de solucionar el problema con software realmente funcionando. Recordad que un 80% de un problema complejo realmente no dice nada, ya que desconocemos la solución final.

--

--