Definition of Done (DoD)

Propósito

La Definición de Terminado (DoD, por sus siglas en inglés) es un entendimiento compartido dentro del equipo Scrum que establece el conjunto mínimo de criterios o requisitos que cada funcionalidad del videojuego debe cumplir para considerarse completa y lista para ser lanzada.

El DoD es una parte crucial del marco de trabajo Scrum, ya que proporciona una descripción clara de lo que se espera que el equipo entregue al final de cada Sprint.

Así, asegura que todo el equipo comparta un mismo estándar de calidad, cumpla con la meta del sprint y esté alineado con los objetivos de la organización y del pryecto.

Gracias al Dod, se garantiza la confianza en el progreso del desarrollo y que el resultado sea jugable, estable y coherente con la visión del proyecto, puesto que cada entrega habrá sido probada, revisada y lista para integrarse en la versión final del juego.

1. Documented

• La documentación esta completa y actualizada, incluyendo tanto la documentación de usuario como la documentación de desarrollo.
• Cada funcionalidad cuenta con una descripción clara de su propósito, parámetros y comportamiento esperado.
• La documentación técnica es accesible para todo el equipo.
• Las dependencias entre módulos (IA, recursos, mapa, interfaz, multijugador) están registradas.
• Se lleva un registro de cambios importantes en README o wiki.
• Las decisiones de diseño y sus justificaciones están documentadas.
• Se registran los errores y sus soluciones para futuras referencias.

2. Coded

• Todo el código fuente está completo y actualizado en el repositorio de control de versiones del equipo, con mensajes de commit claros y descriptivos.
• No existen fragmentos temporales, código duplicado o sin uso.
• Cada función implementada cumple una responsabilidad clara y única.
• Las nuevas funciones están integradas correctamente con las existentes, sin romper compatibilidad.
• Se eliminan los console.log / print / debug u otras salidas temporales antes del commit final.
• Todos los módulos se han codificado tal que cooperen entre sí correctamente.
• Se valida el input de usuario y controles robusta y adecuadamente, ante errores o inputs inválidos.
• Código libre de advertencias o errores de compilación, que además cumpla con criterios de escalabilidad y mantenibilidad.

3. Tested

• Se han escrito y aprobado pruebas unitarias para cada una de las funciones o características implementadas, y estas pruebas se han ejecutado satisfactoriamente.
• Se ha comprobado que no existen errores de integración, es decir, todas las nuevas funciones están integradas con las existentes sin romper compatibilidad.
• Se han realizado pruebas funcionales manuales del flujo principal del juego.
• Se verifica que las animaciones, sonidos y colisiones se ejecutan como se espera.
• Se prueba la compatibilidad en distintas resoluciones o tamaños de ventana.
• Se simulan partidas prolongadas para detectar fugas de memoria o errores acumulativos.
• El Scrum Master ha validado la experiencia jugable.
• Se han realizado pruebas de estrés en modo multijugador (varios jugadores conectados simultáneamente).
• El sistema de guardado y carga de partidas funciona correctatmente, sin pérdida de información o corrupción de datos.

4. Releasable

• Todos los archivos necesarios para la compilación final están presentes y organizador.
• Se genera una build funcional y exportable (por ejemplo, para Windows, Apple, etc.).
• Se han eliminado recursos obsoletos o sin referencia.
• La versión está lista para demostración, entrega o testeo por parte de usuarios externos.
• El juego cumple con los requisitos mínimos de calidad acordados por el equipo.
• Los miembros del equipo han realizado una aprobación final de la entrega.
• La versión puede ser mostrada a partes interesadas (profesor o testers externos) sin necesidad de modificaciones adicionales.