Cuánto debe durar una iteración Francisco Javier Cervigon Ruckauer

Cuánto debe durar una iteración

Un punto clave a la hora de planificar un proyecto iterativo es decidir la duración de las iteraciones (o de los sprint en terminología Scrum). En la siguiente figura se puede ver un ejemplo con iteraciones de 3 semanas de duración.

Ejemplo de planificación de un proyecto iterativo con iteraciones de 3 semanas.

Ten cuidado, que en este punto la terminología puede ser confusa…
Una iteración, es un periodo de tiempo, no confundir con el ciclo de vida iterativo.

Para seleccionar la duración de una iteración, podemos encontrar recomendaciones de todo tipo. Por ejemplo, metodologías como XP recomiendan iteraciones de un par de semanas, mientras que lo habitual en Scrum es que sean de un mes de duración. Y lo normal que nos solemos encontrar en proyectos son iteraciones que están entre una semana y un mes.

¿Qué debería determinar la duración más recomendable para una iteración? Sin que exista una norma exacta, los siguientes factores pueden servirnos de ayuda:

· La frecuencia con la que hay que mostrar el software a los usuarios. Normalmente, el software se puede mostrar al final de una iteración (demos de prototipos), por lo que a mayor frecuencia requerida para mostrar demos y avance, menor debiera ser la duración de la iteración.

·  En línea con el anterior, debiéramos pensar con qué frecuencia hay que medir, o mostrar, el progreso del proyecto. En teoría sólo al final de una iteración podemos medir con precisión la cantidad de trabajo que realmente ha sido completado.

·  La frecuencia con la que se pueden re-ajustar objetivos del proyecto. No debiéramos hacer cambios de objetivo, funcionalidad, o alcance, una vez que ha comenzado una iteración. Los ajustes y cambios deben esperar hasta el momento en que una iteración termina. Por ello, si se requiere mayor ratio de cambio de alcance, menor debiera ser la duración de la iteración. Por lo tanto, el tiempo que se puede aguantar sin cambios de prioridad es un factor determinante a la hora de fijar la temporalidad de una iteración.

Con todo, por ejemplo, si tenemos cuatro meses de proyecto, y nuestras iteraciones son de un mes de duración, tendremos tres momentos (al final de la iteración 1, 2 y 3) para tomar “feedback”, medir progreso y re-ajustar prioridades.
Otra consideración clave es el tiempo que tarda una idea (un requisito funcional, una historia de usuario) en transformarse en software. Por ejemplo, consideremos de nuevo iteraciones de cuatro semanas. Suponiendo que una nueva idea aparece en el medio de una iteración, esa idea solo puede introducirse en la próxima versión, que comenzará en dos semanas. Dos semanas que quedan de la iteración en que aparece el nuevo requisito, más cuatro de la siguiente, hacen que la nueva idea esté implementada en 6 semanas, y si 6 semanas es mucho para nuestro negocio... habrá que considerar iteraciones menores.
Una última consideración. No olvides que a menor tiempo de iteración mayor nivel y sofisticación debe tener el equipo de desarrollo, por lo que la madurez, compenetración, experiencia, cualidades técnicas, etc., juegan un papel importante.

A iteraciones más cortas, harás más entregas, con mayor frecuencia, y menor será la desviación respecto a lo que el usuario espera.  

 

¿Deberían las iteraciones durar el mismo tiempo?

En nuestra experiencia, hemos visto equipos trabajar muy bien con iteraciones, o sprint, de duración variable, es decir, que justo antes de comenzar el mismo, en su planificación, se decidía la duración que tendría la iteración.

Es recomendable que todas las iteraciones duren lo mismo, esto sincroniza a la organización, permite hacer cálculos de velocidad más exactos y detectar problemas en el proyecto  

Pero conviene decir que han sido más los equipos que trabajan bien con iteraciones de la misma duración. Es más, en equipos poco experimentados, variar la temporalidad de la iteración suele conducir a problemas.

Francisco Javier Cervigon Ruckauer