Una de las bases de las metodologías de desarrollo de software es definir cuándo una tarea ha sido realizada o terminada. Parece algo obvio pero muchas veces se fracasa debido a una mala estimación a causa de estimar tareas basadas en el tiempo medido entre su inicio y cuando se dice que se ha terminado.
La definición de terminado o hecho es algo que hay que acordar en el grupo de trabajo. Muchas veces, terminado es simplemente escribir el código, subirlo al sistema de control de versiones y nada más. Otras veces implica el realizar actividades de comprobación, ya sea que el código pase unos tests escritos antes que el código (como dicta extreme programming) o unos tests que haya que programar a posteriori, con lo que el trabajo no habrá acabado hasta que no se terminen estos tests.
Además, si no se dispone de departamento específico de sistemas, terminado puede indicar que esté codificado, subido al control de versiones, probado y subido al entorno de producción. Entre medias podría ser incluso que se suba, que se pruebe en un sistema de integración continua y si pasa esta fase, entonces subirlo a producción. Podría ser marcar el código para producción en un tag, o descargarlo en un formato de paquete para un repositorio que automatice la actualización, subida a un sistema de proveedores de software o cualquier otra tarea necesaria para indicar el tiempo tomado desde que comenzamos hasta que consideramos que ya no hay que hacer nada más en esa actividad para esa persona en concreto.
En cualquier caso, el grupo en su conjunto debe de definir y aprobar su papel de responsabilidad en lo que respecta a la finalización de una tarea, y no podrá decir ¡hecho! hasta que estos parámetros se cumplan.
Una definición que suelo emplear yo casi siempre es:
Esto no está terminado hasta que me lo puedas entregar sin necesidad de tener que tocar nada más.
Suele valer para la mayoría de los casos.
