La planificación ágil

En la actualidad el desarrollo software sigue afectado por graves problemas:

• los proyectos no se ajustan al presupuesto inicial
• son entregados fuera de plazo
• existe una baja calidad del software generado
• el software no cumple las especificaciones
• y el código muchas veces es inmantenible,...

...lo cual dificulta la gestión y evolución del proyecto. Las prácticas ágiles no escapan a este problema y de hecho, por estar asociadas a requisitos cambiantes el desafío es mayor.

La mayoría de los errores que se producen con más frecuencia en los proyectos software están relacionados con aspectos de estimación. Entre estos errores se pueden destacar:

• Calendario optimista: la tendencia al estimar es hacerlo de manera optimista. Esta tendencia es general y se va disminuyendo con la experiencia. Aún así en un histórico de estimaciones estimar por encima es mucho menos frecuente que estimar por debajo.

• Expectativas no realistas: muchas veces las tareas sobre las que se ha estimado son ambiguas. Posteriormente el equipo seguramente se llega a un consenso común pero el cliente puede mantener otra expectativa. Y presionará para obtener el resultado que él cree es el correcto.

• Confundir estimaciones con objetivos: al estimar tenemos que tener en cuenta nuestra capacidad actual real y el histórico de productividad de la empresa. Es decir, si queremos terminar en 3 meses (un objetivo) puede que lo consigamos o no sabiendo que contamos con 2 programadores y que el 20% del tiempo estamos respondiendo incidencias de otros proyectos.

• Omisión de estimar tareas necesarias: las pruebas, la documentación, las tareas relacionadas con la gestión de configuración o la calidad puede que no se planifiquen. Pero muchas veces consumen tiempo.

Puntos de Historia

La definición del punto de historia podría ser "la unidad de tamaño de un requisito".

A la hora de asignar puntos historia a cada historia de usuario lo que importa son los valores relativos de una historia frente al resto: una historia a la que se le asignan dos puntos historia debe requerir el doble de esfuerzo, complejidad o tamaño que una historia a la que se le asigna un único punto.

Y normalmente hay dos formas de hacer esta asignación:

Seleccionar una historia de las más pequeñas y asignarle 1 punto historia. Esta historia de usuario con 1  punto historia hará de unidad, y al resto se le asignarán puntos historia en función de su complejidad respecto a ésta.
 
Seleccionar una historia de tamaño medio y asignarle un número en la mitad del rango de puntos historia a utilizar. Normalmente, se usan rangos de puntos historia entre 1-10. Según esto, buscaríamos una historia de tamaño medio y le asignaríamos cinco puntos historia. Cada historia adicional se calcula comparándola con la primera historia. 
La técnica de estiamación Planning Poker, que explicaremos a continuación, emplea los Puntos Historia.

Planning Poker

El Planning Poker es una técnica que se utiliza para asignar los puntos historia a las historias de usuario. Esta técnica recibe el nombre de Planning Poker ya que cada una de las personas implicadas en el proceso de estimación toma un mazo de cartas que suelen estar numeradas con alguna de las secuencias que vimos antes (por ejemplo la de Fibonacci). 

La técnica de Planning Poker está basada en el consenso y es utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de software. Está muy arraigado en las técnicas ágiles por su sencillez, facilidad y bajo coste. No es una práctica de Scrum pero se suele utilizar con esta metodología ágil.

Los pasos a seguir en el Planning Poker son los siguientes:

 

1. Se presentan las historias de usuario a estimar uno por uno haciendo una descripción de los mismos. Y se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Suele darse un tiempo máximo de discusión para mejorar la productividad.

2.Tras este período de discusión cada una de las personas implicadas en el proceso de estimación toma un mazo de cartas (que están numeradas según la serie de Fibonacci, como objetivo de reflejar la incertidumbre inherente en la estimación). De ahí escoge la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo. Las estimaciones son privadas.

3.Las unidades utilizadas pueden ser variadas y deben estar definidas previamente. Pueden ser días reales, días ideales o puntos de la historia. Como consenso se denominan “puntos de poker”. La diferencia entre días ideales y reales está en la cantidad de horas a tener en cuenta. En los proyectos en los que se suceden muchas interrupciones es conveniente estimar en días reales (o incluso en horas).

4. Finalmente se publican todas las estimaciones, es decir, cada integrante del equipo muestra a la vez la carta seleccionada (esto es así para evitar que las estimaciones de unos modifiquen las de otros). Si existe una gran dispersión entre las estimaciones (unos dicen 2, otros 21) se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimación.

5.Generalmente la dispersión en las estimaciones es síntoma de que la información que manejan parte de los involucrados en el proceso de estimación no es completa o exacta. La segunda ronda de discusión permite aclarar aquellos puntos poco claros, diferencias de criterio y desvelar información que pueda no ser obvia sobre el requisito. En la siguiente ronda de estimación la dispersión de las estimaciones será mucho menor y se podrá llegar fácilmente a un consenso.

Usando Planning Poker es fácil estimar las historias de usuario de una manera ágil y rápida combinando la analogía y el juicio experto a un entorno grupal democrático. Nos lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos.

Si queréis más información, podéis entrar en el curso de Miriadax: Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI