Saltar al contenido principal

Lessons learnt

MUSCLEMATE

Musclemate, Grupo 3, Sprint 3

Historial de versiones

VersiónFechaAutorDescripción
v1.02024-02-22Manuel OrtegaCreación del documento
v2.02024-03-15Manuel OrtegaActualización del documento
v3.02024-04-4Luis García y Manuel OrtegaActualización del documento
v4.02024-04-22Alejandro Mateo CapillaActualización del documento

Resumen ejecutivo

Durante las distintas fases del proyecto han surgido algunos problemas que han sido analizados y resueltos, por ello, en este documento, se ha realizado un registro de las lecciones aprendidas.

Comunicación

A pesar de los esfuerzos por mejorar la comunicación, aún persisten problemas entre los equipos de frontend y backend. Se debe seguir trabajando en estrategias para una comunicación más efectiva entre los equipos. Por otro lado, sí que ha sido optimizada la comunicación entre miembros de un mismo equipo de trabajo mediante el uso de GitHub.

Compatibilidad horaria y Compromiso

A lo largo del sprint, se ha evidenciado que la compatibilidad horaria entre algunos miembros del equipo ha sido un desafío, lo que ha afectado la disponibilidad y el compromiso con el proyecto. Es crucial abordar este problema para optimizar la colaboración y la productividad del equipo para el siguiente sprint.

Revisar Tareas

A raíz del problema anterior ocurrieron ciertos problemas a la hora de revisar tareas. En algunos casos el equipo de frontend, por ejemplo, se ha encontrado con que alguna característica del backend había sido aceptada e incluida en la rama develop sin cerciorarse de su total y correcto funcionamiento. Esto se observó durante los primeros días del sprint y se pudo solucionar conforme se avanzaba en el proyecto. Es necesario para el siguiente sprint comenzar a hacer las cosas bien desde el primer día para evitar problemas y retrasos posibles.

Reparto de Tareas y Gestión del Tiempo

Se ha identificado que el reparto de tareas no ha sido óptimo y que la gestión del tiempo ha sido deficiente en ciertas áreas. Es esencial mejorar la asignación de tareas y dedicar tiempo suficiente a la planificación para evitar retrasos y distribuir equitativamente la carga de trabajo. Es por ello que mejoramos el reparto de tareas siendo más justo con todos los miembros del equipo y desarrollamos una fórmula que asegurarse un mínimo de tareas y un buena gestión del tiempo, debido a que si dedicas más tiempo del esperado para una tarea la fórmula penalizará en la nota de la persona responsable.

Compromiso con las Condiciones de Fallo

Algunos integrantes del equipo no han mostrado el compromiso esperado con las condiciones de fallo de la asignatura del proyecto, lo que ha generado dificultades adicionales en el desarrollo debido al desconocimiento de algunos integrantes sobre el producto que hay que entregar al final del sprint. Se debe reforzar la importancia de cumplir con los requisitos establecidos y trabajar en equipo para alcanzar los objetivos del proyecto.

Priorización Nuevas Tecnologías​

El equipo debe ser más consciente de la importancia y dificultad de la aplicación de las nuevas tecnologías al proyecto, pues la asignación de tareas como la implementación del Docker fueron asignadas a un único integrante del grupo y con un tiempo estimado corto, cuando es fácil prever que este tipo de tareas generan muchos problemas, retrasos y dificultades antes las cuales según la planificación se debería de afrontar una única persona, siendo esta estimación bastante injusta y poco realista.

Evaluación Continua del Rendimiento

Se destaca la importancia de realizar una evaluación continua del progreso del proyecto y estar dispuesto a realizar ajustes según sea necesario. Esto incluye la revisión periódica de la planificación, identificación de áreas de mejora y aplicación de soluciones para optimizar el rendimiento del equipo y el éxito del proyecto en general. La introducción de la nueva fórmula asegura un rendimiento continuo de todos los integrantes implicados en el proyecto.