Nombre

Organizar el trabajo en iteraciones que agrupan unidades de trabajo que son entregadas en una fecha prevista.

Descripción

Esta práctica es esencial en Scrum y Extreme Programming, pues ambos métodos proponen un proceso iterativo. En Scrum las iteraciones se denominan Sprints. En Scrum un Sprint no debería durar más de cuatro semanas, en Extreme Programming se sugieren que cada iteración no sea de más de tres semanas. Esta práctica está condicionada a que efectivamente se pueda e interese agrupar el trabajo, es decir, que el equipo trabaje durante un Sprint y el cliente espere al término del sprint para tener el resultado parcial o final. Esta situación es natural cuando se está desarrollando una primera entrega del producto o una entrega asociada a una modificación de gran envergadura, y cuando además dicha entrega podría tardar más de un mes. Al usar Sprints el equipo y el cliente se aseguran que contarán con una oportunidad frecuente para evaluar el estado del proyecto. Además, si los Sprints están correlacionados con la prioridad de cada uno de los ítems de trabajo, es decir, si en los primeros Sprints se abordan los ítems que más valor aportarán al cliente, el proyecto no tendrá sorpresas en los últimos Sprints. Incluso podría detectarse tempranamente la conveniencia de cancelar el proyecto cuando en los primeros Sprints, por ejemplo, nos damos cuenta que el producto ya no resulta tan importante, se ha perdido su oportunidad de mercado, o se encuentran obstáculos importantes no previstos. Esta práctica no es aplicable en toda su intensidad situaciones en las cuales el equipo no puede agrupar el trabajo para acordarlo con el cliente o ni siquiera puede anticipar cuál es el trabajo que hará en el corto plazo. Hay un caso intermedio, en el cual si bien existe una cierta planificación usando Sprints, se asume que su contenido va a cambiar. Es este caso, los Sprints podrían llegar a ser solo una agrupación “a posteriori” del trabajo realizado en un período, que si bien puede resultar útil para acceder a dicha información, conlleva cierta renuncia a la planificación. Lectura recomendada: Desarrollo Iterativo versus Incremental ... o ¿cuál es la mejor estrategia para pintar la Mona Lisa?.

Un ejemplo de la situación con la anti-práctica es el siguiente: el equipo acuerda con el cliente una fecha de entrega en varios meses por delante sin tener la posibilidad de retroalimentación parcial respecto del trabajo realizado hasta cierto momento.

La organización del trabajo en Sprints, además de ayudar al equipo y al cliente a confirmar que el trabajo va bien encaminado, ofrece otras ventajas tales como: establecer una "cadencia" o ritmo continuo de trabajo que favorece la fiabilidad del equipo, o realización de actividades que conviene aplicarlas en conjunto para un grupo de unidades de trabajo en lugar de hacerlas individualmente para cada una de ellas (tales como: documentación, pruebas de regresión, formación, instalación, etc.).

 

Ver mapa de prácticas ágiles