Un marco agile de gestión de proyectos, gestión de productos, equipos y sistemas y de visualización de flujos de trabajo. La forma habitual y más sencilla de aplicar Kanban es por medio de un tablero kanban.

Descripción

El marco Kanban es un método de gestión de flujo de trabajo que ayuda a las organizaciones a visualizar el trabajo, maximizar la eficiencia y mejorar continuamente los sistemas de trabajo, especialmente en el ámbito del conocimiento y el desarrollo de software.

La historia del término kanban es centenaria. Se originó a partir de dos palabras japonesas: kan (letrero) y ban (tablero)

Este marco de trabajo se basa en el uso de un tablero visual, físico o digital, para representar el flujo de trabajo.

Características y funcionamiento

El núcleo de Kanban es el tablero Kanban, donde las tareas se representan como tarjetas visuales y se mueven a través de columnas que simbolizan las diferentes etapas del proceso de trabajo. Un tablero básico tiene al menos tres columnas: to do (pendiente o solicitado), Doing (en curso) y Done (terminado).

Kanban se rige por una serie de principios claves:

  • Visualizar el flujo de trabajo: Hacer visible cada paso del proceso, de principio a fin, en el tablero.
  • Limitar el trabajo en curso (WIPWork In Progress): Establecer un límite a la cantidad de tareas que pueden estar «En curso» al mismo tiempo. Esto es crucial, ya que evita la sobrecarga del equipo, los cuellos de botella y asegura que las tareas se completen antes de comenzar otras nuevas.
  • Medir y gestionar el flujo: Controlar y optimizar el movimiento de las tareas a través del sistema.
  • Hacer las políticas explícitas: Definir y comunicar claramente las reglas del proceso (por ejemplo, cuándo una tarea puede pasar de una columna a la siguiente).
  • Fomentar la mejora continua: Promover el cambio evolutivo y gradual, utilizando métricas y bucles de retroalimentación para mejorar el proceso de forma constante.

A diferencia de otros marcos ágiles, Kanban no requiere roles predefinidos ni períodos de tiempo fijos (como los sprints); es un sistema de arrastre (pull system), lo que significa que el equipo sólo comienza una nueva tarea cuando tiene capacidad, es decir, cuando una tarea anterior ha sido completada y ha dejado espacio libre según el límite de WIP.

Historia

El marco Kanban tiene sus raíces en la producción manufacturera japonesa, específicamente en Toyota durante la década de 1950, en el período de posguerra.

  1. Inspiración en supermercados: El ingeniero industrial de Toyota Taiichi Ohno buscaba mejorar la eficiencia de la producción para competir con la industria automotriz estadounidense. Se inspiró en el funcionamiento de los supermercados de EE. UU., donde los estantes solo se reponían cuando se vendía un producto, garantizando así el inventario justo y necesario.
  2. Sistema justo a tiempo: Ohno aplicó este concepto a la línea de ensamblaje de Toyota, desarrollando el sistema de producción just in time (JIT). Este sistema buscaba producir sólo lo necesario, cuando es necesario y en la cantidad necesaria, eliminando el desperdicio (muda en japonés) asociado con el exceso de inventario y la sobreproducción.
  3. El nacimiento de las tarjetas: Para implementar el JIT se crearon las tarjetas (Kanban) como señales visuales. Cuando una pieza se agotaba en la línea de producción, se enviaba una tarjeta al proceso anterior o al proveedor, indicando que era el momento de producir o suministrar exactamente la cantidad necesaria.
  4. Expansión al trabajo del conocimiento: Más adelante, el concepto de Kanban se adaptó para la gestión del trabajo del conocimiento, como el desarrollo de software. David J. Anderson es reconocido por haber definido en 2007 el método Kanban moderno, aplicando los principios JIT de Toyota a la gestión de proyectos y servicios, con énfasis en la visualización, la limitación del WIP y la mejora continua en procesos ágiles.

Métricas de flujo

Las métricas de Kanban se centran en el flujo y no en la productividad por individuo. El objetivo es reducir el tiempo de ciclo para aumentar la capacidad de respuesta y la previsibilidad.

Tiempo de ciclo (cycle time)

El tiempo de ciclo es la métrica más importante en Kanban, ya que mide la eficiencia del proceso de trabajo una vez que una tarea ha sido iniciada.

  • ¿Qué mide?: El tiempo que transcurre desde el momento en que un equipo comienza a trabajar activamente en una tarea (pasa a «En curso» o «En desarrollo») hasta que esa tarea está completada (llega a «Hecho» o «Listo para implementar»).
  • Fórmula conceptual:
  • Importancia: Un tiempo de ciclo bajo y predecible es el objetivo principal. Significa que el equipo puede entregar valor al cliente de manera rápida y constante. Si el tiempo de ciclo aumenta, indica un problema en el flujo (por ejemplo, cuellos de botella en la revisión de código o en las pruebas).

Tiempo de espera (lead time)

El tiempo de espera proporciona una visión más amplia, desde la perspectiva del cliente o del sistema completo.

  • ¿Qué Mide?: El tiempo total que transcurre desde el momento en que una tarea es solicitada por primera vez(entra al backlog) hasta que se completa y se entrega al cliente.
  • Fórmula conceptual:
  • Importancia: Esta métrica indica el tiempo de respuesta general del sistema. Si tenemos un lead time alto, pero un cycle time bajo, significa que las tareas pasan mucho tiempo esperando en el backlog o en la columna de «Listo para desarrollo» antes de que el equipo pueda tomarlas.

Gráfico de flujo acumulativo (CFD)

Para visualizar estas métricas y la salud del flujo de trabajo, los equipos Kanban suelen utilizar el diagrama de flujo acumulativo.

Sus componentes son:

  • Eje X: Representa el tiempo (días, semanas).
  • Eje Y: Representa el número de tareas.
  • Las bandas: Cada banda de color representa una etapa del flujo de trabajo (una columna del tablero).

Interpretación

  • Tiempo de ciclo: Se puede estimar midiendo la distancia horizontal entre la línea superior (Terminado) y la línea inferior de la etapa de (En desarrollo).
  • Salud del flujo: Si el ancho de las bandas intermedias (trabajo en curso) se mantiene constante y la línea superior sube de manera uniforme, el flujo es predecible y saludable. Si una banda se ensancha (por ejemplo, «En revisión»), indica un cuello de botella.

Ejemplos

En este ejemplo, el flujo de trabajo es más detallado que el básico, reflejando las etapas comunes por las que pasa una característica de software, desde la idea hasta la implementación.

Fase Límite WIP (Máx. tareas) Descripción de la fase
Backlog Sin límite Todas las ideas, errores (bugs) y características nuevas que podrían desarrollarse. No es parte del flujo de trabajo activo de Kanban.
1. Por priorizar 5 Tareas que el equipo de producto está revisando y especificando (requisitos, diseño UX/UI).
2. Listo para desarrollo 3 Tareas que han sido completamente especificadas y están listas para ser tomadas por un desarrollador. El desarrollador «hala» una tarea de aquí solo si libera espacio en «En desarrollo».
3. En desarrollo 4 Tareas en las que el desarrollador está escribiendo código activamente.
4. En revisión (Code review) 2 Tareas donde el código está completado y está esperando ser revisado por otro desarrollador (para garantizar la calidad). Un límite bajo obliga a priorizar las revisiones.
5. En pruebas (QA) 3 Tareas que están siendo probadas por el equipo de control de calidad (QA) para verificar que cumplen con los requisitos.
6. Listo para implementar Sin límite Tareas que han pasado las pruebas y están pendientes de su despliegue (liberación) en el entorno de producción.
7. Hecho / Completado Sin límite Las tareas han sido desplegadas y entregadas al usuario final.

Componentes y funcionamiento

Las tarjetas (tareas)

Cada tarjeta representa una tarea específica (ej., «Implementar la función de restablecimiento de contraseña», «Corregir error de cálculo en la factura»). Las tarjetas contienen:

  • Descripción: Detalle de lo que se debe hacer.
  • Asignado: Nombre del responsable.
  • Prioridad: A veces indicado por el color de la tarjeta.

Los límites WIP

Los límites bajos en algunas columnas (2. Listo para Desarrollo: 3 y 4. En Revisión: 2) tienen los siguientes objetivos:

  • Evitar la sobrecarga: Si hay 5 tareas esperando en «En Desarrollo» y el límite es 4, nadie puede empezar una nueva tarea de «Listo para Desarrollo». Esto obliga al equipo a centrarse en terminar lo que ya ha comenzado.
  • Identificar cuellos de botella: Si la columna «En revisión (Code review)» (WIP de 2) se llena constantemente es una señal de que la revisión del código es un cuello de botella. El equipo debe trabajar en cómo acelerar o priorizar las revisiones, antes de introducir más trabajo al flujo.

El sistema de arrastre (pull system)

El trabajo fluye a través de un sistema de «arrastre» o pull:

  • Un desarrollador termina una tarea y la mueve a «En revisión». Esto libera un espacio en la columna «En desarrollo».
  • Una vez liberado ese espacio, el desarrollador arrastra (o toma) la siguiente tarea de mayor prioridad de «Listo para desarrollo».

De esta manera, el trabajo se mueve sólo cuando el equipo tiene la capacidad real para procesarlo, optimizando el flujo de principio a fin.

Recursos adicionales