Skip to content

GitLab

Last edited by Carlos Moreno
Page history
This is an old version of this page. You can view the most recent version or browse the history.

5.3. Sprint Review

Objetivo del sprint

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, 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 descompuesto en los 39 issues que a continuación se detallan:

 

 

 

 

 

 

 

Existen otros elementos spring backlog que no están relacionados con PBIs específicos:

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

Finalizado el Sprint 2, durante la revisión, los stakeholders manifiestan que la aplicación debe evolucionar en la gestión de incidencias, incorporando funcionalidades adicionales como el cambio de resolutor, que los usuarios puedan añadir comentarios, que se pueda dotar del rol de resolutor también a los administradores. Además, también se menciona la incorporación de filtros avanzados en los listados de Modelos (Marca, tipo, stock), Inventario (estado de adjudicación), Incidencias (unidades, estado, tipo, estado de asignación y rango de fechas).

Estas demandas se tendrán en cuenta en la selección de los PBI's del siguiente sprint.

Incremento

Con todo lo realizado durante el Sprint 2, se han completado todos los requisitos previstos en el MVP, cumpliendo con la Definición de Hecho (DoD) que se definió para el primer sprint y que se ha mantenido vigente en este segundo Sprint Planning

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, 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.

Impact map de gestión

Impact map de incidencias