Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Contenido
| Tabla de contenidos | ||||||
|---|---|---|---|---|---|---|
|
Resumen
| Sugerencia |
|---|
|
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.
| Expandir | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Introducción
Esta página pretende esclarecer los aspectos fundamentales de las sesiones Sprint Review.
Objetivo
Alineamiento: El equipo Los desarrolladores se comprometió comprometieron 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 alinean 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 de los desarrolladores y Product Owner con el SPRINTSprint.
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
- Comprobar las validaciones funcionales y del DoD realizadas durante el Sprint.
- Obtener feedback de Product Owners sobre el incremento del Producto.
Responsabilidades
| Responsabilidad Scrum | Descripción |
|---|---|
| Proxy Product Owner |
|
| |
| Scrum Master |
|
|
|
| Desarrolladores |
|
| Stakeholder OCA |
|
| |
| Product Owner |
|
(*) En cada proyecto es importante que Scrum Master y Proxy Product Owner alineen conjuntamente cuál de estos dos roles quién gestionará la convocatoria y facilitará la sesión. Es importante notar que la. 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 gestionar 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 | Checkbox |
|---|---|---|---|---|
| Revisión de la agenda | Revisar la agenda de manera que se obtengan los resultados esperados de la sesión:
| Scrum Master ó Proxy Product Owner ** | Scrum Master ó Proxy Product Owner ** | |
| 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 |
| las responsabilidades son correctamente |
| delegadas, 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 |
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.| Estado del DoD | Asegurar feedback previo relacionado con:
| Scrum Master |
| Desarrolladores | |
Preparación de |
revisión de Historias de Usuario y criterios no funcionales | Asegurar que los desarrolladores tienen 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 | Desarrolladores |
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 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.
- Asegurar que todas las HUs están validadas funcionalmente con los PPOs y cerradas antes de la sesió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.
- Utilizar la Review para realizar la validación funcional y cerrar todas las HUs en lugar de cerrarlas durante el Sprint.