Sprint Retrospective
FISIO FIND - SPRINT RETROSPECTIVE
ÍNDICE
Ficha del documento
-
Nombre del Proyecto: FISIO FIND
-
Número de Grupo: Grupo 6
-
Entregable: #SPRINT 2
-
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)
-
Fecha de Creación: 27/03/2025
-
Versión: v1.0
Histórico de Modificaciones
| Fecha | Versión | Realizada por | Descripción de los cambios |
|---|---|---|---|
| 27/03/2025 | v1.0 | Benjamín Ignacio Maureira Flores | Elaboración del documento. |
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?
- ✅ 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.
- ✅ Cambio en la aplicación: Durante este sprint, la aplicación ha experimentado una transformación significativa, lo que demuestra el avance del equipo en el desarrollo de nuevas funcionalidades y mejoras.
- ✅ Disgregación del equipo: Aunque el equipo se dividió en varios grupos para cumplir con los objetivos establecidos, esta disgregación fue necesaria y resultó ser efectiva para avanzar en las funcionalidades críticas.
- ✅ El reparto de tareas se hizo desde el primer momento y todos los miembros trabajaron de forma equilibrada.
- ✅ Pudimos continuar de manera satisfactoria con el desarrollo de las herramientas en las videollamadas.
- ✅ Se integraron de manera exitosa que estaban relacionadas y se hacían en grupos diferentes.
BAD: ¿Qué NO salió bien?
- 🔴 Feedback de los usuarios piloto: Los usuarios piloto no han mostrado el nivel de compromiso esperado, y su feedback ha resultado insuficiente. Es necesario replantear cómo gestionar mejor su participación y la obtención de comentarios más relevantes.
- 🔴 Muchos conflictos de migraciones y de archivos que estaban siendo editados por distintas personas.
- 🔴 El continuo mergeo y cambio de develop propició una gran cantidad de fallos que tuvieron que ser corregidos, quitándonos mucho tiempo.
- 🔴 Integración: no se puede refactorizar y hacer funcionalidades al mismo tiempo, sobre todo si se trata de lo mismo, ya que produce un doble esfuerzo para completar de nuevo la funcionalidad implementada.
START: ¿Qué debemos empezar a hacer?
- 🟡 Merge diario a develop: Es crucial que todos los miembros del equipo realicen merges a develop a diario para evitar los conflictos de integración que se presentaron en este sprint. Esto contribuirá a mantener un flujo de trabajo más estable y sin sobresaltos.
- 🟡 Mejorar la comunicación con los usuarios piloto: Establecer un plan de acción claro para involucrar a los usuarios piloto de manera más activa. Debemos asegurarnos de que comprendan la importancia de su feedback y proporcionarles más contexto sobre cómo sus comentarios impactan el desarrollo de la aplicación.
- 🟡 Medición de conflictos en PRs: A partir de ahora, se realizará un seguimiento del número de conflictos en cada Pull Request y el tiempo perdido en resolverlos. Esto permitirá identificar patrones y mejorar la gestión de ramas e integraciones.
- 🟡 Pushes más frecuentes a main, ya que el despliegue se hace directamente y que esté main tan desactualizado es un problema.
STOP: ¿Qué debemos dejar de hacer?
- 🟠 Posponer tareas importantes: Dejar de retrasar tareas críticas que pueden impactar negativamente en el avance general del proyecto.
- 🟠 Dejar de trabajar con ramas tan desactualizadas.
- 🟠 Dejar de modificar archivos sin estar seguros de que van a funcionar al 100%, mucho menos si no conocemos la funcionalidad.
4. CONCLUSIONES
A partir de las discusiones anteriores, se han definido las siguientes acciones para mejorar el desempeño en el próximo sprint:
| Acción | Responsable | Fecha límite |
|---|---|---|
🔵 Asegurarse de realizar merges a develop a diario para evitar conflictos e integraciones de gran envergadura. | Todo el equipo | Diario |
| 🔵 Replantear la estrategia con los usuarios piloto para mejorar la calidad de su feedback. | Antonio y Guadalupe | Antes de la siguiente ronda de pruebas |
| 🔵 Implementar un plan de comunicación proactiva con los usuarios piloto, asegurando su compromiso y claridad sobre el impacto de sus comentarios. | Antonio y Guadalupe | Durante el próximo sprint |
Aprobado por:
Scrum Master: Antonio Macías Ferrera