Skip to main content

Lecciones Aprendidas del S1

Universidad de Sevilla

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: 20/04/2025
Versión: v1.1

Grupo de prácticas: G1
Nombre del grupo de prácticas: ISPP - Grupo 1 - Holos

Miembros del equipo:

  • 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:

MiembroResponsabilidad
Ignacio WarletaRedactor
Gabriel VacaroRevisor

Repositorio: GitHub - Holos-INC

Tabla de versiones​

VersiónFechaDescripción de cambiosAutor
v1.020/04/2025Creación del documentoIgnacio Warleta
v1.120/04/2025Revisión del documentoGabriel Vacaro

Índice de Contenidos​

  1. Introducción
  2. Análisis de la condición de fallo
  3. Listado de problemas relacionados
  4. Metodología y roles
  5. Análisis individual de cada problema

Introducción​

El Sprint 1 concluyó sin que el equipo pudiera entregar una versión funcional y desplegada a tiempo. Esta fue la principal condición de fallo del entregable, derivada de la acumulación de problemas organizativos, técnicos y de gestión.

Este documento identifica esas causas y propone las acciones de mitigación que se han puesto en marcha para evitar que situaciones similares vuelvan a repetirse.

Análisis de la condición de fallo​

Condición de fallo:

  • La aplicación no se pudo desplegar en producción en la fecha límite del Sprint.

Causas principales:

  • Tareas clave no finalizadas a tiempo.
  • Fallos de integración en la unión frontend-backend.

Listado de problemas relacionados​

1. Problemas identificados por el equipo antes de la entrega:​

  • Tareas clave no finalizadas a tiempo
  • Problema de integración entre frontend y backend

2. Problemas identificados por el equipo después de la entrega:​

  • Intencionalmente en blanco.

3. Problemas identificados por el revisor del entregable (profesor):​

  • La aplicación no contaba con un despliegue

Metodología y roles​

Metodología seguida​

El equipo siguió la metodología SCRUM recomendada a lo largo de la carrera. Para ello se hicieron daily meetings donde se informa de 4 puntos: Tareas realizadas, tareas en proceso, tareas que pueden tener listas para la siguiente daily y problemas encontrados. Se hizo un sprint planning al inicio del sprint donde se crearon y asignaron las issues correspondientes al sprint. Y se hizo al finalizar el sprint un sprint retrospective.

Roles del equipo​

  • CELIA AGUILERA CAMINO: Responsable de Redes Sociales.
  • JULIA VIRGINIA ANGELES BURGOS: Coordinadora de Frontend.
  • MARIA DEL MAR AVILA MAQUEDA: Responsable del aseguramiento de comprobar que cumplimos los criterios para aprobar.
  • MARIA DEL CARMEN BARRERA GARRANCHO: Jefe de costes de la aplicación.
  • JUAN DEL JUNCO OBREGON: Secretario, es decir, responsable de tomar acta y recoger el feedback.
  • MIGUEL ANGEL GOMEZ VELA: Responsable del uso de IA, y de la inclusión de esta en los documentos.
  • JOAQUIN GONZALEZ GANFORNINA: Responsable de revisar costes.
  • DANIEL GUEDES PRECIADOS: Responsable de subir información en la base de conocimiento común.
  • NEREA JIMENEZ ADORNA: Responsable de usuarios pilotos.
  • JUAN ANTONIO MORENO MOGUEL: Coordinador de Backend. Responsable de que se recojan las métricas del equipo.
  • JAVIER MUÑOZ ROMERO: Responsable de calidad software.
  • JUAN NUÑEZ SANCHEZ: Responsable de calidad de documentación.
  • NICOLAS PEREZ GOMEZ: Responsable de revisar los competidores.
  • FRANCISCO PEREZ LAZARO: Responsable de imagen, manteniendo la homogeneidad en Frontend, Landing Page y Presentaciones.
  • JOSE MARIA PORTELA HUERTA: Project Manager, responsable de gestión de problemas entre miembros del grupo, y de asignar, organizar y crear tareas.
  • GABRIEL MARÍA VACARO GOYTIA: Secretario, es decir, responsable de tomar acta y recoger el feedback. Y responsable del docusaurus del grupo.
  • IGNACIO WARLETA MURCIA: Responsable de que el equipo acate el feedback.

Análisis individual de cada problema​

1. Tareas clave no finalizadas a tiempo:​

  • Descripción: Hubo una mala organización a la hora de priorizar la importancia de ciertas tareas y se acabaron dejando para el final tareas que incluían funcionalidades core.

  • Origen técnico: La falta de una estimación adecuada de tiempo para completar las tareas críticas hizo que las tareas relacionadas con las funcionalidades principales se retrasaran. La integración de estas funcionalidades al final del sprint generó conflictos y errores difíciles de resolver en un márgen de tiempo mínimo.

  • Origen del proceso: Durante el Sprint Planning, no se asignó suficiente tiempo para las tareas clave, y el equipo no realizó un análisis adecuado de la complejidad de cada tarea. En las Daily meetings no se detectó ningún retraso a pesar de que se mencionó.

  • Personas responsables: Aunque no hubo una única persona responsable, la falta de comunicación clara entre el PM y los miembros del equipo contribuyó a que el seguimiento de las tareas no fuera lo suficientemente riguroso. Se podría haber realizado un mejor seguimiento de las prioridades durante las Daily Meetings y garantizar que las tareas críticas tuvieran el tiempo adecuado asignado.

  • Acciones mitigadoras: Para evitar que este problema se repita en futuros sprints, se asignó a Mar la responsabilidad de analizar las failure conditions con tiempo y de revisar que se cumplieran todas y cada una de ellas. Además, se crearon dos canales nuevos de comunicación: uno para comunicar el trabajo terminado y otro para incidencias encontradas. De esta forma se pretendió estar más pendiente de cómo avanzaban tareas claves. Tras la enterga del S3, podemos asegurar que el uso de estos canales ha sido efectivo ya que se redujeron significativamente los bloqueos inesperados y las tareas clave fueron completadas a tiempo. Los miembros del equipo pudieron informar sobre los avances de manera más eficiente, y cualquier incidencia fue gestionada rápidamente, lo que permitió un mejor flujo de trabajo y colaboración.

  • Estado: Resuelta.

2. Problema de integración entre frontend y backend:​

  • Descripción: Cada equipo trabajó aislado, sin comunicación ninguna, lo que generó fricciones al momento de integrar funcionalidades y provocó incompatibilidades en los datos y servicios proporcionados por cada parte.

  • Origen técnico: El backend enviaba datos con un formato que no era compatible con lo que el frontend podía procesar. Además, el backend no contemplaba algunos casos de manejo de errores que el frontend necesitaba gestionar correctamente.

  • Origen del proceso: La falta de una planificación detallada en el Sprint Planning y la ausencia de comunicación dificultaron la identificación temprana de los problemas de integración. No hubo comunicación suficiente entre los equipos de frontend y backend durante las fases de desarrollo.

  • Personas responsables: La responsabilidad recae en los líderes de los equipos de frontend (Julia Virginia Ángeles Burgos) y backend (Juan Antonio Moreno Moguel), ya que ambos deberían haber fomentado una mejor comunicación y coordinación. Ambos equipos deberían haber trabajado más estrechamente durante el desarrollo y asegurarse de que los datos y servicios estuvieran alineados desde el principio.

  • Acciones mitigadoras: Para solucionar este problema se estableció una forma de trabajo en parejas interdisciplinares. Si bien ha seguido habiendo problemas entre backend y frontend hemos alcanzado un rango bajo y aceptable de estos.

  • Estado: Resuelta.

3. La aplicación no contaba con un despliegue funcional:​

  • Descripción: No se pudo desplegar la aplicación debido a conflictos y problemas no triviales que impidieron el correcto despliegue de la aplicación.

  • Origen técnico: Problemas de integración entre backend y frontend, como se ha mencionado antes, fue la causa principal de no poder entregar un despliegue funcional.

  • Origen del proceso: La falta de una priorización correcta de las tareas fue la causa principal de no alcanzar con éxito este objetivo.

  • Personas responsables: El Project Manager (José María Portela Huerta) y el responsable de Backend (Juan Antonio Moreno Moguel) fueron responsables de la gestión de las tareas y la supervisión del progreso del equipo. Ambos deberían haber dado mayor prioridad a las tareas de despliegue y gestión de la infraestructura desde el principio.

  • Acciones mitigadoras: Para los siguientes sprints, se incluyó una tarea específica de preparación del despliegue dentro del Sprint Planning, la cual se tomó, tras este suspenso, como una prioridad absoluta. Tras la entrega suspensa del S1, no hemos vuelto a sufrir ningún problema de despliegue, aprendiendo así de nuestro error.

  • Estado: Resuelta.