Skip to main content

Retrospectiva 2

Fecha: 12/03/2025

Hora inicio: 18:17

Hora finalización: 19:52

Lugar: Telemático

Aspectos positivos:​

  • Se aprobó el anterior entregable, lo cual mejoró la animosidad y motivación del grupo.
  • Hemos sido capaces de mejorar nuestra capacidad resolutiva de problemas, apoyándonos mutuamente.
  • El número de reuniones ha decrementado y se han optimizado en terminos de eficiencia.
  • Se han cumplido con las expectativas de trabajo por parte de todos los miembros del grupo.
  • Mejora de la claridad con respecto a la asignación de las tareas haciendo uso del tablero de planificación de Github.
  • La planificación ha mejorado respecto a las anteriores entregas
  • Buena comunicación dentro de cada equipo (excluye entre equipos).
  • Ambiente de colaboración entre los integrantes del grupo.

Aspectos negativos:​

  • Todavía existen ciertos aspectos relativos a la comunicación del equipo que deben mejorar (mayor fluidez).
  • La estimación de esfuerzo que implicaba conectar todo el backend con el frontend no fue acertado. Esto provocó estrés y tuvo repercusiones en la calidad del producto.
  • La distribución de las tareas de integración frontend-backend no ha sido acertada.
  • Deberíamos haber utilizado un proyecto Starter con las funcionalidades base ya implementadas, con objetivo de no reinventar la rueda (login, register, sign in ...).
  • No se han cumplido los plazos establecidos, esto se ha traducido en un arrastre de tareas hasta el final.
  • Falta de coordinación entre frontend y backend.
  • Falta de comunicación entre coordinadores y miembros.
  • Falta de comunicación entre partes dependientes en el equipo de frontend.
  • No se proporcionan detalles sobre como van avanzando las tareas, ni si han finalizado, lo cual genera incertidumbre en el sprint.
  • Ha habido problemas con la integración, lo que puede decrementar la calidad y reducir el tiempo para un buen QA.
  • La comunicación no fue fluida entre el grupo y el equipo de costes, esto es importante ya que ante cualquier modificación se deben reflejar los cambios en el coste.
  • Existen casos donde no se contestan WhatsApps y comunicaciones.
  • Cuello de botella en PM, preguntando mucho por privado.

Buenos hábitos a realizar:​

  • Repartir todas las tareas con la máxima antelación posible despues de la clase por ejemplo, y no dejar al mánager solo en esta tarea.
  • Hacer uso de los tags de clockify.
  • Trabajar en los comentarios de las issues y subissues, de forma que se genere un historial bien formado para facilitar el seguimiento.
  • comentar el estado de las tareas con frecuencia y si estas se han acabado o no. Como opción, realizar pequeños daily meetings entre los subgrupos que desempeñen la tarea.
  • Poner una reacción a los anuncios que se ponen para mostrar conformidad e implicación.
  • Implementar una mejor estimación de tiempos y complejidad de las tareas para evitar retrasos y desajustes en la planificación.(poker)
  • Estimar mejor la carga de trabajo para próximos sprints, analizar mejor el alcance de la integración y dividir tareas más equilibradamente para evitar sobrecargas.
  • Compartir más información con todos los miembros de lo que pasa en los subgrupos mas relevantes (frontend, backend, etc) aunque no todos sean miembros de los mismos.
  • Realización de reuniones backend-frontend para obtener una visión holística de la aplicación y evitar contradicciones.
  • Mayor carga de tareas para el fin de semana, con el objetivo de evitar que se agolpen durante la semana.
  • El encargado del desarrollo una pantalla debería ser responsable también de conectarla directamente al backend para asegurar un flujo más eficiente.
  • Ser más conscientes de la responsabilidad de cada uno, asi como avisar en caso de emergencias, problemas médicos o cualquier otro impedimento para reorganizar las tareas.
  • Seguir las indicacioens proporcionadas para las entradas temporales de clockify, con el objetivo de facilitar el resumen de final de sprint.

Malos hábitos a desechar:​

  • El modelo de negocio puede ser complejo de implementar, sería buena idea darle unas vueltas.
  • Desarrollar funcionalidades de frontend sin tener un backend solido.
  • Dejar de depender únicamente de estimaciones iniciales sin revisarlas durante el desarrollo.
  • Programar a la vez backend y frontend sin comunicación entre los grupos, como opción, se podría priorizar backend y despues frontend o viceversa, pero no en paralelo.
  • No planificar todas las tareas desde el principio.
  • Realizar un código sin funcionalidad (innecesario) o sin sentido.
  • Dejar despliegue para última hora.
  • Invertir tiempo en juntar backend y frontend, cuando se podría desarrollar uno a partir del otro evitando esa pérdida de tiempo
  • No crear código de calidad (código espaguetti), lo cual complica mucho la gestión de la pull request (corregir código).
  • Separar backend y frontend.
  • Saturar al PM de responsabilidades que no le corresponden.

Acciones a tomar:​

  • Comunicarnos más por los grupos para comentar que tareas se han realizado, problemas surgidos que impidan el desempeño de un compañero (enfermedades, improvistos...) y tareas por hacer.
  • Avisar a quien tenga un déficit marcado de horas para que intente compensar en próximos entregables.
  • Mantener unificados frontend y backend, asignando tareas a elementos de ambos grupos.
  • Hacer Daily meetings cada 2 días (subgrupales).
  • Seguir las indicaciones del PM en cuanto a rellenar las entradas temporales de clockify.
  • Planificar tareas antes de empezar el sprint, todos hemos de participar en esta planificación.
  • Dedicarle el tiempo necesario a las tareas para su correcta realización y así evitar exceso de trabajo en las revisiones.
  • Cambiar métricas incluyendo la revisión del compañero.
  • Mantener al tanto al equipo de las tareas.