de Mike Cohn
Por qué lo he leído
Últimamente estoy leyendo muchos libros relacionados con las metodologías ágiles, y en muchos de ellos se hacía referencia a este libro, así que pensé que debía ser un libro imprescindible. Y así es.
Qué esperaba
Esperaba encontrar muchas técnicas de estimación, métricas para controlar que una planificación no se desvía del plan inicial y cosas así.
También esperaba encontrar una serie de consejos a aplicar a la hora de hacer las estimaciones, y la verdad es que el libro no me ha defraudado para nada.
Qué encontre
Encontré todo eso y mucho más. Descubrí nuevos conceptos (ver último apartado) y conocí de primera mano técnicas que hasta ahora solo había conocido por encima, como los diagramas burndown, para registrar los puntos de historia que se han implementado en una iteración.
Conclusiones
El libro me ha encantado. Creo que es una lectura obligatoria para cualquier persona que esté relacionada con las planificaciones de los proyectos software. Estoy seguro de que aprendería muchísimas cosas. Claro, que si eres desarrollador también te conviene conocer las técnicas explicadas en este libro.
Una cosa que me ha gustado muchísimo es que al final de cada capítulo hay un resumen exponiendo las ideas principales del capítulo. Muy útil por si tienes que ojearlo una vez leído.
Pasajes que quiero recordar de este libro
En 1981, Barry Boehm dibujó su primera versión del cono de incertidumbre. La imagen del enlace muestra los rangos iniciales de incertidumbre en diferentes puntos de un proceso de desarrollo secuencial (“en cascada”)
El “cono de incertidumbre” se va estrechando conforme el proyecto va avanzando.
Un plan ágil is aquel que no es que no queramos cambiar, sino que estamos ansiosos de hacerlo, y queremos cambiarlo porque eso significa que hemos aprendido algo o que hemos sorteado una dificultad.
Las funcionalidades son la unidad de valor para el cliente, y no las actividades, aunque nosotros planificamos basándonos en actividades, por eso muchos proyectos fallan.
La multitarea se convierte en un problema para los proyectos planificados tradicionalmente porque incentiva enfocarse en la máxima utilzizacion de todos los individuos en lugar de mantener un margen suficiente para poder manejar la variabilidad típica de las tareas de los proyectos software.
Un equipo ágil trabaja como una unidad, no hay espacio para la mentalidad “ahí lo dejo y ya está”. Un buen equipo ágil debe tener una mentalidad de estamos todos juntos en esto.
Las historias de usuario son una técnica poco pesada para expresar los requisitos del software.
Los equipos ágiles planifican a tres niveles: release, iteración y dia. release: determina el alcance, las fechas y los recursos de un proyecto. iteración: identfica tareas de alta prioridad que el equipo debería realizar en la siguiente iteración. dia: coordina el trabajo y sincroniza los esfuerzos del dia a dia.
Los proyectos se deberían ver como una forma de generar un flujo de nuevas capacidades y conocimientos, conocimientos sobre el producto y sobre el proyecto (equipo, tecnología, personas, …)
Al igual que en los restaurantes las medidas de las raciones son relativas entre sí, en el mundo software sólo necesito saber si una funcionalidad es mayor o menor respecto a otra.
Además de saber que las estimaciones son más fiables si son indicadas por aquellos que realizarán la tarea, las estimaciones son aún mejores si se basan en la colaboración del equipo al completo.
Las tres formas más comunes de dar una estimación son: opinión de un experto, analogía y disgregación (o dividir una tarea en otras más pequeñas).
La cantidad de tiempo que llevará implementar una funcionalidad es función de su tamaño (puntos historia) y el ratio de progreso del equipo (velocidad)
Se deben tener en cuenta cuatro factores a la hora de priorizar tareas: valor de las funcionalidades, coste del desarrollo, nuevo conocimiento que generará y riesgos que eliminará la realización de la tarea.
Kano (link al torpedo este, con imagen y todo si es posible) nos da una forma de separar funcionalidades en tres categorías: indispensables, lineales y excitantes/sorprendentes.
Entregar un subconjunto coherente de todas las capas de una funcionalidad is siempre mejor que entregar una capa entera pero sin conexión con el resto de ellas.
Así como un corazón bate a un ritmo regular que mantienen el cuerpo funcionando, un duración de iteración fija proporciona una constante que ayuda a establecer un ritmo de desarrollo y entregas ~ Simon Baker
Un buffer es un margen de error alrededor de una estimación. Hay dos tipos de buffers: de funcionalidad (un 25-40% de las funcionalidades son opcionales) y de planificación (se añade un 30% de tiempo a lo que creo que me va a costar).
Un buffer de planificación no es un alargamiento consciente. Las personas alargan conscientemente sus estimaciones si creen que se les reprochará no terminar a tiempo. Un buffer es un margen de seguridad necesario que sumar al conjunto de estimaciones.
Algo que el autor encuentra muy útil como trabajo a realizar antes de una iteración son las condiciones de satisfacción de las historias de usuario a desarrollar en dicha iteración por parte del cliente.
Un release burndown chart muestra la cantidad de trabajo que queda por realizar al inicio de cada iteración. Esto se convierte en un indicador visual de cómo y a qué velocidad se está acercando el equipo al objetivo del proyecto.
La variabilidad es parte da cada estimación. No importa cuánto esfuerzo se ponga en mejorarlas, un equipo nunca será capaz de estimar perfectamente.
No gestionar la velocidad individualmente. Se debe incentivar siempre que sea posible que todos los miembros del equipo trabajen como un todo, como un único equipo.
Las estimaciones y planificaciones ágiles funcionan porque se separan las estimaciones de tamaño y de duración: puntos historia * velocidad = duración
Las planficaciones tradicionales se enfocan en las tareas para crear el producto, mientras que las planificaciones ágiles se centran en las funcionalidades que desea el usuario.
Cuando creamos un plan al principio de un proyecto y no lo actualizamos con los nuevos conocimiento adquiridos, estamos perdiendo la oportunidad de sincronizar nuestro proyecto con la realidad.
Conceptos
- Cono de incertidumbre
- Velocidad
- Commitment-driven iteration planning: Una aproximación guiado por el compromiso is una alternativa a la planificación de la iteración. El equipo va añadiendo historias a la iteración de una en una mientras que ellos se puedan comprometer a entregarlas. Las historias son seleccionadas, descompuestas en tareas y éstas estimadas. De una en una. En la aproximación de planificar basándose en la velocidad, se eligen un conjunto de historias cuyas estimaciones sean iguales o menores que la velocidad del equipo.
- Condiciones de satisfacción
- burndown bar chart
Otras lecturas y enlaces relacionadas
- Agile estimating and planning en Amazon
- Guía de conceptos ágiles
- Jose Ramón Díaz, de Agilar, habla de estimaciones ágiles en su blog.