Sprint 4

Feedback de las historias de usuario

• Origen: Informe de Trazabilidad y Retroalimentación (RTF)
• Revisor(es): Grupo G2 — Veneris
• Fecha: 15/11/2025
• Resultado del RTF: Comentario con sugerencias
• Objetivo: Reorganizar la estructura de las Historias de Usuario (HU) y mejorar la trazabilidad, eliminando elementos antiguos y asegurando que las HU visibles sean del desarrollo actual en este y futuros Sprints.

Como parte del análisis externo realizado por el grupo G2 Veneris, se identificó que varias Historias de Usuario provenientes de Sprints anteriores (Sprint 1 e inicios del Sprint 2) permanecían en el documento a pesar de encontrarse en desuso, haber sido reemplazadas o no guardar relación con el estado actual del backlog. Además, eran previas a la creación de pautas y requisitos de las HU, por lo que estaban mal redactadas.

Por este motivo, el equipo ha acordado implementar un proceso de depuración y actualización progresiva de las HU. En concreto:

• Se eliminarán del documento las Historias de Usuario heredadas de Sprints iniciales que ya no estén en uso o que hayan sido descartadas por cambios del desarrollo.
• Las HU que se trabajen en cada Sprint serán revisadas en profundidad, mejorando su redacción, su aceptación y su coherencia con el incremento desarrollado.
• De forma simultánea, todas las HU ya existentes serán actualizadas progresivamente para asegurar consistencia en la estructura, criterios de aceptación, propósito y alineación con los riesgos y el Sprint Backlog.
• Se documentarán claramente las HU activas de cada Sprint.

Este enfoque permitirá mantener un documento limpio, ordenado y trazable, facilitando la comunicación interna, la revisión externa y asegurando que la documentación Scrum refleje de forma fiel el proceso de desarrollo del equipo. Las decisiones tomadas y la justificación de este plan de depuración quedan registradas en la wiki del proyecto dentro del apartado “Proceso SCRUM”.

---

Feedback de la gestión de Riesgos

Plan de Acciones Correctivas y Actualización del Registro de Riesgos

• Origen: Informe de Trazabilidad y Retroalimentación (RTF)
• Revisor(es): Equipo de LogBait
• Fecha: 14/11/2025
• Resultado del RTF: ✅ Aceptado con modificaciones
• Objetivo: Integrar las 5 Acciones Correctivas recomendadas en el Registro de Riesgos (Modelo R-S-G) para fortalecer la Trazabilidad y el Control, asegurando la calidad del proceso según la metodología Boehm.

1. Plan de Acción Inmediato

Nuestro equipo debe ejecutar estas tareas de alta prioridad para formalizar la gestión de riesgos:

Acción Correctiva RTF	Tarea Concreta del Equipo	Rol Responsable	Artefacto Afectado
Asignar responsables de control por cada riesgo.	Crear una columna "Risk Owner" en el Registro de Riesgos y asignar a un miembro del equipo para cada uno de los 7 riesgos.	Líder Técnico / Scrum Master	Registro de Riesgos
Definir indicadores cuantitativos de supervisión.	Por cada riesgo, definir al menos una métrica clara y medible (Ej: "Cobertura de pruebas unitarias", "Tasa de Bug Fix", "Desviación del Estimado").	Equipo de Desarrollo / QA	Registro de Riesgos
Vincular los riesgos con tareas del backlog.	Etiquetar las Historias de Usuario (HU) o Tareas del Sprint Backlog con el ID de Riesgo (Ej: R03-Descoordinación).	Product Owner / Scrum Master	Backlog del Producto/Sprint
Incluir una matriz de reevaluación de riesgos por sprint.	Crear una sección formal para actualizar el estado, PxI y acciones en cada cierre de Sprint.	Scrum Master	Registro de Riesgos
Actualizar el plan de riesgos al cierre de cada sprint.	Incorporar esta actividad obligatoria a la Definición de Terminado del Sprint.	Todo el Equipo	Tras hacer el review y retrospective de cada Sprint

2. Estructura del Documento de Riesgos Revisado (Registro de Riesgos)

El documento debe ser actualizado para incluir las nuevas columnas y secciones que resuelven los problemas de trazabilidad y métricas.

2.1. Matriz de Identificación y Trazabilidad

Se debe modificar la matriz de riesgos para incluir las columnas críticas:

ID Riesgo	Categoría	Riesgo	Prob.	Sev.	Nivel	Risk Owner (NUEVO)	Métricas de Control (NUEVO)	HU/Tareas Afectadas (NUEVO)
R01	Técnico	Fallo en la lógica de combate.	Alto	Crítico	Intolerable	Juan (Dev. Backend)	Tasa de incidentes / Cobertura de tests unitarios (90%)	HU-005: Sistema de combate, Tarea: Code Review.
R02	Organizativo	Descoordinación de integración.	Medio	Serio	Medio	María (Scrum Master)	Tasa de deuda técnica / Retraso promedio en integración.	Tarea: Integración Continua, HU-010: Chat.
...	...	...	...	...	...	...	...	...

2.2. Nuevo Apartado: Matriz de Reevaluación Continua por Sprint (Issue tracker)

Esta sección es crucial para el proceso de Supervisión y Actualización por sprint sugeridos en el RTF.

Sprint	Fecha de Revisión	Riesgo ID	Estado Anterior	Estado Actual (PxI)	Evolución	Acción Tomada	Resultado
SPRINT 1	2025-11-28	R01	Intolerable	Alto	Reducción de PxI (Prevención efectiva)	Aumentada la cobertura de pruebas unitarias al 85%.	Riesgo contenido. Requiere más supervisión.
SPRINT 1	2025-11-28	R04	Medio	Cerrado	Ya no aplica	Se completó la tarea de uso de frameworks stables.	Riesgo cerrado.

Nota Importante: El Plan de Riesgos pasa de ser un documento estático a un Registro de Riesgos vivo que se revisa y actualiza obligatoriamente en la reunión de Retrospectiva de cada Sprint.

---

Feedback del proceso SCRUM

• Origen: Informe de Trazabilidad y Retroalimentación (RTF)
• Revisor(es): Equipo de Scrable
• Fecha: 24/11/2025
• Resultado del RTF: Comentario con sugerencias
• Objetivo: Reforzar el funcionamiento de nuestro proceso de gestión Scrum y su respectiva documentación.

El equipo Scrable ha hecho la Revisión técnica formal de este Sprint. De sus comentarios, concluimos que, en general el planteamiento está bastante alineado con los conceptos de Ingeniería del Software.

Sin embargo, hay algunos aspectos en los que podemos mejorar como son:

• Mantener un equilibrio entre el alcance del Sprint y la capacidad de desarrollo del equipo, especialmente en Sprints de desarrollo más avanzado.
• Mantener de manera explícita la prioridad de cada punto que se aborda en el Sprint, para no perder el foco.

Estas cuestiones se abordaron de nuevo en la siguiente reunión de equipo. No obstante, esta vez se abordan desde otra perspectiva, teniendo en cuenta que la sobrecarga de planificación en Sprints de complejidad elevada es algo notorio no sólo a nivel interno, sino también externo. Las conclusiones de dicha reunión se encuentran en los respectivos documentos de "Proceso SCRUM" de nuestra wiki.