El Sprint en Scrum en Big Data & Business Intelligence

El Sprint en Scrum en Big Data & Business Intelligence

En el artículo anterior me centré en el manifiesto ágil, y en los principios y roles de Scrum. Hoy quiero comentar sobre el concepto de sprint, que por supuesto es un elemento central recogido en la guía de Scrum.

El Sprint

El Sprint es un período de tiempo predeterminado y, en lo posible, de duración constante a lo largo de un proyecto. Las duraciones más habituales son dos o cuatro semanas, pero depende mucho del contexto. Durante el mismo se desarrolla un ciclo completo del resto de eventos (reuniones), más el propio trabajo técnico. Lo que se persigue es entregar un incremento de producto a su finalización, que responda a un objetivo concreto fijado al inicio. Inmediatamente después, comienza el siguiente sprint, de manera que se establece una rutina de entregas periódicas listas para usar, sin que exista tiempo entre sprints.

Se puede pensar el sprint como un miniproyecto. Mientras que de un sprint a otro los cambios son bienvenidos, dentro de un sprint se alcanzan unos compromisos  muy específicos, y solo se deberían permitir cambios o aclaraciones que no amenacen el objetivo del sprint. Si a lo largo del sprint lo que cambia es el compromiso, como puede ser una bajada en la calidad de los entregables, o funcionalidad imprevista al inicio del sprint, estaremos fallando en lo básico de Scrum. Que el sprint sea de un mes máximo facilita las estimaciones, a la vez que limita los riesgos negativos.

Sí que se contemplan casos excepcionales de cancelación de un Sprint en curso, siendo el Product Owner quien tiene la última palabra al respecto. Esto será cuando considere que los objetivos iniciales del sprint ya no son alcanzables, o ya no tienen sentido. No necesariamente hablamos de fracaso, imaginemos simplemente que se decide pasar de una infraestructura propia a otra en la nube, y que no contar con la nueva lo antes posible significará mucho retrabajo posterior. Así pues, se detienen ciertos desarrollos para que se habilite la nueva. En este caso prima el pragmatismo, y no debería castigarse a nadie por una decisión así, ya que seguir con los desarrollos supondría una pérdida futura de valor.

Agilidad

La lección práctica es que dentro de un sprint no se pueden atender cambios importantes de prioridades o de alcance, y es el precio a pagar para cumplir con los compromisos. De esta manera, el equipo técnico puede centrar la mayor parte de su tiempo en las tareas de construcción del producto. Así, hasta cierto punto, se desentiende de otras tareas que no se piensan abordar en el sprint en curso.

Las reuniones, aunque parecen muchas, son limitadas, tanto en tiempo como en intervinientes. Recordemos que se buscan equipos autónomos autoorganizados, y que no quieren ser interrumpidos con frecuencia por directivos, usuarios, etc. Que el Product Owner sea una única persona física (en vez de un grupo de usuarios) ayuda mucho a conseguirlo.

Con todo ello lo que se pretende es que el equipo aumente la velocidad de desarrollo o implementación, hasta encontrar una velocidad de crucero. Siempre entendiendo que la velocidad hace referencia a producto construido y entregado listo para usar dentro de cada sprint, por lo que no vale entregar por entregar. Por ejemplo, una medida de velocidad basada en el número de líneas de código entregadas no es buena elección. Esto es así porque no se puede correlacionar directamente con el valor del producto, aunque un número inusualmente bajo (o alto) de líneas desarrolladas sí que puede activar una alerta de que en ese sprint ha pasado algo peculiar.

Conclusiones

Observemos que los proyectos empiezan a parecerse más a operaciones continuas, sin que por ello se pierda el concepto de producto singular (no estamos fabricando hamburguesas sino productos únicos a medida). Hay quien afirma incluso que para una verdadera agilidad se requiere un sistema de integración continua, que automatiza pruebas y pasos entre entornos, precisamente para que el final del sprint no sea un cuello de botella, y también para que la definición de “hecho” (Done) sea más medible y corporativa.

Debo decir que ni el Business Intelligence ni el Big Data son los proyectos más típicos para pensar en una integración continua muy automatizada, aunque solo sea por posibles problemas de calidad de datos.

Otra adaptación habitual de los proyectos de Analytics, Data Science, Datawarehouse, etc., es considerar un sprint 0. Dicho sprint se sitúa al inicio del proyecto, y puede durar bastante más tiempo que los sprints normales, con el objetivo de preparar infraestructuras, instalaciones de software, estudiar la propia calidad del dato, entender requisitos no funcionales, etc. Es decir, un sprint donde no se entrega un incremento de producto (desde un punto de vista de usuario), y por esto no se puede medir en los mismos términos, ni tienen sentido todos los eventos.

Algunos consideran esto como una especie de trampa, pero yo creo que establecer sprints especiales sin entrega de producto es algo bastante natural en los proyectos analíticos, lo mismo que puede haber sprints cancelados. Todo depende de los objetivos metodológicos que queramos cubrir, y en concreto de cómo queremos medir la velocidad de los equipos, así como el valor del producto.

En siguientes entregas trataré sobre las reuniones y artefactos de scrum, intentando siempre ofrecer algún consejo práctico. Si os está gustando el tema permaneced atentos al Blog de datahack.


José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data & Analytics de DataHack.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *