|
|
|
## Resumen
|
|
|
|
|
|
|
|
**Duración Estimada:**
|
|
|
|
**Duración Estimada:** 53 horas
|
|
|
|
|
|
|
|
**Horas Completadas:**
|
|
|
|
**Horas Completadas:** 65 horas
|
|
|
|
|
|
|
|
## PBIs Completados
|
|
|
|
|
| ... | ... | @@ -10,19 +10,18 @@ |
|
|
|
- PBI-06 - Enviar emails al POC según estado de solicitud
|
|
|
|
- PBI-20 - Creación de Titulaciones
|
|
|
|
|
|
|
|
|
|
|
|
TODO ?
|
|
|
|
|
|
|
|
- PBI-21 - Gestión de Plazas
|
|
|
|
|
|
|
|
## Reunión con el cliente
|
|
|
|
|
|
|
|
Tras la reunión y exposición del producto tras finalizar el sprint, el feedback recibido sobre el mismo y el proyecto en general es altamente positivo. Se da por cerrado el módulo de activaciones de forma satisfactoria a nivel funcional quedando pendientes correcciones mínimas de interfaz como la colocación de botones en en alguna de las interfaces.
|
|
|
|
Tras la reunión y exposición del producto tras finalizar el sprint, el feedback recibido sobre el producto desarrollado durante el proyecto es altamente positivo. Se da por por concluido el MVP del módulo de activaciones planeado durante la fase de análisis quedando pendientes en el PB los PBIs que quedaron fuera del alcance del proyecto durante la Sprint Review 4.
|
|
|
|
|
|
|
|
Dentro del módulo de plazas se da el visto bueno al módulo de gestión de titulaciones, aunque se expresa la necesidad de tener la capacidad de eliminar Ramas, Cometidos y Méritos específicos de igual forma que es posible realizar con las titulaciones en si.
|
|
|
|
Dentro del módulo de plazas el cliente proporciona feedback positivo al módulo de gestión de titulaciones, aunque se expresa la necesidad de tener la capacidad de eliminar Ramas, Cometidos y Méritos específicos de forma similar a las Titulaciones.
|
|
|
|
|
|
|
|
Por último se muestra la parte de solicitud de plazas, con la que el cliente se muestra una reacción satisfactoria. Así mismo se constata que no se ha podido realizar la visualización y borrado de solicitudes a nivel de interfaz por lo que la la única funcionalidad para el usuario es la generación de nuevas solicitudes.
|
|
|
|
Por último, se muestra la funcionalidad de solicitud de plazas, con la que el cliente se muestra satisfecho también. Así mismo, se constata que no se ha podido realizar la visualización y borrado de solicitudes a nivel de interfaz por lo que la única funcionalidad disponible para el usuario es la generación de nuevas solicitudes.
|
|
|
|
|
|
|
|
## Conclusiones
|
|
|
|
|
|
|
|
Al finalizar el último sprint del proyecto, prácticamente se alcanza el 100% de la funcionalidad para el módulo de activaciones, siendo por motivos ajenos las funcionalidades restantes. Así mismo se ha conseguido dejar implementado a nivel de back-end y orientado en la parte de interfaz, el módulo de gestión de plazas. De forma que se pueda alcanzar una versión completamente funcional en un corto periodo de tiempo una vez que el se reanude el proyecto. |
|
|
\ No newline at end of file |
|
|
|
Al finalizar el último sprint del proyecto, se cumplen prácticamente la totalidad de funciones del módulo de activaciones, quedando tan solo pendientes de implementar aquellas que por sus características quedan fuera del alcance del proyecto. Así mismo, se ha conseguido implementar el backend y gran parte del frontend del módulo de gestión de plazas, por lo que se podrá alcanzar una versión completamente funcional en un corto periodo de tiempo una vez que el se reanude el proyecto. |