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.).

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 paréntesis 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 el mejor WIP de un KANBAN.

3 – Medir el tiempo en completar una tarea.

El tiempo que se tarda en terminar cada tarea se debe medir, a ese tiempo se le llama “lead time”. El “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

• Una lista de herramientas Kanban (gratis y de pago)
• Como lograr el mejor WIP de un KANBAN
• Pros y contras de usar una herramienta Kanban
  

.
.
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.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
• Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
• Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024