Vertical Slicing (VI) — Otros casos reales donde usar desarrollo iterativo e incremental.
Siguiendo con los ejemplos y en concreto desde el ejemplo anterior, tenemos varias situaciones donde también podemos utilizar el desarrollo de forma iterativa e incremental aunque a priori nos parezca más difícil.
En los ejercicios que nos solemos encontrar hablamos de desarrollos desde 0 o casi desde 0. Sin embargo, lo más normal es que nos encontremos en nuestro día a día desarrollos en un producto ya creado, una base de código legacy o un código desconocido porque el “cowboy developer” que tenía la empresa dejó una base solamente entendida por él mismo.
Disclaimer: Los ejercicios son ejemplos, más o menos reales, pero ni son ejercicios deterministas, ya que dependen del contexto, la tecnología, el código que tengamos, ni es la solución única de implementación. Es una aplicación práctica de los pasos del proceso a varios ejemplos. Si lo hacéis vosotros mismos, es muy posible que os puedan salir otros incrementos, otras actividades necesarias y otro tipo de implementación.
Desarrollo sobre solución ya existente
Dado que ya tenemos implementado la solución al problema anterior, ahora deseamos que el historial del chat traducido se envíe vía email de manera diaria.
Para ello no debemos de repensar la solución ya implementada, sino que implementamos los mismos 6 pasos de ejemplos anteriores, solo que con los comportamientos o actividades nuevas que necesitamos para resolver el problema.
Trabajamos paso por paso buscando las actividades, los conceptos que nos añaden complejidad y las posibles variaciones de estos. Finalmente, buscaremos mediante vertical slicing, un incremento mínimo que nos permita crear un sistema básico uniendo todos los ingredientes del problema.
Una vez seleccionado el primer incremento, iremos a buscar los baby steps. En esta parte ya podríamos ir tomando algunas decisiones más técnicas, cómo que tecnologías usar o un pequeño diseño de la arquitectura.
En esta ocasión, nos hemos decidido a utilizar un DynamoDB y otro Lambda que recupere los mensajes para mediante el servicio CloudWatch hacer un trigger cada día del envío de emails.
Para encontrar las actividades pensaremos en que necesitamos realizar o modificar de nuestro sistema actual para producir el incremento.
Finalizaríamos seleccionando un primer baby step dependiendo de la incertidumbre que queramos resolver o del feedback que deseemos como primer paso para construir la solución.
Añadir aprendizajes durante el desarrollo
Como hemos comentado en anteriores posts, este ejercicio es un ejercicio vivo, que va necesariamente cambiando con los aprendizajes y feedbacks obtenidos. Podríamos darnos cuenta en el momento de ir desarrollando los baby steps, que si guardar en el DynamoDB falla, nuestro sistema de chatear la traducción puede verse también afectado. Por lo tanto, una solución que necesitamos, sería intentar hacerlo asíncrono.
Añadiríamos al primer ejercicio, en la parte más cercana al producto, una de los conceptos nuevos que añaden complejidad al problema, la sincronía. Y a la vez tendremos que decidir si tiene sentido añadirlo al primer incremento o bien puede ser un siguiente incremento a desarrollar.
En el momento que vayamos a desarrollar el incremento, usaremos la búsqueda de baby steps de la misma forma que antes. También pensaremos más técnicamente cómo podría ser una solución a plantear mediante SQS de AWS.
Supuestos “Todo o nada”
A veces nos encontramos con que un cambio en la solución “tiene que ser un todo o nada” para salir al mercado o al cliente final. Un cambio de un partner, un cambio de infraestructura o un refactor de la arquitectura.
En nuestro ejemplo, podríamos considerar querer cambiar el servicio de traducción de Deepl al servicio de traducción de AWS, pero obviamente no podemos dejar de dar servicio de lo que ya tenemos.
No obstante, no renunciamos al vertical slicing ni al desarrollo iterativo e incremental. En este caso las actividades vendrán dadas por los comportamientos que tendremos que implementar de nuevo para el servicio de traducción nuevo.
Además, en los conceptos que hacen más complejo el problema, tendremos que tener en cuenta las diferencias que existen entre el servicio antiguo y el nuevo, errores, limitaciones, distintos tipos de llamadas…
Seguiremos haciendo lo mismo para buscar los baby steps. Sin embargo, en esta situación no podremos dar el mismo servicio a nuestros usuarios hasta que no tengamos desarrollado al menos la misma solución que antes. Para estas casuísticas me gustaría recomendar el workshop y charla de Eduardo Ferro sobre small safe steps.
#SDsummit — “S3 Small Safe Steps. El secreto de la agilidad”, Eduardo Ferro — YouTube
En ellos habla de diferentes estrategias para dar pequeños pasos seguros en nuestra búsqueda del desarrollo iterativo e incremental.
- Feature flags — Feature Toggles (aka Feature Flags) (martinfowler.com)
- Canary releases — CanaryRelease (martinfowler.com)
- Parallel changes — ParallelChange (martinfowler.com)
- Branch by Abstraction — BranchByAbstraction (martinfowler.com)
- Dark launching — DarkLaunching (martinfowler.com)
La solución no está en renunciar al desarrollo iterativo e incremental, sino buscar estrategias que nos acerquen a recibir feedback temprano y continuo a través de software funcionando.
- 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
