Vertical Slicing (II) — “Merciless slicing”, cómo encontrar los incrementos

Aquí llega lo más difícil, el desafío de todos los equipos. ¿Cómo encontramos estos incrementos? Usando “merciless slicing”, slicing en todos los niveles.

• Slicing para encontrar de inicio los diferentes problemas que componen el problema principal.
• Slicing para encontrar una versión lo más simple posible de cada problema. Tratamos de crear una versión básica E2E juntando todas las versiones más simples. Buscamos un primer incremento que nos dé feedback sobre la complejidad del problema.
• Slicing para encontrar los incrementos más técnicos sobre esa versión E2E. Ahora buscamos que esos incrementos nos den feedback sobre la complejidad de la solución. Nos enfocamos en cómo desarrollar de forma iterativa e incremental esa versión E2E. Usar una mentalidad de baby steps similar a la de TDD.

Slicing no se trata de dividir, si no más bien de encontrar los incrementos que vamos a ir añadiendo poco a poco para hacer crecer una primera solución básica.

Ojo porque no es el concepto de dividir que solemos tener, el de hacer de algo grande, trozos más pequeños. Se parece, pero no es lo mismo.

Tips para un buen Slicing que no solemos hacer:

• Slicing cómo manera inicial de atacar el problema: Escoge el problema, siéntate con tu equipo y empieza a indagar cómo vas a ir construyendo, desde una versión básica y con incrementos poco a poco, la solución al problema.
• Slicing como refinamiento: El slicing te permite reducir incertidumbre a la vez que estás ideando la solución al problema: El propio ejercicio del slicing nos va a obligar a ir descubriendo aspectos de la solución que no sabíamos hasta el momento de buscar los incrementos necesarios. Esto es justo el objetivo de una sesión de refinamiento.
• Slicing para refinar desde el inicio: no lo dejemos para el final, cuando hayamos dedicado horas de refinamiento y nos demos cuenta que “es demasiado grande” y hay que dividirlo.
• No hacer slicing solo cuando algo es muy grande: Tener incrementos pequeños es una consecuencia de hacer bien el slicing. Intentar desarrollar en batches pequeños es muy positivo, sin embargo, esa frase de “esto no cabe en el sprint, hay que dividirlo” es un smell de que estamos haciendo slicing con otro objetivo que no es el de obtener feedback.
• Adapta la herramienta a tu slicing, no tu slicing a la herramienta: jerarquizar items del backlog para organizar el trabajo puede ser de ayuda, sin embargo, hacer slicing porque hay que adaptarse a los conceptos de tu herramienta de gestión, no (épica, feature, theme, tarea… ). Trata cada desarrollo como un incremento más. Tendrás incrementos con más incertidumbre que desarrollarás de forma iterativa e incremental y piezas más simples que podrás desarrollar de una sola vez. No debemos confundir conceptos de la gestión del trabajo para organizarnos mejor con la gestión de ir construyendo el producto.

Intentaré por medio de varios ejemplos, de más simples y genéricos a más complejos y realistas, explicaros el proceso por el cual intento descubrir incrementos.

El proceso de Slicing

¿Cuál es el proceso de slicing? ¿Qué pasos tengo que dar para ir encontrando los incrementos?

No es un nuevo framework ni una nueva dinámica, es más bien un proceso mental, influenciado por algunas dinámicas como Story mapping, Hamburger method o Example mapping

En líneas generales consta de 6 etapas. Intentaré explicarlas con un ejemplo simple y genérico para luego, en diferentes posts, añadir ejemplos más complejos y realistas:

• Formulario de Checkout de una página de compra
• Bot de Slack para la traducción de mensajes
• Enviar el historial de mensajes traducidos del canal de Slack
• Cambiar nuestro servicio de traducción

1. Preparar un primer problema grande

Una gran parte de las dificultades que tienen los equipos al tratar de hacer slicing o dividir sus user stories, es la falta de información sobre el verdadero problema que necesitan resolver.

El trabajo a los equipos suele venir muy masticado o directamente la solución a implementar. Sin una claridad sobre el para qué se necesita y el quién lo necesita, empezamos a implementar soluciones con mucha falta de información y contexto.

Esto hace que muchas veces no veamos de forma fácil los incrementos que necesitamos ni esa primera versión básica de la cual empezar.

La idea en este punto, es “tirar del hilo” para intentar entender todo el contexto y el problema al completo. Intentar buscar el problema grande que hay detrás de la petición

2. Encontrar las Actividades necesarias (Funcionalidades, Capacidades o Comportamientos)

Una vez tenemos el problema inicial, buscaremos ¿Qué actividades, capacidades o comportamientos necesitamos implementar para solucionar el problema?

3. Encuentra los conceptos de la actividad que añadan complejidad

De cada uno de los comportamientos, capacidades o actividades que consideremos necesarias, estudiemos que complejidad tiene realizarlas, dónde podremos encontrar dificultades o incertidumbre al implementarlas.

4. Identificar distintas variaciones posibles de cada complejidad.

Basicamente es encontrar las distintas variaciones, de más simple a más complejo o incierto, con las que podríamos implementar cada parte del punto anterior. Para ellos es bastante útil usar las distintas estrategias de patrones de splitting que un montón de sitios nos han proporcionado ya.

5. Reducir a un incremento que nos dé feedback y resuelva incertidumbre.

De todas las variaciones, de todas las complejidades, de todas las actividades, escoger un slice vertical, que intente darnos feedback, lo más temprano posible, de cómo interaccionan y se combinan los distintos ingredientes de nuestra solución.

La cantidad de variaciones, actividades y complejidades incluidas en el incremento dependerán del tipo feedback que necesitemos o de la incertidumbre que tengamos sobre una parte del sistema. Podrá ser más completo o menos, pero siempre buscando feedback rápido.

6. Desarrolla en baby steps iterativos e incrementales (Volver al paso 2 con el incremento seleccionado)

Una vez seleccionada la primera versión básica de tu sistema, el primer incremento, tendremos que implementarla. Esta implementación, seguramente más técnica, también es necesaria desarrollarla de forma iterativa e incremental.

Básicamente, volveremos al paso 2 con el incremento seleccionado. Iremos realizando los mismos pasos hasta encontrar pequeños baby steps que serán nuevos incrementos a desarrollar. De manera muy cercana al mindset de TDD, aprendemos de cada pequeño paso. Cada baby step nos guía en el desarrollo de la solución técnica final a través del feedback temprano.

Este proceso tiene dos características.

• Es un ejercicio vivo: Ya que estamos trabajando en la complejidad y la incertidumbre, es imposible encontrar todos las variaciones o todos los incrementos de una sola vez. Nos valdrá con los más básicos para poco a poco ir recibiendo feedback y añadiendo nuevos incrementos cuando tengamos un mejor conocimiento.
• No es determinista: Para cada equipo, situación, contexto, tecnología… un mismo problema puede tener distintas implementaciones, se podrán haber seleccionado distintas variantes o distintos incrementos. Lo importante es el propio proceso mental y la discusión durante el mismo, no el dibujo resultante.

1. Vertical Slicing (I) — Desaprende lo que sabes sobre user stories y pon el foco en desarrollo iterativo e incremental.
2. Vertical Slicing (II) — “Merciless slicing”, cómo encontrar los incrementos.
3. Vertical Slicing (III) — Ejemplo práctico (Checkout de un e-commerce).
4. Vertical Slicing (IV) — Desarrollo iterativo e incremental como modelo mental (al igual que en TDD).
5. Vertical Slicing (V) — Ejemplo práctico (Bot en Slack para traducir mensajes)
6. Vertical Slicing (VI) — Otros casos reales donde usar desarrollo iterativo e incremental.
7. Vertical Slicing (VII) — Creación y gestión del product backlog con incrementos
8. (Próximamente) Vertical Slicing (y VIII) — Facilitación del Workshop.
9. Slides del workshop.