jueves, 17 de febrero de 2011

Una Solución pre-Scrumban / A pre-Scrumban Solution



Hace unos meses, leyendo las aportaciones de la comunidad española que trabaja con prácticas ágiles, me topé por primera vez con el término “Scrumban”. A partir de allí me leí el estupendo paper de Kanban vs SCRUM, y me alegré al saber que compartía problemas con ellos y podía leer sobre sus soluciones.

En este post, voy a centrarme en un problema que me he encontrado en el pasado y en una solución que adopté, y en siguientes posts voy a estudiar cómo se relacionan con las tendencias Scrumban que mis compañeros de agilismo están explorando.

En proyectos en los que he implantado SCRUM, había una serie de problemas recurrentes. Uno de estos problemas era qué hacer cuando el equipo de desarrollo también realiza tareas de soporte. Muchas veces, el equipo de desarrollo no sólo tiene que desarrollar nuevas funcionalidades, sino también arreglar bugs y realizar soporte puro y duro. En compañías grandes, los equipos suelen estar diferenciados, pero cuando se trata de empresas pequeñas, los desarrolladores tienen que contestar el teléfono y “apagar fuegos”.

El problema con SCRUM es que no permite incluir tareas nuevas cuando un Sprint ha empezado. Esto no es una restricción caprichosa, pues tiene un buen fundamento: hay que acotar el nivel de cambio dentro de un equipo para poder entregar el paquete de software prometido a final del Sprint. Si estamos cambiando continuamente el alcance de un Sprint, los conceptos de velocidad y compromiso por parte del equipo a entregar lo acordado para ese Sprint, se pierden. ¡No vamos a comprometernos a entregar algo que no sabemos qué es!

Pero si el equipo de software también tiene que ofrecer soporte... ¿cómo podemos decirle a un cliente (usuario, manager…) que tiene que esperar a que el Sprint se acabe para solucionar el problema? Aunque el problema sea urgente, tendrá que esperar a que el Sprint acabe, se priorice la solución en la pila de producto (por el Product Owner) y finalmente, se entregue al final del Sprint siguiente (supongo que, como el problema era urgente, el Product Owner lo prioriza). En el mejor caso, si el problema sucede el último día de un Sprint, el tiempo de respuesta seria la duración del siguiente. Y en el peor, si sucede el primer día del Sprint, dos veces esta duración. E incluso podríamos calcular un tiempo medio de respuesta, haciendo estadísticas de cuando suceden los problemas durante un Sprint en nuestra compañía, calculando su distribución temporal y obtener un tiempo medio de finalización del Sprint en curso (al que sumaríamos después la duración del siguiente). Sea como sea, esto no funciona si el problema es realmente urgente y se debe solucionar.

En un pasado, yo utilicé un método “híbrido”: bajábamos la velocidad de equipo de forma artificial para dejar un buffer para “soporte”. Hay que recordar que en SCRUM, los equipos son multifuncionales y por lo tanto todos los miembros del equipo podían realizar soporte. Definíamos una serie de tareas del Product Backlog como “opcionales”, utilizando una versión reducida del Moscow Method:

- Tareas M “Must”: conformaban el Sprint, el compromiso del equipo.
- Tareas S “Should”: estas tareas se realizarían si no había tareas de soporte. En caso de que surgieran dichas tareas, las tareas “Should” podrían descartarse. No formaban, a priori, parte del compromiso del equipo con el cliente.

Este método no es perfecto, pues también limita la capacidad de soporte del equipo, pero dicha capacidad máxima de soporte era algo que se acordaba con los clientes/usuarios. Por ejemplo, “el equipo dedicará un máximo de 20% a soporte”. Entonces “Tareas Must” = Compromiso = Velocidad - 20%. Si no se realizaban tareas de soporte, el equipo debía realizar las tareas “Must” y “Should”. Las soluciones de bugs se ponían en producción cuando el Sprint finalizaba, con lo que el tiempo de respuesta se reducía.