Gestión y análisis de riesgo - Sprint 2
Universidad de Sevilla
Escuela Técnica Superior de Ingeniería Informática
Grado en Ingeniería Informática – Ingeniería del Software
Curso: 2024 – 2025
Fecha: 24/03/2025
Versión: v1.4
Grupo de prácticas: G1
Nombre del grupo de prácticas: ISPP - Grupo 1 - Holos
- María del Mar Ávila Maqueda
- Joaquín González Ganfornina
- Nerea Jiménez Adorna
- Juan del Junco Obregón
- Miguel Ángel Gómez Vela
- Juan Antonio Moreno Moguel
- María del Carmen Barrera Garrancho
- Daniel Guedes Preciados
- Julia Virginia Ángeles Burgos
- Javier Muñoz Romero
- Juan Núñez Sánchez
- Nicolás Pérez Gómez
- Francisco Pérez Lázaro
- Celia Aguilera Camino
- Gabriel María Vacaro Goytía
- Ignacio Warleta Murcia
- José María Portela Huerta
Responsables:
| Miembro | Responsabilidad |
|---|---|
| Juan del Junco Obregón | Redactor |
| Celia Aguilera Camino | Revisora |
Repositorio: GitHub - Holos-INC
Control de Versiones
| Fecha | Versión | Descripción | Autor |
|---|---|---|---|
| 23/02/2025 | v1.0 | Creación de documento | José María Portela |
| 08/03/2025 | v1.2 | Modificación del documento | Juan del Junco Obregón |
| 13/03/2025 | v1.2 | Modificación de la portada | María del Mar |
| 17/03/2025 | v1.3 | Modificación del documento | Juan del Junco Obregón |
| 24/03/2025 | v1.4 | Modificación del documento | Juan del Junco Obregón |
Índice de Contenidos
- Introducción
- Escala de Impacto y Probabilidad en la Gestión de Riesgos
- Tabla de Riesgos
- Tabla de Seguimiento de Problemas
1. Introducción
El análisis de riesgos es un proceso fundamental en la gestión de proyectos que permite identificar, evaluar y planificar posibles eventos o situaciones que podrían afectar el éxito del proyecto. En este análisis se han identificado diversos riesgos que podrían impactar en el desarrollo, la ejecución y los resultados del proyecto.
2. Escala de Impacto y Probabilidad en la Gestión de Riesgos
-
Probabilidad de Ocurrencia
| Valor | Nivel de probabilidad | Descripción |
|---|---|---|
| 1 | Muy Baja | Es muy poco probable que ocurra. Solo se daría en circunstancias excepcionales. |
| 2 | Baja | Baja probabilidad de que se materialice, pero no puede descartarse completamente. |
| 3 | Media | Posibilidad moderada de que ocurra, dependiendo de las circunstancias. |
| 4 | Alta | Existe una alta probabilidad de que el riesgo ocurra, podría mitigarse con acciones preventivas. |
| 5 | Muy Alta | Casi seguro que el riesgo ocurra si no se toman medidas. |
-
Impacto del Riesgo
| Valor | Nivel de impacto | Descripción |
|---|---|---|
| 1 | Mínimo | El impacto en el proyecto es insignificante y no afectará su desarrollo normal. |
| 2 | Bajo | Puede generar pequeñas dificultades, pero no afecta significativamente la entrega del proyecto. |
| 3 | Medio | Puede causar retrasos o complicaciones en una parte del proyecto, pero es manejable con acciones correctivas. |
| 4 | Alto | Puede impactar de manera significativa el desarrollo del proyecto, generando retrasos importantes o sobrecostes. |
| 5 | Crítico | Afecta gravemente el proyecto, pudiendo causar su fracaso total o un impacto severo en los objetivos principales. |
-
Factor de Riesgo
El factor de riesgo se calcula multiplicando la Probabilidad × Impacto. Este valor ayuda a determinar la prioridad del riesgo y su nivel de criticidad.
-
Niveles de Prioridad
| Prioridad | Nivel de Urgencia | Descripción |
|---|---|---|
| 1 - Crítica | Extremadamente alta | Requiere atención inmediata. Puede detener el proyecto o causar su fracaso si no se gestiona adecuadamente. |
| 2 - Muy Alta | Urgente | Puede tener un impacto grave en los plazos o costos del proyecto. Necesita acciones de mitigación inmediatas |
| 3 - Alta | Alta | Riesgo significativo que debe ser monitoreado continuamente para evitar problemas. |
| 4 - Considerable | Importante | Puede causar retrasos o impactos moderados en el proyecto si no se maneja correctamente. |
| 5 - Media-Alta | Necesita seguimiento | Se debe gestionar de forma proactiva, pero es manejable si se siguen las estrategias de mitigación. |
| 6 - Media | Moderada | Impacto menor en el proyecto, pero se deben tomar medidas preventivas. |
| 7 - Baja | Poco relevante | Riesgo poco probable o con impacto reducido. No es una prioridad alta. |
| 8 - Muy Baja | Irrelevante | Es un riesgo menor con impacto casi insignificante. Solo se gestiona si se materializa. |
| 9 - Mínima | Despreciable | Impacto y probabilidad extremadamente bajos. Prácticamente no requiere gestión. |
| 10 - Insignificante | Sin relevancia | No representa un peligro real para el proyecto, su impacto es mínimo o nulo. |
3. Tabla de Riesgos
A continuación se presenta una tabla que resume los principales riesgos, su impacto y probabilidad, así como las medidas de contingencia que se han diseñado para mitigar o manejar cada uno de estos riesgos.
| ID | Riesgo | Impacto | Probabilidad | Factor | Prioridad | Mitigación del Riesgo |
|---|---|---|---|---|---|---|
| R1 | Cambios frecuentes en el alcance y nuevos requisitos durante el desarrollo | 3 | 2 | 6 | 5 | Implementar un proceso de gestión de cambios y asegurar revisiones periódicas |
| R2 | Requisitos incompletos o erróneos | 3 | 2 | 6 | 5 | Asegurar que los requisitos estén bien definidos y aprobados antes del inicio del proyecto; revisión continua. |
| R3 | Problemas de cohesión y motivación del grupo | 3 | 2 | 6 | 4 | Reuniones de equipo frecuentes, retroalimentación constante, reconocimiento de logros y mantener un ambiente positivo. |
| R4 | Dificultades con la integración y compatibilidad tecnológica | 2 | 3 | 6 | 5 | Planificación de pruebas de integración, pruebas de compatibilidad regulares y uso de herramientas de integración. |
| R5 | Retrasos en actividades claves | 4 | 2 | 8 | 2 | Uso de herramientas de gestión de proyectos para hacer un seguimiento continuo y ajustar plazos. Además de la reasignación de tareas en caso de sobrecarga o bloqueos. |
| R6 | Errores en la planificación del presupuesto | 2 | 2 | 4 | 7 | Revisión periódica del presupuesto, establecimiento de un margen de contingencia y ajuste continuo. |
| R7 | Problemas de seguridad en la aplicación | 3 | 2 | 6 | 4 | Auditorías de seguridad periódicas, uso de buenas prácticas de desarrollo seguro y actualizaciones constantes. |
| R8 | Falta de pruebas y validaciones | 2 | 3 | 6 | 5 | Implementar pruebas exhaustivas, incluyendo pruebas de carga y escalabilidad. |
| R9 | Mala calidad del código | 2 | 1 | 2 | 8 | Implementar revisiones de código regulares, estándares de codificación y usar herramientas de análisis |
| R10 | Insatisfacción de los usuarios piloto | 4 | 2 | 8 | 3 | Recopilación activa de comentarios y retroalimentación, ajustes en base a los comentarios de los usuarios piloto. |
| R11 | Baja productividad del equipo | 3 | 1 | 3 | 7 | Identificar y abordar las causas de baja productividad |
| R12 | Documentación deficiente | 2 | 2 | 4 | 6 | Priorizar la creación y actualización de la documentación técnica y de proyecto de manera continua. |
| R13 | Miembros del proyecto deciden dejar el proyecto | 3 | 1 | 3 | 7 | Abordar proactivamente las preocupaciones del equipo. |
| R14 | Falta de capacidades técnicas o preparación insuficiente | 1 | 3 | 3 | 7 | Dejar tiempo para que los miembros del equipo vean tutoriales y cursos sobre las tecnologías que no conocen. |
| R15 | Falta de comunicación entre equipos de Backend y Frontend | 4 | 4 | 16 | 2 | Establecer reuniones periódicas entre los equipos y coordinar entregas con integración continua. |
| R16 | Usuarios pilotos no responden | 3 | 4 | 12 | 3 | Implementar recordatorios automáticos, incentivar la participación y diversificar las fuentes de feedback. |
| R17 | Mala organización del sprint | 4 | 4 | 16 | 1 | Planificar en detalle cada tarea del sprint, definir claramente las responsabilidades y tareas, y usar GitHub Projects como herramienta para dar seguimiento. |
| R18 | Burnout en el equipo | 3 | 4 | 12 | 3 | Fomentar pausas activas, equilibrar la carga de trabajo, detectar signos tempranos de agotamiento y mantener una comunicación constante para ajustar expectativas. |
| R19 | Fallos en el despliegue | 5 | 3 | 15 | 1 | Asignación de responsables específicos para el despliegue, pruebas en entornos controlados antes de la entrega y automatización de procesos cuando sea posible. |
| R20 | Dependencia de servicios externos | 3 | 3 | 9 | 4 | Identificar dependencias críticas, mantener versiones estables y planificar alternativas ante caídas o cambios en servicios de terceros. |
| R21 | Confusión en la gestión de ramas | 3 | 3 | 9 | 4 | Establecer una convención clara de nombres y flujos de trabajo en Git, formar al equipo y revisar PRs antes de fusionar. |
| R22 | Escasa implicación de algún miembro | 3 | 2 | 6 | 5 | Mantener la motivación mediante reconocimiento, comunicar expectativas con claridad y redistribuir tareas si hay inactividad prolongada. |
| R23 | Errores no detectados en testing | 4 | 3 | 12 | 3 | Ampliar la cobertura de pruebas, revisar los tests críticos y aplicar testing manual en funcionalidades clave. |
| R24 | Cambios tardíos sin validación | 4 | 2 | 8 | 3 | Establecer fechas límite internas para cambios, exigir revisión obligatoria y pruebas antes de cualquier merge final. |
| R25 | Incumplimiento de aspectos legales o de privacidad | 4 | 2 | 8 | 3 | Revisar la normativa vigente (como el RGPD), evitar la recopilación innecesaria de datos personales, y asegurar que las funcionalidades relacionadas con usuarios cumplan con los principios de protección de datos. |
4. Tabla de Seguimiento de Problemas
| ID | Explicación | ¿Sigue vigente? | Acciones tomadas | Trazabilidad |
|---|---|---|---|---|
| P1 | Persiste el riesgo de una mala organización del sprint, que podría afectar la distribución de tareas y las entregas. | Sí | Se han reforzado las reuniones de planificación y se detallan mejor las tareas en GitHub Projects. | Número de tareas replanificadas o retrasadas: Si disminuye, la planificación es más efectiva. / Tareas replanificadas / tareas planificadas = 0 cuanto más cercano a 0 mejor |
| P2 | Se está percibiendo desmotivación en algunos miembros, posiblemente por carga de trabajo desigual o falta de implicación. | Sí | Se ha fomentado el reconocimiento interno y se están rotando tareas para mantener el interés y la equidad. | Tendencia del estado de ánimo después de la implementación de las medidas. |
| P3 | Siguen existiendo fallos en el despliegue que impiden entregar una versión funcional estable. | No | Se han asignado responsables, se está automatizando el proceso y haciendo pruebas en entorno de staging. | Éxito en despliegues automáticos (%) → Si aumenta, la automatización está funcionando bien. |
| P4 | Se han producido errores y conflictos en varias ramas debido a una gestión inadecuada de ramas, esto ha provocado que se produzca pérdida de tiempo y necesidad de rehacer cambios o de resolver conflictos. | Sí | Se establece la práctica de cerrar ramas inmediatamente después de hacer merge de esta rama para evitar confusiones innecesarias y mantener el repositorio lo más limpio posible. | Workflow que detecta las ramas inactivas desde hace más de 7 días y las añade en un txt de ramas inactivas, para que alguien las revise y elimine. Además se analiza cuántas ramas inactivas se detectan semanalmente y cuántas se eliminan efectivamente. Si el número de ramas inactivas disminuye con el tiempo, la solución está funcionando. |
| P5 | El retraso en la entrega a los usuarios piloto puede generar insatisfacción o desinterés por parte de estos. | Sí | Se está priorizando la finalización del MVP funcional y se ha comunicado a los usuarios una nueva fecha de entrega estimada. | Medir los días de retraso (Fecha real de entrega - fecha estimada inicial) / Tasa de abandono de usuarios piloto (UP que abandonan/UP)x100 |
| P6 | Los equipos de Backend y Frontend trabajaron por separado sin coordinarse, lo que resultó en problemas de integración. Ahora falta conexión entre el frontend y el backend, generando retrasos y necesidad de refactorización. | Sí | Se han creado reuniones de sincronización y las nuevas tareas se asignarán en parejas (un desarrollador de Backend y uno de Frontend) para garantizar la conexión entre ambos. | % de funcionalidades integradas sin errores - (Integraciones exitosas / Total de integraciones) × 100 |
| P7 | Se han asignado tareas repetidas a distintos miembros sin coordinación, provocando duplicidad de trabajo. El mayor problema fue la falta de comunicación entre coordinadores o Project Managers al repartir tareas. | Sí | Se ha decidido enviar las tareas de forma más coordinada, mejorando la comunicación entre coordinadores y PM, y definir claramente la "Definition of Done" en cada issue para evitar ambigüedades. | Número de tareas duplicadas por sprint → El objetivo es que este valor tienda a 0. |
| P8 | Falta de revisión exhaustiva en las tareas y ausencia de prácticas de aseguramiento de calidad, lo que aumenta el riesgo de errores no detectados. | Sí | Se ha acordado realizar revisiones más rigurosas en las pull requests y utilizar herramientas como SonarQube para mantener la calidad del código. | Número de PR que, tras ser mergeadas, han requerido correcciones por fallos que no se detectaron en la revisión → El objetivo es que este número tienda a 0. |