
Plantillas de Definición de Listo
Lanza con confianza y elimina la ambigüedad. Usa la plantilla de Definición de Listo para establecer un estándar compartido de calidad, asegurando que cada función esté realmente "terminada" antes de que llegue a tus usuarios.
4 plantillas
- 128 Me gusta1,3 mil usos

- 84 Me gusta688 usos
- 38 Me gusta327 usos
- 4 Me gusta43 usos
Explorar más
¿Qué es una plantilla de la Definición de Hecho?
Una plantilla de la Definición de Hecho (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 considerarse "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 asegurar que las pruebas, la documentación y el cumplimiento nunca se omitan por acelerar los tiempos.
La "auditoría de Calidad": 3 formas de aplicar estándares "listos para entrega"
Una DoD solo es tan buena como la disciplina del equipo. Antes de finalizar tu plantilla, aplica estas tres comprobaciones de salud de expertos:
1. La auditoría de "Trabajo sin terminar"
La auditoría: ¿Estás moviendo las historias a "Hecho" mientras dejas la documentación o las pruebas de integración para el "siguiente sprint"? La solución: Audita la calidad aplazada. Una Definición de Hecho (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á "Hecho"; solo está "Desarrollado." Tu plantilla debe listar explícitamente "Sin 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 la verificación binaria. Cuando sea posible, sustituye las comprobaciones manuales por automatizadas. En lugar de "El código fue revisado", usa "Pull Request aprobado por 2 revisores." En lugar de "Probado con pruebas unitarias", 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. Comienza con un "DoD mínimo viable" y hazlo 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 el DoD a nivel de historia de usuario. Muévela a una "Definición de lanzamiento". Así, el DoD diario se mantiene alcanzable y se respeta.
Marcos estratégicos: Los tres niveles de "Hecho"
Una organización profesional suele usar tres plantillas distintas para gestionar las distintas 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 superadas," "Aprobación del PO," "Pruebas funcionales superadas."
Nivel 2: DoD de 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 superada," "Traducción completa," "Manual de usuario actualizado."
Componentes clave de una plantilla de Definición de Hecho
Un DoD de alto rendimiento requiere estas cinco categorías principales:
Estándares de desarrollo: El código está comentado, refactorizado y se ha integrado en la rama principal.
Pruebas y calidad: Las pruebas unitarias, de integración y las pruebas manuales de humo están completas y pasan.
Entorno y DevOps: El código está desplegado en un entorno de preproducción y supera el pipeline de compilación.
Revisión y aprobación: La revisión por pares está completa y el propietario del producto (PO) ha aprobado la funcionalidad.
Requisitos no funcionales: La función cumple con los criterios específicos de rendimiento, accesibilidad y seguridad.


