|
|
|
Sin contenido |
|
|
\ No newline at end of file |
|
|
|
* **Cosas que fueron bien**:
|
|
|
|
* Mejora en la planificación del _Sprint Backlog_ con respecto al Sprint 1. Se fueron planificado las tareas a medio plazo, con periodicidad aproxidamente semanal, con esto, la planificación general del trabajo acometido durante el sprint ha sido más efectiva, y el resultado final, atendiendo al gráfico _burndown_ ha sido más fiel a la realidad.
|
|
|
|
* Mayor implicación de los _stakeholders_. Se consultaron dudas sobre las diferentes opciones en el desarrollo, que cuanto antes se decidan, más efectivo será el desarrollo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* **Incidencias**:
|
|
|
|
* Implentación de _JWT_ y _Sprint Security_. Para cumplir el objetivo del sprint era imprescindible crear una estructura real de perfiles y usuarios, de tal forma que cada usuario que accede a la aplicación tenga los privilegios imprescindibles para realizar su función. Este desarrollo ha supuesto un reto a nivel técnico, el cual ha sido superado, pero dedicando para ello un mayor tiempo al esperado.
|
|
|
|
* Adaptación componentes para ser responsive. Se han utilizado varios componentes de _Primevue_ como _Chart o Timeline_, que aportan valor al ofrecer una visualización gráfica de la información. Su adaptación a pantallas pequeñas también ha conllevado un tiempo que no estaba planificado en las tareas iniciales.
|
|
|
|
* Durante el proceso de despliegue de la API en la plataforma B4App, se detectaron problemas significativos de rendimiento que impactaron negativamente la respuesta de la aplicación. A pesar de los esfuerzos iniciales por optimizar su funcionamiento en esta plataforma, no se pudo solucinar, llegando a perder el servicio de forma aleatoria en varias ocasiones. Por consiguiente, se tomó la decisión de migrar la API a AWS (Amazon Web Services) para mejorar el rendimiento general y asegurar una operatividad más fluida. Este cambio permitió una mejor estabilidad y rendimiento para satisfacer las necesidades del proyecto y garantizar una experiencia óptima para los usuarios finales.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* **Cuestiones a mejorar**:
|
|
|
|
* Incorporar aspectos como la adaptación a pantallas pequeñas en la descripción de los issues podría prevenir la repetición de tareas ya consideradas como _done_. Por ejemplo, detallar los requerimientos específicos para la adaptación a pantallas pequeñas en la fase de planificación de tareas evitaría la necesidad de volver sobre elementos ya finalizados.
|
|
|
|
* Documentar de manera continua y detallada los eventos de Scrum a lo largo del sprint podría mejorar la transparencia y el seguimiento del progreso del equipo. Por ejemplo, documentar las algunos opiniones o debates clave, decisiones tomadas durante las reuniones _daily_. |
|
|
\ No newline at end of file |
