Diferencia entre revisiones de «Sprint»
(→Reglas) |
(→Reglas) |
||
| Línea 24: | Línea 24: | ||
* Si el Sprint requiere un 20% más de trabajo que el planificado luego de dos días después de la [[Planificacion Del Sprint]], se necesita planificar mejor. Esto es algo para tratar en la [[Retrospectiva Del Sprint]]. | * Si el Sprint requiere un 20% más de trabajo que el planificado luego de dos días después de la [[Planificacion Del Sprint]], se necesita planificar mejor. Esto es algo para tratar en la [[Retrospectiva Del Sprint]]. | ||
* Si el Equipo determina que puede resolver más items del Backlog del Producto de los que seleccionó durante la Planificacion del Sprint, el Equipo le puede consultar al [[Dueño Del Producto]] sobre otros items para agregar al mismo [[Sprint]]. | * Si el Equipo determina que puede resolver más items del Backlog del Producto de los que seleccionó durante la Planificacion del Sprint, el Equipo le puede consultar al [[Dueño Del Producto]] sobre otros items para agregar al mismo [[Sprint]]. | ||
| − | * Los [[Miembros Del Equipo De Scrum]] tienen dos responsabilidades administrativas durante el Sprint: tienen que asistir a la [[Reunion Diaria De Scrum]], y tienen que mantener actualizado el estado de los items del [[Backlog Del Sprint]] (por ejemplo, estimado en horas restantes). Se pueden agregar nuevas tareas al [[Backlog | + | * Los [[Miembros Del Equipo De Scrum]] tienen dos responsabilidades administrativas durante el Sprint: tienen que asistir a la [[Reunion Diaria De Scrum]], y tienen que mantener actualizado el estado de los items del [[Backlog Del Sprint]] (por ejemplo, estimado en horas restantes). Se pueden agregar nuevas tareas al [[Backlog Del Sprint]] a medida que vayan surgiendo. |
* Si los miembros del Equipo informan el mismo item el mismo día, tienen que planificar mejor y descomponer las tareas con un mayor nivel de granularidad. | * Si los miembros del Equipo informan el mismo item el mismo día, tienen que planificar mejor y descomponer las tareas con un mayor nivel de granularidad. | ||
* El Equipo tiene que adherir a los estándares y convenciones existentes para el desarrollo, prácticas y arquitectura. | * El Equipo tiene que adherir a los estándares y convenciones existentes para el desarrollo, prácticas y arquitectura. | ||
Revisión del 12:43 28 jul 2008
Un Sprint en Scrum es el término que denomina a una iteración que está acotada en el tiempo, usualmente entre 2 y 4 semanas, durante la cual el Equipo trabaja para convertir items del Backlog Del Producto en un Incremento Del Producto potencialmente productivo.
La duración del Sprint debería ser lo suficientemente larga para crear algo de valor y con la suficiente calidad como para ser demostrado frente al DueñoDelProducto y los stakeholders. Con un plazo superior a 4 semanas el Equipo pierde agilidad, ya que tendrá más artefactos y documentación por la cual preocuparse.
Un Sprint de 2 semanas es la duración ideal, y se conviertió en un estandard defacto por los siguientes motivos:
- Fuerza al equipo a operar de una manera ágil, en vez de hacer "mini cascadas"
- Brinda un feedback más frecuente en lo que se está construyendo
- Reduce el riesgo de "construir la cosa equivocada"
- Incrementa la respuesta del equipo ante cambios en el negocio
- Le brinda al equipo más oportunidades de analizar y adaptarse a la forma que trabajan
Los objetivos y actividades del Sprint se planifican al comienzo de cada Sprint en la reunión de PlanificacionDelSprint. Al finalizar el Sprint el equipo demuestra lo que construyeron en la Revision Del Sprint, y analizan su propia performance y deciden qué mejorar en la Retrospectiva Del Sprint.
La duración de las reuniones del Sprint (Planificación, Revisión y Retrospectiva) se escalan de acuerdo a la duración del Sprint.
El progreso del Sprint se sigue con el Backlog Del Sprint y un gráfico Burndown.
Reglas
- El Equipo puede buscar ayuda externa (consejos, recomendaciones, información y soporte) durante el Sprint.
- Nadie del exterior debe proveer al Equipo con instrucciones, comentarios o direcciones durante el Sprint. El Equipo es el único responsable de sí mismo: se auto-administra completamente, y cada miembro del equipo es responsable por la gestión del mismo.
- El Equipo se compromete a resolver items del Backlog Del Producto durante la reunión de Planificacion Del Sprint. Nadie fuera del Equipo debe cambiar los items del Backlog Del Producto que el equipo ya comprometió.
- Si el Sprint se torna no viable, el Scrum Master puede terminar anormalmente el Sprint y organizar una nueva reunión de Planificacion Del Sprint para iniciar un Sprint nuevo. El Scrum Master puede realizar este cambio a su criterio, o a pedido del Dueño Del Producto o del Equipo. El Sprint podría ser no viable si la tecnología no funciona, las condiciones del negocio cambian, o si alguien exterior interfiere con el Equipo.
- Si el Equipo siente que no podrá completar todos los items del Backlog del Producto comprometidos en el Sprint, puede consultar al Dueño Del Producto sobre qué items quitar. Si son demasiados los items a quitar, y el Sprint pierde así sentido, el Scrum Master puede terminar anormalmente el Sprint.
- Si el Sprint requiere un 20% más de trabajo que el planificado luego de dos días después de la Planificacion Del Sprint, se necesita planificar mejor. Esto es algo para tratar en la Retrospectiva Del Sprint.
- Si el Equipo determina que puede resolver más items del Backlog del Producto de los que seleccionó durante la Planificacion del Sprint, el Equipo le puede consultar al Dueño Del Producto sobre otros items para agregar al mismo Sprint.
- Los Miembros Del Equipo De Scrum tienen dos responsabilidades administrativas durante el Sprint: tienen que asistir a la Reunion Diaria De Scrum, y tienen que mantener actualizado el estado de los items del Backlog Del Sprint (por ejemplo, estimado en horas restantes). Se pueden agregar nuevas tareas al Backlog Del Sprint a medida que vayan surgiendo.
- Si los miembros del Equipo informan el mismo item el mismo día, tienen que planificar mejor y descomponer las tareas con un mayor nivel de granularidad.
- El Equipo tiene que adherir a los estándares y convenciones existentes para el desarrollo, prácticas y arquitectura.
Meta del Sprint
Así como la Visión del Proyecto comunica el objetivo global y el espíritu del proyecto, es también útil contar con una visión para cada Sprint que encapsule todas las tareas en una "Meta". Por ejemplo, en vez de que el "Sprint 6" sea un Sprint más donde se construyen cosas, se podría convertir en el "Sprint del sistema de pagos". Una meta del Sprint puede ser algo como:
- "En este Sprint lograremos que los usuarios puedan ingresar al sitio, recuperar un password olvidado, y administrar su pérfil"
La Meta del Sprint se acuerda durante la reunión de PlanificacionDelSprint al comienzo del Sprint.
Cancelación del Sprint
Un sprint puede ser cancelado antes de tiempo cuando:
- El equipo cancela un sprint si sienten que no pueden completar la Meta del Sprint
- La gerencia puede cancelar el Sprint si circunstancias externas anulan el valor de la Meta del Sprint
Cuando un Sprint se termina anormalmente, el próximo paso es realizar una nueva reunión de PlanificacionDelSprint, en donde se revisa la razón de terminación.
