archivo

Archivos diarios: junio 30, 2011

Cuando nos planteamos una estrategia de desarrollo basada en ciclos de vida iterativos e incrementales, como tenemos por ejemplo en las metodologías ágiles, se suele plantear la entrega de evoluciones del producto en períodos constantes de tiempo. Esto es lo que en algunas metodologías se conoce con el nombre de sprint.

La cantidad de trabajo que cabe en una entrega no deja de ser una combinación de estimaciones, ya que por un lado tenemos el parámetro velocity, que constituye la cantidad de unidades de trabajo que puede asumir el equipo de proyecto en una iteración (y que no podemos considerar estable, hasta que se hayan completado algunas de ellas) y por otro la estimación de esfuerzo de las diferentes historias de usuario o casos de uso que se van a implementar en este ciclo, pudiéndose utilizar para ello diferentes técnicas, como por ejemplo Planning Poker.

Contingencias en un proyecto de desarrollo de sofware puede haber muchas, así como errores en las estimaciones, por lo que no siempre será posible implementar lo previsto en cada iteración. Ante esto, hay diferentes opciones, por un lado está el overtime y será el equipo de proyecto en consenso con el cliente el que determine si merece la pena invertir ese tiempo extra, debiéndose tener en cuenta si se ha acudido recientemente al mismo.

Kent Beck cuando describe los principios y recomendaciones de la programación extrema indica que el overtime es un recurso que se debe utilizar solo en causas muy justificadas y de manera muy espaciada y yo estoy totalmente de acuerdo con él.

Otra opción será replanificar la fecha de entrega o entregar los hitos cerrados a la fecha de finalización del ciclo. La metodología en unos casos determinará qué camino utilizar. Soy de la opinión de que si las iteraciones se producen en períodos constantes de tiempo, no se debe romper el ritmo, sin embargo si no lo son, sí que se puede abrir la puerta a la replanificación.

También habrá que tener en cuenta las demandas del proyecto y el tiempo entre iteraciones. Por ejemplo, si no ha dado tiempo de corregir una incidencia y la siguiente iteración no es hasta dentro de cinco semanas, tal vez sí que habría que plantear un cierto retraso en la entrega.