El sistema Kanban comenzó su viaje en la década de 1950 en las líneas de producción de Toyota, después de lo cual se trasladó a las oficinas y se convirtió en una herramienta importante para los gerentes de proyectos.
La flexibilidad ilimitada de la práctica y su capacidad para autoorganizar al personal permitieron una eficiencia donde otros enfoques no funcionaron. Este es el caso en el que la tarjeta de presentación del sistema se convirtió en la tarjeta misma — se ha establecido como una moneda interna en las organizaciones que han implementado Kanban.
Origen
Como el concepto de manufactura Lean, el sistema Kanban fue desarrollado por gerentes de Toyota. El autor del sistema, el ingeniero japonés Taiichi Ohno, se inspiró en los principios operativos de los supermercados estadounidenses, donde los clientes seleccionaban ellos mismos los productos que necesitaban. El rol de “supermercado” en Toyota fue desempeñado por el almacén.Allí, las tarjetas de señalización — que es lo que “kanban” se traduce literalmente del japonés — eran intercambiadas entre los trabajadores, quienes regulaban manualmente el proceso de producción.Las tarjetas se adjuntaban a las cajas con piezas. Dichas etiquetas indicaban información sobre el número de parte y la cantidad, qué departamento las estaba enviando y dónde debían llegar.
El trabajador directamente involucrado en el ensamblaje de máquinas (“aguas abajo”) tomaba piezas de la caja à la que estaba adjunta la “kanban” que solicitaba reabastecimiento. La tarjeta se retiraba y pasaba junto con la caja vacía al transportista hacia el almacén. Allí, otro trabajador preparaba una nueva caja con piezas de repuesto, à la que se adjuntaba la “kanban” de producción — una etiqueta con información sobre las piezas de repuesto producidas.
La “kanban” de producción se reemplazaba con una “kanban” solicitando reabastecimiento y se enviaba à la línea de producción de piezas de repuesto — “aguas arriba”. Así, exactamente la cantidad de piezas especificadas en la tarjeta se producía. La caja con nuevas piezas de repuesto era colocada por los transportistas en la línea de ensamblaje.
Principios de Kanban
Los gerentes de Toyota articulaban 6 reglas formadoras del sistema:
- Los trabajadores de “aguas abajo” retiran exactamente tantas piezas del inventario como se especifica en la kanban
- Los trabajadores de “aguas arriba” también suministran piezas estrictamente de acuerdo con las tarjetas
- No se produce ni se mueve nada sin una kanban
- La kanban debe estar siempre adjunta a las piezas
- Las piezas defectuosas no se utilizan en el sistema
- Reducir el número de tarjetas kanban hace que la gestión sea más sensible a los cambios. Pero sin una necesidad extrema, no es recomendable cambiar el número establecido de tarjetas.
Kanban es un sistema de “jala”. Crea un equilibrio entre un flujo constante, que elimina los costos de espera, y una cantidad mínima de trabajo en progreso (WIP), que reduce los riesgos de sobreproducción. El WIP se regula utilizando tarjetas: su número es fijo, y las instrucciones en ellas guían a los trabajadores “aguas abajo”.
El límite de WIP consiste en proporción al número de tarjetas kanban, que se calcula en función de los niveles de ventas y la variabilidad estadística en los procesos actuales. El número máximo de etiquetas — la “energía” en el sistema — asegura el nivel superior de WIP en un momento dado. El WIP también está limitado por el principio de jala: la velocidad de producción de aguas arriba depende de la velocidad de trabajo de aguas abajo.
El gráfico muestra que uno de los elementos básicos del sistema es la cultura Kaizen. Los procesos autónomos y la variabilidad estándar liberan la gestión de la supervisión constante, permitiéndole centrarse en mejorar el rendimiento de los empleados.
Aplicación de Kanban en TI
El sistema Kanban, que continúa proporcionando beneficios en las líneas de producción, ha penetrado en el dominio del software.
Ahora solo se adjuntan tarjetas, que contienen información sobre plazos, descripciones, o números de proceso y el nombre del ejecutor, no a cajas de piezas de repuesto sino a tableros con columnas divididas:
- Backlog — tareas por completar
- Tareas actualmente en desarrollo
- Tareas completadas pero aún no entregadas a los testers
- Tareas listas para ser entregadas al departamento de pruebas
- Tareas en revisión del gerente de proyecto (PM)
- Tareas completadas
El número generalmente se escribe encima de las columnas — el límite, que indica la cantidad máxima de procesos en ella. El límite del backlog se calcula en función del tiempo de entrega. Si hay 5 procesos de trabajo en el sistema y el tiempo medio de finalización de cada uno es de 1 día, el backlog puede limitarse a 5.
La estructura anterior no es estricta — dependiendo de las especificidades del proyecto, se pueden añadir columnas improvisadas. Un sistema Kanban puede tener a menudo la necesidad de definir criterios para la preparación de tareas antes de la ejecución. En este caso, aparecen dos columnas, referidas en inglés como especificar (parámetros de clarificación) y ejecutar (asumir el trabajo).
- Otra columna con una cola de prioridad puede ser añadida. Cuando un ejecutor queda libre, necesita limpiar esta columna de tareas primero antes de asumir otras.
- Las tareas que no se han completado son devueltas al backlog o tachadas del esquema.
- Kanban no fomenta el multitasking, limitando así el número de procesos para cada ejecutor.
- El trabajo completado es mejor que varias tareas comenzadas.
- Se puede asumir un segundo trabajo si el primero está bloqueado.
- El tiempo para la ejecución de la tarea debe ser equilibrado. Un plazo demasiado corto puede afectar la calidad. Un límite excesivamente extendido quema los recursos del equipo y incrementa los costos del proceso.
¿Por qué se utiliza la pizarra Kanban en todas partes en lugar de, por ejemplo, tabletas o grandes monitores? Los partidarios del sistema responden a esta pregunta afirmando que una pizarra regular tiene dos ventajas: es simple y proporciona control visual. Es fácil realizar cambios en ella, y fomenta la interacción táctil y social entre los miembros del equipo.
Ventajas y Desventajas de Kanban
Kanban tiene las siguientes ventajas:
- Flexibilidad en la planificación. El equipo se centra únicamente en el trabajo actual, con la prioridad de tarea establecida por el gerente.
- Alto compromiso del equipo en el proceso de desarrollo. Gracias a reuniones regulares, transparencia del proceso y oportunidades de autoorganización, los empleados se unen y muestran un interés genuino.
- Duración del ciclo más corta. Si las habilidades necesarias son poseídas por varias personas, la duración disminuye; si solo una persona las posee, se produce un cuello de botella. Por lo tanto, los empleados deben compartir conocimientos optimizando así la duración del ciclo. Esto permite que todo el equipo trabaje en tareas atascadas y restaure un flujo suave.
- Menos cuellos de botella. Los límites de WIP permiten la identificación rápida de cuellos de botella y áreas problemáticas que surgen por falta de enfoque, mano de obra o habilidades.
- Visibilidad. Cuando todos los ejecutores tienen acceso a los datos, se vuelve más fácil identificar cuellos de botella. Los equipos Kanban, además de las tarjetas mismas, suelen utilizar dos informes comunes: gráficos de control y flujo acumulativo.
En la práctica, el sistema muestra grandes resultados en áreas de producción no centrales:
- grupos de soporte de software o mesas de ayuda.
- Kanban funciona bien en la gestión de startups sin un plan claro pero donde se está llevando a cabo un desarrollo activo.
Kanban también tiene desventajas:
- el sistema funciona mal con equipos de más de 5 personas
- no está destinado à la planificación a largo plazo.
Diferencias con Scrum
Scrum, al igual que Kanban ágil, es una metodología flexible que también se aplica a menudo en la esfera de TI. Las diferencias entre ellas no son obvias a simple vista. Hay muchas similitudes, por ejemplo, la presencia de un backlog en ambos enfoques.
Scrum | Kanban | |
Ritmo | Repetidos sprints de duración fija | Proceso continuo |
Salida de lanzamientos | Al final de cada sprint tras la aprobación del gerente de proyecto (product owner) | El flujo continúa ininterrumpido o a criterio del equipo |
Roles | Product owner, Scrum master, equipo de desarrollo | Equipo liderado por PM; en algunos casos se involucran coaches ágiles de Kanban |
Métricas clave | Velocidad del equipo | Tiempo de entrega |
Respecto à la aceptabilidad del cambio | Durante un sprint, los cambios son indeseables, ya que pueden llevar a errores en el cálculo de tareas | Los cambios pueden ocurrir en cualquier momento |
Ejemplos de Aplicación en TI
Desde Microsoft: El Debut de Kanban en el Desarrollo de Software
El uso de los principios Kanban en tecnología de la información comenzó hace un poco más de 10 años. David Anderson, uno de los principales promotores de Kanban para desarrolladores de software, consultó con Microsoft en 2005. Ellos estaban insatisfechos con el rendimiento de su departamento — Ingeniería Sostenida XIT, que estaba corrigiendo errores en aplicaciones internas. Al comienzo del año de informes, este departamento era el peor en su división. El backlog superaba la dimensión aceptable por cinco veces, y el tiempo de procesamiento de una solicitud era típicamente de cinco meses.
El nuevo PM, con las consultas de Anderson, aumentó la productividad del problemático departamento en un 155% en nueve meses. El tiempo de entrega era ahora de cinco semanas, el backlog volvió a un tamaño normal, y la finalización oportuna de tareas se estabilizó en un 90%. Todos estos resultados se lograron con una incorporación mínima de nuevos empleados; el personal continuó corrigiendo errores de la misma manera — solo cambiaron los enfoques para organizar el trabajo.
Un hecho interesante: el gerente de programa Dragos Dumitriu, quien se propuso cambiar la situación en XIT, se sintió cautivado por el libro de Anderson. Para su sorpresa, se encontró con el ideólogo del programa Kanban en la misma Microsoft donde había comenzado justo el día anterior. Dumitriu pidió ayuda a Anderson con su tarea, y este último estuvo de acuerdo en aplicar los principios de su libro en la práctica.Dumitriu se encontró con un departamento compuesto por tres desarrolladores y tres testers, que tenía 80 solicitudes acumuladas en el backlog. El PM mismo fue nombrado temporalmente ya que los requisitos del trabajo incluían experiencia en tecnología ASP, administración de SQL Server y conocimiento de MS Project Server. La dirección imaginaba un “techie” que pudiera codificar, preparar informes y pronosticar la carga del backlog en esta posición. Como se creía en aquel entonces, el problema del departamento se revelaría si se recopilaba una gran cantidad de datos. Dumitriu no era un “techie”.
Sin embargo, al comenzar a analizar las operaciones de XIT junto a Anderson, identificó rápidamente los factores clave que afectan negativamente la velocidad del departamento:
- Predecir las implicaciones (ROM) de cumplir una solicitud tomó mucho tiempo. Tanto el desarrollador como el tester tenían que dedicar un día completo de trabajo realizando los cálculos necesarios, revisando el código y completando la documentación. En promedio, llegaba una solicitud cada día. Según los cálculos del PM, el 40% de la productividad del departamento se destinaba al ROM;
- Se daba prioridad a las solicitudes de mayor valor. XIT se financió en función del valor del pedido. La priorización de solicitudes se discutía mensualmente en las reuniones de gerentes de departamento con clientes — gerentes de otros departamentos. Con un backlog en expansión à la velocidad actual, donde solo se procesaban 6 – 7 solicitudes mensualmente, las prioridades de otras solicitudes cambiaban constantemente debido al paso del tiempo. Muchas de ellas se pospusieron a un “más tarde” significativo, que ni siquiera era igual al siguiente mes.
- En la etapa ROM, se filtraban la mitad de las solicitudes. Algunas eran demasiado grandes y se reclasificaban como proyectos para ser transferidos a otros departamentos, otras eran demasiado caras y simplemente se cancelaban. Algunas solicitudes no se tomaban en desarrollo porque su implementación llevaría demasiado tiempo. Por lo tanto, el 40% de la productividad del departamento se gastaba en analizar solicitudes, de las cuales el 50% eran rechazadas. Aproximadamente el 15 – 20% de los recursos de trabajo se perdían.
- El trabajo preparatorio sobre las solicitudes podía prolongarse durante meses antes de que comenzara la implementación. Los cálculos en la etapa ROM podrían perderse o olvidarse durante ese tiempo. Especialmente si la implementación era manejada por un desarrollador diferente al que inició el análisis.
Soluciones Kanban para el departamento problemático de Microsoft
Al final de 2005, la productividad del departamento aumentó en un 155%. Para mejorar aún más el trabajo de XIT, se incorporaron dos empleados: un desarrollador y un tester. El número de solicitudes en el backlog disminuyó a 10, y un desarrollador procesó consistentemente 11 solicitudes por trimestre. En promedio, se completaron 56 solicitudes por trimestre en comparación con 11 anteriormente. El costo de las solicitudes cayó de $7500 a $2900.
Aplicación en Corbis
Después de lograr el éxito en Microsoft, Anderson en 2006 comenzó a abordar una nueva tarea compleja. Ahora trabajaba en Corbis — otra empresa de Bill Gates, que aún no había dejado MS. Una de las actividades de Corbis era la concesión de licencias de fotos. En ese momento, era la segunda mayor biblioteca de fotos de stock del mundo con una base de datos de unas 3.5 mil imágenes.
La tarea de Anderson era acelerar los lanzamientos principales de la empresa. El intervalo entre sus lanzamientos era de tres meses y podría crecer incluso más. Solo discutir el plan de lanzamiento tomaba dos semanas à la dirección. Era necesario establecer la liberación de lanzamientos secundarios o actualizaciones cada dos semanas. Al mismo tiempo, los recursos clave debían dirigirse hacia el proyecto principal.
Una pizarra Kanban apareció en la oficina de Corbis, donde Anderson hablaba con el equipo a diario. El objetivo del PM era mejorar el control visual sobre los procesos, fomentar la autoorganización y una mayor responsabilidad personal entre los ejecutores. El sistema Kanban también tenía como objetivo reducir la supervisión del gerente y aumentar la productividad.
Además de tarjetas coloridas y gráficos, apareció en la pizarra un “contenedor de basura” — al que se enviaban tareas que eran demasiado grandes.
Foto de la presentación oficial
Un Sistema Kanban para la Ingeniería de Sostenimiento en Sistemas de Software por David J Anderson
El sistema Kanban clarificó cuándo el flujo deja de ser suave y dónde ocurren demoras, el llamado cuello de botella. Rápidas discusiones con el equipo ayudaron a identificar problemas actuales. Por ejemplo, las pruebas tomaban 3 días, lo que afectaba negativamente el cronograma de lanzamientos. Tres empleados se unieron y encontraron una manera de reducir el tiempo a un día.
Un cuello de botella es una sección del esquema o algoritmo de las operaciones de la empresa, donde limitaciones de recursos o productividad humana reducen drásticamente el rendimiento del flujo de tareas. La escasez de mano de obra, un mal internet, o un director de vacaciones bloquean o ralentizan la ejecución de tareas.
Los límites para las tarjetas Kanban se establecieron de manera empírica dos veces. En la columna “listo para desarrollar”, se aumentaron los límites. También apareció una nueva columna — “listo para pruebas”. Muchas solicitudes para aguas abajo estaban formuladas incorrectamente, causando gastos de tiempo innecesarios. Por lo tanto, el PM investigó las operaciones del flujo superior y encontró errores.
El procedimiento de revisión de solicitudes podría tomar 100 días, pero los lanzamientos aún comenzaron a emerger cada dos semanas como se planeó. Las decisiones sobre el contenido de los lanzamientos se tomaron 5 días antes de la publicación. La práctica de conteo, como en el caso del departamento XIT en Microsoft, se abandonó en favor de la productividad. Las prioridades de las tareas se establecieron según el “costo de los retrasos” o la disponibilidad de recursos.
El sistema Kanban no solo ayudó a Anderson a alcanzar la meta establecida, sino que también mejoró la moral dentro del equipo. Gracias a discusiones colectivas y visibilidad de los procesos, los empleados establecieron confianza entre sí. El personal también se adhirió a Kaizen, es decir, la práctica de mejora continua.
Programas y Aplicaciones para KANBAN
Trello
Sistema de Kanban popular para la gestión de tareas. Se destaca por su atractivo visual y su interfaz fácil de usar. Los usuarios resaltan su súper flexibilidad.
Kanbantool
Tablero gratis para dos usuarios. Soporte de API e interfaces táctiles.
Lean Kit Kanban
Tablero gratuito para cinco usuarios con buenas características de colaboración. Soporte de API y capacidades de importación/exportación, estadísticas extensas.
Kanbanize
Servicio completamente gratuito con funcionalidad decente. Sus propietarios garantizan un aumento del 300% en la productividad al usar su producto.
Worksection
SaaS ucraniano — aplicación para el seguimiento y gestión rápida de proyectos. Actualmente, además de la contabilidad de finanzas y plazos, hay un diagrama de Gantt. En los próximos meses, los desarrolladores agregarán un tablero Kanban con opciones de personalización, haciendo que el servicio sea aún más adecuado para Kanban.
Veredicto
Kanban es una práctica que ayuda a alcanzar el éxito, mientras que el uso solo de métodos ágiles no es obligatorio. Cambios significativos se logran eliminando el tiempo desperdiciado, gestionando cuellos de botella y reduciendo la variabilidad.
Sin embargo, los cambios exitosos requieren tiempo. Ocurren gradualmente, mientras que la resistencia del equipo a las innovaciones es mínima. El sistema Kanban motiva al personal a mejorar sin cambios en los métodos de ingeniería.
Los libros para el artículo son proporcionados por kniga.biz.ua