¿Cuánto tiempo debería durar una iteración en un proyecto ágil?

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).
Para seleccionar la duración de una iteración, podemos encontrar recomendaciones de todo tipo. Por ejemplo, metodologías como XP recomiendan iteraciones un par de semanas, mientras que lo normal en Scrum (te dejo un pequeño resumen de 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 puede 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, 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 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 que 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.

Cuánto puedo esperar desde que aparece un nuevo requisito hasta que se implementa

Por último, 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 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 requisitos, 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

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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba