Diferencia entre revisiones de «Sprint»

De Dos Ideas.
Saltar a: navegación, buscar
(Página nueva: 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 it...)
(Sin diferencias)

Revisión del 15:45 27 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 ScrumMaster puede terminar anormalmente el Sprint y organizar una nueva reunión de PlanificacionDelSprint para iniciar un Sprint nuevo. El ScrumMaster puede realizar este cambio a su criterio, o a pedido del DueñoDelProducto 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 ScrumMaster 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 PlanificacionDelSprint, se necesita planificar mejor. Esto es algo para tratar en la RetrospectivaDelSprint.
  • 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ñoDelProducto 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 BacklogDelSprint (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 descomponeer las tareas con un mayor nivel de granularidad.
  • El Equipo tiene que adherir a los estándares y convenciones existences 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.

Ver también

  • SprintDeRelease