Nombre

Realizar entregas frecuentes de unidades de trabajo terminadas.

Descripción

Esta práctica es uno de los pilares del agilismo. Antes de aplicar esta práctica es importante determinar si lo que se ofrece es un servicio o un producto. Cuando se trata de un servicio, lo ideal sería entregar continuamente al cliente el resultado del trabajo (tickets, incidencias, etc.), si es posible directamente en la medida que el trabajo se va terminando. Sin embargo, si existen dependencias entre los ítems de trabajo puede que esto obligue a entregar el trabajo terminado de forma agrupada por no tener valor para el cliente el contar con un resultado parcial. Por contraparte, cuando se trata de la construcción de un producto lo ideal sería proporcionar el producto en el menor tiempo posible. Si se trata de un producto de gran envergadura los plazos pueden ser grandes, pero normalmente exista la posibilidad de establecer versiones del producto las cuales podrían incluso ser explotadas por el cliente en plazos más cortos. Gracias a esta práctica el cliente y el equipo pueden ir confirmando que los resultados son satisfactorios, con la certeza que proporciona el hecho que dichos resultados ya están siendo utilizados por el cliente, incluso se podría detectar anticipadamente que no vale la pena continuar o terminar el trabajo y cancelarlo (antes de haber hecho una mayor inversión). En Extreme Programming se sugiere que las entregas al cliente no deberían tardar más de 3 meses. Es importante destacar la diferencia entre una Entrega (release) y un Sprint (iteración); una entrega de tres meses podría, por ejemplo, realizarse en base a tres sprints de un mes cada uno. Al final del sprint el cliente puede evaluar un resultado parcial pero sin poder aún explotarlo, en cambio una entrega conlleva el hecho que el cliente puede explotar el resultado. Cuando se está en una situación de mantenimiento de un producto, si las modificaciones no son de gran envergadura los sprints podrían coincidir con entregas, es decir, el resultado del sprint podría ser explotado por el cliente. Lectura recomendada: "Bueno, bonito y barato", ¿puede conseguirse esto con un método ágil? .

Un ejemplo de una situación con la anti-práctica es el siguiente: entregar al cliente un trabajo después de muchos meses de trabajo sin haber tenido la posibilidad de confirmar su aplicación real al menos de forma parcial.

 

Ver mapa de prácticas ágiles