Kanban

Kanban es una palabra japonesa que significa algo así como “tarjetas visuales” (kan significa visual, y ban tarjeta). Esta técnica se creó en Toyota, y se utiliza para controlar el avance del trabajo, en el contexto de una línea de producción. El Kanban está dentro de la estrategia Kaizen (te dejo un post sobre el Kaizen), es decir, la mejora continua y continuada.
Aunque esta técnica la explicamos en el libro de gestión ágil de proyectos, me ha parecido interesante hacer un resumen de la misma en este post.
Todo surgió en una metodología llamada Lean (te dejo un post sobre qué es Lean), creada por Toyota para mejorar su producción usando técnicas just-in-time (JIT).
Kanban no es una técnica específica del desarrollo software, su objetivo es gestionar de manera general como se van completando tareas, pero en los últimos años se ha utilizado en la gestión de proyectos de desarrollo software, a menudo con Scrum (lo que se conoce como Scrumban).
Las principales reglas de Kanban son las tres siguientes: (1) Visualizar el trabajo y las fases del ciclo de producción o flujo de trabajo, (2) determinar el límite de “trabajo en curso” (o Work In Progress) y (3) medir el tiempo en completar una tarea (lo que se conoce como “lead time”). Veámos que significa cada uno de los anteriores.

1- Visualizar el trabajo en Kanban y las fases del ciclo de producción, o flujo de trabajo.

Al igual que Scrum (te recomiendo este post introducción de Scrum), Kanban se basan en el desarrollo incremental, dividiendo el trabajo en partes. Una de las principales aportaciones es que utiliza técnicas visuales para ver la situación de cada tarea, y que quizás habrás visto representado pizarras llenas de post-it.
El trabajo se divide en partes, normalmente cada una de esas partes se escribe en un post-it y se pega en una pizarra. Los post-it suelen tener información variada, si bien, aparte de la descripción, debieran tener la estimación de la duración de la tarea.
La pizarra tiene tantas columnas como estados por los que puede pasar la tarea (ejemplo, en espera de ser desarrollada, en análisis, en diseño, etc.). Abajo dejo una figura con un ejemplo de tablero Kanban.

EJEMPLOKANBAN

Ejemplo de tablero o pizarra Kanban. Las tareas (post-it) van de la A a N. Y el flujo de trabajo tiene 5 fases.

El objetivo de esta visualización es que quede claro el trabajo a realizar, en qué está trabajando cada persona, que todo el mundo tenga algo que hacer y el tener clara la prioridad de las tareas.
Las fases del ciclo de producción o flujo de trabajo se deben decidir según el caso, no hay nada acotado. En la figura se han puesto un conjunto de fases de ejemplo.

2 – Determinar el límite de “trabajo en curso”.

Quizás una de las principales ideas del Kanban es que el trabajo en curso (Work In Progress o WIP) debería estar limitado, es decir, que el número máximo de tareas que se pueden realizar en cada fase debe ser algo conocido.
En Kanban se debe definir cuantas tareas como máximo puede realizarse en cada fase del ciclo de trabajo (ejemplo, como máximo 4 tareas en desarrollo, como máximo 1 en pruebas, etc.), a ese número de tareas se le llama límite del “work in progress”. A esto se añade otra idea tan razonable como que para empezar con una nueva tarea alguna otra tarea previa debe haber finalizado.
En la anterior figura de ejemplo el número límite del “work in progress” se ha colocado entre parentesis debajo del nombre de cada tarea. Podéis, por ejemplo, ver que el límite del “work in progress” para las pruebas es 1.
La idea es: centraté en cerrar tareas y no en comenzar tareas. Por ello limitar el WIP impide empzar cosas hasta que se han cerrado aquellas en las que se está ya trabajando. Lo difícil aquí es encontrar “lead time” cuenta desde que se hace una petición hasta que se hace la entrega.
Aunque la métrica más conocida del Kanban es el “lead time”, normalmente se suele utilizar también
otra métrica importante: el “cycle time”. El “cycle time” mide desde que el trabajo sobre una tarea comienza hasta que termina. Si con el “lead time” se mide lo que ven los clientes, lo que esperan, y con el “cycle time” se mide más el rendimiento del proceso.
Puede haber más métricas, pero las anteriores son las realmente importantes,y necesarias para el control y mejora continua.

Otras fuentes y recursos que te pueden interesar

Uno de los libros más populares, leídos y recomendados es el de Anderson, que fue el libro que llevó Kanban al mundo de la tecnología.
Mi segunda recomendación es, sin lugar a dudas, el libro de Kniberg, me parece el más práctico y conciso de todos. Eso sí, su ámbito son las metodologías ágiles y Kanban.
Una tercera y última recomendación, esta vez en castellano. Un libro que te puede dar una visión general de Kanban, Lean y Jus-in-Time, no exclusiva del ámbito tecnológico, es el libro de Kanban y Just-in-Time, de la asociación japonesa de gestión.

Alguna consideración final sobre Kanban

Una unión muy común es utilizar Scrum y Kanban. Aunque hay diferencias entre ambos métodos, por ejemplo, las reglas de Kanban son muchas menos que las de Scrum, Kanban no define iteraciones (Sprints), Kanban limita explícitamente las tareas que se pueden realizar por fase (con el límite del work in progress), mientras que Scrum lo hace de manera indirecta por medio del sprint planning, etc.
Esta unión Kanban – Scrum (o Scrumban) tiene sus particularidades, pero las dejo para un futuro post.

Otros post relacionados y recomendados

.
.
Si has llegado hasta aquí, y te has leído el artículo… verdaderamente estás interesado en el Kanban; cualquier comentario, difusión y compartir el artículo son de agradecer.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

29 comentarios en “Kanban”

  1. Pingback: Bitacoras.com

  2. Pingback: Resumen de la semana – del 21 al 27 de Noviembre - Javier Garzás

  3. Pingback: Lean Software Development: la estrategia de fabricación japonesa aplicada al desarrollo software agil - Javier Garzás, sobre calidad software y otros temas relacionados

  4. Pingback: Dos sistema de gestión de proyectos basados en Kanban

  5. Pingback: Kanpress: Gestión Kanban para Wordpress | Codigo Geek

  6. Pingback: Kanpress: Gestión Kanban para WordPress | Jobbr es

  7. Pingback: Scrum para Dummies (2/2). Las ideas de Scrum en 2 post de 5 min. - Javier Garzás, sobre calidad software y otros temas relacionados

  8. Pingback: Pros y contras de usar una herramienta Kanban - Javier Garzás, sobre calidad software y otros temas relacionados

  9. Hola Javier,
    Estaba buscando información en tu blog sobre la metodología Scrumban y justo en este artículo que dejabas la información para un futuro post, pero creo que de momento no está redactado.
    ¿Podrías explicar por favor en qué consiste y cuál es son las principales ventajas o inconvenientes de usarlo, con respecto a Scrum o Kanban por separado?
    Un saludo y muchas gracias,
    Alberto Blázquez

  10. Pingback: ¿Cómo se producen nuestros juegos? | Wake Studios Devzone!

  11. Hola,
    Es resumidamente la unión de Scrum y Kanban. Scrum limita tareas indirectamente por slot de tiempo (semanas de sprint) y kanban por fases del ciclo de trabajo (el wip). La unión de ambos, siendo breve, es Scrumban.
    Saludos

  12. Pingback: El Metodo Kanban « Control de inventarios

  13. Eduardo Contreras

    Es realmente necesario tener conocimiento de estas metodologias y no tan solo eso, si no mas bien llevarlas a la practica y dejar de lado la vieja escuela en el desarrollo de software. Agredecido y comparto con la opción de algunos arriba, existe poca info en español, gracias!

    1. Estoy totalmente de acuerdo con Luis. Por otra parte, creo que es muy importante analizar los resultados luego de implementar Kanban. Debemos buscar el mejor método para nosotros, no para todos. En cuanto a herramientas para Kanban, le recomiendo que Kanban Tool

  14. La búsqueda del método ideal para llevar a cabo nuestros proyecto dependerá en gran media de la información disponible y, en algunos caso de la documentación requerida. Este articulo me ha ayudado mucho para aclarar algunos puntos, tales como el determinar el limite del trabajo en curso. A propósito de esto, comparto un post relacionado, si me lo permiten http://www.uv-mdap.com/blog/cuales-son-las-reglas-del-kanban-algunos-tips-y-reflexiones/ creo que servirá de complemento a lo aqui expuesto.

  15. Daría Maestas Orozco

    Estoy de acuerdo con Miriam. Es verdad que las páginas españolas escasean en el tema del método Kanban. Tu artículo explica bien en qué consiste este sistema. Por cierto, has escuchado sobre la herramienta Kanban Tool? http://kanbantool.com/es/tablero-kanban Es una buena manera que te permite organizar mejor tus proyectos y tiempo en el trabajo. Yo misma lo he implementado en mi empresa y ahora el negocio va sobre ruedas! Te recomiendo echar un vistazo en esta herramienta.

  16. Hola:
    Gracias por la información del blog. Solo quiero comentar que el enlace a «el mejor WIP de un KANBAN.» no funciona.
    Un saludo,
    José Luis

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *