Qué es el método Kanban y por qué funciona en la programación de software
¿Qué tiene que ver un ingeniero industrial japonés del siglo pasado con las tendencias en el desarrollo de software? Mucho más de lo que parece. Taiichi Ohno (1912-1990) está considerado uno de los principales teóricos de la organización industrial eficiente, pero además de la teoría conocía muy bien la práctica por su experiencia en las fábricas de Toyota.
Sus ideas sobre la producción industrial, plasmados en el libro ‘Toyota Production System: Beyond Large-Scale Production’ de 1988, fueron claves en el crecimiento de la empresa japonesa hasta convertirse en uno de los fabricantes de automóviles más solventes, respetados y rentables del mundo.
Un sistema sencillo
En contra de lo que se pudiera pensar, el sistema Kanban ideado por Ohno es relativamente sencillo. Solo su nombre, en japonés, ya explica mucho. “Kan” significa visible o visual, y “ban”, tarjeta o tablón. Ya sabemos que los tablones son básicos en las fábricas de Ohno, pero evidentemente el sistema es más complejo, y vamos a intentar explicarlo con un ejemplo.
Imaginemos una fábrica de bicicletas y que somos los encargados de las pastillas de freno. Contamos junto a nuestro puesto de trabajo con un stock de diez piezas que vamos ensamblando, y cuando nos queda la mitad, utilizamos un tablón para avisar de que vamos a necesitar otras diez pastillas de freno. Estas llegarán cuando nos quedemos sin las cinco que teníamos cuando colocamos el aviso.
La gestión del inventario es justo la adecuada: nunca hay piezas ocupando espacio necesario para otras tareas y nunca se frena la producción por falta de material. El sistema se ajusta al menor o mayor número de pedidos entrantes. La clave del éxito del método es su capacidad de adaptación a un volumen de trabajo cambiante.
Las columnas, parte fundamental del método
Si tomamos como referencia el conjunto de una fábrica, o también cualquier otro tipo de organización, como por ejemplo un equipo de desarrollo, el sistema Kanban se organiza con un gran tablón dividido en columnas, normalmente siete:
- Objetivos: se marcan a largo plazo, con la idea de que todos los miembros del equipo los tengan en mente. Es una columna opcional, no siempre está presente.
- Pendiente: esta columna engloba las tareas pendientes que se pueden afrontar de forma inmediata. En el lugar más alto de esa columna colocaremos la tarea pendiente que tiene la máxima prioridad, y en cuanto empecemos, la pasaremos a las siguientes columnas.
- Preparación: también es opcional. Aquí incluimos aquellas tareas que necesitan cierta discusión interna antes de ser afrontadas. Cuando lo tengamos claro, pasamos a la siguiente columna.
- Desarrollo: en este espacio situamos la tarea hasta que la terminemos. Si algo falla, regresa a la columna anterior.
- Prueba: comprobamos que todo funciona bien. En función de ese examen, la tarea avanza en el tablón o retrocede.
- Aplicación: la existencia de esta columna depende de las características de cada tarea. Hablamos, por ejemplo, de tareas como colocar una nueva versión de una aplicación en un servidor.
- Hecho: cuando ya no tenemos que preocuparnos más de algo porque hemos terminado la tarea.
Este no es un sistema cerrado que no se deba modificar si queremos tener la certeza de que va a funcionar. Por ejemplo, los trabajos con prioridad pueden aparecer en lo alto de cualquier columna, y aunque no fuesen parte de la planificación, hay que ponerse manos a la obra inmediatamente. Incluso se puede crear una fila específica -horizontal, por encima de todas las columnas- de ‘urgente’. Eso sí, ahí solo puede estar una tarea, que irá recorriendo, en su propio carril especial superior, todas las columnas.
Otra forma de mejorar el procedimiento de gestión es establecer un número máximo de tareas para cada una de las columnas, en función del equipo de profesionales que tengamos. Por ejemplo, si hablamos de software y tenemos ocho programadores, sería absurdo tener diez tareas en ‘desarrollo’. Algunas tendrán que esperar en ‘pendiente’.
Kanban y el software, ¿mejor o peor que Scrum?
Desde que en 2004 Kanban fuese utilizado en un proyecto de IT de Microsoft, se ha ido creando toda una teoría sobre su uso en la producción informática. Es frecuente el debate que contrapone Kanban al método Scrum. ¿Cuáles son sus grandes diferencias?
Básicamente, Scrum pone más acento en la rapidez de los procesos y en el control por parte del gestor del equipo. Pero ese control exige tiempo en reuniones, discusiones y verificaciones internas. Con Kanban la labor del gestor es básicamente determinar las tareas que hay que hacer y cambiar su prioridad en función de los acontecimientos. Toda la cadena de trabajo está a la vista de todos, y si hay atascos queda claro dónde se producen: los mismos principios organizativos que hicieron mejorar la producción de coches siguen siendo muy útiles en la era de la economía digital.