Skip to content

GitLab

Last edited by Carlos Moreno
Page history

4.3. Sprint Review

Objetivo del sprint

Que los usuarios puedan consultar y dar de alta Modelos, Equipos e 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 1

Las actividades que se han realizado durante el Sprint 1 corresponden a los items seleccionados del Product Backlog. Para una mejor visualización de los elementos en el board, se han etiquetado estos elementos como PBI estando los issues (sprint backlog) relacionados el con PBI correspondiente.

Todos los PBIs se han documentado en la wiki, siguiendo una misma plantilla en la que se ha incluido la Descripción, el Valor aportado, y los Criterios de acpetación entre otra información.

  • PBI #5 (closed) Desarrollo de la Librería orientada a interfaces

 

 

 

 

 

 

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

Actividades pendientes

Ninguna. Se han completado el 100% todas las tareas previstas durante el Sprint Planning

Resumen de actividades planeadas y ejecutadas durante el Sprint 1

Dada la frecuencia de realización de reuniones daily entre los developers y atendiendo a la libertad otorgada a los mismos en cuanto al refinamiento y planificación del Sprint Backlog, se ha optado por planificar los issues a corto plazo, en el Sprint Retrospective se explicará el resultado con esta planificación.

Próximas actividades

Tras la finalización del Sprint 1, 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

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

Impact map de gestión

Impact map de incidencias