archivo

Archivos diarios: noviembre 23, 2012

En el artículo de ayer veíamos la necesidad de tener bien definidas las historias de usuario que van a formar parte de la pila de sprint, en el de hoy veremos una posible estrategia para conseguir esto.

¿Qué hacemos entonces? Mientras se trabaja en un sprint hay que estar preparando el siguiente, si trasladamos esto a una línea de producción, mientras las máquinas y sus operarios trabajan es necesario que alguien vaya a comprar y preparar las materias primas, de lo contrario se interrumpe el proceso.

¿Quién hace eso? Posibilidades hay muchas. Hay bibliografía que recomienda reservar entre un 5% y un 10% de la capacidad del equipo del sprint a realizar estas tareas o lo que es lo mismo, el equipo de sprint considera en cada iteración que tiene entre un 5 y un 10% de capacidad menos para asumir tareas. Estos límites pueden fluctuar en función del momento del proyecto en el que no encontremos a la vez que podrían sobrepasarse en el caso de que fuera necesario (y se tuviera en cuenta en la definición de la capacidad asumible en el sprint).

¿Mi opinión? Como siempre, os advierto que no hay soluciones únicas. Es fundamental que las tareas con mayor prioridad de cara al siguiente sprint estén lo suficientemente detalladas para que se pueda hacer una buena estimación y se pueda comenzar a trabajar con el objetivo de que la línea de producción pueda funcionar fluida y podamos cumplir los compromisos.

Por tanto no debemos quedarnos cortos a la hora de dedicar esfuerzo a esta actividad (que suele recibir el nombre de refinamiento de la pila de producto). Es posible que para conseguir ese objetivo tengamos que poner un cierto colchón de seguridad por si el proceso de definición es más complejo de lo que parecía (algo que es, por otro lado, bastante frecuente), desde mi punto de vista es mejor que no se llegue a ese tope y corramos el riesgo de “tirar” capacidad (algo que no tiene por qué ser así porque ese tiempo extra lo podría dedicar a echar una mano en el sprint en curso ya que siempre hay tareas que hacer y nunca está de más contar con ayuda extra) que poner en riesgo los compromisos del sprint o lo que es lo mismo, perder más tiempo por bloqueos en el proceso de desarrollo motivados por no tener todos los “ingredientes” necesarios para trabajar.

Con esto estoy diciendo que quien realice esa tarea (que podría ser siempre el mismo o no) es parte del equipo, es decir, sufrirá o se beneficiará de la calidad de su trabajo, de esta manera evitamos antipatrones del tipo “arrojar al otro lado del muro”. Esto implicará que parte de su dedicación (prevista y cuantificada en cada iteración) tiene que estar en el sprint y ser tenida en cuenta la hora de definir los compromisos.

Por tanto, estoy de acuerdo con lo que indica la bibliografía pero no tanto en los porcentajes que expresa porque me parecen demasiado optimistas sobre todo para proyectos que empiezan.

Anuncios