Monthly Archives: marzo 2010

Pruebas con tablero Kanban

Hace ya unas semanas que lleva una pizarra de etiquetas que puse en un sitio muy visible (de camino a los aseos) en la oficina donde trabajo. Quisiera explicaros un poco el funcionamiento y las ventajas que he observado hasta ahora.

Se llama pizarra Kanban . Hay muchas variaciones. Scrum Alliance propone una etiqueta para historia de usuario y otras etiquetas para las tareas de esa historia de usuario. El que he puesto tiene 2 columnas y 3 Filas:

DESARROLLO TESTING
SIN EMPEZAR
EN CURSO
COMPLETADAS

En cada celda de la tabla habrá de 0 a varios post-its indicando proyectos en los que estamos. Los temas de soporte no hace falta meterlos aqui porque ya se gestionan en la web que tenemos. De todos modos si hay algo de soporte que implica un seguimiento concreto se puede meter para que se sepa en tejado de quien está. Las tareas pequeñas de menos de un dia no hace falta incluirlas y se considera ruido.

Un proyecto software tipicamente tendrá este circuito:
Desarrollo/Sin empezar –> Desarrollo/En Curso –> Testing/Sin empezar –> Testing/En curso –> Testing/Completado

El movimiento de las etiquetas lo hará la persona responsable para esa función. Tipicamente los desarrolladores moveran en la columna de Desarrollo y los del area tecnica lo harán en la columna de Testing. Todos los que estan implicados en ese proyecto pueden moverlo. Si hay discrepancias, enseguida se verán y se solucionarán.

En una etiquetas se puede escribir el nombre de la tarea y la fecha de inicio.
Si a una etiquetas se le quiere indicar información añadida temporal, (por ejemplo la tarea dentro de ese proyecto que hace falta para que se complete, necesidades especificas,… )se puede adjuntar una mini-etiqueta. Dado que no he conseguido pegar las mini-etiquetas dentro de la etiqueta grande de la tarea con el propio pegamento, lo he solucionado con unas pinzas pequeñas que las sujetan.

Ventajas del sistema:

  • Visibilidad global del trabajo de toda la oficina. Todo el mundo que ve la pizarra ve claramente qué se está moviendo y como está de camino a los aseos es paso obligado. 😉
  • Concretitud de la cantidad de proyectos. En ocasiones no tenemos constancia de las cosas que se estan haciendo en un departamento y puede parecer que hay muchas más o muchas menos de las que en realidad hay. El tablero es una vision realista de la carga de trabajo.
  • Decision a la hora de dar un proyecto como completado. Cuando alguien pasa algo de en curso a completado lo hace a la vista de todos y esto conlleva a que se asegura de que realmente no queda nada por hacer. Esto evita el tipico problema del 85% completado.
  • Cuando hay varios implicados en un proyecto, si uno de ellos mueve la tarea a completado y otro no está de acuerdo enseguida se verá y se llegará al consenso para decidir si el proyecto está completado o no.
  • No se cogen más proyectos hasta que todo lo que está en curso no se haya completado. Para evitar la saturacion de tareas en curso, normalmente se motiva el completar lo que se tiene por terminar antes de empezar algo nuevo. En algunas implementaciones de Kanban incluso se define un número maximo de elementos que pueden estar en curso.
  • Claridad en lo que está en el tejado de un departamento o en el otro.

El objetivo es que sea una herramienta que nos ayude a todos más que una burocracia. Si se ve que no se mantiene al día o que no ayuda en nada pensaré en quitarlo pero por el momento parece que ya esta dando frutos. Es importante la experimentación para intentar sacarle el máximo jugo. Si descubro usos nuevos o variaciones las iré actualizando esta entrada.

Un saludo.

Anuncios