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.

1 comentario:

  1. For instance, loot bins in Team Fortress 2 and Rocket League only contain cosmetic items—things that change the best way|the way in which} that players look, however don't alter their effectiveness at taking part in} the game itself. Some video games have loot bins whose contents might probably 바카라사이트 give players a aggressive edge. For instance, players of FIFA's Ultimate Team mode can pay real-world money to buy ‘player packs’ that contain a random choice of footballers. Receiving uncommon and powerful footballers from these packs improves a person's capacity to play the game and is essential to competing at a excessive degree. At in-person casinos, problem gamblers will at instances get banned from the casino. In some circumstances, when a participant tries to give up playing for good, on-line casinos will do every little thing they can so as to to} get their loyal buyer back.

    ResponderEliminar