Creando una Definition of Done Efectiva

Cuando "done" significa cosas diferentes para diferentes personas, obtienes trabajo incompleto, stakeholders sorprendidos y deuda técnica. Una Definition of Done (DoD) clara crea entendimiento compartido de cómo luce la completitud, asegurando calidad consistente y entrega predecible.

Por Qué Importa DoD

Componentes de DoD

Categorías a Cubrir

CATEGORÍAS DE DEFINITION OF DONE
════════════════════════════════

CALIDAD DE CÓDIGO:
├── Código compila sin errores
├── Sin warnings de linting
├── Sigue estándares de codificación
├── Sin code smells obvios
└── Código auto-documentado

TESTING:
├── Tests unitarios escritos y pasando
├── Tests de integración pasando
├── Sin disminución de coverage
├── Casos edge testeados
└── Testing manual completo

CODE REVIEW:
├── PR creado con descripción
├── Review solicitado
├── Feedback atendido
├── Al menos 1 aprobación
└── Sin comentarios sin resolver

DOCUMENTACIÓN:
├── Comentarios de código donde sea necesario
├── README actualizado si es necesario
├── Docs de API actualizados
├── Docs de usuario actualizados (si UI)
└── Entrada de changelog agregada

DEPLOYMENT:
├── Mergeado a main branch
├── Deployed a staging
├── Smoke test pasado
├── Sin errores en monitoreo
└── Listo para producción

Ejemplos de Definiciones

DoD Básica (Equipo Pequeño)

DEFINITION OF DONE (Básica)
═══════════════════════════

Antes de marcar una tarea "Done":

CÓDIGO:
- [ ] Código compila sin errores
- [ ] Sin errores de linting
- [ ] Sigue guía de estilo del equipo

TESTING:
- [ ] Tests escritos para código nuevo
- [ ] Todos los tests pasando
- [ ] Testing manual completo

REVIEW:
- [ ] PR aprobado por 1 reviewer
- [ ] Feedback atendido

DEPLOY:
- [ ] Mergeado a main
- [ ] Deployed a staging
- [ ] Verificado funcionando

DoD Comprensiva (Enterprise)

DEFINITION OF DONE (Enterprise)
════════════════════════════════

DESARROLLO COMPLETO:
- [ ] Feature completa según criterios de aceptación
- [ ] Código compila en CI pipeline
- [ ] Sin warnings de análisis estático
- [ ] Deuda técnica documentada (si hay)
- [ ] Feature flag configurado (si aplica)

TESTING COMPLETO:
- [ ] Unit tests: >80% coverage en código nuevo
- [ ] Integration tests escritos y pasando
- [ ] E2E tests para flujos de usuario (si UI)
- [ ] Performance testeado (si aplica)
- [ ] Security scan pasado
- [ ] Accesibilidad testeada (WCAG 2.1 AA)

REVIEW COMPLETO:
- [ ] Descripción de PR completa
- [ ] 2+ code reviews aprobados
- [ ] Todos los comentarios de review resueltos
- [ ] Aprobación de arquitectura (si cambio mayor)
- [ ] Security review (si manejo de datos)

DOCUMENTACIÓN COMPLETA:
- [ ] Documentación inline de código
- [ ] Documentación de API (si cambio de API)
- [ ] Documentación de usuario (si cambio de UI)
- [ ] Runbook actualizado (si impacto ops)
- [ ] ADR creado (si decisión arquitectónica)

DEPLOYMENT COMPLETO:
- [ ] Mergeado a main branch
- [ ] CI/CD pipeline verde
- [ ] Deployed a staging
- [ ] Sign-off de QA en staging
- [ ] Alertas de monitoreo configuradas
- [ ] Listo para deployment a producción

HANDOFF COMPLETO:
- [ ] Product owner verificó
- [ ] Demo grabada (si feature mayor)
- [ ] Equipo de soporte informado (si customer-facing)
- [ ] Release notes redactadas

DoD por Tipo de Tarea

DoD POR TIPO DE TAREA
═════════════════════

BUG FIX:
├── Causa raíz identificada
├── Fix implementado
├── Test de regresión agregado
├── Sin issues relacionados
└── Deployed y verificado

FEATURE:
├── Todos los criterios de aceptación cumplidos
├── Tests comprensivos
├── Documentación actualizada
├── Revisado y aprobado
└── Sign-off de producto

DEUDA TÉCNICA:
├── Problema abordado
├── Sin cambio de funcionalidad
├── Tests siguen pasando
├── Performance mantenido
└── Aprendizajes documentados

DOCUMENTACIÓN:
├── Contenido preciso
├── Spell-checked
├── Enlaces verificados
├── Revisado por SME
└── Publicado

SPIKE/INVESTIGACIÓN:
├── Pregunta respondida
├── Hallazgos documentados
├── Recomendación hecha
├── Equipo informado
└── Tareas de seguimiento creadas

Implementando DoD

Creando Tu DoD

PROCESO DE CREACIÓN DE DoD
══════════════════════════

PASO 1: Workshop del Equipo (60 min)
─────────────────────────────────────
- ¿Qué problemas ha causado el trabajo incompleto?
- ¿Qué siempre olvidamos?
- ¿Cómo debería verse "done"?

PASO 2: Borrador de Categorías
─────────────────────────────────────
Agrupar sugerencias en:
├── Código
├── Testing
├── Review
├── Documentación
├── Deployment

PASO 3: Priorizar
─────────────────────────────────────
- Debe tener (no negociable)
- Debería tener (estándar)
- Bueno tener (aspiracional)

PASO 4: Empezar Pequeño
─────────────────────────────────────
Comenzar con 5-8 items. Expandir conforme
el equipo madura y las capacidades crecen.

PASO 5: Hacer Visible
─────────────────────────────────────
- Publicar en wiki del proyecto
- Enlazar desde GitScrum
- Referenciar en standup
- Revisar en retros

DoD en GitScrum

APLICANDO DoD EN GITSCRUM
═════════════════════════

TEMPLATE DE TAREA:
─────────────────────────────────────
Incluir checklist DoD en descripción de tarea

## Definition of Done
- [ ] Código revisado y aprobado
- [ ] Tests escritos y pasando
- [ ] Documentación actualizada
- [ ] Deployed a staging
- [ ] Verificado funcionando

AUTOMATIZACIÓN:
─────────────────────────────────────
Regla: Prevenir mover a "Done" si
checklist DoD no está completo

VISIBILIDAD:
─────────────────────────────────────
Mostrar % de completitud DoD en card de tarea

Manejando Violaciones de DoD

CUANDO DoD NO SE CUMPLE
═══════════════════════

NO HACER:
✗ Dejarlo pasar "solo esta vez"
✗ Culpar a la persona
✗ Agregar overhead burocrático

HACER:
✓ Discutir en retro
✓ Entender por qué sucedió
✓ Ajustar proceso o DoD
✓ Proporcionar soporte para cumplirla

EXCEPCIONES VÁLIDAS:
├── Fix de producción de emergencia (documentar tech debt)
├── Trabajo experimental/prototipo
├── Skip explícitamente acordado (documentado)

AÚN ASÍ:
Crear tarea de seguimiento para completar
los items de DoD saltados

Evolución de DoD

Madurando Tu DoD

NIVELES DE MADUREZ DE DoD
═════════════════════════

NIVEL 1: BÁSICO
├── Código compila
├── Tests pasan
├── Código revisado
└── Mergeado

NIVEL 2: ESTÁNDAR
├── Todo en Nivel 1
├── Requisitos de coverage
├── Documentación
├── Deployment a staging
└── Verificación

NIVEL 3: MADURO
├── Todo en Nivel 2
├── Escaneo de seguridad
├── Testing de performance
├── Accesibilidad
├── Monitoreo configurado
└── Listo para producción

NIVEL 4: EXCELENTE
├── Todo en Nivel 3
├── Feature flags
├── Listo para A/B testing
├── Plan de rollback
├── Soporte entrenado
└── Analytics configurado

Mejores Prácticas

Para Definition of Done

1. Colaboración del equipo — Todos contribuyen a crear DoD
2. Empezar simple — Agregar complejidad gradualmente
3. Revisión regular — Actualizar conforme el equipo madura
4. Visible y accesible — DoD debe estar siempre presente
5. Aplicación consistente — Mismos estándares para todos

Soluciones Relacionadas

• Creando criterios de aceptación claros
• Mejores prácticas de code review
• Mejores prácticas de continuous integration