Qué es Definition of Done y por qué importa
Definition of Done (DoD) es el contrato de calidad del equipo: la checklist que determina si una user story está realmente terminada. Sin DoD, 'terminado' es subjetivo: para un dev significa código pusheado, para QA significa testeado, para el PO significa desplegado. Esa ambigüedad genera trabajo incompleto que vuelve en forma de bugs, retrabajos y deuda técnica.
Un DoD sólido tiene tres capas: 1) Estándares técnicos (tests, code review, cobertura), 2) Validación funcional (QA, PO sign-off, acceptance criteria cumplidos), 3) Preparación para producción (docs, deployment checklist, monitoring). No es una wishlist infinita; es lo mínimo no negociable para considerar algo listo.
Error común: DoD demasiado laxo ('código funciona en mi máquina') o demasiado estricto (requiere 100% cobertura incluso en código trivial). El balance: lo suficientemente riguroso para mantener calidad, lo suficientemente pragmático para no bloquear progreso.
Evoluciona el DoD cada retro: si bugs de producción revelan gaps (ej: rollback no testeado), agregá ese ítem. Si algo nunca aplica (ej: 'legal review' en features internos), sacalo o marcalo 'si aplica'.
Cómo implementar DoD en tu equipo desde cero
Paso 1: Workshop de 1 hora. Juntá dev, QA, PO, ops. Pregunta: '¿Qué condiciones deben cumplirse para que yo confíe en que esto va a prod sin explotarnos?'. Cada rol aporta su perspectiva: devs hablan de tests/refactoring, QA de cobertura funcional, ops de deployment/rollback, PO de acceptance criteria.
Paso 2: Agrupa ítems en categorías (dev, testing, docs, deployment, quality). Esto evita listas planas de 50 bullets que nadie lee. Categorías = cognitive chunks manejables.
Paso 3: Prioriza must-haves vs nice-to-haves. Un DoD de 40 ítems donde 30 son opcionales no sirve. Definí 10-15 no negociables (ej: tests pasando, code review, QA sign-off) y 5-10 condicionales (ej: security review solo si toca authn/authz).
Paso 4: Haz visible el DoD. Ponelo en Jira/Linear como checklist templatizada en cada ticket. En daily standup, el dev dice 'Feature lista, solo falta DoD item 8: docs'. Hace el progreso transparente.
Paso 5: Audita en retro. Si un bug llegó a prod porque faltó un paso del DoD, discutí si el DoD era claro, si fue ignorado, o si falta enforcement (ej: CI debe bloquear merge si tests no pasan).
DoD para equipos remotos y asincrónicos
Desafío: sin stand-ups presenciales, es difícil validar que el DoD se cumplió. Solución: automatización + async accountability. Ítems técnicos (linter, tests, cobertura) los valida CI: pipeline rojo = merge bloqueado. Ítems humanos (code review, QA) los trackea la herramienta: PR no mergea hasta 2 approvals, ticket no pasa a 'Done' hasta QA movió a 'Verified'.
Usa checklists en PRs. Plantilla en GitHub/GitLab: markdown con checkboxes del DoD. El dev tickea lo que cumplió, reviewers validan. Ejemplo:
- [x] Tests unitarios pasando - [x] Cobertura > 80% - [ ] Docs actualizados - [x] QA sign-off
Si algo queda sin checkear, el PR no se aprueba hasta que se complete o se justifique (comentario: 'docs no aplica porque es fix interno').
Para ítems async como 'PO review', usá labels/tags en Jira: ticket tiene label 'needs-po-review', PO filtra por ese label 1-2 veces/día, da feedback, quita label. Evita bloqueos de 'esperando que el PO se conecte'.
Truco pro: DoD debe ser self-service. Si un ítem requiere conocimiento tribal ('pedir acceso a X sistema'), documenta el how-to en el DoD mismo con link. Ej: 'Deploy to staging (see runbook)'.
Errores comunes y cómo evitarlos
Error 1: DoD cambia cada sprint. Genera confusión. El DoD debe ser estable salvo cambios deliberados en retro. Si cambia 3 veces por sprint, el equipo no lo internaliza.
Error 2: DoD es aspiracional, no realista. 'Cobertura 100%', 'cero deuda técnica' suenan bien pero son inalcanzables. El DoD debe reflejar lo que podemos cumplir sostenidamente, no la utopía. Mejor '> 80% cobertura en lógica crítica' que '100% siempre'.
Error 3: DoD es solo técnico. Falta el lado producto: '¿Cumple los acceptance criteria?', '¿PO lo vio funcionando?'. Un feature técnicamente perfecto pero que no resuelve la necesidad del usuario no está done.
Error 4: No hay enforcement. El DoD queda en un Google Doc que nadie lee. Solución: hazlo parte del workflow (CI checks, PR templates, Jira automation que no permite cerrar ticket sin completar checklist).
Error 5: DoD idéntico para todos los tipos de trabajo. Un bugfix P0 en prod no puede tener el mismo DoD que un feature nuevo. Definí DoD por tipo: hotfix (mínimo: tests críticos, rollback plan), feature (completo: tests, docs, QA, PO), spike técnico (doc de hallazgos + decisión de arquitectura).
Principio rector: el DoD debe ser habilitador, no bloqueador. Si el equipo lo ve como burocracia, algo está mal. Debe dar confianza de que lo que deployamos no va a romper producción.