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

Reducción, Supervisión y Gestión de Riesgos

A continuación, se presentan los principales riesgos identificados en el proyecto, junto con las estrategias de reducción, supervisión y gestión propuestas, según el Plan RSGR, el cual seguimos como marco para asegurar el control y la mitigación de riesgos durante todo el desarrollo. El objetivo es prevenir que los riesgos se materialicen, supervisar su evolución a lo largo de los sprints y aplicar planes de contingencia en caso de que se hagan reales.

1. Cambios constantes en requisitos

Probabilidad: Frecuente

Severidad: Crítica

Nivel de riesgo: Intolerable

Descripción: En el desarrollo del juego, pueden surgir modificaciones frecuentes en las mecánicas, la estética o las funcionalidades a medida que avanza el diseño. Estos cambios impactan directamente en la planificación de los sprints, pudiendo así generar retrabajo, retrasos en las entregas y pérdida de coherencia en el diseño general del sistema si no se gestionan adecuadamente.

1.1 Reducción

  • Mantener un Product Backlog dinámico, priorizado por importancia y complejidad.
  • Definir criterios de aceptación claros antes del desarrollo de cada historia de usuario.
  • Realizar reuniones semanales de refinamiento para validar cambios y evitar interrupciones en los sprints.
  • Aprobación consensuada de cambios, siempre precedida por una evaluación del impacto en alcance y cronograma.

1.2 Supervisión

  • Revisión del Backlog en cada Sprint Review y control de la frecuencia de modificaciones.
  • Registro de solicitudes de cambio.
  • Evaluación del cumplimiento de los criterios de aceptación en cada historia afectada por cambios.

1.3 Gestión

  • Si el riesgo se materializa, se aplicará una revisión de alcance y sprint replanning.
  • Se llevará a cabo un ajuste del calendario o reducción de drafts secundarios para mantener los hitos críticos del proyecto dentro de fechas.

2. Falta de habilidades técnicas

Probabilidad: Frecuente

Severidad: Crítica

Nivel de riesgo: Intolerable

Descripción: Si el equipo no cuenta con las habilidades técnicas necesarias o la experiencia suficiente en motores de juego y arte digital, pueden aparecer errores, baja calidad visual o demoras en la implementación de funcionalidades clave.

2.1 Reducción

  • Hacer sesiones de code review para transferencia de conocimiento entre miembros del equipo.
  • Distribuir tareas según fortalezas individuales y fomentar aprendizaje cruzado.
  • Dividir tareas complejas en módulos simples y asignarlas a miembros con habilidades afines.
  • Utilizar librerías, frameworks y recursos preexistentes para reducir la complejidad técnica sin comprometer la calidad.

2.2 Supervisión

  • Evaluar semanalmente la autonomía técnica del equipo y la calidad de los avances.
  • Revisar las tendencias de velocidad de trabajo para detectar bloqueos técnicos.
  • Monitorear los problemas técnicos en un tablero junto con su tiempo de resolución.

2.3 Gestión

  • Si se materializa la falta de capacidades, se priorizará la simplificación de funcionalidades o la reutilización de código existente.
  • Redistribución temporal de tareas y posible incorporación de apoyo externo (expertos puntuales como lo serían compañeros de carrera de cursos superiores).

3. Requisitos mal definidos o no cumplidos

Probabilidad: Frecuente

Severidad: Crítica

Nivel de riesgo: Intolerable

Descripción: Una definición ambigua o incompleta de los requisitos del videojuego, ya sea en las mecánicas, el estilo visual o las funcionalidades, puede causar confusión en el equipo, desarrollo incoherente o pérdida de tiempo en tareas no alineadas con los objetivos, así como inconsistencias entre lo planeado y lo implementado, afectando los plazos del proyecto.

3.1 Reducción

  • Priorizar las funcionalidades con la metodología MoSCoW (Must, Should, Could, Won’t) para evitar dispersión de esfuerzos.
  • Usar historias de usuario bien redactadas y criterios de aceptación medibles para cada requisito funcional.
  • Mantener un backlog compartido con descripciones actualizadas y responsables asignados, registrando quién y cuándo realiza cada modificación en el proyecto y/o requisitos del mismo.
  • Realizar retrospectivas breves al final de cada sprint, enfocadas en discutir requisitos poco claros o problemáticos.

3.2 Supervisión

  • Mantener un historial de decisiones de diseño (por qué se aprobó o modificó un requisito) e irlo comparando con lo implementado para detectar desviaciones funcionales.
  • Evaluar el impacto de cualquier cambio en requisitos sobre el cronograma y actualizar el plan de trabajo.
  • Implementar una trazabilidad de requisitos → tareas → commits, para asegurar que cada entrega se relaciona con un objetivo claro.

3.3 Gestión

  • Si se detecta un requisito mal definido en fase avanzada, activar un proceso de revisión urgente con el equipo.
  • Implementar versiones temporales o simplificadas del requisito afectado para no detener el desarrollo principal.

4. Retrasos en tareas clave

Probabilidad: Frecuente

Severidad: Crítica

Nivel de riesgo: Intolerable

Descripción: La interdependencia entre tareas críticas, como la programación de la jugabilidad básica, la implementación del modo multijugador o el diseño de los recursos visuales, afecta directamente la planificación del sprint, la integración del proyecto y el cumplimiento de los hitos globales, pues al tratarse de un videojuego, los retrasos en una sola parte pueden paralizar el progreso general.

4.1 Reducción

  • Establecer dependencias claras entre tareas desde la planificación inicial (por ejemplo, el mapa antes de la generación aleatoria de recurso al comienzo de la partida).
  • Usar estimaciones realistas de esfuerzo, y dividir las tareas grandes en subtareas pequeñas y manejables.
  • Identificar desde el inicio las tareas críticas para el progreso del videojuego (motor de colisiones, sistema de guardado, etc) y priorizar la implementación temprana de estos componentes base sobre las mejoras estéticas o secundarias.
  • Repartir la carga de trabajo de forma equilibrada, evitando la sobreasignación de tareas a una sola persona.

4.2 Supervisión

  • Usar herramientas de seguimiento visual de progreso (como tableros Kanban) para detectar bloqueos con rapidez y revisar semanalmente el porcentaje de avance real vs. planificado en tareas.
  • Analizar las causas de los retrasos recurrentes (tiempo insuficiente, alta complejidad técnica, baja participación del equipo).
  • Comunicar al equipo con antelación cualquier retraso previsto para reorganizar las tareas restantes.

4.3 Gestión

  • Realizar un análisis de impacto en el cronograma global, ajustando futuras entregas.
  • Implementar una versión mínima viable (MVP) del componente afectado por el retraso crítico para mantener la funcionalidad básica del juego.

5. Objetivos no alcanzados o desviaciones por alta complejidad

Probabilidad: Frecuente

Severidad: Catastrófica

Nivel de riesgo: Intolerable

Descripción: El desarrollo del videojuego implica una alta complejidad, especialmente en la integración de la simulación de recursos y el modo multijugador persistente. Esta complejidad puede derivar en una sobrecarga de tareas, mal dimensionamiento de tiempos, o dificultades técnicas que impidan cumplir con los objetivos iniciales en los plazos previstos o con la calidad deseada.

5.1 Reducción

  • Priorizar el desarrollo de un prototipo funcional temprano para validar la viabilidad técnica de las mecánicas centrales.
  • Realizar pruebas de comportamiento en versiones tempranas del juego, evitando que los problemas escalen.
  • Establecer un backlog flexible que permita ajustes técnicos sin comprometer las metas principales.
  • Definir objetivos específicos, medibles, alcanzables, relevantes y con plazo definido para cada sprint.

5.2 Supervisión

  • Monitorear la evolución del burn-down chart y detectar tendencias de retraso.
  • Revisar las métricas de rendimiento del juego (FPS, uso de memoria) como indicadores indirectos de complejidad no controlada.
  • Supervisar métricas clave de rendimiento (FPS, uso de memoria) como indicadores indirectos de complejidad técnica no gestionada.

5.3 Gestión

  • Si un objetivo resulta inalcanzable dentro del sprint, redefinir su alcance manteniendo la coherencia con la experiencia de usuario prevista.
  • Aplazar o simplificar temporalmente elementos secundarios (animaciones, efectos visuales, etc.) si amenazan los plazos críticos.

6. Complejidad técnica del modo multijugador persistente

Probabilidad: Frecuente

Severidad: Crítica

Nivel de riesgo: Intolerable

Descripción: El desarrollo de un modo multijugador con persistencia de partidas implica desafíos técnicos significativos: sincronización entre la vista local y la estratégica, actualización en tiempo real de los datos de los jugadores, gestión de eventos simultáneos y consistencia del estado del juego.

6.1 Reducción

  • Limitar inicialmente el número de jugadores simultáneos para controlar complejidad y errores.
  • Dividir la funcionalidad en módulos independientes: sincronización, persistencia, interfaz y comunicación.
  • Usar tests automatizados y simulaciones de partidas para detectar problemas de sincronización.
  • Crear un prototipo funcional mínimo (MVP) del sistema multijugador antes de añadir guardado de partida, ranking y chat.

6.2 Supervisión

  • Realizar testing incremental y automatizado para detectar desincronización o pérdida de datos.
  • Supervisar el grado de alineación entre el diseño técnico y el plan de desarrollo, asegurando que los módulos evolucionan coordinadamente.
  • Verificar el correcto registro y recuperación de datos persistentes tras cada iteración.

6.3 Gestión

  • Activar planes de contingencia que deshabiliten temporalmente funciones avanzadas del modo multijugador si provocan errores críticos.
  • Revertir temporalmente a un modo multijugador no persistente, desactivar la sincronización en tiempo real y optar por actualizaciones por turnos.

7. Carga de trabajo en IA, simulación y gestión de recursos

Probabilidad: Frecuente

Severidad: Crítica

Nivel de riesgo: Intolerable

Descripción: El proyecto incluye la implementación de inteligencia artificial para simulación poblacional, así como la gestión dinámica de la aparición de recursos. Parte de esta lógica podría depender de generación de código asistida por IA, lo que aumenta el riesgo de errores, inconsistencias o comportamientos inesperados, afectando la jugabilidad del juego.

7.1 Reducción

  • Priorizar la implementación de una IA y simulación simplificada en la primera versión del juego, aumentando la complejidad gradualmente.
  • Revisar y validar el código generado por IA, asegurando su adaptación al estilo y estructura del proyecto.
  • Usar pruebas unitarias y de integración para validar comportamientos de la IA antes de integrarlos en el juego completo.
  • Limitar la generación de contenido automatizada por IA a tareas repetitivas o auxiliares, dejando la lógica crítica al equipo humano.

7.2 Supervisión

  • Detectar cualquier comportamiento inesperado o inconsistencia en el juego y documentarlo para corrección inmediata.
  • Supervisar la eficacia de las pruebas unitarias y de integración, ajustando los casos de prueba según los hallazgos.
  • Coordinar revisiones de código con más de un miembro del equipo para verificar la coherencia de cualquier generación de recursos.

7.3 Gestión

  • Si surgen inconsistencias significativas, aplicar planes de contingencia modulares, desactivando temporalmente aquellos módulos de IA o simulación que presenten errores críticos para mantener el juego jugable.
  • Mantener versiones de respaldo de las simulaciones y configuraciones de IA para poder restaurar el estado estable del juego rápidamente.