Un kanban (en kanji 看板 donde kan (看) significa "visual", y ban (板) significa "tarjeta" o "tablero") es un concepto de producción justo-a-tiempo.
El kanban es una tarjeta física que se utiliza en el Sistema de Producción de Toyota (TPS - Toyota Production System) para soportar un control productivo descentralizado por demanda. Actualmente en el desarrollo ágil de software se visualizan los proyectos mediante la publicación de tarjetas con tareas en una pared, lo cual se conoce como "software kanban" o "tareas kanban".
Pero exactamente, ¿qué es kanban? ¿Cómo se puede utilizar en el contexto del desarrollo de software?.
¿Qué es Kanban?
Un kanban es un dispositivo de señalización inventando y desarrollado por Toyota, que instruye la creación o movimiento de partes en un sistema de producción por demanda, generalmente mediante el uso de una tarjeta física. Antes de entrar en el uso de Kanban para el desarrollo de software vamos a ver el uso original de Kanban en TPS (Toyota Production System).
El objetivo de Kanban es minimizar el TEP (Trabajo En Progreso), o stock, entre los procesos. Para lograr esto Kanban se asegura que el proceso superior produzca partes sólo si el proceso inferior las necesita. "Por demada" significa que los trabajadores del proceso inferior consumen las partes que necesitan de los procesos superiores.
La figura muestra un modelo abstracto de un sistema Kanban. Se ven dos procesos, uno superior y otro inferior, donde el proceso superior provee de partes (items) al inferior. Para entregar productos al consumidor final, el proceso necesita producir partes y hacerlas circular hacia los procesos inferiores, pero no demasiadas, ya que la sobreproducción se considera el peor de los gastos. Por lo tanto, para prevenir la sobreproducción, el proceso superior no "empuja" partes terminadas al inferior, sino que es el proceso inferior el cual activamente demanda (busca) partes del proceso superior. El lugar donde se guardan las partes se conoce como "almacen" (o "supermercado", de donde originalmente se tomó la idea, al ver que son los mismos clientes quienes toman los productos que necesitan, y no el administrador del local). El almacen está en el proceso superior y funciona como un "buffer" o "cola" para el TEP. Cuando un trabajador del proceso inferior, llamado "manejador de materiales", va al almacen y recoge nuevas partes terminadas, también retorna una señal a producción - por ejemplo, el proceso inferior retira cosas del superior y al mismo tiempo empuja información al proceso superior via tarjetas Kanban. Esto es necesario ya que el proceso superior nunca produce partes sin recibir instrucciones del proceso inferior.
Por lo tanto, en la figura hay dos tipos de Kanban trabajando juntos:
- Kanban de Retiro: es un item en la lista de compras que el empleado lleva al almacen.
- Kanban de Producción: instruye al proceso superior a producir partes para los procesos inferiores.
Como se ve en la figura, los Kanban de Retiro circulan entre los procesos, mientras que los Kanbans de Producción circulan dentro del proceso, y se intercambian en el almacen. Detallemos entonces un poco más la mecánica de este procedimiento.
La siguiente figura muestra como funciona el "intercambio de Kanbans" en el almacen.
- A un empleado del proceso inferior le llega una señal para retirar partes. Esta señal está definida por el proceso inferior y alguna de las siguientes eventos:
a) señalizado por la cantidad de Kanbas de Retiro recolectadas.
b) señalizado por un período de intervalos de tiempo.
El empleado visita entonces el almacen del proceso superior con pallets vacios y su Kanban de Retiro como una lista de compras, la cual indica qué se necesita del proceso superior, y en qué cantidad. - Las partes terminadas por el proceso superior se empacan en pallets y se ubican en el almacen con los Kanban de producción adjuntados (esto ocurre independientemente del paso 1).
- El empleado recoge las partes indicadas en su Kanban de Retiro (la lista de compras), comprueba si concuerda con el Kanban de Producción que está adjuntado con las partes, e intercambia los dos Kanban.
- Ubica el Kanban de Producción en el "Tablero de Producción", el cual más tarde disparará la producción de partes en el proceso superior cuando los Kanban acumulados alcancen cierto límite.
- El empleado se lleva las partes, con el Kanban de Retiro adjuntado, del almacen al proceso inferior.
El almacen es una cola entre los dos procesos, trabajando en en forma independiente, intercambiando cosas e información a través de los Kanban. En la superficie de las tarjetas de Kanban se escribe información (como ser el número/nombre de la parte, cantidad, tipo de pallet, dirección del almacen, etc.), de forma que el manipulador de materiales que toma la tarjeta sepa qué hacer.
Existe una disciplina estricta para llevar adelante Kanban, llamada "las seis reglas de Kanban":
- Los procesos Cliente (inferiores) retiran elementos en la cantidad exacta que indica el Kanban.
- Los procesos proveedores (superiores) producen items en la secuencia y cantidad exacta que indica el Kanban.
- No se mueven o crean items sin un Kanban.
- Un Kanban tiene que acompañar a cada item, siempre.
- Los defectos y cantidades incorrectas nunca se envian al siguiente proceso inferior.
- La cantidad de Kanbans se reduce cuidadosamente para disminuir el stock y revelar problemas.
Como hemos visto, el almacen trabaja como una cola de items, los pallets funcionan como transportadores de partes, y las tarjetas Kanban hacen las veces de "lista de compras". Se convierte en un sistema por demanda, creando un balance entre sostener un "flujo continuo" (eliminando las esperas) y minimizando el TEP (eliminando los desperdicios por sobreproducción). Este mencanismo de gestionar la cantidad "exacta" de TEP en el flujo entre el retiro y reposición de items es exactamente lo que ocurre en un supermercado, y hacerlo de forma correcta es clave para mantener las ganancias del almacen.
Hasta aquí vimos como Kanban funciona en un proceso productivo de manufacturación. Hay que tener en cuenta que lo contado hasta ahora es un modelo simplificado de Kanban. Por ejemplo, el Kanban muestra visualmente el flujo de información e items a todos los trabajadores, y estimula el Kaizen (mejora de los procesos) y el Gemba (lugar de trabajo). El Kaizen comienza al poder observar lo que ocurre en el Gemba. A través del Kanban. todos los trabajadores (y no sólo los directivos) pueden ver el flujo y pueden así detectar desperdicios, y sugerir mejoras al proceso en el cual participan.
Propiedades de Kanban
De todo lo expuesto, a continuación una lista de las propiedades y efectos del concepto de Kanban original en TPS:
- Físico: es una tarjeta física. Puede tenerse en la mano, moverse, y ubicarse en algún lugar.
- Limita el TEP: limita el TEP (Trabajo En Proceso); por ejemplo, previene la sobreproducción.
- Flujo continuo: notifica la necesidad de producción antes de que el almacen se quede sin stock.
- Auto-dirigido: contiene toda la información de qué hacer y hace que la producción sea autónoma de una manera descentralizada, y sin micro-administración.
- Visual: se apila o pega para mostrar el estado actual y progreso, visualmente.
- Señal: su estado visual señaliza las próximas acciones de Retiro o Producción.
- Kaizen: el flujo del proceso visual muestra y estimula el Kaizen.
- Adjunto: se adjunta y se mueve con las partes físicas provistas.
El objetivo es minimizar el TEP y a la vez mantener un flujo continuo y sustentable. Si el TEP del almacen es muy bajo, el proceso inferior tiene que esperar a los items a que esten terminados, pero al mismo tiempo el TEP tiene que ser minimizado para prevenir sobreproducción. Por lo cual, ambos objetivos entran en conflicto, y el Kanban se convierte en una estrategia para resolver el dilema.
Un Kanban está físicamente adjunto a las partes, se recolecta y reutiliza, por lo tanto la cantidad de Kanbans es fija. También señaliza visualmente al proceso inferior a buscar partes sólo cuando es necesario. Estos dos mecanismos limitan el TEP.
El primer mecanismo, "Kanban físicamente adjunto", trabaja como la ley de conservación de la energía. Una vez que queda definido la cantidad de Kanbans (basado en la cantidad de ventas del producto en el mercado, y la variación intrínseca del propio proceso), el TEP queda limitado en proporción al número de Kanbans, sin importar el flujo entrante o saliente de las partes. El número máximo de Kanbans (la "energía" del sistema) es fija y conserva físicamente el límite superior del TEP en cualquier momento.
El segundo mecanismo, "la demanda", también limita el TEP al hacer que la velocidad del proceso superior dependa de la velocidad de consumo del proceso inferior. El primer mecanismo sólo se refiere a la cantidad de TEP, mientras que este segundo mecanismo se refiere al flujo, su dirección y velocidad.
- Dirección: el motivador de la producción sólo es dado por el proceso inferior.
- Velocidad: el Kanban comunica el momento y la cantidad de la próxima producción.
- Demanda: la demanda limita el TEP al hacer que la producción del proceso superior sea dependiente de los consumos del proceso inferior. Esta dependencia se logra cuando se intercambian los kanban en el almacen, empujando la información de control de producción desde el proceso inferior al superior.
El Kanban también es auto-dirigido y promueve el Kaizen. Al ver las tarjetas de Kanban publicadas en los tableros, todos pueden comprender lo que está ocurriendo y que tan bien funciona el proceso. El Kaizen comienza al poder observar el flujo de trabajo en el Gemba. Y las tarjetas físicas de Kanban en los tableros hacen que el trabajo se haga auto-dirigido sin un control centralizado. Este proceso autónomo provee datos de su performance para soportar el Kaizen, y cambia el centro de atención para la gestión: se deja de asignar y seguir tareas detalladas y se centraliza en actividades de Kaizen.
El objetivo final del Kanban puede ser resumido en "limitar el TEP", "flujo continuo" y "Kaizen". Un sistema Kanban limita el TEP y a la vez mantiene un flujo continuo y sustentable. Amortigua el impacto de la variaciones por causas comunes, y expone las variaciones especiales, que son candidatos para el Kaizen.
Kanban en el desarrollo de software
Veamos un poco nuestra propia área de trabajo: el desarrollo de software. En los desarrollos ágiles, es una práctica ccomun el visualizar y compartir el estado de un proyecto mediante tarjetas pegadas en la pared o en un tablero. En particular, estas tarjetas de tareas pegadas en la pared que muetran el estado actual se las llama "Tarea Kanban" o "Software Kanban".
En el tablero, las tareas técnicas se representan con tarjetas (notas adhesivas, tipo Post-It), y el estado de cada tarea se muestra al pegar la misma en distintas áreas del tablero: "Pendiente", "En trabajo" y "Terminada". Pero aquí no se visualiza ningún "proceso" (superior o inferior), y en cambio aparece el concepto nuevo de "iteración". Por cada iteración, se identifican nuevas tareas al descomponer historias de usuario, y estas tareas se pegan en el área de "Pendiente".
¿Es esto un sistema por demanda? En un proceso productivo, las partes se movilizan desde un proceso superior hacia los procesos inferiores. En el desarrollo ágil no se visualiza este "movimiento" o movilización de elemetos. Una tarjeta Kanban es la contrapartida de una tarea, las cuales tienen escritas información como la identificación de la tarea, su nombre, tiempo estimado, quién está asignado a la tarea, etc. La tarea tiene un estado ("Pendiente", "En trabajo", "Terminada"), y es compartida por todo el equipo. El enfoque del desarrollo ágil promueve el trabajo en equipo, y tiende a reducir la burocracia dentro del equipo. A esto se lo llama Kanban Ágil.
Por otro lado, se puede utilizar un sistema de Kanban en un desarrollo en cascada tradicional pero con un flujo. El proyecto puede separar y serializar varios procesos, como "diseño", "desarrollo", "validación", etc, y las tarjetas Kanban se mueven entre estos procesos. Cada tarjeta representa un requerimiento para el sistema, y se va moviendo hacia los procesos inferiores. Nótese que esto no es una cascada clásica, donde todos los requerimientos se "diseñan" a la vez, se "desarrollan", se "validan", etc, moviendo todas las tarjetas a la vez en un único grupo. En cambio, las tarjetas van avanzando una a una. Lo que ocurre es una fase estable y sustentable en el ciclo de vida del producto, gestionado con un modelo de transición estilo cascada, con flujo. Aquí se puede ver claramente el "flujo de trabajo", diferente al concepto de "iteración" en ágil, que se parece mucho más a una fábrica con Kanban que el Kanban Ágil. Además, se puede convertir en un sistema por demanda al crear una regla que sólo le permita a los procesos inferiores el mover tarjetas. Esto se llama Kanban Sustentable.
Kanban en el proceso completo de desarrollo
Otro ejemplo seria el uso de Kanban durante el proceso completo de creación de software, como se muestra a continuación.
Supongamos que existe un equipo de clientes, un dueño del producto, un equipo de desarrollo y un equipo de QA, en todo un flujo para el desarrollo de un producto, y que trabajan juntos pasándose entregables utilizando colas, de manera que cada equipo puede trabajar asincrónicamente, manteniendo la velocidad de trabajo dependiente de los demás. Cada espacio de "Terminado" es, de hecho, la cola de trabajo similar al "almacen" en un proceso productivo en las fábricas, y es muy parecido al sistema de Kanban de TPS. Además, se parece mucho a utilizar Kanban Ágil sincrónicamente dentro de cada proceso, y usar Kanban Sustentable asincrónicamente a través de todo el proceso. El sistema de kanban puede escalar para cubrir todo el flujo de trabajo, de forma de poder visualizar todo el valor del proceso.
En este ejemplo, el TEP puede limitarse al definir el tamaño de cada área o cola. Para hacer que sea un sistema por demanda, se necesita un mecanismo que permita al proceso inferior señalizar al superior para que comience a trabajar. Así, una opción es crear una regla que sólo le permita al proceso inferior mover tarjetas de "Terminado". También se pueden tener "reuniones de iteración" de forma periódica, que sincronicen a los equipos y a la comunicación de información entre ellos. Estas dos opciones de comunicaciones pueden corresponderse a las dos señales de Retiro de partes discutidas anteriormente: un Kanban de señalización de la cantidad de retiros, y un intervalo periódico de tiempo. Aquí, un grupo de historias de usuario para una iteración se corresponde con las partes retiradas de los pallets para la iteración, y la cantidad de partes (Kanban) se corresponde a la velocidad del proyecto.
Entonces, hay varias formas de aplicar los conceptos de Kanban al desarrollo de software. El Kanban Ágil funciona dentro del equipo para compartir información y hacer que el trabajo sea auto-dirigido, pero no soporta flujos. Kanban Sustentable es otro tipo que permite a porciones pequeñas de trabajo circular entre distintos estados. La combinación es Kanban Sustentable + Ágil, la cual utiliza Kanban Sustentable a través de todos los procesos, y Kanban Ágil dentro de cada sub-proceso.
Es importante destacar que el Kanban Ágil, que hoy en día se ve en los proyectos ágiles, sólo se focaliza en un equipo dentro de todo el proceso. Como se ve, podemos expandir el concepto de Kanban Ágil para abarcar a todos los equipos y procesos involucrados en la creación de un producto de software.
Hacer fluir el valor
Cuando se comienza a utilizar Kanban, ¿qué debería representar cada una de las tarjetas de Kanban?
En un sistema de Kanban Ágil, una tarjeta es una "tarea" que surgió de una "historia de usuario". En un equipo de desarrollo, el Kanban funciona como una unidad de trabajo porque todos en el equipo comprenden lo que significa. Pero en sistemas de Kanban que funcionan a través de múltiples procesos (o equipos), lo que fluye debería ser algo con valor reconocible para el cliente. En este caso, un Kanban se corresponde no al "trabajo", sino a una "característica", de forma que todos los involucrados en el proceso, incluso el cliente, pueden comprender el significado y el valor de lo que fluye.
Las "Historias de Usuario", "Items del backlog" o "Casos de Uso" se los llama de forma abstracta como CMV (Características Mínimas Vendibles), de forma que muestran explíticamente que el flujo contiene valor para el cliente. El desarrollo ágil puede explicarse como "hacer que las CMV fluyan lo más rápido posible a través de todo el proceso".
En el ejemplo de Kanban Ágil se descompone el trabajo, y funciona bien dentro del equipo. En el ejemplo de Kanban Sustentable se descomponen las características, y cada tarjeta representa un CMV. Y en el ejemplo de Kanban Sustentable + Ágil se ve una combinación de descomposición de características en los niveles superiores, y una descomposición de trabajo en los niveles inferiores.
Una vez que el flujo queda establecido, los cinco conceptos del "Pensamiento Ágil" pueden aplicarse directamente a todo el proceso. La gestión del proceso sigue los siguientes principios:
- Especificar el valor desde la perspectiva del cliente - Especificar y ordenar las CMV.
- Indetificar el flujo de valor y eliminar los desperdicios - Encontrar los bloqueos (tareas bloqueantes).
- Hacer que fluya el valor por la demanda del cliente - Hacer una "regla de demanda" de Kanban.
- Involucrar y participar a los empleados - Participar al equipo en el Gemba.
- Mejorar continuamente en búsqueda de la perfección - Reflexión y Kaizen.
Conclusión
Se utilizan los sistemas Kanban para lograr dos objetivos:
- mejor control del proceso - mantienen un flujo continuo y limitan el TEP.
- mejor proceso de mejoras - el flujo es visible y se estimula el Kaizen.
El Kanban Ágil se focaliza en el #2, mientras que el Kanban Sustentable se focaliza en el #1. Se pueden combinar ambos enfoques, extendiendo el Kanban Ágil e integrándolo a un Kanban Sustentable.
Por último, los dos pilares de todo el proceso son el Kaizen y las Personas. Toyota produce casi 10 millones de automóviles por año y, al mismo tiempo, mejorar su proceso con cerca de 1 millón de propuestas en el Gemba (el lugar de trabajo). El poder visualizar el trabajo del equipo es siempre el punto inicial para el Kaizen.
Leer más
- Traducido de Kanban applied to software development: from agile to lean.
- Lean software engineering: scrum-ban
