Retrospective2

Retrospective Sprint 2

¿Qué hicimos bien?	¿Qué hicimos mal?	¿Qué aprendimos?	¿Qué deberíamos cambiar?
Juan: Se implementaron el inicio de sesión (HU02) y la recuperación de contraseña (HU03), con validación de credenciales, bloqueo por intentos fallidos y envío del enlace de recuperación por correo.	Juan: La configuración del servidor de correo (SMTP) tomó más tiempo del previsto y retrasó el avance de la HU03.	Juan: Aprendí a configurar servicios externos como el envío de correos y a manejar tokens con tiempo de vigencia.	Juan: Probar al inicio del sprint las integraciones con servicios externos antes de desarrollar la lógica que depende de ellas.
Diego: Se implementó la consulta y edición de perfil (HU04) en el backend y en Flutter, con el correo en solo lectura, cambio de foto de perfil y cambio de contraseña validando la actual.	Diego: Al inicio del sprint se perdió tiempo migrando el entorno de desarrollo a un equipo nuevo, y la HU04 dependía de la HU02 para obtener el usuario autenticado.	Diego: Aprendí a desarrollar una HU que depende de otra aún no terminada, usando un punto temporal (id enviado por el front) fácil de reemplazar después.	Diego: Documentar la configuración del entorno para reinstalarlo rápido y acordar desde el inicio el orden de las HU que dependen entre sí.
Yeimy: Se implementó la edición de mascota publicada (HU06) reutilizando el módulo de mascotas de la HU05, incluyendo la gestión de fotos.	Yeimy: Fue necesario estudiar el código de la HU05 antes de empezar, lo que tomó tiempo al inicio del sprint.	Yeimy: Aprendí a reutilizar el código de un compañero sin modificarlo, extendiéndolo desde mi propia HU.	Yeimy: Revisar al inicio del sprint el código del que depende la HU y resolver las dudas con su autor desde el primer día.
Equipo: Se cumplió el horario fijo de Daily's (lunes y miércoles), una de las mejoras acordadas en la retrospectiva del Sprint 1.	Equipo: En algunas Daily's los bloqueantes no se describieron con suficiente detalle.	Equipo: Tener un horario fijo de reuniones mejora el seguimiento del avance de cada HU.	Equipo: Describir en cada Daily el bloqueante concreto y quién puede ayudar a resolverlo.
Equipo: Se revisaron los criterios de aceptación antes de comenzar cada HU, como se acordó en el Sprint 1.	Equipo: Algunas HU dependían de otras del mismo sprint (HU04 de HU02 y HU06 de HU05), lo que obligó a usar soluciones temporales.	Equipo: Identificar las dependencias entre HU durante la planeación evita bloqueos durante el desarrollo.	Equipo: Ordenar las HU por dependencias en el Sprint Planning y priorizar las que otras HU necesitan.
Equipo: Cada integrante trabajó en módulos y archivos propios, lo que evitó conflictos al unir las ramas en develop.	Equipo: Al compartir la misma base de datos en Supabase, los datos de prueba de todos los integrantes se mezclaron.	Equipo: Trabajar en módulos separados facilita la integración y reduce los conflictos de Git.	Equipo: Usar datos de prueba ficticios identificables por integrante y limpiar la base de datos al cerrar cada sprint.
Equipo: Se integraron frontend y backend de forma progresiva durante el desarrollo de cada HU.	Equipo: Algunos Pull Requests se crearon cerca del cierre del sprint, dejando poco tiempo para su revisión.	Equipo: Revisar los Pull Requests temprano permite corregir los errores antes del cierre del sprint.	Equipo: Crear el Pull Request apenas la HU esté funcional y fijar un plazo para su revisión.
Equipo: Se mantuvo la comunicación constante por WhatsApp y reuniones virtuales para resolver dudas.	Equipo: Algunos errores encontrados en HU de otros compañeros (por ejemplo, en la HU01) tardaron en corregirse.	Equipo: Reportar los errores al dueño de la HU, en lugar de corregirlos uno mismo, evita conflictos en el código.	Equipo: Registrar los errores como Issues en GitHub con un responsable asignado.