Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Contenido

Resumen

Versión: v01r01
Fecha publicación: 29 de Octubre de 2020
Entrada en vigor desde: 29 de Octubre de 2020

Histórico de cambios

Los cambios en los estándares vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Versión	v01r01	Fecha publicación	29 de Octubre de 2020	Fecha entrada en vigor	29 de Octubre de 2020
Alcance
Sprint Review; Objetivo, contenido, agenda típica, roles y responsabilidades, preparación de la sesión y buenas prácticas

Introducción

Esta página pretende esclarecer los aspectos fundamentales de las sesiones Sprint Review.

Objetivo

Alineamiento: El equipo se comprometió con unos objetivos para el sprint y durante la Sprint Review es el momento en el que el equipo clama con claridad y alinea con el resto de interesados qué trabajo se ha completado durante el Sprint y cuál no, pidiendo a los Product Owners (o equivalentes) aceptación formal para el trabajo completado.
Demostración Práctica (Show & Tell): Visualizar el progreso asociado al incremento a través de Software que funciona.
Conseguir feedback directo: Escuchar de Product Owners o usuarios feedback del producto desarrollado (¿Cómo de útiles es el producto?, ¿sirven el propósito inicial?, ¿qué otras ideas podrían desprenderse de este producto?).
Ofrecer una visibilidad del desarrollo del sprint: El equipo ofrece a los interesados una ventana de visibilidad acerca de cómo el equipo ha trabajado tanto conjuntamente como en el contexto de la organización (p.ej. con otras áreas de la STIC). La Sprint Review es un buen momento para dar visibilidad de los impedimentos recurrentes.
Revisión de deuda Técnica.
Obtención del grado de satisfacción del Equipo y Product Owner con el SPRINT.

Contenido y Agenda típica

Revisar el grado de consecución de objetivos del SPRINT y de sus historias de usuario a través de Software que funciona.
Validación del DoD: Validación funcional, de requisitos no funcionales (según aplique), análisis estático del código.

Roles & Responsabilidades

Rol Scrum	Descripción
Proxy Product Owner	Gestión de la convocatoria así como de la agenda, siendo imprescindible evaluar, comunicar y coordinar de manera proactiva y de antemano posibles disrupciones que comprometan la sesión: falta de asistencia de invitados clave, urgencias,… * Facilitación de la sesión (mantener tiempos, mantener el foco de la sesión, asegurar que las acciones y decisiones quedan grabadas, incentivar la participación de todo el mundo, etc). * Asegurar que se ha llevado a cabo la coordinación previa con Sistemas, OTI, Calidad,…en caso de necesitar requerimientos de áreas específicas. Garantizar que los resultados son conformes con los requisitos, garantizando así el éxito y aceptación del proyecto. Asegurar la comunicación y seguimiento de cualquier información o acción relevante que se desprenda de la sesión con los/as interesados/as del proyecto relevantes si estos/as no están presentes en la Sprint Review. Garantizar la recepción y comprobación de entregables.
Scrum Master	Gestión de la convocatoria así como de la agenda, siendo imprescindible evaluar, comunicar y coordinar de manera proactiva y de antemano posibles disrupciones que comprometan la sesión: falta de asistencia de invitados clave, urgencias,… * Facilitación de la sesión (mantener tiempos, mantener el foco de la sesión, asegurar que las acciones y decisiones quedan grabadas, incentivar la participación de todo el mundo, etc). * Ayudar al equipo de desarrollo en la preparación de la sesión. Asegurar toma de métricas tras la sesión. Asegurar disponibilidad del resumen de la sesión en Confluence.
Equipo de desarrollo	Estatus del alcance pactado. Demo del sistema.
Stakeholder OCA	El rol de la OCA en la Sprint Review deberá pactarse para cada proyecto, siendo necesario alinear si aplican o no las siguientes responsabilidades: Antes de la Sprint Review, el representante de la OCA en el proyecto realizará, a nivel de historia de usuario de acuerdo a la normativa vigente, lo siguiente: Verificación de estructura Repositorio GIT. Verificación de uso correcto de Gitflow. Verificación de diversas cuestiones relacionadas con la estructura de la carpeta del proyecto y algunos de sus ficheros: campos fichero Readme.md, estructura de los archivos pom.xml, documentos .feature, cumplimiento normativa Oracle. Validación no funcional de las historias de Usuario. Validación de la compilación en Jenkins. Validación del análisis estático del código cumpliendo normativa o acuerdo DoD. Verificación de cumplimiento normativa Oracle. Comprobación de que las pruebas de regresión se han ejecutado correctamente (sólo si procede). Durante la Sprint Review, el representante de la OCA en el proyecto comprobará que las historias de usuario cumplen el DoD. Pruebas funcionales a Sprint pasado con el objetivo de lograr una detección temprana de errores.
Product Owner	Asistir a la Sprint Review para validar el Producto desarrollado durante el SPRINT.

(*) En cada proyecto es importante que Scrum Master y Proxy Product Owner alineen conjuntamente cuál de estos dos roles gestionará la convocatoria y facilitará la sesión. Es importante notar que la persona finalmente encargada de gestionar la convocatoria, deberá prestar especial atención a preparar una agenda relevante para la sesión además de evaluar, comunicar y coordinar proactivamente posibles disrupciones que comprometan la sesión (p.ej. falta de asistencia de invitados clave, urgencias, etc).

Preparación de la sesión

Input	Descripción	Responsable preparación de la sesión	Fuente de información
Envío de convocatoria	Envío con suficiente antelación de la convocatoria, asegurando la relevancia de la lista de invitados a la sesión.	Scrum Master ó Proxy Product Owner **	Scrum Master ó Proxy Product Owner **
Gestión de la convocatoria	En caso de avisos de no asistencia o indisponibilidad, se deberá gestionar de manera proactiva la convocatoria para asegurar que se mantiene la eficiencia de la misma (p.ej. buscando fecha alternativa, asegurando que los roles y responsabilidades son correctamente delegados, etc).	Scrum Master ó Proxy Product Owner **	Interesados relevantes del Sprint
Alineamiento de validaciones de previas (si aplica)	En caso de requerirse de la validación de requisitos impuestos por interesados externos al equipo del proyecto, se asegurará o bien la asistencia de dichos interesados a la review o bien se deberá velar por la validación de dichos requisitos con anterioridad a la review.	Scrum Master ó Proxy Product Owner **	Otros interesados
Preparación de revisión de Historias de Usuario y criterios no funcionales	Asegurar que el equipo de desarrollo tiene conocimiento previo de cómo se va a ejecutar la Demo de las Historias de Usuario del Sprint, de cuáles son los Criterios de Aceptación que se validarán durante la Review y de cómo de cómo se va a demostrar el cumplimiento con dichos Criterios de Aceptación así como con los requisitos no funcionales del proyecto. NOTA: se recomienda organizar una sesión previa días antes de la review junto con el equipo para tratar este punto así como los siguientes relacionados con el DoD.	Scrum Master	Equipo de desarrollo
Estado del DoD	Asegurar feedback previo relacionado con: La disponibilidad del plan de pruebas del sprint. El estado de la subida del código a GIT siguiendo la normativa Gitflow, así como de la subida de los archivos .features a GIT. El estado de la compilación Jenkins del incremento. El estado del análisis estático del código. El despliegue de incremento en el entorno acordado. La actualización del Backlog de acuerdo al contenido desarrollado, así como de la documentación del proyecto relacionada con el sprint. El resultado de las pruebas automáticas del sprint.	Scrum Master	Equipo de desarrollo
Preparación de la agenda	Preparación de la agenda de manera que se obtengan los resultados esperados de la sesión: Validación del contenido del Sprint (cumplimiento DoD). Listado de acciones y pendientes. Valoración del sprint por Product Owners y equipo de desarrollo.	Scrum Master ó Proxy Product Owner **	Scrum Master ó Proxy Product Owner **

(**) Scrum Master ó Proxy Product Owner según se convenga para cada proyecto.

Buenas Prácticas

Limitar el tiempo de preparación de la Demo (1 o 2 horas).
La preparación de la Demo comienza en el SPRINT Planning.
Asegurar que los participantes adecuados están presentes.
Asegurar que el equipo celebra los logros y éxitos y que los “stakeholders” así lo reconocen.
Asegurar que diferentes miembros del equipo participan en la Demo.
Asegurar que el equipo está preparado para la Demo, y si aplica, están coordinados con el equipo de Sistemas para la revisión de una Versión.

Anti-patrones

Se emplea mucho tiempo en la preparación de la Demo.
La Demo se desarrolla a modo de discurso/diapositivas en lugar de apoyarse sobre software/hardware en funcionamiento.
El Product Owner ve una funcionalidad en la Demo de la que no tenía constancia.
Pensar que las Demos no son relevantes para “stakeholders” a nivel dirección / programas.

Árbol de páginas

Sprint Review