| id |
title |
type |
status |
version |
created_date |
updated_date |
| DOD-BA |
Definition of Done - Betting Analytics |
Process |
Approved |
1.0.0 |
2026-01-04 |
2026-01-04 |
Definition of Done (DoD) - Betting Analytics
1. PROPOSITO
La Definition of Done establece los criterios que un item debe cumplir para considerarse COMPLETADO. Garantiza calidad consistente y evita deuda tecnica.
2. CRITERIOS GENERALES
2.1 Codigo
| Criterio |
Descripcion |
Obligatorio |
| Implementado |
Codigo funcional que cumple requisitos |
Si |
| Revisado |
Code review aprobado por otro agente |
Si |
| Sin warnings |
ESLint/TSC sin errores ni warnings |
Si |
| Formateado |
Prettier aplicado |
Si |
| Tipado |
Sin any innecesarios |
Si |
2.2 Testing
| Criterio |
Descripcion |
Obligatorio |
| Tests unitarios |
Coverage minimo 80% |
Si |
| Tests pasando |
Todos los tests en verde |
Si |
| Tests E2E |
Flujos criticos cubiertos |
Deseable |
| Tests manuales |
Funcionalidad verificada |
Si |
2.3 Documentacion
| Criterio |
Descripcion |
Obligatorio |
| API documentada |
Endpoints en Swagger/OpenAPI |
Si (si aplica) |
| Codigo comentado |
Logica compleja documentada |
Deseable |
| README actualizado |
Si hay cambios de setup |
Si (si aplica) |
| _MAP.md actualizado |
Navegacion actualizada |
Si |
2.4 Calidad
| Criterio |
Descripcion |
Obligatorio |
| Sin bugs conocidos |
No deja bugs abiertos |
Si |
| Performance OK |
Cumple benchmarks si aplica |
Deseable |
| Seguridad OK |
Sin vulnerabilidades obvias |
Si |
| Accesibilidad |
Cumple basicos si es UI |
Deseable |
2.5 Deploy
| Criterio |
Descripcion |
Obligatorio |
| Build exitoso |
CI/CD en verde |
Si |
| Deployable |
Puede desplegarse a staging |
Si |
| Smoke tests |
Funciona en ambiente destino |
Si |
3. CRITERIOS POR TIPO
3.1 User Story (US)
## Checklist DoD - User Story
### Codigo
- [ ] Implementacion completa de todos los criterios de aceptacion
- [ ] Code review aprobado
- [ ] Sin warnings de linter
- [ ] Codigo formateado con Prettier
- [ ] Sin uso de `any` sin justificacion
### Testing
- [ ] Tests unitarios con coverage >= 80%
- [ ] Todos los tests pasando
- [ ] Tests de integracion si aplica
- [ ] Prueba manual exitosa
### Documentacion
- [ ] API endpoints documentados (Swagger)
- [ ] Comentarios en logica compleja
- [ ] YAML front-matter actualizado con:
- status: "Done"
- completed_date: "YYYY-MM-DD"
### Calidad
- [ ] Criterios de aceptacion verificados
- [ ] Sin bugs conocidos pendientes
- [ ] Performance aceptable
- [ ] Sin vulnerabilidades de seguridad
### Deploy
- [ ] Build exitoso
- [ ] Merge a develop/main sin conflictos
- [ ] Funciona en ambiente de desarrollo
3.2 Task (TASK)
## Checklist DoD - Task
- [ ] Trabajo tecnico completado
- [ ] Resultado esperado logrado
- [ ] Code review (si aplica)
- [ ] Tests actualizados (si aplica)
- [ ] Documentacion actualizada (si aplica)
- [ ] YAML actualizado: status: "Done", completed_date
3.3 Bug (BUG)
## Checklist DoD - Bug
- [ ] Bug corregido
- [ ] Causa raiz identificada
- [ ] Regression test creado
- [ ] Probado en ambiente de desarrollo
- [ ] No introduce nuevos bugs
- [ ] YAML actualizado: status: "Done", resolved_date, fix_commit
4. PROCESO DE VALIDACION
4.1 Quien Valida
| Item |
Validador Principal |
Validador Secundario |
| US Backend |
@Frontend-Agent |
@Tech-Lead |
| US Frontend |
@Backend-Agent |
@Tech-Lead |
| Task |
Peer del mismo equipo |
- |
| Bug |
@QA-Agent |
Autor del fix |
4.2 Flujo de Validacion
Desarrollo -> Code Review -> Tests -> QA -> DoD Check -> Done
- Desarrollo: Agente implementa el item
- Code Review: Otro agente revisa el codigo
- Tests: Verificar que tests pasan
- QA: Prueba manual de funcionalidad
- DoD Check: Verificar checklist completo
- Done: Mover a columna "Hecho" en Board.md
4.3 Rechazo
Si un item no pasa DoD:
- Documentar razon del rechazo
- Regresar a "En Progreso"
- Agregar nota en el item
- Notificar al agente responsable
5. YAML FRONT-MATTER DONE
User Story Done
---
id: "US-BA-XXX"
title: "Titulo descriptivo"
type: "User Story"
status: "Done"
priority: "Alta"
epic: "BA-XXX"
story_points: X
labels: ["modulo", "feature"]
assignee: "@Agente"
created_date: "YYYY-MM-DD"
updated_date: "YYYY-MM-DD"
completed_date: "YYYY-MM-DD"
reviewer: "@Reviewer-Agent"
---
Bug Done
---
id: "BUG-BA-XXX"
title: "Descripcion del bug"
type: "Bug"
status: "Done"
severity: "P1"
affected_module: "Backend"
created_date: "YYYY-MM-DD"
resolved_date: "YYYY-MM-DD"
fix_commit: "abc123def"
root_cause: "Descripcion de la causa raiz"
---
6. EXCEPCIONES
Cuando se puede relajar DoD
| Situacion |
Criterios relajables |
Aprobador |
| Hotfix Produccion |
Tests E2E, Docs completos |
@PO-Agent |
| Spike |
Tests coverage, Docs API |
@Tech-Lead |
| POC |
Todos excepto funcionalidad |
@PO-Agent |
Documentar Excepciones
Agregar al item:
## Excepcion DoD
**Fecha:** YYYY-MM-DD
**Aprobador:** @Agente
**Criterios omitidos:** [lista]
**Razon:** [justificacion]
**Deuda tecnica:** [items a completar despues]
7. DEUDA TECNICA
Registro de Deuda
Si se acepta una excepcion, crear tarea de deuda:
---
id: "TASK-BA-DEBT-XXX"
title: "Completar DoD para US-BA-XXX"
type: "Task"
status: "To Do"
priority: "P2"
labels: ["tech-debt", "dod"]
parent_us: "US-BA-XXX"
created_date: "YYYY-MM-DD"
---
8. METRICAS
KPIs de DoD
| Metrica |
Target |
Actual |
| % Items que pasan DoD primera vez |
>80% |
- |
| Items con excepciones por Sprint |
<2 |
- |
| Deuda tecnica acumulada |
<5 items |
- |
| Bugs por US completada |
<0.5 |
- |
9. REFERENCIAS
Documento: Definition of Done
Proyecto: Betting Analytics
Version: 1.0.0
Fecha: 2026-01-04
Estado: Approved
rckrdmrd
094493625c