Sprint ​

“Todos los días el equipo se reúne brevemente para informar del progreso, y actualizan unas gráficas sencillas que les orientan sobre el trabajo restante. Al final del Sprint, el equipo revisa el Sprint con los interesados en el proyecto, y les enseña lo que han construido. La gente obtiene comentarios y observaciones que se puede incorporar al siguiente Sprint. Scrum pone el énfasis en productos que funcionen al final del Sprint que realmente estén 'hechos'; en el caso del software significa que el código esté integrado, completamente probado y potencialmente para entregar [...]“ (The Scrum Primer - versión en español, 2009, pág. 5).

El Sprint de Desarrollo (El Corazón del Scrum) ​

Se denomina Sprint a cada ciclo o iteración de trabajo que produce una parte del producto terminada y funcionalmente operativa (incremento). El objetivo principal es transformar un conjunto de ítems requeridos por el usuario en un incremento de funcionalidad 100% operativa para el software.

Las implementaciones más flexibles pueden adoptar dos tácticas diferentes para mantener un avance (incremento) en el proyecto:

• Incremento Iterativo: basado en pulsos de tiempo prefijado o Sprint.
• Incremento Continuo: basado en el mantenimiento de un flujo continuo, no marcado por pulsos de tiempo prefijado.

Al usar el marco técnico se trabaja con Sprints, y por tanto con incremento iterativo. Cuando se logra un conocimiento pragmático se puede adoptar el incremento continuo.

Un Sprint tiene dos características fundamentales:

• Una duración fija entre 1 a 6 semanas.
• Cada Sprint se ejecuta de forma consecutiva.

Entonces: ¿Sin tiempo muerto entre un Sprint y otro?

Descansos entre Sprints ​

Ironía → Como desarrollador nunca puedes relajarte, todos los días tienes que estar de pie en esa puñetera reunión y decirle a todo el mundo lo que conseguiste ayer. Muy pocos dirán algo como “pasé la mayor parte del día con los pies sobre la mesa, leyendo blogs y sorbiendo un capuchino”.

En la vida real no puedes estar siempre esprintando. Si siempre estás esprintando, en realidad acabarás haciendo footing (metiendo la pata).

Lo mismo ocurre en Scrum y en el desarrollo de software en general. Los Sprints son muy intensos.

Además del propio descanso, hay otra buena razón para dejar algo de espacio entre Sprints. Después de la demo y la retrospectiva tanto el Dueño del Producto como el Equipo estarán llenos de información y de ideas por digerir. Si se ponen de inmediato a planificar el próximo Sprint, es probable que nadie tenga la oportunidad de digerir ninguna información o lección aprendida, el Dueño del Producto no tendrá tiempo de ajustar sus prioridades después de la demo, etc.

Mal:

Intentar introducir algo de descanso antes de empezar un nuevo Sprint (más específicamente, en el periodo después de terminar la Retrospectiva del Sprint y antes de la siguiente Reunión de planificación de Sprint). No siempre se consigue, la verdad.

Como mínimo, intentar que la Retrospectiva y la subsiguiente Planificación del Sprint no ocurran el mismo día. Todo el mundo debería tener al menos una buena noche de sueño sin Sprint antes de comenzar el siguiente Sprint.

Mejor:

Mucho Mejor:

“Una forma de hacer esto son los “días de laboratorio” (o como quieras llamarlos). Es decir, días en los que a los desarrolladores se les permite hacer esencialmente cualquier cosa que deseen (OK, admitido, está inspirado en Google). Por ejemplo, leer sobre las últimas herramientas y API’s, estudiar para una certificación, discutir asuntos técnicos con colegas, programar un proyecto personal como hobby, etc.”

El objetivo es tener un día de laboratorio entre cada Sprint. De esta forma se obtiene un descanso natural entre Sprints, y se tendrá un Equipo de Desarrollo que tendrá una oportunidad realista de mantener su conocimiento al día. Además, es un estupendo beneficio laboral.

Henrik Kniberg

¿El Mejor?

“Actualmente tenemos días de laboratorio una vez al mes. El primer viernes de cada mes, para ser más específicos. ¿Por qué no entre Sprints? Bueno, porque sentía que era importante que toda la compañía se tomase el día de laboratorio a la vez. De otra forma la gente tiende a no tomárselo en serio. Y dado que (hasta ahora) no hemos sincronizado los Sprints de todos los productos, tuve que seleccionar un día de laboratorio no dependiente de los Sprints.

Puede que algún día intentemos sincronizar los Sprints de todos los productos (es decir, misma fecha de inicio y fin de Sprint para todos los productos y equipos). En ese caso, definitivamente colocaremos un día de laboratorio entre Sprints.”

Henrik Kniberg