Con la popularidad de las metodologías ágiles para el desarrollo de software también aumento la popularidad del desarrollo iterativo, tanto en equipos ágiles como en los tradicionales. Una consideración clave en los procesos iterativos es definir qué tan larga deben ser las iteraciones. Las recomendaciones varian, desde 1 semana para equipos de Extreme Programming hasta 1 mes para equipos con Scrum. Algunos equipos también usan iteraciones más largas todavía, aunque la mayoría utiliza iteraciones de entre 1 semana y 1 mes.
No hay una "duración mágica" que le sirva a todos los equipos en cualquier circunstancia. Más aún, la duración ideal para un equipo en un proyecto podría no ser la adecuada para el mismo equipo en otro proyecto. Elegir la duración apropiada para la iteración es una decisión importante. Este artículo presenta los factores que deben considerarse cuando se tenga que elegir la duración de la iteración para el equipo.
Duración general de la entrega
Los proyectos cortos se benefician de iteraciones cortas. La duración de la iteración de un proyecto determina:
- Qué tan seguido se va a mostrar el software (en forma potencialmente entregable) a usuarios y clientes: si, por supuesto que se puede mostrar el software a mitad de una iteración, pero ese software no suele tener calidad productiva sino hasta el final de la iteración.
- Qué tan seguido se puede medir el progreso: se puede tener una sensación de avance durante la iteración, pero sólo al final de la iteración se puede medir de forma precisa cuánto trabajo se logró terminar.
- Qué tan seguido el equipo y el cliente pueden ajustar los objetivos del proyecto: es decir, sin introducir un "amontonamiento de requerimientos" o caos al proyecto al permitir cambios mayores durante la iteración.
Por ejemplo, si un equipo está trabajando en una entrega que está a 3 meses de distancia, al usar iteraciones de 1 mes sólo va a haber dos oportunidades para recolectar feedback de la iteración, ver el avance, y ajustar prioridades. En la mayoría de los casos, este número resulta insuficiente. Como regla general, cualquier proyecto se va a beneficiar con al menos 4 o 5 oportunidades para revisión. Si la duración general del proyecto es de cuatro o más meses, podría considerarse usar iteraciones de 4 semanas. Si las entregas generales son en menos tiempo, el proyecto se va a beneficiar con iteraciones más cortas.
Cantidad de incertidumbre
La incertidumbre aparece de muchas formas diferentes, e impacta en distintas áreas:
- exactamente qué necesita el cliente o los usuarios
- cuánto trabajo va a completar el equipo en cada iteración
- aspectos técnicos del proyecto
Mientras más incertidumbre exista, más cortas deberían ser las iteraciones. Cuando haya mucha incertidumbre sobre el trabajo o el producto a realizar, las iteraciones cortas van a permitir más oportunidades para que el equipo mida su progreso y más oportunidades para obtener feedback de los interesados, clientes y usuarios.
Cuánto tiempo pueden permanecer las prioridades sin cambio
Una vez que el equipo de desarrollo se compromete a una cantidad de características para la iteración, es importante que no se los distraiga de este objetivo, por lo que las personas externas no deberían cambiar las prioridades del equipo durante la itearción. Por lo tanto, el tiempo durante el cual las prioridades no cambian es un factor al elegir la duración de las iteraciones.
Una consideración clave es cuánto tiempo lleva convertir una buena idea en software que funcione. Consideremos el caso de un equipo que usa iteraciones de 4 semanas. Si asumimos que pueden surgir nuevas ideas en cualquier momento de la iteración, entonces en promedio se podría decir que las nuevas ideas surgen a mitad de la iteración. La nueva idea va a ser priorizada en la próxima iteración, la cual comienza en dos semanas. Va a llevar otras cuatro semanas (una iteración completa) para que esta nueva idea se convierta en software potencialmente productivo. Esto significa que a las nuevas ideas les lleva seis semanas transformarse en software entregable. El punto clave para recordar de este ejemplo es que a las nuevas ideas les va a llevar un promedio de tiempo de 1½ iteraciones para convertirse en software.
En promedio, los cambios se entregan 1½ iteraciones después de que fueron definidos.
La sobrecarga de las iteraciones
Existen costos asociados a cada iteración. Por ejemplo, cada iteración tiene que tener una regresión completa. Si esto resulta costoso (usualmente en términos de tiempo), el equipo podría preferir usar iteraciones más largas, de 4 semanas. Naturalmente, uno de los objetivos del equipo debería ser reducir (o casi eliminar) los costos asociados por iterar. Pero especialmente durante las primeras iteraciones del equipo, este costo puede ser bastante importante y podría influenciar la decisión sobre la mejor duración de las iteraciones.
Uno de los principales objetivos al seleccionar la duración de las iteraciones es encontrar una que motive a todos a trabajar a un ritmo consistente a través de toda la iteración.
Qué tan rápido aparece la sensación de urgencia
Los niveles de intensidad varian bastante dramáticamente en proyectos de 12 meses, no iterativos, con procesos en cascada. Al inicio del proyecto, cuando el equipo no tienen stress sobre la fecha de entrega, pueden tomarse descansos y almuerzos de dos horas. Durante el mes 13 de un proyecto planificado en 12 meses, ya seguramente están en su segundo o tercer mes de trabajar horas extra y fines de semana. En general, mientras la fecha de entrega está lejana en el futuro, no se siente presión y se trabaja con relajo. Recién cuando la fecha de entrega aparece tangible es que se comienza a trabajar más duro.
Incluso con iteraciones de 4 semanas, la fecha de entrega no está muy lejos en el futuro. Pero está lo suficientemente lejana como para que varios equipos sientan menos necesidad de trabajar durante las primeras semanas, y más apuro durante la última semana de la iteración. El objetivo es seleccionar una duración de iteración que distribuya la presión que siente el equipo de forma pareja. El punto no es agregarle más presión la equipo ("¡Van a entregar hoy!"). En cambio, el punto es tomar la cantidad total de stress que el equipo va a sentir normalmente, y distribuirla de forma más pareja a través de toda la iteración.
Y por último... decidirse
Uno de los principales objetivos al elegir la duración de las iteraciones es encontrar aquella que motive a que todos trabajen a un ritmo consistente durante toda la iteración. Si la iteración es muy larga, hay una tendencia natural a relajarse al principio, lo que lleva al pánico y horas más largas sobre el final. Hay que esforzarse por encontrar la duración de iteraciones que balancee y distribuya estas variaciones.
Mi preferencia general es de 2 semanas. Las iteraciones de 1 semana (o cualquier cosa más corta) pueden ser muy estresantes y caóticas. La próxima entrega está a cuatro días de distancia. Las iteraciones extremadamente cortas no dejan tiempo de reacción si, por ejemplo, un miembro del equipo se enferma o cualquier cosa sale mal. No recomendaria empezar con iteraciones de una semana a menos que el proyecto cuente con pruebas completamente automatizadas para todas las partes del sistema.
Por otro lado, las iteraciones de 4 semanas empiezan a sentirse eternas, especialmente si ya trabajaron en iteraciones de 1 ó 2 semanas. Con iteraciones de 4 semanas los equipos tienen tiempo para investigar y buscar soluciones más creativas que en las iteraciones más cortas. Un equipo ágil experimetnado que trabaja en una fase exploratoria del proyecto podría beneficarse de iteraciones de 4 semanas. Sin embargos, estas iteraciones de 4 semanas comienzan a sentirse con un inicio, medio y fin muy separados. Se siente el inicio relajado y el fin más caótico, y eso no está bueno.
Las iteraciones de 2 semanas suelen ser ideales. La sobrecarga por planificar y probar se amortiza a lo largo de dos semanas. La primera semana puede sentirse algo disinta a la segunda, pero esta diferencia no es tan dramática como en las iteraciones de 4 semanas. Además, con la práctica suficiente las organizaciones pueden aprender a no cambiar las prioridades por 2 semanas, mientras que sería algo mucho más dificil de lograr con 4 semanas.
Y un último consejo: una vez que determines la duración apropiada para las iteraciones, mantenela. Los equipos se benefician de tener un ritmo para sus proyectos. Cualquier duración puede generar este ritmo. Esto no significa que no pueda experimentarse con duraciones diferentes, pero hay que evitar ir rebotando entre distintas duraciones sin un buen motivo.
