Hola, aquí el libro de hoy: “NoEstimates: How to measure project progress without estimating” de Vasco Duarte
Datos básicos:
- Autor: Vasco Duarte (Es un speaker sobre Agile, Lean y Scrum. Promotor del movimiento #NoEstimates)
- Páginas: 252 (apróx. ya que no existe libro físico)
- ¿De qué trata?: Explica un enfoque no tradicional sobre la medición y visibilidad de los proyectos de desarrollo de software bajo la premisa de #NoEstimates
- ¿Quién podría leerlo?: Cualquier profesional a cargo de la gestión de productos digitales, equipos de desarrollo o personas de otras áreas (”clientes”) relacionadas
¿Por qué lo leí?
Como regla general me gusta leer y profundizar sobre temas que puedan ser útiles para mi desarrollo profesional y que puedan generar impacto en mi día a día. En este caso, me parecía interesante conocer algunas visiones que se escapen a la actual gestión del desarrollo de software (en este momento SCRUM)
Las estimaciones o el ¿cuándo se va a entregar este desarrollo/sistema/app? es muy común en mi día a día y aquí quizás podía haber una oportunidad de obtener nuevos enfoques (spoiler: me parece que sí)
Algunos puntos relevantes (muy simplificado):
- En el prólogo se define un concepto importante: el desperdicio (y su origen en el Japón de los 60-80 y el just in time como gestión de #NoInventories). Así, estimar es desperdicio
- En los siguientes capítulos hay un barrido lógico desde la situación actual (estimaciones y gestión de proyectos) y el camino a seguir (y el por qué) con #NoEstimates
- Para hacerlo más amigable y digerible se ejemplifica a través de una historia sobre la gestión de un proyecto (Big Fish) que va evolucionando durante el camino y como el enfoque #NoEstimates les ayuda a salir de diferentes puntos muertos que hay en un enfoque tradicional
- ¿Estimar funciona? Todos lo hacemos, pero las estadísticas dicen que en la práctica no funciona (Ley Hofstadter, Ley Parkinson y Complicaciones accidentales)
- Proyectar/pronosticar: calcular o predecir usualmente como resultado de un estudio y análisis de la información pertinente disponible
- Project driven development (ir a tiempo en presupuesto y tiempo sin foco en la utilidad del producto) versus Toyota Set based design (decisiones de diseño lo más tarde posible en el proyecto)
- Cosas que podemos hacer: reducir la variabilidad (ej: historias de usuario más pequeñas, equipos estables, prioridades claras, etc)
¿Mi recomendación?
La verdad siempre he creído que nos dejamos llevar mucho por las estimaciones en el mundo digital (¿cuándo estarán listas estas X funcionalidades?) y, como siempre ocurre, nunca son correctas. El desarrollo de software y sobre todo la gestión de productos digitales donde buscamos entregar valor al usuario hacen que el entorno sea muy dinámico y así, queremos saber con demasiada precisión cosas que no podemos debido a toda la incertidumbre inicial o variabilidad (tecnológica, producto, equipo, voz del cliente, sobrecarga, competidores, dependencias, etc)
El libro resulta interesante pues sugiere algo mucho más sensato: medir y hacer proyecciones en base al rendimiento del equipo. Es cierto que la comparación es contra un típico proyecto cascada y que al usar SCRUM ya hay varias cosas que están consideradas, pero también es cierto que al menos en mi experiencia todavía se ve mucho desperdicio en plannings eternas, puntos de historia y métricas como la velocidad que no aportan a entregar valor al usuario o a lograr un throughput constante y visibilidad sobre cómo vamos (y cuánto working software estamos colocando en manos del usuario)
Totalmente recomendado y sobre todo, una invitación a procesarlo, verlo con ojo crítico e intentar aplicar los principios (no necesariamente como recetas) en nuestro día a día gestionando productos digitales