|
|
* **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.
|
|
|
* Mayor compenetración entre los _developers_. El equipo ha evolucionado de manera positiva, alcanzándose un mayor entendimiento entre los propios miembros, lo que ha redundado en una mejora en la coordinación y eficiencia, evitándose duplicidades en la realización de las tareas.
|
|
|
|
|
|
|
|
|
|
|
|
* **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.
|
|
|
* 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 del 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.
|
|
|
|
... | ... | |