En Scrum, cada Sprint debe generar un incremento de calidad en el producto de manera que pueda repercutir en la producción. La comprensión de esto implica que el incremento sea verdaderamente liberable y por lo tanto se pueda considerar como “hecho” y proporciona transparencia al trabajo que un equipo de desarrollo planifica, y al desarrollo de las tareas para llevarlo a cabo.

¿Por qué “Done” es tan importante? Veamos. El trabajo incompleto tiene la mala costumbre de aumentar, y si no se ve cuánto esfuerzo queda realmente por hacer, la deuda técnica puede irse rápidamente de las manos. El problema del trabajo que está casi hecho, o al 99,99%, pero que en realidad no se ha terminado de hacer, puede poner a un equipo a merced de la deuda técnica. La mayoría de los equipos a los que les pasa esto, suele dejar al margen la calidad de los PBI’s. Esto hace que los miembros del equipo estén obligados a pagar el “déficit por entrega” a tasas de interés muy altas. Cada Sprint se vuelve más difícil para que ese trabajo no acabado se encuentre en un estado utilizable y liberable. Se comprometen a endeudarse, trabajando para deshacer decisiones que podrían haber parecido oportunas en ese momento, pero que comprometieron su trabajo y lo hicieron con menos calidad de entrega.

Sin embargo, si el equipo tiene un claro entendimiento de lo que significa “Hecho“, la transparencia reina, y en cada Sprint la “Definición de Hecho” aporta mejor entendimiento y mejor planificación. Plantéate las siguientes preguntas ¿Qué es lo que realmente ha sido entregado? ¿El incremento tiene una calidad suficiente? ¿se puede liberar? ¿es de uso inmediato? y por último ¿aporta valor real para los clientes?

En definitiva, la “Definición de Hecho” es fundamental para el logro de la transparencia en la práctica ágil. Pero, curiosamente, muchos equipos no reconocen esta conexión y consideran “Hecho” como si fuera un elemento adicional más que debería negociarse de forma rápida y flexible. La falta de rigor puede representar un verdadero desafío. Haz una cosa: pide a un equipo que comparta su Definición de Hecho. y preguntales sobre las pruebas unitarias y de integración por ejemplo. Observarás que se produce un silencio o un murmullo sobre estos temas. Pregunta además si esto es adecuado para que el trabajo sea de calidad en producción y es posible que el equipo se ponga a la defensiva o temeroso. En realidad, sus incrementos puede que ni siquiera estén cerca de un estado liberable. (puesta en producción).

Pero por algo se empieza. Es mejor comenzar por algo realizable, aunque sea poco. No importa si son sólo una o dos líneas en una hoja, confluence, etc. como “pruebas unitarias” o “código verificado“. En esta etapa, lo que importa es que la Definición de Hecho ha comenzado a materializarse. Por muy chapucera que sea. Sólo entonces podrán esperar mejorarla.

Ejemplo de un Definition of Done – Definición de hecho

Recuerde que una definición de hecho se aplica a un incremento.

Entornos preparados para la release

Por ejemplo, comprobar que la integración contínua funciona, incluidas las pruebas de regresión y las revisiones de código automatizadas. La herramiento de build debe estar configurada para programar un build en el check-in.

Preparar la review

Parte del trabajo en un Sprint incluye la preparación de la review. Las métricas de Sprint deben estar disponibles, incluyendo burndown-chart si el equipo lo está usando.

Completar el  código

El código fuente debería haber sido refactorizado para hacerlo comprensible, mantenible y más capaz de mantener en futuros cambios.

Los casos de pruebas unitarias deben haber sido diseñados para todas las características en desarrollo. El grado de cobertura del código debe ser transparente para todos y debe cumplir o exceder el estándar requerido. Los casos de prueba unitaria deberían haberse ejecutado y el incremento debería funcionar como se esperaba.

Deberían realizarse revisiones cruzadas. El código fuente debería haber sido fusionado con la rama principal y la implementación automática en entornos superiores debería ser verificada.

Completar las pruebas

Se deben realizar pruebas funcionales. Esto incluye tanto las pruebas automatizadas como las pruebas exploratorias manuales. También debería haberse generado un informe de prueba. Además de que se hayan completado las pruebas de regresión y demostrado que la funcionalidad proporcionada en iteraciones anteriores sigue funcionando. Por otro lado, haberse realizado pruebas de rendimiento, seguridad y aceptación del usuario, y debería demostrarse que el producto funciona en todas las plataformas necesarias.