Sprint Retrospective
FISIO FIND - SPRINT RETROSPECTIVE
ÍNDICE
Ficha del documento
-
Nombre del Proyecto: FISIO FIND
-
Número de Grupo: Grupo 6
-
Entregable: #SPRINT 1
-
Miembros del grupo: Alberto Carmona Sicre, Antonio Macías Ferrera, Benjamín Ignacio Maureira Flores, Francisco Capote García, Daniel Alors Romero, Daniel Fernández Caballero, Daniel Ruiz López, Daniel Tortorici Bartús, Daniel Vela Camacho, Delfín Santana Rubio, Guadalupe Ridruejo Pineda, Julen Redondo Pacheco, Miguel Encina Martínez, Francisco Mateos Villarejo, Pablo Fernández Pérez, Ramón Gavira Sánchez, Rafael Pulido Cifuentes.
-
Contribuidores: Benjamín Ignacio Maureira Flores (autor), Daniel Alors Romero (autor), Antonio Macías Ferrera (revisor)
-
Fecha de Creación: 13/03/2025
-
Versión: v1.1
Histórico de Modificaciones
| Fecha | Versión | Realizada por | Descripción de los cambios |
|---|---|---|---|
| 04/02/2025 | v1.0 | Antonio Macías Ferrera | Elaboración de la plantilla del documento. |
| 13/02/2025 | v1.1 | Benjamín Ignacio Maureira Flores, Daniel Alors Romero | Desarrollo del documento, adición de las retrospectivas de los demás grupos. |
Participantes
| Nombre completo | Rol | Contacto |
|---|---|---|
| Antonio Macías Ferrera | -- | antmacfer1@alum.us.es |
| Alberto Carmona Sicre | -- | albcarsic@alum.us.es |
| Benjamín Ignacio Maureira Flores | -- | benmauflo@alum.us.es |
| Francisco Capote García | -- | fracapgar1@alum.us.es |
| Daniel Alors Romero | -- | danalorom1@alum.us.es |
| Daniel Fernández Caballero | -- | danfercab@alum.us.es |
| Daniel Ruiz López | -- | danruilop1@alum.us.es |
| Daniel Tortorici Bartús | -- | dantorbar1@alum.us.es |
| Daniel Vela Camacho | -- | danvelcam@alum.us.es |
| Delfín Santana Rubio | -- | delsanrub@alum.us.es |
| Guadalupe Ridruejo Pineda | -- | guaridpin@alum.us.es |
| Julen Redondo Pacheco | -- | julredpac@alum.us.es |
| Miguel Encina Martínez | -- | migencmar@alum.us.es |
| Francisco Mateos Villarejo | -- | framatvil@alum.us.es |
| Pablo Fernández Pérez | -- | pablofp.33@gmail.com |
| Ramón Gavira Sánchez | -- | ramgavsan@alum.us.es |
| Rafael Pulido Cifuentes | -- | rafpulcif@alum.us.es |
1. OBJETIVOS DE LA RETROSPECTIVA
La Sprint Retrospective es una oportunidad para reflexionar en equipo sobre el desempeño durante el Sprint. En esta reunión, buscamos:
- Evaluar el trabajo realizado y los resultados obtenidos.
- Reconocer los logros y buenas prácticas implementadas.
- Identificar los desafíos y problemas enfrentados.
- Analizar oportunidades de mejora para optimizar el próximo Sprint.
Nuestro objetivo es fomentar un proceso de mejora continua, fortaleciendo la colaboración y eficiencia del equipo.
2. METODOLOGÍA UTILIZADA
El equipo utilizó un enfoque basado en cinco secciones clave:
✅ Good: Se identificaron las acciones y prácticas que funcionaron bien durante el sprint, destacando los logros y fortalezas del equipo.
🔴 Bad: Se señalaron aquellos aspectos que no se manejaron de manera óptima, incluyendo desafíos enfrentados y posibles áreas de mejora.
🟡 Start: Se discutieron iniciativas o prácticas que el equipo debería comenzar a implementar para mejorar la dinámica de trabajo.
🟠 Stop: Se identificaron procesos o hábitos que han resultado poco efectivos y que deberían ser eliminados o modificados.
🔵 Actions: A partir de los hallazgos de las secciones anteriores, se definieron acciones concretas para aplicar en los próximos Sprints, asegurando así un proceso de mejora continua.
Este tipo de retrospectiva permite que el equipo reflexione de manera estructurada sobre su rendimiento y fomenta una cultura de aprendizaje y adaptación, proceso crucial en la correcta aplicación de una metodología ágil.
3. DISCUSIÓN Y FEEDBACK
GOOD: ¿Qué salió bien?
- ✅ El reparto de tareas se hizo desde el primer momento y todos los miembros trabajaron de forma equilibrada.
- ✅ Pudimos resolver con facilidad el problema que suponía inicialmente la funcionalidad de las videollamadas.
- ✅ Aprendimos en poco tiempo a usar el stack de frontend propuesto.
- ✅ Ambiente y comunicación: el grupo al completo está satisfecho con el ambiente y la comunicación fluida que se ha generado entre los compañeros.
- ✅ Trabajo en equipo: estamos muy orgullosos de que si un compañero necesitaba ayuda, sin pensarlo, algún otro compañero le ayudaba a resolverla.
- ✅ Compromiso: Todos los miembros del equipo mostraron una actitud proactiva y se mantuvieron enfocados en cumplir con las metas establecidas, aunque a veces de forma tardía.
- ✅ Adaptibilidad: Nuestro equipo se ha adaptado satisfactoriamente a todos los cambios realizados por parte de otros grupos debido a la dependencia de los requisitos.
- ✅ Buenas decisiones: Las decisiones tomadas, como la utilización de librerias para el desarrollo del calendario o la estrutura de los JSON del horario del fisioterapeuta, fueron las adecuadas.
BAD: ¿Qué NO salió bien?
- 🔴 El bajo número de commits y pull requests ralentizó el progreso, dificultando que todos los miembros asignados a cada tarea pudieran trabajar de manera simultánea sobre el mismo código.
- 🔴 Organización: algunos compañeros del equipo no sabían cómo empezar ciertas tareas sin pisar la funcionalidad de otros compañeros, lo que generó retrasos y complicó el avance en algunos momentos.
- 🔴 Definicion de requisitos: Debido a la falta de claridad en la definicion de los requisitos, tuvimos que realizar varias reuniones para aclarar conceptos.
- 🔴 Alta dependencia: Para llevar a cabo las funcionalidades asignadas, fue necesario esperar a que existieran otros requisitos implementados previamente por parte de otros grupos, provocando retrasos en el comienzo de desarrollos.
- 🔴 Desigualdad en la carga de trabajo: Aunque se intento equilibrar las labores de cada miembro, algunos realizaron mas trabajo de lo esperado.
- 🔴 Integraciones de última hora: Debido al retraso con algunas funcionalidades, nos hemos visto obligados a hacer integraciones con toda la lógica de la aplicación cuando ya estaba próxima la fecha límite del Sprint.
- 🔴 Refactorización de los endpoints: Estando en etapas avanzadas del sprint, se solicitó la modificación del diseño para mejorar la legibilidad de los endpoints asociados a los requisitos a implementar.
START: ¿Qué debemos empezar a hacer?
- 🟡 Integración más frecuente del código a las ramas principales.
- 🟡 Añadir tests para la funcionalidades críticas como las videollamadas para garantizar que funcionan independientemente de cambios futuros.
- 🟡 Distribuir mejor las responsabilidades: Hacer revisiones semanales de la carga de trabajo para ver si alguien está sobrepasado y redistribuir tareas de forma más equitativa.
- 🟡 Distribuir mejor los recursos: Hemos observado que es necesario mas recursos para llevar a cabo las tareas de Frontend a comparación de Backend, por lo que se planteará otra asignación interna.
STOP: ¿Qué debemos dejar de hacer?
- 🟠 Evitar la integración tardía del código, ya que genera conflictos difíciles de resolver.
- 🟠 No postergar las revisiones de código, para asegurar la calidad y coherencia proyecto.
- 🟠 Trabajar de forma independiente en algunas ocasiones sin comunicar el trabajo realizado
- 🟠 Dejar los mensajes sin leer: Asegurarnos de que todos los miembros del equipo estén al tanto de la información compartida para evitar malentendidos.
- 🟠 Posponer tareas importantes: dejar de retrasar tareas críticas que pueden impactar negativamente en el avance general del proyecto.
4. CONCLUSIONES
Detalle de las acciones acordadas para el próximo Sprint. Se deberá incluir el contenido de ACTIONS, mencionando los aspectos que se deben empezar y dejar de hacer:
| Acción | Responsable | Fecha límite |
|---|---|---|
| 🔵 Aumentar la frecuencia de commits e integraciones en las ramas principales para mejorar la colaboración | Todo el grupo | Cada tres días durante el Sprint (Si se ha trabajado) |
| 🔵 Implementar revisiones intermedias en las tareas de desarrollo | Daniel Ruiz López, Rafael Pulido Cifuentes | Cada semana |
| 🔵 Definir un calendario de requisitos claro y consensuado con los equipos dependientes para evitar retrasos | Equipo de Requisitos | 21/03/2025 |
| 🔵 Planificar y documentar las integraciones de forma anticipada para evitar ajustes de última hora | Todo el equipo | 21/03/2025 |
| 🔵 Reasignar recursos hacia el Frontend para equilibrar la carga de trabajo y evitar sobrecarga en un solo ámbito | Scrum Master y Líder de Equipo | 21/03/2025 |
| 🔵 Realizar reuniones de seguimiento intermedias (mini retrospectivas) para identificar bloqueos y gestionar dependencias | Todo el equipo | 21/03/2025 |
| 🔵 Formalizar la comunicación de cambios en endpoints para minimizar la necesidad de refactorizaciones tardías | Todo el equipo | 21/03/2025 |
| 🔵 Crear un plan de inicio de tareas para evitar bloqueos entre funcionalidades | Todo el equipo | Al inicio del sprint |
| 🔵 Destacar los mensajes para asegurar la lectura del mismo por los integrantes del equipo | Todo el equipo | Diariamente |
| 🔵 Realizar una revisión al final de cada sprint sobre la distribución de la carga de trabajo y proponer mejoras si es necesario | Todo el equipo | Final de sprint |
Aprobado por:
Scrum Master: Antonio Macías Ferrera