Plantillas de Definición de Listo

¿Qué es una plantilla de Definition of Done (DoD)?

Una plantilla de Definition of Done (DoD) es una lista de verificación integral de criterios técnicos y funcionales que una historia de usuario o tarea debe cumplir antes de que se considere "Terminada". A diferencia de los "Criterios de Aceptación" (que son únicos para cada historia), la DoD es un estándar global que se aplica a todo el trabajo. Evita la "deuda técnica" al asegurarse de que nunca se omitan las pruebas, la documentación y el cumplimiento por acelerar.

La auditoría de "Calidad": 3 formas de aplicar estándares "listos para enviar"

Una DoD solo es tan buena como la disciplina del equipo. Antes de finalizar tu plantilla, aplica estas tres comprobaciones de "salud" recomendadas por expertos:

1. Auditoría del "Trabajo sin terminar"

La auditoría: ¿Pasas historias a "Done" mientras dejas la documentación o las pruebas de integración para el "siguiente sprint"? La solución: Audita la calidad diferida. Un DoD profesional debe incluir pruebas de regresión y actualización de la documentación. Si no está documentado y probado en todo el sistema, no está "Done"; solo está "Desarrollado." Tu plantilla debe listar explícitamente "No generar nueva deuda técnica" como requisito.

2. La prueba de la "verdad automatizada"

La auditoría: ¿Tu DoD se basa en "promesas humanas" (p. ej., "Revisé el código")? La solución: Audita en busca de Verificación binaria. Siempre que sea posible, reemplaza las comprobaciones manuales por automatizadas. En lugar de "Code is reviewed", usa "Pull Request aprobado por 2 revisores." En lugar de "Unit tested", usa "Cobertura de pruebas unitarias > 80%." Esto elimina la subjetividad y garantiza que el estado "Done" sea medible e indiscutible.

3. El conflicto "global vs. local"

La auditoría: ¿Tu DoD es tan largo que el equipo ignora la mitad para alcanzar el objetivo del sprint? La solución: Audita la realidad. Empieza con una "DoD mínima viable" y hazla crecer a medida que el equipo madura. Si el equipo no puede realizar de forma realista una auditoría de seguridad completa en cada sprint, no la incluyas en la DoD a nivel de historia de usuario. Muévela a una "Definición de lanzamiento" en su lugar. Esto mantiene la DoD diaria alcanzable y respetada.

Marcos estratégicos: Los tres niveles de "Hecho"

Una organización profesional suele usar tres plantillas distintas para gestionar diferentes etapas de finalización:

• Nivel 1: DoD de la historia de usuario (nivel de sprint)

  • Enfoque: Calidad del código, revisión por pares y cumplimiento de criterios de aceptación específicos.

  • Ejemplo: "Pruebas unitarias aprobadas", "PO aprobado", "Pruebas funcionales aprobadas."

• Nivel 2: DoD del sprint/función (nivel de integración)

  • Enfoque: Cómo la función interactúa con el resto de la aplicación.

  • Ejemplo: "Sin errores de regresión", "Métricas de rendimiento estables", "Entorno de staging actualizado."

• Nivel 3: DoD de lanzamiento (nivel de mercado)

  • Enfoque: Cumplimiento legal, de marketing y de seguridad.

  • Ejemplo: "Prueba de penetración de seguridad aprobada", "Traducción completa", "Manual del usuario actualizado."

Componentes clave de una plantilla de Definición de Hecho

Un DoD de alto rendimiento requiere estas cinco categorías clave:

• Estándares de desarrollo: El código está comentado, refactorizado e integrado en la rama principal.

• Pruebas y calidad: Las pruebas unitarias, de integración y las pruebas manuales tipo "smoke" están completas y aprobadas.

• Entorno y DevOps: El código está desplegado en un entorno de preproducción y supera la canalización de compilación.

• Revisión y aprobación: La revisión por pares está completa y el propietario del producto (PO) ha dado el visto bueno a la funcionalidad.

• Requisitos no funcionales: La función cumple con métricas específicas de rendimiento, accesibilidad y seguridad.