Acabo con este post la serie dedicada a la estimación. Aunque no lo parezca, entre el primer artículo y el segundo de esta serie ya he explicado lo más importante de la estimación en proyectos ágiles. Todo se resume en cinco reglas sencillas:
- No estimes si no lo necesitas. Normalmente se estima para adelantar una previsión a los interesados en el proyecto y para evaluar si algo se debe implementar o no.
- Sólo debe estimar personal experto, que haya construido software similar en el pasado.
- Estima por comparación, y no usando unidades absolutas.
- No compares cosas dispares, tanto en tamaño como en nivel de abstracción. Por ejemplo, tareas con historias de usuario, o historias de usuario con releases.
- No necesitas estimar tareas.
La regla número 2 nos la dice explícitamente Scrum: el PO sólo estima el valor y el equipo de desarrollo estima el coste. Cada uno estima dentro de su área de conocimiento. Ninguna de las partes debe admitir presiones por parte de la otra para que cambie su estimación. Se asume un equipo experto, si algún miembro es un junior, yo recomiendo no darle mucho peso a su estimación, pero que participe en ella para que vaya cogiendo experiencia.
La forma más sencilla de aplicar la regla número 3 es no permitir usar unidades absolutas, como horas, dinero, etc. Simplemente se coge una funcionalidad a estimar y se pregunta, ¿en qué grado esta funcionalidad es más grande o pequeña que esta otra? ¿En qué grado el cliente valora más esta funcionalidad que aquella otra? A dichas preguntas se debe responder en unidades relativas, por ejemplo, «es el doble», «es similar», «es un 123% mayor», etc.
Si a la regla número 3 le añadimos la 4, obtenemos una escala de medida relativa pero que a la vez está simplificada. Si sólo debemos comparar cosas que sean similares, ¿tiene sentido decir que esta funcionalidad es 100 veces más grande que esta otra? No. Claramente las dos cosas que estamos comparando no se encuentran al mismo nivel. Otro problema es intentar obtener una precisión en la estimación absurda, similar o incluso mayor a nuestro margen de error. No es razonable estimar que tal funcionalidad es 1.07 veces más grande que tal otra, cuando normalmente nuestro margen de error es mucho mayor de un 7%. Para reforzar estas ideas se han propuesto varias escalas de medida, y al realizar una estimación no se puede asignar un valor que no aparezca en la escala.
La más famosa de dichas escalas es la escala de Cohn. En la escala de Cohn se admiten los siguientes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Si os fijáis en escalas pequeñas tenemos 0, 1, 2 y 3, admitiendo que podemos tener cierta precisión. A escalas más grandes, 5, 8, 13, 20, 40 y 100, hay huecos. Estos huecos indican que no debemos invertir esfuerzo en ajustar nuestra precisión ya que estaríamos excediendo el margen de error que normalmente tenemos al estimar.
Siguiendo con el razonamiento que defiendo a lo largo de toda esta serie, ¿tiene sentido decir que una funcionalidad es 20 veces mayor que otra? Seguramente no, y estemos comparando funcionalidades en escalas muy distintas de tamaño. Normalmente una funcionalidad mayor que 5 u 8 se etiqueta como épica. De hecho las funcionalidades épicas normalmente no caben en un sprint, y por lo tanto no son aptas para ser implementadas. Si en vez de Scrum usas kanban, tampoco te salvas, ya que si introduces en el sistema funcionalidades de tamaño muy variable, tanto tu tiempo de entrega como tu productividad se van al garete (teoría de colas). Por lo tanto las funcionalidades épicas son carne de analista funcional, no se aceptan en la fase de desarrollo y deben ser analizadas y descompuestas con más rigor.
Lo inverso ocurre con funcionalidades de tamaño 0. En este caso se consideran tan pequeñas que no merece la pena de gastar esfuerzo en estimarlas. Normalmente representan un nivel de abstracción por debajo del que estamos tratando. Podría se una tarea en vez de una funcionalidad, o un simple detalle de ésta. En general cuando tenemos varias cosas de tamaño cero, o bien las descartamos por estar en un nivel de abstracción inadecuado, o bien las fusionamos si están relacionadas entre si.
Si tenemos en cuenta estas dos prácticas, podemos llegar a la conclusión de que la escala de Cohn, aunque útil para principiantes, no es realmente lo que buscamos. Así llegamos a la otra escala que se usa mucho: tallas de camiseta. Los valores admisible son S, M, L y XL. Las funcionalidades XL se consideran épicas. Sólo se aceptarán funcionalidades S, M o L. Este sistema simplifica el proceso de estimación y evita que caigamos en las trampas de estimar en horas o con una precisión irreal. La dificultad de este sistema estriba en que la capacidad del equipo debe medirse también en tallas de camiseta. Por ejemplo: en un sprint el equipo será capaz de 1 funcionalidad L, 2 M y 4 S. Esto puede causar problemas de estilo de «si tenemos 1 funcionalidad L, pero no hemos escogido ninguna que sea M o S, ¿podemos escoger otra funcionalidad L?». Una posible solución es definir equivalencias entre tallas: 1 L son 2 M y 6 S, pero 1 M son 2 S.
Otra posible solución para este problema es simplemente no usar una escala. En esta modalidad las funcionalidades o bien son épicas o no lo son. En este caso se deben descomponer todas las funcionalidades de forma que sus tamaños no sólo sean comparables, sino muy similares y constantes. De esta forma el proceso de estimación se simplifica enormemente, y si se hace bien se reduce la variabilidad de las funcionalidades a implementar. Esto último es especialmente importante, ya una mayor variabilidad implica peores estimaciones y también peor productividad (de nuevo teoría de colas). De esta forma acercamos bastante Kanban a Scrum, donde realmente estaríamos haciendo Kanban si la capacidad de nuestro equipo fuera siempre igual a su límite de WIP. También nos permite estar alineados con la regla 1. La dificultad de esta técnica radica en que tanto el equipo como PO deben ganar mucha experiencia estimando, analizando las funcionalidades y conociendo la capacidad de la otra parte. Por lo tanto sólo lo veo factible en equipos muy maduros.
Finalmente, la regla número 5 simplemente nos indica que tanto al PO como a los stakeholders del proyecto no les interesa saber la descomposición en tareas del proyecto. Si las funcionalidades se descomponen o no en tareas, y si éstas se estiman o no, es una cosa del equipo de desarrollo. Al PO no el interesa el Sprint Burndown, ni el Task Board, sino el Project Burndown, el reporte de bugs y el flujo acumulado de entrega de funcionalidad. Como excepción a esta regla tenemos el caso en el que parte del equipo de desarrollo pertenece al cliente, o que tal vez no hay un equipo sino varios equipos de especialistas que forman un pipeline. Para asegurar una correcta coordinación, puede ser razonable hacer un plan de tareas y llevar un seguimiento de éstas, pero obviamente esta forma de estructurar equipos no es la recomendada en un proyecto gestionado de forma ágil.
Como apunte meramente personal, mi posición con respecto a la estimación es bastante pesimista, ya he visto muchas veces como hasta la estimación más cuidadosa fracasaba, y como planes muy bonitos plantados sobre un «project» se iban al garete en cuanto tenían el más mínimo contacto con la realidad. Mi opinión personal es que hay que estimar en formato «rápido y sucio», y el proceso de desarrollo que uséis debe estar preparado para trabajar con este tipo de estimaciones aproximadas. Bueno, pues con esto acabo la serie sobre estimación, espero que os haya sido útil.
Hola Enrique, y Saludos a los demás excompañeros que siguen el blog!
Muy interesantes los tres posts, y muy útiles para mi porque estoy en esa misma situación que describes, también conocida como «Me parece muy bien que useis Scrum pero necesitamos unas estimaciones de alto nivel»
La mejor técnica para mi también es la comparación, el problema es que por ahora tenemos pocos proyectos con el mismo entorno tecnológico con el que comparar y mucha gente que ha entrado en los últimos meses, eso espero que mejore.
Pero para esas primeras estimaciones he tenido que dividir las historias en tareas, el resultado es desigual, ha funcionado bien en muchas cosas, pero veo el problema de que al presentarle esa descomposición en tareas al equipo las usa en vez de crear las suyas desde cero, que es uno de los mejores ejercicios al hacer scrum (y el que mas me está costando que se haga).
Me hubiera gustado estimar en base a valor y no a horas, pero no me vi con la experiencia suficiente, así que lo que hice fue estimar en horas y aplicar un factor de corrección, como tenemos muchas interrupciones en nuestro entorno (trainings, reuniones, soporte a antiguos proyectos) que no podemos corregir todavía, ese factor de corrección por ejemplo fue estimar para 3 personas pero luego conseguir una cuarta para apoyarlas, y no ha funcionado mal, aunque quiero aplicar estimaciones de valor cuando que pueda.
Lo dicho, tomo nota de estos tres posts, este tipo de entradas sobre aplicar la teoría a proyectos reales se pueden desarrollar mucho.
Un Saludo!
La estimación es algo complejo pero considero que los equipos con experiencia ya saben a cuanto se pueden compremeter en un sprint sin necesidad de aplicar algún método en especial.
La verdad es que en el equipo que trabaje el año pasado jamas fuimos capaces de acertar en una estimación ya que siempre o eramos muy optimistas o muy pesimistas y al final terminamos usando el método de comparación entre historias sin ajustarnos a un limite de n puntos de historia.
El artículo me ha resultado muy interesante y práctico. Hay un punto que siempre genera polémica: «Sólo debe estimar personal experto, que haya construido software similar en el pasado». Yo soy los que opina por el contrario, que debe estimar quien va a desarrollar la historia, es decir, todo el equipo.
Un experto tiene conocimientos que le harán ser mucho más productivo porque tiene más capacidades. Un nóvel puede tener poca experiencia en algunas tareas que le hagan ir tal vez más lento. Si planifica el experto y desarrolla el nóvel, es probable que los cálculos no cuadren.
Como alternativa esto, hay técnicas como el Scrum Poker, donde todos los miembros del equipo discuten sobre la estimación. Todo el mundo da su estimación al mismo tiempo, evitando los condicionantes de tener que hablar después que el experto. Si el experto dice 3 yo también diré que 3 porque sino me van a mirar mal… Si hay discordancia en los resultados, se exponen los motivos por los que cada miembro estimó esos puntos.
Esto es un mundo de posibilidades! Hay que intentar probar cosas diferentes y ver cuáles se adaptan mejor a cada equipo.
Saludos!!