Kanban: metodología, procesos y reglas

Muchas variantes de Ágil utilizan intervalos cortos y repetidos para completar partes del trabajo del proyecto dentro de los grupos. En cambio, Kanban utiliza un flujo continuo para completar elementos de trabajo del proyecto de forma rápida e independiente. Conoce el proceso, la metodología y las reglas de Kanban.

Definición y origen

Kanban, una forma de metodología de proyectos Ágil creada por el autor y consultor empresarial David J. Anderson, se centra en un flujo continuo de trabajo que mantiene la cantidad de trabajo que se realiza en un momento dado en consonancia con la capacidad del equipo. La palabra Kanban, sinónimo de "tarjeta", está tomada del enfoque de fabricación "justo a tiempo" de Toyota. Este enfoque sólo permite que los artículos avancen en la cadena de fabricación si hay capacidad disponible en la siguiente parte de la cadena. Esto se hace saber pasando una tarjeta, o Kanban, de una parte de la cadena a otra. Kanban intenta aplicar este enfoque "justo a tiempo" al desarrollo de software.

Proceso Kanban

Uno de los elementos importantes del proceso Kanban es la representación visual del trabajo. Esto suele implicar un tablero en el que los elementos de trabajo se escriben en notas adhesivas y se colocan en carriles de progreso, como "Por hacer", "Haciendo" y "Hecho". El "Hacer" podría dividirse en "Desarrollo" y "Pruebas". Lo visual ayuda a mantener al equipo centrado, otro elemento clave del proceso Kanban. El tablero sólo contiene los elementos de trabajo actuales, ya que son las únicas cosas en las que debe trabajar el equipo. La multitarea es, en la mayoría de los casos, ineficaz, porque es mucho más difícil cambiar de un elemento de trabajo a otro que centrarse en un elemento a la vez.

Otro elemento importante de Kanban es el uso de límites de trabajo en curso o WIP. Se trata de un límite en el número de elementos de trabajo que pueden estar en cualquier parte del proceso. Un elemento no puede avanzar a la siguiente fase del proceso a menos que esa fase esté por debajo de su límite WIP. Por ejemplo, si el desarrollo tiene un WIP de 5 y las pruebas tienen un WIP de 3, un elemento de trabajo no puede avanzar del desarrollo a las pruebas si ya hay 3 elementos de trabajo en las pruebas, aunque el desarrollo haya completado 5 elementos de trabajo. El equipo de Linda expresa su preocupación por el elemento de un límite WIP, anticipando cuellos de botella que ralentizarán al equipo. Sin embargo, el límite WIP no crea cuellos de botella, sino que los hace más evidentes.

Poner de manifiesto los cuellos de botella y otras ineficiencias conduce al último elemento de Kanban, que es la mejora continua. Este elemento es menos obvio en un flujo continuo porque no hay un punto de partida y de parada designado ni un tiempo formal para la reflexión. Sin embargo, el equipo debe identificar sistemáticamente las ineficiencias y abordarlas. Algunas áreas potenciales de evaluación son el tiempo que tarda en completarse un elemento de trabajo o el número de errores asociados a un elemento de trabajo. Esto puede ayudar a identificar si el trabajo está tardando demasiado o avanzando demasiado rápido.

Metodología y reglas de Kanban

Los elementos de trabajo que están listos para ser asumidos por el equipo se mantienen en una cartera de pedidos en orden de prioridad. Esto lo suele hacer la persona que solicita el proyecto y crea los elementos de trabajo. A medida que se dispone de capacidad para trabajar en nuevos elementos, el elemento de mayor prioridad de la cartera de pedidos pasa al flujo. Este elemento de trabajo avanza entonces a través del flujo, siempre que la siguiente fase no esté en el límite de WIP. Una regla que existe es el mantenimiento del límite WIP. Siempre existe la tentación de hacer una excepción o de ignorar por completo el límite WIP, pero esto mantiene un área ineficiente. Lo ideal en Kanban es que el WIP coincida con la capacidad de cada paso del proceso.

Finalmente, el trabajo pasa por todas las fases del proceso y se considera hecho. En este punto, debería estar en un estado en el que se pueda pasar a producción o entrar en funcionamiento. El valor aquí es que cada elemento de trabajo puede realizarse de forma independiente y no requiere el final de un intervalo o la finalización de otros elementos de trabajo para pasar a producción. Otra regla, o mejor práctica, es tener una definición clara de hecho. Esto puede ser más o menos obvio, dependiendo del desglose de las vías de progreso (como separar "hacer" en vías separadas para el desarrollo y las pruebas). La clave es que el equipo tenga un entendimiento común de cuándo se considera que un elemento de trabajo está hecho.