Diferencia entre revisiones de «Revision Del Sprint»

Revisión actual del 19:08 31 jul 2008

La Revisión del Sprint brinda una inspección del progreso del proyecto al finalizar cada Sprint. Basándose en esta inspección se realizan adaptaciones al proyecto. El equipo estimó hasta donde llegará al finalizar el Sprint, y fija el curso acorde. Al fin del Sprint el equipo presenta el Incremento Del Producto que pudo construir. El management, clientes, usuarios y el Dueño Del Producto verifican el Incremento Del Producto. Escuchan las historias del equipo que surgieron durante el transcurso del Sprint. Escuchan qué salió mal y qué salió bien. Verifican en dónde realmente se encuentran en la construcción de todo el sistema. Luego de todo esto, finalmente pueden tomar una decisión con información acerca de qué hacer a continuación. En otras palabras, determinan el mejor curso de acción para poder alcanzar el destino.

Durante la reunión, todos ven funcionar la demostración del producto en el entorno del cliente o usuario. A medida que se visualiza, consideran qué funcionalidad podría ser agregada durante el próximo Sprint. El incremento del producto es el punto inicial para una lluvia de ideas. Por ejemplo, alguien podría sugerir luego de ver la demostración: "Si hiciéramos el control de costos del paciente a mano, podrías comenzar a usar el sistema ahora!", o "Esto podría resolver los problemas de seguimiento del inventario en los distritos. ¿Qué faltaría hacer para que el sistema tome la información de la base de datos?".

A medida que el equipo muestra el incremento del producto, ayuda a los espectadores a entender las fortalezas y debilidades del producto, y las dificultades y éxitos de la experiencia de trabajar juntos.

Pre-condiciones

• Se ha concluido el sprint.
• Asiste todo el equipo de desarrollo, el propietario del producto, el responsable de procesos de la empresa y todas las personas implicadas en el proyecto que lo deseen.

Entradas

• Incremento terminado.

Resultados

• Feedback para el propietario del producto: hito de seguimiento de la construcción del sistema, e información para mejorar el valor de la visión del producto.
• Feedback para el responsable de procesos (Scrum Manager): buenas prácticas y problemas durante el sprint.
• Convocatoria de la reunión del siguiente Sprint.

Reglas

• El Equipo no debería invertir más de una hora en preparar la Revisión del Sprint.
• La funcionalidad que no está completa no puede ser presentada.
• Los artefactos que no son funcionalidad no pueden ser presentados excepto cuando sean usados para explicar mejor el funcionamiento de los productos.
• La funcionalidad debería ser presentada en las máquinas de desarrollo del equipo, y ejecutada en un entorno lo más parecido posible al productivo (generalmente un entorno para QA).
• La revisión del Sprint comienza con un miembro del equipo presentando el objetivo del Sprint, los items del backlog del producto del comprometidos, y los items del backlog del producto terminados. Los distintos miembros del equipo pueden discutir qué salió bien y qué salió mal durante el Sprint.
• La mayor parte de la revisión del Sprint se usa para que los miembros del equipo presenten funcionalidad, responden preguntas del stakeholder, y anoten los cambios deseados.
• Al finalizar la presentación, se les pregunta a los stakeholders la impresión que se llevan, cambios deseados y la prioridad de los mismos.
• El Dueño Del Producto discute con el stakeholder y el equipo cualquier potencial reorganización del Backlog Del Producto basado en el feedback.
• Los stakeholder tienen libertad de realizar cualquier comentario, observación o crítica relacionado con el incremento del producto en las presentaciones.
• Los stakeholders pueden identificar funcionalidad que no fue completada aún, o que no fue completada cómo se esperaba y pedir que la misma sea agregada al Backlog Del Producto para priorizar.
• Los stakeholders pueden identificar cualquier nueva funcionalidad que se les ocurra mientras ven la presentación, y pedir que la misma sea agregada al Backlog Del Producto para priorizar.
• El ScrumMaster debe determinar la cantidad de personas que asistirán a la Revisión del Sprint, y preparar las instalaciones para ubicarlos.
• Al finalizar la reunión de Revisión del Sprint, el Scrum Master le anuncia al Dueño Del Producto y stakholders el lugar y fecha para la próxima Revisión del Sprint.

Consecuencias de la Revisión del Sprint

Luego de la revisión del Sprint algunas consecuencias pueden surgir:

• Recuperar funcionalidad sin finalizar del backlog del producto y priorizarla
• Quitar funcionalidad del Backlog del Producto que el equipo pudo completar de forma inesperada.
• Trabajar con el Scrum Master para reformular el Equipo.
• Volver a priorizar el Backlog del Producto para tomar ventaja de las oportunidades que surgieron durante la demostración.
• Pedir un Sprint De Release para implementar la funcionalidad demostrada, sólo o con incrementos de Sprints anteriores.
• Elegir no seguir avanzando con el proyecto y no autorizar otro Sprint.
• Pedir que se acelere el progreso del proyecto, autorizando el ingreso de nuevos Equipos para trabajar en el Backlog Del Producto.

Ver también

• Proceso De Desarrollo Con Scrum