En este post me centraré en ilustrar algunas variantes del concepto de Sprint en su aplicación en diferentes contextos de trabajo. Tener presente estas variantes es muy importante para hacer una buena adaptación metodológica al contexto de trabajo. Sin embargo, tampoco habría que desestimar la opción "cero", que sería simplemente NO usar Sprints :-). Pero de aquí en adelante en este post asumo que estamos en un contexto donde sí que es conveniente usar Sprints.
En Scrum el concepto de Sprint es protagonista, aunque si no usáramos Sprints todavía tendríamos de Scrum otras prácticas ágiles que son muy interesantes, tales como: equipo auto-gestionado, equipo crosss-functional, los roles de Scrum, etc. Aunque básicamente un Sprint es una iteración, en Scrum establecen las siguientes características específicas:
- Debe dar como resultado un incremento potencialmente entregable del producto.
- No debería durar más de 4 semanas.
- Debería comenzar apenas se termine el Sprint anterior.
- Contiene ítems cuya suma de esfuerzo estimado debe ser coherente con la Capacidad del equipo.
Contenido de los Sprints
- A priori, se esperaría que al usar Sprints los ítems que se van a implementar en un Sprint estén predeterminados, ya que asumimos que el contexto de un Sprint es el de trabajo planificable (se conoce anticipadamente qué se hará en el Sprint). Además, durante el Sprint no debería haber demasiada presión por añadir ítems adicionales, considerando que su duración es de unas pocas semanas. El cliente puede que no vería resuelto su nuevo ítem al finalizar el Sprint actual, pero si dicho ítem tiene suficiente prioridad podrá incluirse en el siguiente Sprint. Sin embargo, si hay cierta urgencia se podría añadir el nuevo ítem al Sprint quitando otro equivalente en esfuerzo y que aún no haya sido implementado.
- Por otra parte, los Sprints pueden ser útiles en contextos NO planificables, es decir, donde no se conoce con exactitud qué trabajo se realizará en las próximas semanas. En estos casos el Sprint permite agrupar ítems de trabajo, aunque el contenido no será definitivo hasta que no se dé por terminado el Sprint. Por ejemplo, en un contexto de mantenimiento de un producto, al comenzar un Sprint se podría en extremo iniciarlo vacío, y en la medida que se van terminando ítems se van incluyendo (ya terminados) en el Sprint. Luego, en algún momento se decide cerrar el Sprint con el contenido de ítems terminados en ese instante. Otro escenario posible sería incluir en el Sprint un conjunto de ítems candidatos y que luego, cuando se considere conveniente, se terminaría el Sprint solo con los ítems terminados, y el resto de ítems se devolverían al Backlog para competir con otros ítems candidatos para el siguiente Sprint.
- Tener Sprints de la misma duración genera una sana rutina de trabajo para el equipo. Esto además facilita el cálculo de la Capacidad del equipo, es decir, facilita el conocer cuántos Puntos u Horas Ideales (o cualquier otra unidad de medida que se utilice) podría abordar con éxito el equipo en un Sprint.
- Por otra parte, si durante el Sprint se detecta que no será posible terminar todos los ítems podría optarse por alargar el Sprint. Si esto se hace de forma habitual puede llevar a una relajación o falta de compromiso del equipo. Suele ser más recomendable terminar el Sprint en la fecha prevista y tomar oportunamente las acciones necesarias respecto a decidir qué ítems no se llegarán a terminar, o incluso para aquellos ítems ya comenzados crear un nuevo ítem que incluya el trabajo no realizado permitiendo así terminar el ítem original solo con la parte del trabajo ya hecha.
- Hay situaciones en las cuales la demanda de trabajo no es previsible y fluctúa de forma importante. Por ejemplo, en un contexto de mantenimiento podemos pasar por períodos de mucho trabajo (después de una entrega de una versión con cambios importantes), y otros en los cuales hay poca demanda. En esta situación aún podría ser útil usar Sprints como agrupador, pero en este caso los Sprints podrían no ser ni continuos ni de la misma duración.
- En cuanto al tamaño de los Sprints, ¿cuál es el tamaño aconsejable (considerando que no deben ser de más de 4 semanas)?. Mientras menos duración tengan los Sprints más frecuentemente podremos evaluar la buena marcha del trabajo. Sin embargo, el arranque y cierre de cada Sprint conlleva un esfuerzo (costes de transacción), y debe evaluarse hasta qué punto compensa realizarlo tan frecuentemente. Me refiero a actividades tales como las reuniones de planificación y de revisión del Sprint, el posible despliegue de la versión, pruebas (y especialmente pruebas de regresión), formación de usuarios, actualización de manuales, etc. Para un contexto nuevo de trabajo (nuevo en cuanto a los miembros del equipo, la tecnología utilizada, el dominio de aplicación, etc.) mi recomendación es comenzar con Sprints más bien pequeños, de 1 a 2 semanas, con el propósito de que el equipo aprenda y se adapte rápidamente. Luego, en un régimen de trabajo más estable recomendaría pasar a Sprints de 3 semanas. No me gustan los Sprint de 4 semanas y menos cuando se corresponden con meses de calendario pues prefiero que exista mayor atención (o inquietud) respecto a qué semana se termina un Sprint :-).
- Para poder tener cierta garantía de cumplir con la implementación de los ítems incluidos en el Sprint debería existir coherencia entre la Capacidad del equipo y el esfuerzo requerido. Pero para hacer estimaciones de dicho esfuerzo con cierta precisión es necesario definir qué involucra cada ítem, es decir, saber cuáles son los requisitos asociados al ítem. Cada ítem necesita una "preparación", es decir, tareas relacionadas con la definición, especificación, validación, diseño y estimación (entre otras). Así pues, cada ítem del Sprint debería estar preparado antes de comenzar el Sprint. De esta forma, durante el periodo del Sprint el trabajo consistiría básicamente en implementar y probar cada ítem. La preparación de ítems de un próximo Sprint se debería hacer en paralelo a la implementación del Sprint actual. Particularmente, podría dejarse dicha preparación hacia el final del Sprint actual, cuando se va extinguiemdo el trabajo del Sprint actual y los miembros del equipo que vayan quedando sin trabajo en el Sprint actual puedan dedicarse a la preparación de ítems del Sprint siguiente. El caso extremo sería esperar a realizar toda la preparación en la Reunión de Planificación del Sprint, para la cual Scrum propone una duración de 8 horas (para un Sprint de 4 semanas). La razón de dichas 8 horas es precisamente porque se asume que los ítems que se incluirán en el Sprint podrían aún no estar preparados.
- Si hay ítems incluidos en el Sprint y que no están preparados al comenzar el Sprint puede deberse a que simplemente no alcanzaron a ser preparados, y se tendrán que ir preparando durante el Sprint con el ruido que esto conlleve en la marcha del Sprint. También esa situación podría corresponder a una decisión estratégica para abordar un ítem de cierta complejidad, entremezclando su preparación e implementación, llevando al extremo el desarrollo incremental de dicho ítem. Obviamente, cuando no todos los ítems del Sprint están preparados y estimados hay más incertidumbre respecto a si se terminarán todos los ítems en la fecha de fin del Sprint.
- En ediciones anteriores de la Guía de Scrum (scrumguide.org) se hablaba de la Release Planning Meeting, la cual consistía en establecer previamente cuáles serían los Sprints que conformarían una Release (Entrega). Por ejemplo, si teníamos una Release comprometida en 6 meses, podríamos planificar el contenido de 8 Sprints de 3 semanas cada uno hasta conseguir dicha Release. Sin embargo, muchas veces la dinámica del contexto de trabajo usualmente tira por tierra cualquier intento de planificación detallada a mediano o largo plazo. Por esto es más eficaz trabajar con un Backlog bien gestionado y ordenado, y luego a partir de él ir estableciendo solo el Sprint siguiente. Sin embargo, en la medida que se va extinguiendo el trabajo del Sprint actual podría abrirse ya el nuevo Sprint, aunque no necesariamente para comenzar a implementar sus ítems, sino solo como contenedor de los ítems candidatos que se están preparando para ese próximo Sprint.
- Otra situación en la cual puede ser útil tener varios Sprints abiertos, e incluso implementándose en paralelo, es cuando tenemos equipos diferentes trabajando sobre el mismo producto. Podría tratarse que equipos trabajando en diferentes áreas o subsistemas, equipos trabajando en mantenimiento o en desarrollo, etc. En esas situaciones puede que además sea conveniente que cada línea de trabajo tenga su propio Backlog y planificación de Sprints (aunque se trate del mismo producto). Indudablemente en estos casos se requiere una buena coordinación del entre los equipos involucrados.
Finalmente, y muy importante que cualquier decisión asociada a los Sprints (y otros aspectos de organización del trabajo) debe tomarse considerando las características de cada línea de trabajo, pues puede haber diferencias significativas entre una y otra. Aplicar de forma uniforme una decisión siempre es lo más sencillo, pero suele ser muy ineficaz cuando hay diferencias importantes entre las líneas de trabajo. Cuando digo "línea de trabajo" me refiero al desarrollo, mantenimiento o soporte, de un producto o de un servicio. No es lo mismo un contexto de desarrollo planificado respecto de uno de mantenimiento continuo, o de uno de soporte (donde no podemos prever el trabajo que llegará en las próximas semanas), incluso tratándose del mismo producto o servicio sus líneas de trabajo en general requieren un tratamiento particular. Lectura recomendada: Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega.
Patricio Letelier
No hay comentarios:
Publicar un comentario