|
|
## Mejoras aplicadas
|
|
##### Aspectos a Mejorar
|
|
|
|
|
|
|
|
Además del plan de pruebas detallado en la Sprint Review 2, se realizó la reunión semanal con el cliente que quedó establecida durante el Sprint Retrospective 1. El calendario de reuniones fue el siguiente:
|
|
Una vez finalizado el segundo sprint se han identificado una serie de aspectos a mejorar de cara al siguiente.
|
|
|
|
|
|
|
|
- Semana 1 (15/05/2025): Especificación más detallada de algunas dudas del negocio.
|
|
#### Lógica del Sistema
|
|
|
- Semana 2 (22/05/2025): Resolución de dudas de los tipos de solicitudes y puesta en común del diseño requerido para el frontend.
|
|
|
|
|
- Semana 3 (29/05/2025): Especificación de la actualización de los costes por día y de los presupuestos.
|
|
A medida que se avanza en el proyecto se está viendo que la lógica en los procesos del mismo es mucho mas compleja de lo idenficada en un inicio. La funcionalidad es mayor de lo esperado y la transición entre estados tiene mas casuística que la expresada durante el análisis del proyecto.
|
|
|
- Semana 4 (05/06/2025): Planteamiento y aprobación de la batería de pruebas. Resolución de dudas respecto a la actualización del presupuesto.
|
|
|
|
|
- Semana 5: Sprint Review y pruebas.
|
|
Esto lleva a una dificultad mayor en el desarrollo y la implementación de la misma, así como a la hora de llevar a cabo las pruebas necesarias.
|
|
|
|
|
|
|
|
#### Feedback Directo de Usuarios
|
|
|
|
|
|
|
|
## Conclusiones
|
|
El feedback obtenido hasta ahora ha sido desde demostraciones y visualización de lo desarrollado hasta el momento. Por lo tanto, para mejorar el desarrollo del proyecto y orientarlo exactamente a las necesidades del cliente en un siguiente sprint buscaremos que los usuarios tengan acceso a una versión del sistema y puedan devolver un feedback directo y sobre la propia experiencia con el sistema.
|
|
|
|
|
|
|
|
Tras realizar la batería de pruebas, se puede llegar a la conclusión de que los casos de uso están cumplidos casi al 100%. El único error encontrado es la actualización de una solicitud en fechas donde no se actualiza el coste de la misma. Si bien puede llegar a ser un error importante en función de las características.
|
|
##### Aspectos Positivos
|
|
|
|
|
|
|
|
A continuación se realiza el resto de la retrospective de la misma forma que en el primer sprint.
|
|
Como en el sprint anterior también hemos identificado una serie de puntos positivos que no debemos perder
|
|
|
|
|
|
|
|
## ¿Qué fue bien?
|
|
#### Dificultad de comunicación con el cliente
|
|
|
|
|
|
|
|
- Mejora de comunicación con el cliente al marcar reuniones periódicas.
|
|
Para apaliar en la mayor medida la dificultad de mantener contacto con el cliente, se ha adoptado la directiva de mantener una reunión semanal con el cliente para estableciendo un calendario definido y garantizar un contacto mínimo.
|
|
|
- Consenso de las pruebas entre todos los miembros del equipo y el cliente.
|
|
|
|
|
|
El calendario llevado a cabo ha sido el siguiente:
|
|
|
|
|
|
|
|
- Semana 1 (15/05/2025): Especificación más detallada de algunas dudas del negocio.
|
|
|
|
- Semana 2 (22/05/2025): Resolución de dudas de los tipos de solicitudes y puesta en común del diseño requerido para el frontend.
|
|
|
|
- Semana 3 (29/05/2025): Especificación de la actualización de los costes por día y de los presupuestos.
|
|
|
|
- Semana 4 (05/06/2025): Planteamiento y aprobación de la batería de pruebas. Resolución de dudas respecto a la actualización del presupuesto.
|
|
|
|
- Semana 5: Sprint Review y pruebas.
|
|
|
|
|
|
|
|
## ¿Qué podría mejorarse?
|
|
#### Plan de Pruebas
|
|
|
|
|
|
|
|
- La lógica de trabajo del proyecto es compleja y difícil de entender aun con con la mejora de la comunicación del cliente.
|
|
Con el fin de una correcta comprobación del sistema y ante la gran complejidad del sistema, se ha definido un plan de pruebas concreto intentando abarcar toda la casuística del mismo. Esto nos garantiza un mínimo de corrección y cobertura de la aplicación. De esta manera nos aseguramos un mínimo de funcionalidad de cara a continuar con el desarrollo.
|
|
|
|
|
|
|
|
## ¿Qué se hará diferente?
|
|
|
|
|
|
|
|
|
|
- Se buscará acceso a los usuarios del sistema para ver de primera mano la operativa concreta de cada caso de uso. |
|
|