|
|
|
## Objetivo del sprint
|
|
|
|
Sprint Goal: xxxxxx |
|
|
\ No newline at end of file |
|
|
|
|
|
|
|
_Hacer una efectiva separación de roles, para poder asignar dispositivos y gestionar incidencias._
|
|
|
|
|
|
|
|
|
|
|
|
## Estimación y tiempo real empleado en cada tarea:
|
|
|
|
|
|
|
|
Como se puede observar en el [Diagrama de BurnDown](./5.5.-Burndown), se ha ido avanzando en la realización de los distintos trabajos del Sprint Backlog de manera homogénea y distribuida en el tiempo. No obstante, conviene indicar que el objetivo marcado para este primer sprint, se ha alcanzado antes de la fecha límite inicialmente prevista, por lo que se ha procedido al cierre del mismo 3 días antes de dicha fecha.
|
|
|
|
|
|
|
|
|
|
|
|
## Actividades realizadas durante el Sprint 2
|
|
|
|
|
|
|
|
Para este segundo sprint se han extraído 8 PBI's (Product Backlog Items) del _Product Backlog_. Estos PBI's se han desglosado en los 39 issues que a continuación se detallan:
|
|
|
|
|
|
|
|
- PBI #50 - Login de Usuarios
|
|
|
|
- #58 - Entidades API: Usuario, MiembroGC PersonalExterno y Unidad
|
|
|
|
- #59 - Controller y Repositorio Unidades y Usuarios
|
|
|
|
- #60 - Modelos Usuario y Unidad
|
|
|
|
- #64 - Implementación JWT Security API
|
|
|
|
- #65 - Pantalla login y comunicación API
|
|
|
|
- #68 - Endpoint de usuario
|
|
|
|
- #69 - Interceptores de petición y respuesta en Front
|
|
|
|
- #81 - Implementación de login con tecla Intro
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #51 - Asignación de equipos a propietarios
|
|
|
|
- #72 - Formulario asignación equipo
|
|
|
|
- #77 - Desasignar equipo
|
|
|
|
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #52 - Resolver incidencia
|
|
|
|
- #74 - Formulario de asignación de incidencias
|
|
|
|
- #71 - Opción para cerrar incidencia
|
|
|
|
- #73 - Formulario de resolución de incidencia
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #53 - Mostrar detalle de una incidencia
|
|
|
|
- #70 - Vista de una incidencia
|
|
|
|
- #76 - Mostrar grafico estado incidencia
|
|
|
|
- #93 - Corrección línea del tiempo en incidencias
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #54 - Mostrar detalle de un equipo
|
|
|
|
- #75 - Detalle de un equipo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #55 - Acceso a funciones segun el rol
|
|
|
|
- #61 - Filtro/autorización equipos API según rol
|
|
|
|
- #62 - Filtro/autorización modelos API segun rol
|
|
|
|
- #63 - Filtro/autorizacion incidencias API segun rol
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #56 - Mostrar estadísticas
|
|
|
|
- #86 - Grafico Modelos
|
|
|
|
- #87 - Grafico Equipos
|
|
|
|
- #88 - Grafico Incidencias
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- PBI #57 - Mostrar Listado de Usuarios/Unidades
|
|
|
|
- #83 - Menu seleccion personas/unidades
|
|
|
|
|
|
|
|
Existen otros elementos _spring backlog_ que no están relacionados con _PBIs_ específicos:
|
|
|
|
|
|
|
|
- #66 - Solución de error de CORS con peticiones OPTIONS
|
|
|
|
- #67 - Gestión de resultados de peticiones unificada en frontend
|
|
|
|
- #78 - Filtros front segun rol
|
|
|
|
- #79 - Mejoras en repositorios JPA
|
|
|
|
- #80 - Dialogo de confirmación
|
|
|
|
- #82 - Resolver incidencia
|
|
|
|
- #84 - Borrado de Stores
|
|
|
|
- #85 - Tooltips en iconos
|
|
|
|
- #89 - Formatear código API
|
|
|
|
- #90 - Formatear código front
|
|
|
|
- #91 - Despliegue API AWS
|
|
|
|
- #92 - Carga coherente de datos
|
|
|
|
- #94 - Configuración guardas y elementos dinámicos
|
|
|
|
- #96 - Listado Incidencias responsive
|
|
|
|
- #95 - Manual de usuario
|
|
|
|
|
|
|
|
Todos los issues se encuentran documentados, de manera detallada, en la wiki, incluyendo la **Descripción, el Valor aportado, y los Criterios de acpetación** entre otra información.
|
|
|
|
|
|
|
|
## Actividades pendientes
|
|
|
|
|
|
|
|
Se han completado el 100% todas las tareas previstas durante el Sprint _Planning_
|
|
|
|
|
|
|
|
|
|
|
|
## Resumen de actividades planeadas y ejecutadas durante el Sprint 2
|
|
|
|
|
|
|
|
El sprint 2 se ha desarrollado de conformidad con lo planificado, habiéndose dado cumplimento a la realización de todas las tareas. En este sentido, cabe resaltar que se han producido algunas incidencias que se han podido resolver sin que hayan impactado de manera significativa en la planificación global del sprint.
|
|
|
|
|
|
|
|
|
|
|
|
## Próximas actividades
|
|
|
|
|
|
|
|
Tras la finalización del _Sprint 2_, se realizará el _Sprint planning_ correspondiente al _Sprint 2_. Durante este proceso, nos enfocaremos en establecer un objetivo claro y conciso para el Sprint 2, con el propósito siempre de agregar valor al producto.
|
|
|
|
|
|
|
|
|
|
|
|
## Incremento
|
|
|
|
|
|
|
|
Con todo lo realizado durante el _Sprint 1_, se ha completado varios de los requisitos previstos en el MVP, todos hechos cumpliendo con la _Definición de Hecho (DoD)_ que se definió en el [Sprint Planning](./4.1.-Sprint-Planning)
|
|
|
|
|
|
|
|
Hay que tener en cuenta que la separación de roles no se ha implentado en este sprint, por lo que se han marcado como _done_ los requisitos relacionados con funcionalidades que se pueden hacer tanto con separación de roles como sin ella.
|
|
|
|
|
|
|
|
| Id | Prioridad | Descripción | MVP | Sprint 1 | Sprint 2 |
|
|
|
|
| --- | ---------- | ------------ | --- | -------- | -------- |
|
|
|
|
| RF1 | Alta | Existirán cuatro roles diferenciados: Administrador Central, Administrador de Unidad, MiembroGC no administrador y Personal Externo (Técnico) | ✔️ | | ✔️ |
|
|
|
|
| RF2 | Alta | Usuarios administradores centrales podrán de alta nuevo material, categorizado dentro de una de las categorías (subtipos) existentes | ✔️ | ✔️ | |
|
|
|
|
| RF3 | Alta | Los administradores centrales podrán dar de baja o modificar material existente | ✔️ | ✔️ | |
|
|
|
|
| RF4 | Alta | El material se podrá asignar a un usuario (MiembroGC) o a una unidad | ✔️ | | ✔️ |
|
|
|
|
| RF5 | Alta | Los MiembroGC pertenecerán a una unidad determinada, pudiendo los administradores listar el material que tiene la unidad, bien asignado a la propia unidad, o asignado a alguno de sus usuarios. Los MiembroGC no administrador, solo podrán ver sus materiales | ✔️ | | ✔️ |
|
|
|
|
| RF6 | Media | Todos los MiembroGC (administrador y no administrador) podrán dar de alta nuevas incidencias, que pueden ser relativas a configuración, avería, extravío o solicitud | ✔️ | ✔️ | |
|
|
|
|
| RF7 | Media | Los Administradores y Técnicos podrán marcar las incidencias como resueltas, o cambiarlas al estado que corresponda | ✔️ | | ✔️ |
|
|
|
|
| RF12 | Alta | Los Administradores de Unidad podrán visualizar los usuarios de su unidad, así como el material que tienen asignado | ✔️ | | ✔️ |
|
|
|
|
|
|
|
|
|
|
|
|
### Requisitos No Funcionales
|
|
|
|
|
|
|
|
| Id | Prioridad | Descripción | MVP | Sprint_1 | Sprint_2 |
|
|
|
|
| ---- | ---------- | ------------ | --- | -------- | -------- |
|
|
|
|
| RNF1 | Alta | La aplicación debe poseer un diseño que garantice la adecuada visualización en PC, tablets y smartphones | ✔️ | ✔️ | |
|
|
|
|
| RNF3 | Alta | El acceso a la aplicación se realizará a través de protocolos que aseguren la confidencialidad de la información | ✔️ | ✔️ | |
|
|
|
|
| RNF4 | Alta | La interfaz de la aplicación se desarrollará siguiendo las pautas de accesibilidad recogidas en la especificación WCAG 2.1, debiendo seguir, al menos, el nivel A de las directrices que guían cada uno de sus principios (Perceptible, Operable, Comprensible y Robusto) | ✔️ | ✔️ * | |
|
|
|
|
|
|
|
|
|
|
|
|
* Dada la extensión que tiene la especificación [WCAG 2.1](https://www.w3.org/WAI/standards-guidelines/wcag/glance/es), no se ha realizado un test de usabilidad completo de la aplicación para garantizar fehacientemente que se cumple esta espeficación, no obstante, se ha desarrollado atendiendo al nivel A.
|
|
|
|
|
|
|
|
### Incremento a través del Impact map
|
|
|
|
|
|
|
|
En la siguientes imagenes se puede observar como los entregables realizados contribuyen a la consecución del objetivo. Así mismo, se muestran las próximas tareas previstas a realizar para el siguiente sprint.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
\ No newline at end of file |
