Archivos por Etiqueta: SCRUM

En Scrum existen diversas reuniones o eventos, también llamadas ceremonias, que tratan de crear regularidad y reducir al mínimo la necesidad de reuniones fuera de las definidas en Scrum. Todas estas reuniones tienen una duración máxima (timeboxing) con el objetivo de que estos eventos no se conviertan en eternos llevándonos por disquicisiones que no van a ningún lado o a la pérdida de tiempo.

El propio Sprint es el evento central dentro de Scrum y contiene al resto de eventos y ceremonias. Todos estos eventos están diseñados para permitir la inspección y la adaptación de lo que está pasando en el proyecto. Cada uno de ellos es una oportunidad de mejorar el proyecto y darle transparencia a todos los participantes. Si falta alguno de ellos podría estar faltando transparencia al proyecto y perderse esa oportunidad de adaptarse a los cambios para mejorar.

El Sprint

El Sprint es el corazón de Scrum, es un bloque de tiempo de un menos o menos, suele ser de dos semanas, durante el que se crea un incremento del producto Terminado, Utilizable y Potencialmente desplegable. Estas tres características son importantes:

• Terminado: Se dice así cuando por consenso de los participantes del proyectos, las funcionalidades, nuevas características o errores corregidos durante el Sprint están completamente hechos o terminados. Es decir que no faltan fases de test o que las funcionalidades están incompletas a falta de uno o más sprints para finalizarlos.
• Utilizable: Las nuevas características que estamos añadiendo en este Sprint son utilizables por el usuario final que las puede comenzar a usar tan pronto como hayan sido desplegados. No se trata de características a las que les falte alguna otra funcionalidad a ser desarrollada más adelante para poder ser utilizada.
• Potencialmente desplegable: Puede que decidamos no subir a producción tan pronto como terminemos el Sprint y que esperemos a tener un conjunto mayor de funcionalidades a hacer esta subida pero lo que entreguemos al final el Sprint estará listo y podría ser desplegado en producción si así lo hubiéramos decidido.

Dentro de cada Sprint encontraremos las siguientes reuniones y ceremonias que se explicarán con más detalle a lo largo de este capítulo:

• Reunión de planificación del Sprint (Sprint Planning Meeting)
• Reuniones de Scrum Diario (Daily Scrums)
• Reunión de demo o revisión del sprint (Sprint Review)
• Retrospectiva del Sprint (Sprint Retrospective)

El Sprint tiene las siguientes características:

• Cada Sprint comienza justo después de la finalización del Sprint anterior.
• El Sprint se ajusta a un Objetivo del Sprint que es la meta que quiere alcanzarse cuando se acabe el Sprint. Por ejemplo: Desarrollar el sistema de login de la aplicación.
• No se disminuyen los objetivos de calidad para llegar al objetivo del Sprint.
• El alcance del Sprint puede ser clarificado con el Dueño del Producto y el Equipo de Desarrollo para renegociarlo con ellos a medida que sucede el Sprint y vamos conociendo más durante el Sprint.

Podemos considerar al Sprint como un mini proyecto que tiene un horizonte de un mes o menos (por ejemplo dos semanas). Un proyecto que tiene un objetivo y unas etapas en las que se va a definir qué se va a construir, se diseña y se trabaja un plan para la construcción del producto resultante al finalizar esas dos semanas.

El objeto de dividir el proyecto en todos esos mini proyectos de un mes o menos es el del clásico divide y vencerás. Con proyectos tan pequeños podemos mantener acotada al complejidad, evitar que cambie lo que se está construyendo y evitar que aumente el riesgo de proyecto durante ese tiempo. Además al ser proyectos tan pequeños podemos adaptarnos al finalizar y comenzar un nuevo Sprint a lo que hayamos aprendido en el Sprint anterior. Por todo esto el riesgo de estos mini proyectos estarán limitados al costo de un mes de trabajo como máximo.

¿Se puede cancelar un Sprint?

Sí, un Sprint puede ser cancelado antes de que llegue a su fin. El Dueño del Producto y sólo él puede decidir que no merece ya la pena el Objetivo del Sprint por lo que puede concluirlo.

Algunas cosas pueden ocurrir en el plazo máximo de un mes que puede durar un Sprint: la dirección cambia de estrategia, a los interesados en el producto ya no le interesan las funcionalidades a desarrollar en este Sprint, o las condiciones del mercado o de la tecnología cambian y ya no tiene sentido el objetivo del Sprint.

Debido a la corta duración del Sprint las cancelaciones normalmente no tienen lugar porque no tantas cosas pueden cambiar de repente. Es algo que debemos de evitar porque cancelar un Sprint tiene un coste: Hemos estado preparando y planificando el Sprint y debemos reunirnos de nuevo para planificar el siguiente. Casi todo ese esfuerzo se tira a la basura para comenzar un nuevo Sprint. Podemos dar además la sensación de estar actuando sin una clara dirección o estar tomando los objetivos de los sprints muy alegremente, sin pensarlos demasiado.

A la hora de cancelar un Sprint revisaremos todos los elementos de la Lista o Pila de Producto y comprobamos cuales de ellos están en estado Terminado y son potencialmente entregables para presentarlos al Dueño del Producto y que éste diga si lo acepta como entrega o no. El resto de elementos de la Lista del Sprint que no estuviesen completados vuelven a la Pila del Producto para volver a ser estimados ya que el trabajo que se haya hecho en ellos pierde valor con rapidez y debe volverse a estimar.