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 6: Sprint!
Paso #6: Sprint
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 listo para el paso #6: el Sprint.
Scrum en realidad no prescribe como se debe hacer para la entrega de tus tareas en el Sprint. Scrum es una práctica de gestión ágil y no cubre realmente la ingeniería ágil. XP (Extreme Programming - Programación Extrema) por otro lado es una práctica de ingeniería ágil.
Personalmente pienso que esta es la belleza de Scrum.
Cualquier práctica de ingeniería que uses, desde vaquero a riguroso, desde RAD a RUP, desde XP hasta DIY, cualquiera, Scrum se puede colocar directamente en la parte superior. Ese es el porque digo que es fácil. Es un enfoque de gestión alternativo. Para proyectos y para BAU(Business as Usual). No es un enfoque de desarrollo. Y ese es el porque Scrum funciona, incluso fuera de un contexto de desarrollo.
Así que, el equipo hace el Sprint para lograr la meta del Sprint que ellos se habían comprometido durante los estados de planeación (pasos 2,3 y 4 de esta serie). Aunque Scrum no prescribe nada acerca de como el equipo debería hacer esto, hay unos pocos principios claves del desarrollo de software ágil que quiero resaltar que son particularmente importantes para recordar en este estado del ciclo de vida de Scrum.
Los equipos ágiles deben ser apoderados.
El equipo Scrum toma sus propias decisiones durante el Sprint. El equipo está apoderado. Cada vez que e un gerente se mete y toma una decisión para el equipo, ellos remueven alguna responsabilidad desde el equipo. Si un gerente se mantiene haciendo esto, el equipo gradualmente - pieza por pieza - pierde propiedad, junto con su compromiso.
Como un gerente, debe dar al equipo apoyo, guia, entrenamiento y asistencia. No instrucciones. Si es necesario, el equipo debería ser ayudado a alcanzar sus propias decisiones. La facilitación se convierte en una habilidad clave para gerentes ágiles. Usando su experiencia y responsabilidades de gestión para ayudar al equipo a hacer su trabajo. La gestión ágil requiere liderazgo de servicio. Idealmente liderazgo inspiracional. El equipo se auto-organiza para lograr sus metas. Pero la auto-organización no significa sin control.
El tiempo no espera por nadie.
El plazo - en este caso la duración del Sprint - es fijo. Puedes agregar alcance si debes, o agregar tareas si son necesarias. Sin embargo, cambios en el alcance deben ser compensado por reducciones en el ámbito, por ejemplo quitando algo mas del Sprint.
Si terminas pronto, incluye mas alcance, por ejemplo la cosa siguiente mas importante en la pila del producto. Si te parece que vas a terminar tarde, debes reducir el alcance para alcanzar el plazo.
hecho significa Hecho!
Para lograr un escala de tiempo fija, es imperativo asegurar que completas una característica a la vez antes de moverte a la siguiente. Necesitas evitar alcanzar el fin de la duración del Sprint con el 90% de todo. El 90% de todo te permite entregar nada. Es mejor tener el 100% de algo...
Las pruebas están integradas a través del ciclo de vida
Lograr la conclusión - asegurar que hay algo hecho antes de seguir - significa que las pruebas deben estar integradas a través del ciclo de vida. En el desarrollo ágil, si usas Scrum o no, el ciclo tradicional de desarrollo: análisis, diseño, desarrollo, pruebas, es repetido en una base de característica por característica, en lugar de grandes fases para el proyecto entero o producto.
Sin interferencias por favor.
Idealmente, una vez que el equipo Scrum se ha comprometido a un Sprint, ellos deberían ser dejados que se enfoquen en entregar lo que se han comprometido entregar. Cambios constantes para prioridades previene que un equipo de desarrollo de ser totalmente productivo y en el peor de los casos previenen un equipo de entregar nada.
Si las prioridades deben ser cambiadas durante un Sprint, entonces hay que hacerlo. Sin embargo, una pieza equivalente de trabajo debe ser removida del Sprint para compenzar.
Personalmente me gusta educar a los dueños del producto sobre el impacto de la tala y el cambio mediante el cálculo de los cambios en el doble de esfuerzo. Esto es por que la nueva pieza de trabajo no fue discutida en la Planeación del Sprint, etc, y por lo tanto todo esto debe ser hecho además del esfuerzo para implementar el cambio. Haciendo esto a mitad del camino del Sprint es muy disruptivo. Así que, si debes agregar 3 horas de desarrollo, te debería tomar 6 horas.
Abortando el Sprint
Abortar el Sprint es un acto muy serio y debería ser reservado excepcionalmente para raras circunstancias.
Digamos que la meta del Sprint ya no puede ser aplicable. O algo se ha presentado lo que significa que necesitamos re-enfocar el equipo completamamente. O el Sprint o proyecto está tan alejado del camino que justifica un replanteamiento. Estos son el tipo de eventos cuando deberías considerar abortar un Sprint.
Abortar el Sprint significa literalmente abandonarlo o retrasarse hasta la Planeación del Sprint para reevaluar la prioridades y re-planear.
Afortunadamente esta situación es muy rara y ordinariamente tu equipo Scrum hace el Sprint exitosamente para lograr la meta del Sprint.
Kelly
La entrada original de este artículo es: Step 6: Sprint!
Paso #6: Sprint
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 listo para el paso #6: el Sprint.
Scrum en realidad no prescribe como se debe hacer para la entrega de tus tareas en el Sprint. Scrum es una práctica de gestión ágil y no cubre realmente la ingeniería ágil. XP (Extreme Programming - Programación Extrema) por otro lado es una práctica de ingeniería ágil.
Personalmente pienso que esta es la belleza de Scrum.
Cualquier práctica de ingeniería que uses, desde vaquero a riguroso, desde RAD a RUP, desde XP hasta DIY, cualquiera, Scrum se puede colocar directamente en la parte superior. Ese es el porque digo que es fácil. Es un enfoque de gestión alternativo. Para proyectos y para BAU(Business as Usual). No es un enfoque de desarrollo. Y ese es el porque Scrum funciona, incluso fuera de un contexto de desarrollo.
Así que, el equipo hace el Sprint para lograr la meta del Sprint que ellos se habían comprometido durante los estados de planeación (pasos 2,3 y 4 de esta serie). Aunque Scrum no prescribe nada acerca de como el equipo debería hacer esto, hay unos pocos principios claves del desarrollo de software ágil que quiero resaltar que son particularmente importantes para recordar en este estado del ciclo de vida de Scrum.
Los equipos ágiles deben ser apoderados.
El equipo Scrum toma sus propias decisiones durante el Sprint. El equipo está apoderado. Cada vez que e un gerente se mete y toma una decisión para el equipo, ellos remueven alguna responsabilidad desde el equipo. Si un gerente se mantiene haciendo esto, el equipo gradualmente - pieza por pieza - pierde propiedad, junto con su compromiso.
Como un gerente, debe dar al equipo apoyo, guia, entrenamiento y asistencia. No instrucciones. Si es necesario, el equipo debería ser ayudado a alcanzar sus propias decisiones. La facilitación se convierte en una habilidad clave para gerentes ágiles. Usando su experiencia y responsabilidades de gestión para ayudar al equipo a hacer su trabajo. La gestión ágil requiere liderazgo de servicio. Idealmente liderazgo inspiracional. El equipo se auto-organiza para lograr sus metas. Pero la auto-organización no significa sin control.
El tiempo no espera por nadie.
El plazo - en este caso la duración del Sprint - es fijo. Puedes agregar alcance si debes, o agregar tareas si son necesarias. Sin embargo, cambios en el alcance deben ser compensado por reducciones en el ámbito, por ejemplo quitando algo mas del Sprint.
Si terminas pronto, incluye mas alcance, por ejemplo la cosa siguiente mas importante en la pila del producto. Si te parece que vas a terminar tarde, debes reducir el alcance para alcanzar el plazo.
hecho significa Hecho!
Para lograr un escala de tiempo fija, es imperativo asegurar que completas una característica a la vez antes de moverte a la siguiente. Necesitas evitar alcanzar el fin de la duración del Sprint con el 90% de todo. El 90% de todo te permite entregar nada. Es mejor tener el 100% de algo...
Las pruebas están integradas a través del ciclo de vida
Lograr la conclusión - asegurar que hay algo hecho antes de seguir - significa que las pruebas deben estar integradas a través del ciclo de vida. En el desarrollo ágil, si usas Scrum o no, el ciclo tradicional de desarrollo: análisis, diseño, desarrollo, pruebas, es repetido en una base de característica por característica, en lugar de grandes fases para el proyecto entero o producto.
Sin interferencias por favor.
Idealmente, una vez que el equipo Scrum se ha comprometido a un Sprint, ellos deberían ser dejados que se enfoquen en entregar lo que se han comprometido entregar. Cambios constantes para prioridades previene que un equipo de desarrollo de ser totalmente productivo y en el peor de los casos previenen un equipo de entregar nada.
Si las prioridades deben ser cambiadas durante un Sprint, entonces hay que hacerlo. Sin embargo, una pieza equivalente de trabajo debe ser removida del Sprint para compenzar.
Personalmente me gusta educar a los dueños del producto sobre el impacto de la tala y el cambio mediante el cálculo de los cambios en el doble de esfuerzo. Esto es por que la nueva pieza de trabajo no fue discutida en la Planeación del Sprint, etc, y por lo tanto todo esto debe ser hecho además del esfuerzo para implementar el cambio. Haciendo esto a mitad del camino del Sprint es muy disruptivo. Así que, si debes agregar 3 horas de desarrollo, te debería tomar 6 horas.
Abortando el Sprint
Abortar el Sprint es un acto muy serio y debería ser reservado excepcionalmente para raras circunstancias.
Digamos que la meta del Sprint ya no puede ser aplicable. O algo se ha presentado lo que significa que necesitamos re-enfocar el equipo completamamente. O el Sprint o proyecto está tan alejado del camino que justifica un replanteamiento. Estos son el tipo de eventos cuando deberías considerar abortar un Sprint.
Abortar el Sprint significa literalmente abandonarlo o retrasarse hasta la Planeación del Sprint para reevaluar la prioridades y re-planear.
Afortunadamente esta situación es muy rara y ordinariamente tu equipo Scrum hace el Sprint exitosamente para lograr la meta del Sprint.
Kelly
Serie completa:
#6: Sprint
Comentarios
Publicar un comentario