febrero 10, 2013

La estimación ágil de proyectos, puntos-historia y velocidad

Uno de los temas más recurrentes, y que causa más dolores de cabeza es la estimación de proyectos. Trataré de explicar mi visión al utilizar una posible técnica: la estimación por puntos-historia utilizado típicamente en algunas de las metodologías ágiles.

Dejamos aparte por ahora el nirvana de no tener que estimar. Si ya has conseguido no tener la necesidad de estimar, enhorabuena, tus comentarios sobre el proceso serán bienvenidos :) A los demás: todo llegará ;)
Supongamos que en un determinado momento nos llega un proyecto, una visión, y nos hacen la pregunta del millón ¿para cuando estará? y sobre todo, ¿cuanto va a costar?
Es entonces cuando el equipo suspira, mira al techo, y tras asegurar que lo que vas a dar es una estimación aproximada, se pone a trabajar. Porque tus estimaciones las hará el equipo que va a hacer el trabajo, ¿verdad? ^_^

Historias de Usuario: Colaboración,
planificación, y requisitos. 

1) Obtención de las historias de usuario del proyecto

  Debemos averiguar con precisión aproximada lo que hay que realizar en el proyecto. Pero, ¿aproximada? Ten en cuenta que nunca nunca nunca se puede definir un alcance de un proyecto de manera cerrada y completa. Así que no merece la pena intentarlo. Hay que hacerse el suficiente detalle por si alguien necesita calcular el ROI o la inversión a realizar aproximado. Pero también hay que hacer ver que sabemos que va a haber cambios que imposibilitan la certeza absoluta. Y que desconocemos el el inicio de un proyecto, el alcance real. Recordad el cono de incertumbre.
 Con una visión de proyecto necesitamos hacer dos cosas: un Inception para bajarla a tierra y empezar a crear visión compartida. Y los talleres de historias de usuario que sean necesarios para generar un backlog con el que gestionar el alcance del proyecto. En este punto debes valorar el tiempo invertido en detallarlas. Es más importante lograr el máximo despliegue de historias que profundidad en cada una. Una gran técnica son los mapas de producto.

2) Aplicar la vara de medir del equipo

Planning poker
 Ahora debemos medir lo que queremos construir para saber cuando podemos terminarlo. No podemos decir el tiempo que podremos hacer en una carrera, si no sabemos la longitud de la misma. Asignar puntos en realidad no es estimar una historia, es solo medirla. Establecer el acuerdo por el que el equipo decide qué tamaño tiene. Esta es la razón por la que posteriormente las velocidades no son comparables entre equipos, simplemente porque cada equipo tiene su propia vara de medir. Y es subjetiva.
 ¿Te puedes equivocar asignando tamaños? Sí, pero NO. :) En realidad no importa mucho si te puedes equivocar o no. Lo importante es que seguro que te equivocas siempre de la misma manera, y eso nos dará predecibillidad. Asignar tamaños relativos nos ayuda a acertar por comparación, de manera que no nos hace falta demasiado detalle en cada elemento para relativizarlo unos respecto de otros.
 En mi experiencia funciona mejor crear una escala de tamaños de historia de usuarios relativa, ordenándolas de mayor a menor, y posteriormente asignándoles los puntos del "planing poker". Ver historia a historia, de una en una, y asignándole tamaños individualmente, genera reuniones tediosas y donde perdemos la visión comparativa entre historias.

3) Estimar la velocidad

 Es en este momento cuando realmente hacemos una estimación, respondiendo a la pregunta: ¿a qué velocidad avanzará este equipo en este proyecto? Esta es la verdadera piedra angular de la estimación y que nos dará como resultado una posible planificación temporal.
 La situación ideal se da en un equipo que tiene históricos anteriores. Guardamos las velocidades anteriores de los proyectos, y si el proyecto se da en condiciones parecidas, ¡la velocidad anterior la podemos proyectar al futuro!
 Cuando no tenemos históricos, es cuando realmente hacemos una estimación compleja. ¿cuantas historias de las definidas anteriormente creemos que podemos hacer por sprint? ¿vamos a ir más rápido o más lento construyendo el software? El equipo debe calcular cuanto será capaz de hacer por sprint, para estimar la velocidad. Juega siempre con un rango, una estimación pesimista y otra optimista. Es más fácil así dejar claro que es una estimación, y que puede tener un error.

4) Planificar

Índice de mi formación en Historias de Usuario.
 NO todo en esta vida, ni en los proyectos, son historias de usuario. NO intentes hacer que lo sean. A veces ;) hay que realizar formaciones, instalaciones de entornos, hacer spikes, etc. Hay que tenerlas en cuenta para calcular la fecha final, por si hay que sumar al tiempo de desarrollo, obviamente.
 Dada la velocidad y el tamaño del proyecto podemos hacer una simple regla de tres para conocer una posible planificación, entre la velocidad optimista y pesimista. Número de puntos totales dividido por la velocidad por iteración = número de iteraciones. Sumando imprevistos y cualquier cuestión que quede fuera de historias de usuario, tendremos nuestra primera aproximación al proyecto.

5) Asumir la realidad

 Esta es la parte más difícil de todo el proceso. Deja que el proyecto/producto evolucione y adáptate a los que vaya sucediendo.
 ¿el proyecto marcha a menos velocidad de la estimada? Calcula los nuevos costes, ¿son aceptables? ¿debes cortar en el alcance?
 ¿Surgen problemas que no habías previsto? Actualiza lo que vaya a afectar a la velocidad. ¿o necesitas nuevos perfiles? Actualiza el coste... compara la velocidad real con la planificada continuamente.

 En definitiva, no dejes que tu maravilloso plan arruine la realidad. Haz un chequeo a nivel global tras cada iteración, y no caigas en el optimismo de "ya mejoraremos" si tu gráfica de burn-down te dice que no hay tutía.






2 comentarios:

  1. Hola,

    Muy interesante este post! Tengo una duda en la parte del punto 2 en la que dices « Ver historia a historia, de una en una, y asignándole tamaños individualmente, genera reuniones tediosas y donde perdemos la visión comparativa entre historias». ¿Cómo se evita eso?

    Quiero decir, si ponemos todas las cartas de la baraja de los puntos de historia y a cada uno vamos asignándole diferentes historias por donde entramos/empiezas? Esto es cogemos la primera carta de la bajara (0 puntos de historia) y preguntamos al equipo qué historias encajan ahí y surge el debate?? Entiendo que así ya se perdería el "secretísimo" que evita la contaminación a la hora de "estimar" entre los miembros del equipo. ¿Merece la pena? Quizá lo pruebe en mis próximos proyectos.

    Gracias!

    ResponderEliminar
  2. Hola,
    Se puede empezar por cualquier historia, luego se pueden recolocar los puntos. Incluso, puedes empezar sin puntos, simplemente ordenando las historias de menor a mayor tamaño, y después asignando puntos. Lo típico suele ser empezar por la que considereis como más pequeña. (1)
    Es cierto que elimina la parte de "secretismo". Probablemente debas recalcar que todo el mundo debe estar de acuerdo, y que lo bueno son las discusiones que genera la estimación. Si ves que el equipo no es maduro y que hay gente que se influencia demasiado, vuelve a las cartas de una en una, pero ojo, que ahí tienes un problemilla.

    Un saludo

    ResponderEliminar