viernes, 21 de octubre de 2011

Estimaciones / Estimations



Es de sobras conocido que la estimación es una de las áreas más problemáticas en todo proyecto de software. Pero en esta entrada no quiero centrarme en los problemas más habituales cuando estimamos (cómo conseguir estimaciones lo más cerca de la realidad posible), sino en un punto directamente relacionado con SCRUM. Un punto en el que he visto, muchas veces, que hay confusión.

Por si fuera poco con los problemas intrínsecos de la estimación, cuando estamos empezando a trabajar con SCRUM surgen dudas, que yo llamo "logísticas", sobre cómo vamos a estimar. ¿En horas? ¿En puntos de historia? ¿Qué relación hay entre las unidades de estimación y estimar en tareas o historias de usuario?

Voy a explicar mi punto de vista, basado en mi experiencia. Pero quiero dejar claro que no hay un método estándar. Es cierto que algunas herramientas (estoy pensando en TFS) pueden predeterminar cómo entrar las estimaciones (por ejemplo en horas), pero no hay una fórmula mágica. Y esto es bueno, porque es flexible.

SCRUM te da la posibilidad de adaptar cómo estimamos a nuestra necesidad. En general, las historias de usuario se estiman en puntos de esfuerzo mientras que las tareas en horas.

Las historias de usuario forman el Product Backlog. Del Product Backlog, las escogeremos para nuestro Sprint (el Product Backlog está ordenado por prioridades del negocio) y compondremos con él el Sprint Backlog.

En la reunión de Sprint Kickoff, analizaremos las historias de usuario y refinaremos su estimación. Aquí es donde yo suelo descomponer las historias de usuario en tareas y asignar horas.

Es decir:
  • Las estimaciones de las historias de usuario son más globales y las utilizo para dar estimaciones al negocio. Es muy útil en el caso que el negocio necesite tener buenas estimaciones del proyecto en sí: cuando, por ejemplo, es crítico cumplir plazos.

  • Las estimaciones en horas por tareas las utilizaré para controlar el Sprint, con el Burndown Chart.
Esta es una forma de hacerlo, pero no la única. Por ejemplo, en un proyecto que realicé tuvimos suficiente con las estimaciones de historias de usuario, puesto que eran pequeñas, (de 1 o 2 días de duración), y no valía la pena dividirlas en tareas. Como en ese caso tampoco utilizábamos ninguna "herramienta sofisticada" para llevar el tracking del proyecto (nuestro Sprint Backlog era un fichero excel y nuestro Burndown Chart, un gráfico derivado de dicho excel), pudimos cambiar nuestro "modus operandi" y trabajar con puntos de esfuerzo sin mucha complicación.

En general es importante entender los conceptos básicos (historias de usuario, tareas, etc.), pero es más importante aún saber adaptarlas a tu entorno (necesidades del negocio, equipo, etc.). Y, muchas veces, cambiar: A veces el equipo puede tener dificultad estimando en puntos de esfuerzo por estar muy habituado a estimar en horas, mientras que otras veces, al cabo de poco, estimar en puntos de esfuerzo resultará más afinado.

No hay comentarios:

Publicar un comentario