Hola, aquí el libro de hoy: “When will it be done?: Lean-agile forecasting to answer your customers most important question” de Daniel Vacanti
Datos básicos:
- Autor: Daniel Vacanti (Antiguo desarrollador e impulsor de Kanban en la industria)
- Páginas: 307 (el libro físico)
- ¿De qué trata?: Habla sobre como pronosticar de mejor forma los desarrollos de software y poder responder a los clientes cuándo algo estará terminado (spoiler: de forma probabilística y no determinística)
- ¿Quién podría leerlo?: Personas que componen o lideran un equipo de desarrollo de software y también las personas interesadas (que preguntan todos los días cuando un desarrollo estará listo)
¿Por qué lo leí?
Creo que en un post de LinkedIn leí algo al respecto y me pareció interesante profundizar en algo tan esencial y recurrente en el día a día de quienes trabajamos en el mundo digital (responder cuándo algo estará listo)
Siempre (sí, siempre) algún jefe o stakeholder va a hacer la pregunta mágica de cuándo algo va a estar terminado y siempre (sí, siempre) las estimaciones van a fallar, así que leer y profundizar otras formas de abordar este tema es muy útil
Algunos puntos relevantes (muy simplificado):
- El libro está dividido en cinco partes donde se busca ir profundizando, desde la premisa de lo errado que son las estimaciones, en métodos modernos para poder hacer pronósticos basados en los datos actuales
- La primera parte se centra en entender realmente qué es un pronóstico y por qué es relevante. Usa como ejemplo el huracán Sandy y el trabajo que realiza la NHC pensando probabilísticamente, usando pronósticos de corto y largo plazo y actualizándolos a medida que se tiene más información
- La segunda parte se enfoca en como hacer pronósticos para un ítem (¿cuándo estará listo?) y utilizar métricas relevantes como el Cycle Time (en vez de métricas con poca transparencia y previsibilidad como los Story Points o la Velocidad). Además, cómo ese pronóstico puede ser basado en datos, entregando un rango y una probabilidad (usando scatterplots y percentiles) y sobre todo, cómo esa mirada ayuda a entender qué etapas del flujo se deben mejorar para tener un proceso ordenado y aceitado que permita una mayor previsibilidad (o menos variabilidad)
- La tercera parte tiene un eje parecido pero buscando responder la pregunta de ¿cuándo estará listo? para un grupo de items (por ejemplo: para un proyecto) y aquí aparecen métricas relevantes como el Throughput y el WIP (en desmedro de métricas vacías o métodos poco útiles como las proyecciones lineales). Así, se pueden utilizar métodos probabilísticos como las simulaciones de Monte Carlo que, tomando como base la historia, permitan prever posibles escenarios futuros y sobre todo, entender que etapas del flujo están generando escenarios negativos y cómo abordarlas para tener un mejor proceso y mayor previsibilidad
- La cuarta parte busca aterrizar los métodos previos y proponer una forma de empezar a ponerlos en práctica y buscar así alcanzar mejores flujos de trabajo que permitan tener pronósticos más robustos
- En la última parte se muestran casos de estudio con empresas reales donde se aprecia el impacto en el trabajo, el delivery y las métricas asociadas, lo cual es una invitación a tomar las buenas prácticas y evolucionar la forma de trabajar (tanto el proceso de desarrollo como la forma de realizar pronósticos)
¿Mi recomendación?
En un mundo donde la agilidad es cada vez más utilizada, es necesario ir avanzando también en pulir etapas o procesos que no son útiles. Las estimaciones, Story points o Velocidad no aportan valor, consumen tiempo y no generan previsibilidad. Es clave tomar técnicas modernas que permitan hacer pronósticos basados en datos y que incorporen la incertidumbre, pero sobre todo que nos permitan entender que los pronósticos no son magia y que hay algo obvio pero que siempre se omite: para tener mejores pronósticos necesitamos mejorar nuestros procesos día a día (oor ejemplo gestionar impedimentos o controlar el WIP)
Creo que este libro es una lectura obligatoria y una invitación a repensar el cómo funcionan los equipos de desarrollo de software. Es clave apalancar nuestras decisiones y nuestra operación en datos y que mejor que entender los flujos de trabajo actuales y trabajar día a día en mejoras que permitan tener un proceso más fluido y previsible
