Probablemente hayas oído hablar de la metodología de gestión de proyectos Kanban, pero es posible que no sepas mucho al respecto. ¿Cuáles son las diferencias entre Kanban y otras metodologías ágiles como Scrum y herramientas como el diagrama de Gantt? ¿Para qué sirve la metodología Kanban?
Veamos los orígenes de Kanban, respondamos estas preguntas y veamos cómo se utiliza en la práctica.
Los principios fundamentales de la metodología Kanban
El término Kanban proviene de Japón gracias al sistema de producción de Toyota, muy conocido en los pequeños círculos. Sería fantástico que todo el mundo conociera la metodología Kanban y sus principios básicos: lean manufacturing, desarrollo continuo, orientación al cliente, etc. Todos los principios se describen en el libro de Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production.
El término Kanban tiene una traducción literal. «Kan» significa visible o visual y «ban» significa una tarjeta o tablero. Las tarjetas de metodología Kanban se utilizan en todas las plantas de Toyota para mantener la gestión de inventario optimizada: sin almacenes ni talleres abarrotados con suficiente acceso a las piezas.
Imagine que su garaje instala puertas de Toyota Corolla y hay un paquete de 10 puertas cerca de su espacio de trabajo para instalar, una tras otra, en autos nuevos. Cuando solo hay cinco puertas en la caja, sabes que es hora de pedir puertas nuevas. Luego tomas una tarjeta Kanban, escribes en ella un pedido para 10 puertas más y llevas la tarjeta a la tienda que fabrica las puertas. Está seguro de que se producirán puertas nuevas cuando haya agotado las cinco puertas restantes.
En los talleres de Toyota funciona así: cuando instalas la última puerta, llega otro paquete de 10 puertas. Solicita constantemente nuevos puertos sólo cuando los necesita.
Ahora imagine este sistema ejecutándose en toda la fábrica. No hay almacenes con repuestos tirados durante semanas o meses. Todos los empleados trabajan bajo demanda y producen sólo la cantidad necesaria de repuestos. Si hay más o menos pedidos, el sistema coincidirá con los cambios.
La idea principal de las tarjetas de metodología Kanban es reducir la cantidad de trabajo que se realiza . Por ejemplo, gracias a esto, sólo se pueden suministrar 10 tarjetas de puerta para toda una línea de producción. Esto significa que sólo 10 puertas prefabricadas estarán en línea a la vez durante el ciclo de producción. Decidir cuándo pedir esas puertas depende de quien las instale. Siempre limitado a 10 puertas, sólo los instaladores conocen las próximas necesidades del taller y pueden realizar pedidos al fabricante de puertas.
Esta metodología de fabricación ajustada se introdujo por primera vez en Toyota, pero muchas empresas de todo el mundo la han adoptado. Pero estos ejemplos son para manufactura, no para ingeniería de software.
¿Cómo funciona la metodología Kanban para el desarrollo de software?
Comencemos examinando las diferencias en la planificación de proyectos con respecto a otras metodologías ágiles.
La diferencia entre la metodología Kanban y SCRUM es que:
- No hay cuadros de tiempo (ni para tareas ni para sprints)
- Las tareas son más grandes y hay menos
- Las calificaciones de período son opcionales o ninguna
- No existe la “velocidad de equipo”: sólo se cuenta el tiempo medio para una implementación completa
Ahora mira esta lista y piensa: ¿qué quedará de la metodología ágil, si eliminamos los sprints, aumentamos el tamaño y dejamos de contar la velocidad de trabajo del equipo? ¿Nada?
¿Cómo es posible hablar de supervisión del desarrollo si se eliminan todas las principales herramientas de supervisión? Esta es probablemente la pregunta más importante para mí.
Los gerentes siempre están pensando en el control y tratando de conseguirlo, incluso si realmente no lo tienen. La supervisión del proceso de desarrollo por parte de un gerente es una ficción. Si un equipo no quiere trabajar, fracasará en un proyecto a pesar de cualquier nivel de control.
Si un equipo se divierte mientras trabaja y trabaja con total eficiencia, no hay necesidad de control, porque sólo perturba el proceso y aumenta los costes.
Por ejemplo, un problema común con la metodología SCRUM son los costos más altos debido a discusiones, reuniones y grandes pérdidas de tiempo en las uniones de los sprints, cuando se pierde al menos un día para completar un sprint y un día extra para comenzar otro. Si un sprint dura dos semanas, dos días de dos semanas equivalen al 20%, lo cual es mucho. Por lo tanto, cuando se utiliza la metodología SCRUM, se pierde aproximadamente entre el 30 y el 40 % del tiempo apoyando el proceso en sí, incluidos los mítines diarios, las retrospectivas de sprint, etc.
La metodología de desarrollo Kanban se diferencia de SCRUM en su enfoque en las tareas. El objetivo principal de un equipo en SCRUM es completar con éxito un sprint. En la metodología Kanban, la tarea es lo primero. No hay sprints y un equipo trabaja en una tarea de principio a fin. La distribución se realiza cuando está listo en función de la presentación del trabajo realizado. Un equipo que sigue la metodología Kanban no debe estimar cuánto tiempo llevará realizar una tarea, ya que no tiene sentido y estas estimaciones casi siempre son incorrectas.
¿Por qué un directivo necesitaría una cotización si cree en el equipo? El objetivo de un gerente que utiliza la metodología Kanban es crear un grupo priorizado de tareas, y el objetivo del equipo es completar tantos elementos de este grupo como sea posible. Eso es todo. No se requieren medidas de control. Todo lo que el administrador tiene que hacer es agregar elementos al grupo o cambiar su prioridad. Así gestiona un proyecto un gestor Kanban.
El equipo trabaja desde un tablero Kanban. Podría verse así:
Columnas de izquierda a derecha en el tablero Kanban:
- Objetivos : esta es una columna opcional, pero útil, en el tablero Kanban. Los objetivos de alto nivel de un proyecto se pueden ingresar aquí para que todos los miembros del equipo los conozcan y puedan recordarlos periódicamente. Los objetivos de ejemplo podrían ser «Aumentar la velocidad de trabajo en un 20%» o «Agregar soporte para Windows 7».
- Cola de historias : esta columna cubre las tareas que están listas para comenzar. La carta más alta (que tiene la mayor prioridad) se toma primero y su carta se mueve a la siguiente columna.
- Aceptación del procesamiento : esta columna y todas las demás anteriores a la columna «Listo» pueden variar según el flujo de trabajo de los equipos individuales. Las tareas que están en discusión, como un diseño incierto o un enfoque de código que debe finalizarse, se pueden colocar aquí. Una vez finalizada la discusión, se pasa a la siguiente columna.
- Desarrollo : la actividad reside aquí hasta que se completa el desarrollo de la característica. Una vez completada la tarea, se mueve a la siguiente columna. Si la arquitectura es incorrecta o incierta, se puede mover a la columna anterior.
- Prueba : la actividad está en esta columna Kanban mientras se prueba. Si hay algún problema, se devuelve a ‘Desarrollo’. Si no hay ninguno, se pasa a la siguiente columna.
- Distribución : Cada proyecto tiene su propia distribución. Esto podría significar poner una nueva versión en el servidor o simplemente enviar el código al repositorio.
- Listo : la pestaña aparece en esta sección del tablero Kanban cuando el objeto está completamente terminado y ya no necesita preocuparse.
Las tareas de máxima prioridad se pueden mostrar en cualquier columna. Planificados o no, deben ejecutarse de inmediato. También puedes crear una columna especial en el tablero Kanban para estos elementos. En nuestra imagen de ejemplo, está marcado como «Acelerar». Una tarea con la mayor prioridad se puede colocar en «Acelerar» para que el equipo comience y finalice lo antes posible, ¡pero solo una de estas tareas puede existir en el tablero Kanban! Si se crea otra, se debe agregar a la “Cola de historias” hasta que se maneje la tarea existente de mayor prioridad.
Hablemos de uno de los elementos más importantes del tablero. ¿Ves los números debajo de cada columna en la tarjeta de muestra? Esta es la cantidad de tareas que se pueden colocar en cada columna al mismo tiempo. Las cifras se eligen de forma experimental, pero normalmente se basan en el número de desarrolladores del equipo, es decir, en la capacidad de trabajo del equipo.
Si hay ocho programadores en el equipo, podrías darle un 4 a la columna «Desarrollo». Los programadores sólo pueden trabajar en cuatro tareas de desarrollo a la vez y tendrán muchas razones para comunicarse y compartir experiencias. Si pones un 2 ahí, es posible que empiecen a aburrirse y a perder demasiado tiempo discutiendo. Si le das un 8, entonces cada programador trabajará en su tarea, pero algunos elementos permanecerán en el tablero por mucho tiempo, mientras que el objetivo principal de la metodología Kanban es acortar el tiempo desde el inicio de una tarea hasta su final. .
Nadie puede darte una respuesta precisa sobre los límites de las actividades: cada equipo es diferente. Un buen punto de partida es dividir el número de desarrolladores por dos y ajustar los números según la experiencia.
Por «desarrolladores» me refiero no sólo a los programadores, sino también a otros especialistas. Los especialistas en control de calidad, por ejemplo, son los desarrolladores de la columna «QA», ya que las pruebas son su responsabilidad.
Cómo se benefician los equipos de Kanban
¿Qué beneficios obtendrá un equipo de una metodología Kanban con estas limitaciones?
En primer lugar, disminuir la cantidad de tareas que se ejecutan simultáneamente reducirá el tiempo necesario para completarlas. No es necesario cambiar el contexto entre actividades y realizar un seguimiento de diferentes entidades, ya que solo se toman las acciones necesarias. No es necesario realizar la planificación del sprint ni los talleres del 5% porque la planificación ya se realizó en la columna «Story Queue». El desarrollo profundo de una empresa comienza sólo cuando se lanza la empresa.
En segundo lugar, los obstáculos se ven inmediatamente. Cuando los especialistas de control de calidad, por ejemplo, no pueden manejar las pruebas, llenarán su columna y los programadores que estén listos con nuevas tareas no podrán moverlas a la columna «Prueba». ¿Qué se hará entonces? En tal situación es hora de recordar que son un equipo y solucionar el problema. Los programadores pueden ayudar a completar una de las tareas de prueba y solo entonces mover un nuevo elemento a la siguiente columna. Ayudará a realizar ambos elementos más rápido.
En tercer lugar, es posible calcular el tiempo necesario para completar una actividad media. Podemos registrar las fechas en que se agregó una tarjeta a Story Queue, cuándo se inició y cuándo se completó. Podemos calcular el tiempo promedio de espera y el tiempo promedio de finalización a través de estos tres puntos. Un gerente o propietario de producto puede calcular lo que quiera utilizando estas cifras.
La metodología Kanban se puede describir con sólo tres reglas básicas:
- Ver producción:
- Divide tu trabajo en tareas. Escribe cada una de ellas en una tarjeta y colócalas en una pared o pizarra.
- Utilice las columnas mencionadas para mostrar la ubicación de la tarea que se está cumpliendo.
- Limite el WIP (trabajo en progreso o trabajo realizado al mismo tiempo) en cada etapa de producción.
- Mida el tiempo del ciclo (tiempo de entrega promedio) y mejore constantemente el proceso para reducir este tiempo.
¡Solo hay tres reglas fundamentales en la metodología Kanban!
Existen nueve reglas básicas en la metodología SCRUM, 13 en la metodología XP y más de 120 en la metodología clásica RUP. Esa es la gran diferencia.
