control_calidad_externo.md - UCM-FDI-DISIA/proyectois1-algoritmos GitHub Wiki

Criterios para el control de calidad

Como equipo de control de calidad vamos a definir unos criterios fijos y claros de cara a estandarizar las RTFs que hagamos para el resto de equipos.

1. Criterios para las Historias de Usuario

Las historias de usuario definen los requisitos funcionales y de experiencia desde la perspectiva del jugador o usuario final.
Su formato debe ser uniforme, claro y verificable, permitiendo una trazabilidad sencilla entre la idea, su implementación y los criterios de aceptación.

1.1. Formato general

Cada historia de usuario debe escribirse en un archivo independiente siguiendo la convención:

[número]. [Título descriptivo] ([Autor o responsable])
Como [tipo de usuario o jugador],
quiero [acción o funcionalidad deseada],
para [beneficio o propósito que obtiene].

1.2. Criterios de aceptación

Cada historia debe incluir una lista de criterios de aceptación verificables, descritos en forma de lista con viñetas.
Estos criterios deben ser medibles, concretos y observables dentro del juego.

Ejemplo:

Criterios de aceptación

- El personaje responde inmediatamente a los controles de dirección.
- Se reproducen animaciones al moverse o atacar.
- Las animaciones del personaje principal se diferencian visualmente de las de los NPCs.

1.3 Recomendaciones de redacción

Utilizar un lenguaje claro y centrado en la experiencia del jugador.
Evitar términos técnicos o de implementación (por ejemplo, “script”, “variable”, “nodo”).
Mantener un único objetivo por historia. Si una historia abarca más de una funcionalidad, dividirla.
Asegurar que los criterios de aceptación permitan a los testers o revisores comprobar objetivamente si la historia está cumplida.

1.4. Ejemplo completo

3. Experiencia visual atractiva (Mateo)
Como usuario interesado en el diseño gráfico,
quiero que el juego tenga una estética visual cuidada,
para disfrutarlo como una experiencia audiovisual armoniosa.

Criterios de aceptación

- Todas las pantallas (menús, mapas) utilizan una paleta de colores coherente definida en la guía de estilo del juego.
- Las animaciones de transición (al cambiar de menú o abrir secciones) se reproducen con fluidez.
- Al activar una mecánica importante (combate, construcción o recolección), aparece un efecto visual distintivo alineado con la estética del juego.
- El uso de efectos visuales es equilibrado y no afecta negativamente el rendimiento.

2. Criterios para la Gestión de Riesgos

Estos criterios se aplican a la documentación y procesos asociados con la identificación, análisis, planificación y control de riesgos del proyecto, desde su inicio hasta su cierre.

Integridad del contenido

El plan de gestión de riesgos incluye todos los apartados requeridos: contexto, metodología, roles, herramientas, identificación, análisis, planificación de respuesta, monitoreo y control.
Se identifican todos los riesgos relevantes para el alcance, cronograma, costo, calidad y recursos del proyecto.
Cada riesgo cuenta con una descripción clara, causas, consecuencias y categoría asignada.

Metodología y coherencia

Se especifica la metodología empleada para la gestión de riesgos.
La matriz de probabilidad e impacto está claramente definida y es coherente con la metodología adoptada.
Los criterios de priorización de riesgos están claramente explicados y aplicados de forma consistente.

Trazabilidad

Cada riesgo identificado tiene un responsable asignado y un seguimiento documentado.
Existe trazabilidad entre los riesgos, las acciones de mitigación y los entregables o fases del proyecto afectados.

Plan de respuesta

Se definen acciones concretas de mitigación, contingencia y monitoreo para los riesgos más críticos.
Los planes de respuesta son realistas, medibles y asignables.
Se incluye un mecanismo formal para actualizar los riesgos durante el ciclo de vida del proyecto.

Control y comunicación

Se establecen frecuencias de revisión de riesgos y responsables del seguimiento.
Se evidencia la retroalimentación y cierre de los riesgos que ya han sido tratados.

3. Criterios para otros documentos Scrum

3.1. Criterios para el Sprint Planning

Sprint Goal claramente formulado (1 o 2 frases medibles y relevantes).
- El Sprint Goal tiene relación directa con la estrategia y el Product Backlog.
Ítems seleccionados del Product Backlog con criterios de aceptación.
Estimaciones.
- Capacidad del equipo (días disponibles, ausencias, velocidad promedio).
Plan tentativo de trabajo (cómo lograrán el Sprint Goal).
Riesgos o impedimentos previsibles.
Criterio de aceptación común o Definition of Done vigente.
Se evidencian ajustes derivados de retrospectivas anteriores.

3.2. Criterios para el Sprint Retrospective

Método de retrospectiva usado (por ejemplo: Start doing, keep doing, stop doing, more of, less of).
Observaciones detectadas en:
- Qué salió bien.
- Qué no salió tan bien.
- Qué se puede mejorar o mantener.
Acciones de mejora concretas definidas (quién, qué, cuándo).
Seguimiento a acciones del sprint anterior: estado actualizado.
Se evidencia reflexión del equipo, no es una lista de quejas y avances.
- Foco en procesos y colaboración.
- ¿Cómo fue el último Sprint en cuanto a personas y relaciones?
- ¿Cómo fue el último Sprint en cuanto a procesos y herramientas?
Las acciones son específicas, medibles y factibles.

3.3. Criterios para el Sprint Review

Análisis del Sprint completado.
- Qué historias o ítems del Product Backlog se completaron (marcar Done según la Definition of Done).
- Qué ítems quedaron incompletos y por qué.
- Qué problemas aparecieron.
- Cómo fueron resueltos esos problemas.
Demostración o resumen de funcionalidades entregadas.
- Retroalimentación recibida, si se ha lanzado un prototipo del proyecto (comentarios, sugerencias, rechazos, ajustes).
Medidas o compromisos surgidos para próximos sprints.
¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?