Continuando con la serie: Como implementar SCRUM en 10 pasos fáciles. Creación de Kelly Waters y traducida con la autorización correspondiente por su servidor.
La entrada original de este artículo es: Step 10: Review, Reflect, Repeat
Paso #10: Revisa, Reflexiona, Repite
Así que tienes tu pila del producto en orden, has estimado la pila, esclarecido los requisitos, planeado tu sprint y has creado un espacio de trabajo colaborativo.
Estás haciendo un Sprint para alcanzar tus metas y estás haciendo reuniones diarias y estás midiendo el progreso con un gráfico.
Ahora vienes al final del Sprint y terminas cuando dijistes que lo harías. Todo lo que queda por hacer ahora, es la revisar, reflexionar y repetir ...
Revisión del Sprint
Al final del Sprint haz una reunión para revisar el Sprint (Sprint Review) . Invita a todo el equipo. Invita a todos los tomadores de decisiones del negocio. Invita a tomadores de decisiones importantes incluyendo ejecutivos cuando sea apropiado. ¡Entre mas partes interesadas, mejor!
Revisa lo que fue entregado con el Sprint. Haz una demostración del software. Si es completo, software funcional antes de la entrega final o si es un trabajo en progreso dentro de un proyecto de varios Sprints, haz la demostración de lo que se ha completado dentro del Sprint. Deja que los miembros del equipo demuestren las áreas en las que han trabajado.
El propósito de la revisión del Sprint es triple:
Permite a los miembros del equipo mostrar lo que han logrado y demostrar su contribución al producto.
Permite a todos los tomadores de decisión ver lo que se ha hecho y proveer valiosa retroalimentación en una base regular, mientras aun hay tiempo de tomarla en consideración.
Ayuda al equipo a permanecer enfocado en el tiempo del Sprint. - nadie quiere aparecerse en la revisión del Sprint con nada útil que demostrar.
Retrospectiva del Sprint.
Siguiendo la revisión del Sprint, haz una reunión de retrospectiva. Invita a todo el equipo. Invita al propietario del producto. Pero esta reunión no es para todos los tomadores de decisión. Típicamente puede seguir inmediatamente después de la revisión del Sprint.
El propósito de la retrospectiva del Sprint es reflexionar sobre como fueron las cosas durante el Sprint. Es una oportunidad para que el equipo discuta el Sprint y consideren como se pueden mejorar las cosas.
Juntos el equipo debería:
Este es un proceso de aprendizaje continuo
Los métodos de gestión de proyectos tradicionales, tales como PRINCE2 (2), también alientan el aprendizaje continuo, aunque la producción de una lección aprendida se reporta en la clausura del proyecto.
El problema con esto es que las personas no siempre recuerdan lo suficiente al final de un proyecto largo. O tal vez hay tanto por reflexionar al final de un proyecto largo, que hay demasiadas cosas por considerar y el resultado no es accionable. Y a menudo al completar un proyecto tradicional, el equipo del proyecto se dispersa en otros proyectos o regresan de donde vinieron, previniendoles de aplicar su aprendizaje como equipo.
En el desarrollo ágil Scrum, como el producto así mismo, el aprendizaje es en pequeños trozos. Poco pero seguido. Mientras aun hay tiempo para que la retroalimentación tenga un impacto positivo en el proyecto.
Repetir
Todo lo que le queda al equipo, es repetir el proceso, con el mayor conocimiento ganado desde lo anterior.
De modo realista toma 3 o 4 Sprints para que el equipo entre en ritmo. Para aplicar las mejoras y que sean usadas en el proceso. Para que la velocidad se estabilice.
¡Eso es todo amigos!
Así que eso es. Eso es básicamente Scrum y como puedes implementarlo en 10 pasos fáciles.
Por supuesto en la realidad, los pasos no son tan fáciles. Los pasos incluye humanos. Y desarrollo de software. Una combinación con truco.
No obstante, el proceso Scrum es inherentemente fácil. Y dependiendo de tu situación, Scrum y el desarrollo ágil puede ayudar tu tasa de éxito en muchas formas.
Kelly
La entrada original de este artículo es: Step 10: Review, Reflect, Repeat
Paso #10: Revisa, Reflexiona, Repite
Así que tienes tu pila del producto en orden, has estimado la pila, esclarecido los requisitos, planeado tu sprint y has creado un espacio de trabajo colaborativo.
Estás haciendo un Sprint para alcanzar tus metas y estás haciendo reuniones diarias y estás midiendo el progreso con un gráfico.
Ahora vienes al final del Sprint y terminas cuando dijistes que lo harías. Todo lo que queda por hacer ahora, es la revisar, reflexionar y repetir ...
Revisión del Sprint
Al final del Sprint haz una reunión para revisar el Sprint (Sprint Review) . Invita a todo el equipo. Invita a todos los tomadores de decisiones del negocio. Invita a tomadores de decisiones importantes incluyendo ejecutivos cuando sea apropiado. ¡Entre mas partes interesadas, mejor!
Revisa lo que fue entregado con el Sprint. Haz una demostración del software. Si es completo, software funcional antes de la entrega final o si es un trabajo en progreso dentro de un proyecto de varios Sprints, haz la demostración de lo que se ha completado dentro del Sprint. Deja que los miembros del equipo demuestren las áreas en las que han trabajado.
El propósito de la revisión del Sprint es triple:
Permite a los miembros del equipo mostrar lo que han logrado y demostrar su contribución al producto.
Permite a todos los tomadores de decisión ver lo que se ha hecho y proveer valiosa retroalimentación en una base regular, mientras aun hay tiempo de tomarla en consideración.
Ayuda al equipo a permanecer enfocado en el tiempo del Sprint. - nadie quiere aparecerse en la revisión del Sprint con nada útil que demostrar.
Retrospectiva del Sprint.
Siguiendo la revisión del Sprint, haz una reunión de retrospectiva. Invita a todo el equipo. Invita al propietario del producto. Pero esta reunión no es para todos los tomadores de decisión. Típicamente puede seguir inmediatamente después de la revisión del Sprint.
El propósito de la retrospectiva del Sprint es reflexionar sobre como fueron las cosas durante el Sprint. Es una oportunidad para que el equipo discuta el Sprint y consideren como se pueden mejorar las cosas.
Juntos el equipo debería:
- Revisar el gráfico de seguimiento: ¿Cómo fue? ¿Entregó el equipo lo que se había comprometido en entregar al inicio del Sprint? Anotar las horas empleadas en una hoja de cálculo para que la taza de éxito del equipo pueda ser graficada sobre el tiempo, para ver si está mejorando o empeorando. Esta es una herramienta para que el equipo mida su progreso. No es una medida para gestión.
- Revisa la "velocidad" del equipo: La velocidad es el número de puntos estimados en la pila del producto original, para los items completados en el Sprint. Solamente los items 100% completos y entregados, firmados, en el software cuentan para la velocidad del equipo. De nuevo, grafica esto para que la velocidad del equipo pueda ser monitoreada sobre el tiempo, así el equipo puede ver si está entregando mas o menos en el transcurso del tiempo. La velocidad gradualmente se establecerá cerda de una norma y entonces puede ser usada en la planificación del Sprint como una medida de cuanto puede realmente un equipo lograr, basado en la trayectoria.
- Discute lo que fue bien: (intenta asegurarte que se repita la siguiente vez)
- Discute que podría haber ido mejor: (intenta entender por qué)
- Decide lo que el equipo hará diferente en el siguiente Sprint: (Intenta tomar un par de puntos de acción que en realidad puedan ser hechos de forma diferente en el siguiente Sprint)
Este es un proceso de aprendizaje continuo
Los métodos de gestión de proyectos tradicionales, tales como PRINCE2 (2), también alientan el aprendizaje continuo, aunque la producción de una lección aprendida se reporta en la clausura del proyecto.
El problema con esto es que las personas no siempre recuerdan lo suficiente al final de un proyecto largo. O tal vez hay tanto por reflexionar al final de un proyecto largo, que hay demasiadas cosas por considerar y el resultado no es accionable. Y a menudo al completar un proyecto tradicional, el equipo del proyecto se dispersa en otros proyectos o regresan de donde vinieron, previniendoles de aplicar su aprendizaje como equipo.
En el desarrollo ágil Scrum, como el producto así mismo, el aprendizaje es en pequeños trozos. Poco pero seguido. Mientras aun hay tiempo para que la retroalimentación tenga un impacto positivo en el proyecto.
Repetir
- El equipo está ahora armado con valiosa información - sobre el producto, sobre el rendimiento y sobre algunos impedimentos en su entorno, ejemplo:
- Cómo se ve el software después del último Sprint.
- Retroalimentación sobre el producto desarrollado hasta entonces.
- Hasta que punto el equipo capaz de entregar lo que se había comprometido en la planificación del Sprint.
- La velocidad del equipo y lo que es alcanzable en una iteración típica.
- Lo que fue bien
- Lo que no fue tan bien
- Lo que será hecho distinto para avanzar
Todo lo que le queda al equipo, es repetir el proceso, con el mayor conocimiento ganado desde lo anterior.
De modo realista toma 3 o 4 Sprints para que el equipo entre en ritmo. Para aplicar las mejoras y que sean usadas en el proceso. Para que la velocidad se estabilice.
¡Eso es todo amigos!
Así que eso es. Eso es básicamente Scrum y como puedes implementarlo en 10 pasos fáciles.
Por supuesto en la realidad, los pasos no son tan fáciles. Los pasos incluye humanos. Y desarrollo de software. Una combinación con truco.
No obstante, el proceso Scrum es inherentemente fácil. Y dependiendo de tu situación, Scrum y el desarrollo ágil puede ayudar tu tasa de éxito en muchas formas.
Kelly
Serie completa:
#10: Revisa, Reflexiona, Repite
Excelente aporte Muchas Gracias
ResponderEliminarExcelente articulo acerca de Scrum, los 10 pasos y su documentacion son super agiles. Mil Gracias.
ResponderEliminarThese recordsdata additionally be|may also be|can be} compressed to half the size of an STL file. These recordsdata include an object, materials, texture, constellation, and metadata information. This file format isn't extensively used in the meanwhile, despite it providing greater than an STL file. Once created or downloaded, STL recordsdata are usually exported right into a 3D printing slicer, similar to Ultimaker Cura. There, the STL file is transformed right into a language your 3D printer can understand “G-code,” which tells it precision machining precisely how to to|tips on how to} print a model or design.
ResponderEliminar