A través de javahispano, (original de One day in Kanban land ), encuentro un post de astracanada en el que cuentan un dia de Kanban en una tira de comic. Leyendo el comic que copio a continuación, se entiende bastante bien la filosofía de Kanban. De todas formas, después de la imagen pongo las mil palabras que valen menos.
En Kanban la idea es centrarse en tareas concretas, bajo demanda y no abordar demasiadas cosas a la vez. En la primera columna del tablero están todas las tareas a hacer. El responsable del proyecto pasa las que considera más importantes a la columna "selected" con una restricción: nunca puede tener en esa columna más de dos tareas (el 2 que aparece debajo de selected).
Los desarrolladores, en su columna "Develop", pueden tener un máximo de dos tareas. La columna se subdivide en dos: las que están haciendo en ese momento "Ongoing" y las que ya han acabado "Done". No puede nter más de 2 tareas en la columna "Develop".
Los de pruebas "Deploy", sólo pueden tener una tarea. Una vez probada, se pasa a la columna "Live", que es definitivamente acabada.
Cuando cualquiera se queda sin trabajo porque los límites de las columnas le impiden coger alguna o añadir más, deben intentar ayudar a los del tapón. Es el ejemplo, hacia la mitad del comic, en que un grupo de desarrolladores no pueden coger una nueva tarea puesto que hay un taón en la parte de pruebas. Su misión es ir a ayudar en las pruebas. Incluso el jefe, cuando ve el atasco, intenta ayudar como puede (llevando más café).
La verdad es que es una metodología bastante interesante para fases finales de proyecto, donde básicamente lo que hay son bugs, modficaciones y pequeños añadidos.
Poned la referencia al original, no? (http://blog.crisp.se/henrikkniberg/). Por cierto, recomiendo el blog de Henrik Kniberg, muy bueno.
Hola:
Ya he puesto el enlace al original. De todas formas, normalmente enlazo al sitio en el que lo he visto (javahispano en este caso) y no me dedico a seguir el enlace del enlace del enlace hasta llegar al original, porque puede ser un poco largo.
Se bueno.
Pingback: Diario de Programación » Blog Archive » La parte olvidada de las metodologías ágiles