Hay quien piensa que buscar una pared, llamarla DashBoard y pegar Post-its va a ser la solución a todos sus males: vamos a utilizar Scrum y ahora todo irá bien. Cumpliremos fechas, no habrá bugs y el equipo estará motivado.
Es fácil perder el rumbo con tan vistoso elemento, pero no debemos dejarnos llevar y tenemos que hacer un esfuerzo por ver el tablero como la herramienta que es. Debemos darle su importancia, cuidarlo, trabajarlo, respetarlo... al igual que las demás herramientas: Daily meeting, TDD, calidad del código, pair programming, pruebas, definition of done...
Si solo tenemos tiempo para producir líneas de código y tenemos que aprovechar las escapadas al baño para mover post-its de una columna a otra, lo único que tendremos será un bonito panel para las fotos, pero no habremos mejorado mucho más. Tendremos los post-its en la pared, pero también un par de ellos pegados en los ojos.
Cuando veo a algún equipo sobrecargado de historias de usuario, que va cayendo en la típica espiral de generación de código sin probar para llegar a fechas en una iteración, que seguirá igual en la siguiente, añadiendo el agravante de tener que resolver los bugs encontrados en la anterior... lo que veo es que tienen también post-its en los ojos. ¿No sería más fácil reconocer que la velocidad del equipo no es la esperada y replanificar las entregas? ¿No podríamos decir que en el primer sprint se ha visto que la velocidad estaba mal calculada? Seguro que habría alguna buena explicación como la falta de conocimientos funcionales, mayor complejidad técnica de la esperada, el equipo podría estar siendo menor a la previsión inicial, o simplemente la gripe podría haber desacelerado una tarea curso.
Si solo tenemos tiempo para programar, eliminamos las reuniones diarias porque nos quitan tiempo... es que también tenemos los post-its pegados en los ojos.
Si solo podemos pensar en por qué no se ha movido un post-it a la columna siguiente en lugar de eliminar las dificultades del equipo, no estaremos ayudando. Y significará que también tenemos los post-its pegados en los ojos.
viernes, 4 de febrero de 2011
viernes, 28 de enero de 2011
Kanban con departamentos externos
Es complejo trabajar con kanban cuando no tienes el control de todos los procesos. Muchas veces las tareas quedan paradas en una parte del proceso al depender de otros departamentos.
En nuestro caso, tenemos que realizar los despliegues vía tiquet a otro departamento. La resolución de los mismos no es inmediata. Esto hace que los límites de WIP (work in progress) no siempre puedan ser aplicables. No podemos mantener esas tareas dependientes en la columna de "En proceso" porque restan capacidad de trabajo, pero la dependencia de la acción del departamento externo en nuestro flujo de estados (para pasar la tarea al estado "En pruebas" después y luego al estado "Finalizado") hace que tengamos que guardar el estado de esa tarea. No podemos por tanto ni devolverla a la columna de Pendiente con alguna anotación añadida, ni dejarla En proceso.
Esta problemática hacía que me cuestionara la viabilidad de utilizar Kanban con el proyecto actual, hasta que he dado con una posible alternativa que a priori, resolvería esta casuística:
La solución que planteo es crear una nueva columna con el estado "Despliegue Externo", pero sin WIP. Esto nos permite poder mover allí todas las tareas que finalicemos en el estado previo "En Proceso", aunque se vayan acumulando. Como el departamento externo, podría llegar a realizar los despliegues en bloque, y necesitamos guardar el estado de desplegado, podemos crear 2 subcolumnas: "Pendiente" y "Desplegado". Con la 2º subcolumna creamos un pequeño buffer para poder retomar las tareas y continuar con los procesos de nuestro departamento.
En nuestro caso, tenemos que realizar los despliegues vía tiquet a otro departamento. La resolución de los mismos no es inmediata. Esto hace que los límites de WIP (work in progress) no siempre puedan ser aplicables. No podemos mantener esas tareas dependientes en la columna de "En proceso" porque restan capacidad de trabajo, pero la dependencia de la acción del departamento externo en nuestro flujo de estados (para pasar la tarea al estado "En pruebas" después y luego al estado "Finalizado") hace que tengamos que guardar el estado de esa tarea. No podemos por tanto ni devolverla a la columna de Pendiente con alguna anotación añadida, ni dejarla En proceso.
Esta problemática hacía que me cuestionara la viabilidad de utilizar Kanban con el proyecto actual, hasta que he dado con una posible alternativa que a priori, resolvería esta casuística:
La solución que planteo es crear una nueva columna con el estado "Despliegue Externo", pero sin WIP. Esto nos permite poder mover allí todas las tareas que finalicemos en el estado previo "En Proceso", aunque se vayan acumulando. Como el departamento externo, podría llegar a realizar los despliegues en bloque, y necesitamos guardar el estado de desplegado, podemos crear 2 subcolumnas: "Pendiente" y "Desplegado". Con la 2º subcolumna creamos un pequeño buffer para poder retomar las tareas y continuar con los procesos de nuestro departamento.
Suscribirse a:
Entradas (Atom)