5 min lectura • Guide 310 of 877
Mejores Prácticas de Definition of Done
La Definition of Done (DoD) es una lista de verificación compartida que define cuándo el trabajo está verdaderamente completo. Sin una DoD clara, "hecho" significa cosas diferentes para diferentes personas—llevando a trabajo incompleto, problemas de calidad, y sorpresas tardías.
Propósito de la DoD
| Sin DoD | Con DoD |
|---|---|
| "Hecho" varía por persona | Estándar consistente |
| Trabajo incompleto se envía | Calidad asegurada |
| Sorpresas de última hora | Entrega predecible |
| Deuda de calidad acumula | Estándares mantenidos |
Creando una DoD
Construyendo tu Checklist
PLANTILLA DE DEFINITION OF DONE
═══════════════════════════════
CALIDAD DE CÓDIGO:
─────────────────────────────────────
☐ Código sigue estándares del equipo
☐ Sin errores de linting
☐ Sin warnings del compilador
☐ Auto-documentado o comentado
☐ Code review aprobado
TESTING:
─────────────────────────────────────
☐ Tests unitarios escritos y pasando
☐ Tests de integración pasando
☐ Todos los tests existentes siguen pasando
☐ Casos edge cubiertos
☐ Sin bugs conocidos
DOCUMENTACIÓN:
─────────────────────────────────────
☐ README actualizado si necesario
☐ Documentación de API actualizada
☐ Documentación de usuario actualizada
☐ Release notes redactadas
☐ Comentarios para lógica compleja
DEPLOYMENT:
─────────────────────────────────────
☐ Merge a rama principal
☐ Deploy a staging
☐ Smoke tests pasando
☐ Sin regresión en staging
☐ Feature flag configurado (si se usa)
ACEPTACIÓN:
─────────────────────────────────────
☐ Criterios de aceptación cumplidos
☐ Product Owner aceptó
☐ Demostrable a stakeholders
☐ Cumple requisitos de performance
☐ Accesible (si aplica)
COMPLETO:
─────────────────────────────────────
☐ Todo lo anterior verificado
☐ Listo para producción
☐ Sin tareas de seguimiento necesarias
☐ Equipo acuerda que está hecho
Personalizando para tu Equipo
PERSONALIZACIÓN DE DOD
══════════════════════
EMPEZAR SIMPLE:
─────────────────────────────────────
DoD inicial (equipo nuevo):
☐ Code review completado
☐ Tests pasando
☐ Merge a main
☐ PO aceptó
Empezar con lo esencial.
Agregar a medida que equipo madura.
EQUIPO MADURO:
─────────────────────────────────────
DoD avanzada:
☐ Code review (2 aprobadores)
☐ Tests unitarios (>80% cobertura)
☐ Tests de integración
☐ Scan de seguridad limpio
☐ Benchmarks de performance cumplidos
☐ Documentación actualizada
☐ Deploy a staging
☐ Tests E2E pasando
☐ PO aceptó
☐ Release notes redactadas
Más riguroso a medida que capacidad crece.
CONTEXTO ESPECÍFICO:
─────────────────────────────────────
Agregar según tus necesidades:
Industria regulada:
☐ Review de compliance pasado
☐ Audit trail documentado
App móvil:
☐ Probado en dispositivos target
☐ Accesibilidad verificada
API pública:
☐ Breaking changes documentados
☐ Versionado correcto
DoD vs Criterios de Aceptación
DIFERENCIA CLAVE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRITERIOS DE ACEPTACIÓN: │
│ ───────────────────────── │
│ • Específicos de la historia/tarea │
│ • Definen QUÉ debe hacer el feature │
│ • Cambian con cada historia │
│ • Product Owner los define │
│ │
│ Ejemplo para "Login con Google": │
│ ☐ Usuario puede clickear "Login con Google" │
│ ☐ Redirige a pantalla de auth de Google │
│ ☐ Después de auth, usuario está logueado │
│ ☐ Email de Google se guarda en perfil │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DEFINITION OF DONE: │
│ ─────────────────── │
│ • Universal para todo el trabajo │
│ • Define CALIDAD mínima │
│ • Consistente sprint a sprint │
│ • Equipo la define │
│ │
│ Aplica a TODAS las historias: │
│ ☐ Code review aprobado │
│ ☐ Tests escritos y pasando │
│ ☐ Deploy a staging │
│ ☐ Sin bugs conocidos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AMBOS REQUERIDOS: │
│ Historia completa = AC ✅ + DoD ✅ │
│ │
└─────────────────────────────────────────────────────────────┘
Manteniendo la DoD
EVOLUCIÓN DE LA DOD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REVISAR PERIÓDICAMENTE: │
│ ├── En retrospectivas cada 2-3 sprints │
│ ├── Cuando hay problemas de calidad recurrentes │
│ └── Cuando el equipo madura o cambia │
│ │
│ SEÑALES PARA AGREGAR ITEMS: │
│ ├── Bugs recurrentes del mismo tipo │
│ ├── "Olvidamos hacer X" repetidamente │
│ ├── Feedback de stakeholders sobre calidad │
│ └── Nuevos requisitos regulatorios │
│ │
│ SEÑALES PARA REMOVER ITEMS: │
│ ├── Item ya es automático/implícito │
│ ├── Nunca encontramos problemas sin este check │
│ ├── Overhead no justifica beneficio │
│ └── Herramientas lo hacen automáticamente │
│ │
│ MEJORA CONTINUA: │
│ Sprint 1: DoD básica → Sprint 10: DoD robusta │
│ No todo de una vez, mejora incremental │
│ │
└─────────────────────────────────────────────────────────────┘