¿Qué largo debe tener una iteración?

Antiguamente, cuando se hablaba de desarrollo de software, se decía que había que analizar el problema a resolver, hacer un diseño, programar y controlar la calidad.  En ese órden y con una mínima interacción entre las distintas etapas más que una pila de documentos. Esta forma de desarrollar software se conoce como "waterfall".

Hoy en día está de moda el desarrollo ágil - y con mucha razón! Las pilas de documentos nadie las leyó y con el tiempo vimos cómo fallaba proyecto tras proyecto en el mundo de la informática, porque quienes desarrollaban el software no sabían qué era lo que quería el cliente y no eran capaces de estimar cuánto demoraría el proyecto. Finalmente se producía un software cuando ya nadie lo necesitaba y que no satisfacía los requerimientos del usuario.

Uno de los principios de la "agilidad" es el desarrollo iterativo. La idea es que al inicio no hay que definir más que la dirección y durante la ruta se va comprobando frecuentemente la posición para corregir la dirección. De esta manera, los proyectos no sólo se tornan más predecibles, sino que además se benefician de la curva de aprendizaje. Es así que el desarrollo de software es dividido en bloques de tiempo.  Tras cada bloque de tiempo (iteración) se debe producir una versión del producto que esté en un estado que permita ser utilizada potencialmente por el cliente.

Acerca del largo de la iteración se han escrito muchos libros y todos los gurús de la industria han expuesto sus tésis. Cuando convertimos nuestro proceso en uno iterativo, no tenía bien claro qué largo tenía que tener una iteración. Hoy he visto ya muchas iteraciones y me gustaría recomendar algunos parámetros para facilitar la decisón:

• Las iteraciones deben ser cortas. Mientras más cortas mejor!
• Las iteraciones largas son malas, porque la presión externa por modificar el contenido de las iteraciones crece a tal punto que es difícil evitarlo. Es más fácil protejer al equipo y al plan de la iteración por periodos más cortos.
• Las iteraciones tienen ciertos costos fijos, en cada empresa y equipo son distintos.  Es importante mantener bajos estos costos fijos, sólo así se pueden acortar las iteraciones.
• No existe un número mágico que sirva para todas las situaciones.  Mi recomendación es empezar con un número de semanas en que se puedan implementar pequeñas funciones e ir evaluando en el camino si la decisión fue correcta. El objetivo debe ser siempre buscar caminos para acortar las iteraciones.  Iteraciones largas (más de 3 semanas) son en general un síntoma que el equipo o la organización no ha comprendido el significado del desarrollo iterativo de software.

Si en tú empresa utilizas desarrollo de software iterativo, qué tamaño tienen las iteraciones?