Vertical slicing (I) — Desaprende lo que sabes sobre user stories y pon el foco en desarrollo iterativo e incremental
Hace unas semanas facilité un workshop en la Software Crafters BCN sobre vertical slicing y como poner foco en el desarrollo iterativo e incremental. Me gustaría compartir las ideas y los propios ejemplos del workshop por aquí. Serán varios posts por la longitud del tema a tratar, espero que sea de ayuda para quien busque respuestas a este problema.
- Vertical Slicing (I) — Desaprende lo que sabes sobre user stories y pon el foco en desarrollo iterativo e incremental.
- Vertical Slicing (II) — “Merciless slicing”, cómo encontrar los incrementos.
- Vertical Slicing (III) — Ejemplo práctico (Checkout de un e-commerce).
- Vertical Slicing (IV) — Desarrollo iterativo e incremental como modelo mental (al igual que en TDD).
- Vertical Slicing (V) — Ejemplo práctico (Bot en Slack para traducir mensajes)
- Vertical Slicing (VI) — Otros casos reales donde usar desarrollo iterativo e incremental.
- Vertical Slicing (VII) — Creación y gestión del product backlog con incrementos
- (Próximamente) Vertical Slicing (y VIII) — Facilitación del Workshop.
- Slides del workshop.
Los conceptos que explicaré en esta serie de posts, nacieron de mi experiencia con los equipos en los que he estado. Todos han tenido problemas con user stories, vertical slicing y el mal usado splitting.
La raíz de estos problemas es el jaleo de conceptos, ideas, teorías y ejercicios poco prácticos sobre cómo dividir user stories, sobre qué es valor y sobre que es realmente una story — el “user” apareció tiempo después.
Por poner un ejemplo de lo que me he encontrado, he visto desde la típica división entre frontend y backend, hasta user stories que eran reuniones, sí, reuniones. Hemos convertido una práctica de creación del producto en una herramienta de gestión de tareas y trabajo.
Cuando esto me pasó en varios equipos, decidí volver a los orígenes de todo, Extreme programming explained y Planning extreme programming. Os recomiendo releer cualquier libro de los básicos con el conocimiento y la experiencia que tenéis ahora, descubriréis un nuevo libro.
Solo necesitamos 2 conceptos clave
Story: “chunks of desired behavior of a software system”
Tan fácil como esto. En Extreme programming explained, una story es un “cachito” de un comportamiento deseado de nuestro sistema. Asi de simple, con esto nace todo, nos han vuelto locos con user stories, épicas, jerarquías, Jiras y demás rollos.
A partir de aquí, mi recomendación es que mejor desaprender lo que nos han contado y trabajar a partir de la base de 2 conceptos .
Desarrollo iterativo e incremental — ir haciendo crecer una solución más que dividirla
Un incremento aporta valor si nos da feedback — de si vamos por buen camino o no
Pero antes de explicarlos con profundidad, empecemos por el principio:
El desarrollo de software soluciona problemas y la mayoría de veces problemas complejos.
Si aplicamos Cynefin al vertical slicing (no explicaré Cynefin aquí, ya hay muchos posts sobre ello), nos encontramos con distintas aproximaciones de solución dependiendo del tipo de problema.
Problemas simples u obvios: no hace falta todo el lío de encontrar poco a poco la solución, sino que simplemente construye la solución directamente. Si es muy grande, divídela y construye primero lo que más valor aporte.
Un problema simple, por ejemplo, es si en nuestro coche vemos el piloto de la gasolina encendido, la solución es obvia, echar gasolina. No necesitamos descubrir ni trabajar de forma iterativa ni incremental.
Problemas complicados: después de realizar el análisis y decidir cuál es la mejor solución, encuentra todos los “slices” y desarrolla los de más riesgo/valor lo antes posible.
Si en nuestro coche, vemos otra lucecita encendida, pero no tenemos ni idea, lo llevamos al mecánico. Este analiza y chequea el coche, descubre el problema e identifica la mejor solución. Si esta involucra varias piezas o es muy grande, tal vez tenga que desarrollarla en pequeñas partes o incrementos.
Problemas complejos: En desarrollo de software nos aplica casi siempre trabajar en problemas o sistemas complejos. Donde desconocemos la solución final y tampoco tenemos seguridad sobre la relación causa-efecto.
Con nuestro coche tratamos de conducir de un sitio a otro, conocemos la dirección, sin embargo, es imposible planificar cuando acelerar, cuando frenar, cuando girar… Vamos avanzando y adaptándonos al entorno que desconocemos, peatones, semáforos, otros coches…
En desarrollo de software nos encontramos incertidumbre técnica con legacy code, nuevas tecnologías, código sin tests, refactors necesarios. También incertidumbre en el desarrollo del producto con funcionalidades y un producto que realmente desconocemos de antemano si será lo que necesite el cliente. Todo este contexto desconocido hace que entremos en un mundo lleno de complejidad para saber de antemano que decisiones tomar.
Lo que he experimentado con los equipos es que erramos en clasificar el problema. Pensamos que un problema complejo, es complicado o incluso simple y por ende nos ponemos a trabajar con la aproximación errónea.
Ya sea por optimismo de los desarrolladores o por la presión de estimar cuanto antes, sin entender el problema — por favor probad #Noestimates — nos ponemos a pensar en soluciones del dominio simple más que en el complejo.
Por todo esto, es necesario ir iterando poco a poco, creando pequeños incrementos que nos den feedback para dar el siguiente paso.
Y para resolver este tipo de problemas, los únicos conceptos que te harán falta:
Desarrollo iterativo e incremental
Ir haciendo crecer una solución más que dividirla. Pensar en tener una versión básica, con funcionalidades básicas, incluso funcionalidades que no serán las finales e ir creciendo hasta encontrar la solución final.
Si tratamos de crear el producto final desde el principio o buscamos desarrollarlo todo de una vez en un entorno complejo, nos vamos a dar un buen tortazo de realidad.
Soluciones técnicas que no funcionan, desarrollos que rompen el sistema, bugs y defectos que no esperamos o peor, un producto que no soluciona el problema. Estamos arriesgando más de lo que nos gustaría.
Un incremento aporta valor si nos da feedback
Feedback de si vamos por buen camino o no. ¿Y qué es feedback? cualquier información que nos permita saber si estamos iendo bien, que todo está funcionando, que nos ayude a reducir incertidumbre o que nos descubra cuál es el siguiente paso a dar en el desarrollo.
Como analogía, si deseáramos crear una tarta y desconocemos si los ingredientes combinan bien, los incrementos no serían cada uno de los pasos para desarrollar la tarta final, hacer el bizcocho, el relleno…
Seguramente nuestro primer feedback sería reducir la cantidad de ingredientes para combinarlos en un cupcake y descubrir si la combinación está buena de sabor o si los ingredientes ligan y cuajan bien entre ellos.
El feedback que busquemos dependerá de cuánto desarrollada tengamos ya nuestra solución.
Desde los pequeños incrementos iniciales de una versión básica del sistema con funcionalidades no definitivas, que nos dará feedback más técnico y nos ayudará a reducir la complejidad de la solución. Hasta una versión mínima funcional del producto que nos podrá dar feedback más cercano al usuario y saber si estamos acercándonos a solucionar el problema o no.
Pero cada incremento nos debe aportar feedback valioso o “valor”.
Aquí nos puede surgir una duda, ¿y si el incremento que nos piden como desarrolladores es muy grande? ¿Qué pasa si nos piden un todo o nada?
Pues con respecto a producto, tendremos un feedback mucho más tardío y asumiremos un riesgo mucho más alto. Podríamos discutir si esto es recomendable o una buena práctica en un entorno complejo.
Sin embargo, asumiendo que no sabemos aún como hacerlo de otra forma, podremos implementarlo igualmente de forma iterativa e incremental. Seguiremos pudiendo desarrollar en incrementos hasta completar el incremento final que supuestamente es necesario y que nos piden.
Seguiremos recibiendo feedback con cada incremento, seguramente más técnico o que nos sirva para reducir incertidumbre sobre el producto a implementar. No hay porque renunciar al desarrollo iterativo e incremental aunque no sepamos desde un inicio como recibir feedback temprano del producto.
- Vertical Slicing (I) — Desaprende lo que sabes sobre user stories y pon el foco en desarrollo iterativo e incremental.
- Vertical Slicing (II) — “Merciless slicing”, cómo encontrar los incrementos.
- Vertical Slicing (III) — Ejemplo práctico (Checkout de un e-commerce).
- Vertical Slicing (IV) — Desarrollo iterativo e incremental como modelo mental (al igual que en TDD).
- Vertical Slicing (V) — Ejemplo práctico (Bot en Slack para traducir mensajes)
- Vertical Slicing (VI) — Otros casos reales donde usar desarrollo iterativo e incremental.
- Vertical Slicing (VII) — Creación y gestión del product backlog con incrementos
- (Próximamente) Vertical Slicing (y VIII) — Facilitación del Workshop.
- Slides del workshop.
