Pages Menu
Categories Menu

Posted by on Abr 26, 2016 in General | 8 comments

Un Sprint no es, sólo, un trozo de tiempo

La agilidad está de moda. Scrum está de moda. Y todo el mundo quiere estar a la moda. Pero no creas que es fácil ir a la moda. De hecho, como dice el refrán popular, para presumir… hay que sufrir.

Aunque los ciclos de vida en cascada existe, existirán y son la mayoria, decir que los usas suena un poco “retro”. No queda bien, no están de moda.

Será por ello, que una palabra con más de 20 años en nuestro sector, curioso, se ha puesto muy de moda al hablar de aspectos temporales, llámalo ciclo de vida, llámalo contar tu proyecto, cómo trabajas o lo que quieras: el Sprint (entiendo que el de Scrum).

Pero me da que podemos estar abusando del uso de la palabra Sprint. Hasta el punto que en muchos lugares, Sprint se ha convertido en sinónimo de… trozo de tiempo. Algo similar hablamos en Aléjate del concepto “Proyecto” si quieres usar bien Scrum: confundir “versión a entregar” al cliente con final de sprint, y me parece oportuno volver a profundizar en ello.

Un Sprint es un “trozo de tiempo” pero no cualquier trozo de tiempo, no todo trozo de tiempo es un Sprint. Vamos a ver qué dice lo “oficial”, a ver qué dice la guía de Scrum, copy-pego algunos párrafos…

“…un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo”

“Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes”

(Sprint según la guía de Scrum)

No haría falta escribir más, sí, un Sprint es un trozo de tiempo, pero, de menos de un mes, que termina con algo que se puede usar. Pero tampoco te pases al otro lado, que no implica que un Sprint tenga obligatoriamente que terminar con una versión final entregada al cliente o usuario o puesta en producción, esto es cosa de tener claro el concepto de MVP.

Un Sprint, manteniendo su temporalidad de menos de un mes, termina con “un incremento” o un “producto potencialmente entregable”, es decir, una versión del producto, que hay quien llama prototipo, con un incremento de valor (por ejemplo, para que se entienda, con más funcionalidad incorporada que el anterior) y en condiciones “técnicas” para entregarse al usuario o cliente si el Product Owner así lo decide.

Y, además, recuerda que el ciclo de vida ágil es iterativo e incremental, lo que hace que lo normal es que en cada “trozo de tiempo” se dedique tiempo a limpiar deuda técnica.

Ciertamente, que cantidad de extraños usos y adaptaciones hay de Scrum.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

8 Comments

  1. Buenos días,

    Me gustaría saber cómo se gestionan los cambios con metodologías ágiles. Establecer una gestión de cambios es complejo y hasta ahora, en ninguno de tus post he visto referencias a ello.

    Muchas gracias y un saludo, Ascen

  2. Hola Ascen, al leer tu comentario me gustaría preguntarte: ¿A qué tipo de cambios te refieres? ¿Añadir funcionalidad a tu aplicación? ¿corregir alguna parte que no termina de ir bien? ¿te refieres a la gestión del cambio con los usuarios finales stakeholders? En cualquier caso, y seguro que Javier podrá darte una respuesta más completa, cualquier cambio que afecte a la aplicación para evolucionarla puede ser tratado como una historia de usuario que entra a formar parte del product backlog, y sería el product owner el encargado de priorizarla y decidir en qué sprint la atacaría el equipo de desarrollo. Un saludo!

  3. Hola,

    No, me refiero a la gestión de cambios que se realiza en el proyecto por modificaciones en línea base. ¿Cómo se hace una gestión de cambios de manera ágil? No sé si me explico. Un saludo

    • Te refieres a Gestión de la Configuración / Control de versiones? rama por tarea o historia de usuario?

  4. Gestión de la Configuración / Control de versiones, exacto. ¿Qué puedo aplicar a nivel de scrum para que sea más ágil?
    Muchas gracias Javier

  5. No, no me he explicado bien. No lo quiero a nivel de desarrollo, sino a nivel de gestión de proyecto. Me refería a cómo gestionar, dentro del proyecto, a nivel de seguimiento, de forma ágil, la gestión de configuración, control de versiones, elaboración de pruebas…etc..
    Muchas graciass

  6. Buena explicación, bien aclaratoria y al punto.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This