Kanban

share on:
maxresdefault

Un placer tener que escribir sobre Kanban. Pocas veces uno se encuentra con un sistema “nuevo” – por así decirlo – que pueda agregar mucha productividad a un equipo de trabajo. Así de útil resultó ser, en Proyectos Ágiles, una pizarra Kanban.

Básicamente el término Kanban viene de Japón y significa más o menos “Tarjeta Visual”, y en sí es un sistema que ya viene siendo usado hace sesenta años en la producción de productos y el abastecimiento de partes. Ahora bien, poniendo esos conceptos al servicio del software, nos encontramos con una metodología de trabajo que nos permite hacer que las componentes vayan “fluyendo”, lenta y sostenidamente, desde la concepción hasta la producción.

A ver si puedo dar un ejemplo:
En las metodologías Ágiles, como en Scrum, una de las partes importantes de cada ciclo o Sprint es cuando los desarrolladores escogen una tarea (o más) de la Lista de Pendientes. En Scrum esto se suele hacer de modo voluntario, de acuerdo a las capacidades de cada persona en el equipo. Ellas se encargan de llevar esa tarea a un nivel necesario (definido por lo que el equipo considera como “Terminado”. Hasta ahí lo que sabíamos, y nos iba muy bien.

En una pizarra Scrum, normal tenemos una columna para las tareas:

Pendientes / En Desarrollo / Finalizadas.

En Kanban, reemplazamos esa columna del medio “En Desarrollo” y la dividimos en tantas columnas como nuestro “flujo de trabajo” o Workflow necesite, por ejemplo en:

Pendientes / Especificaciones / Diseño / Ejecución / Test / Finalizadas

kanban-board-1

Hasta ahí no parece que hiciéramos mucho más, pero el secreto está en que, de acuerdo a la capacidad de nuestro equipo, demos a cada columna un “Tope” de capacidad. Por ejemplo que no podamos estar “Diseñando” más de tres componentes en un momento dado, y que si quisiéramos meter un cuarto ítem, deberíamos mover a Ejecución alguno. De esa forma se crea un flujo de ítems que se van “empujando” unos a otros, como si fueran una cadena de producción hasta que se den por finalizadas todas las tareas.
Terminaríamos con algo así:

Pendientes (10)/ Especificaciones (3) / Diseño (3) / Ejecución (4) / Test (2) / Finalizadas

La ventaja que tiene este modelo es que vamos generando ítems finalizados constantemente.

Aquí algunos ejemplos (podemos ver arriba, donde está el nombre de la columna, la cantidad de ítems que puede aceptar)

 

visualizing-work

La característica principal que tiene Kanban, es que limita el trabajo que se puede hacer en un momento dado. Es más realista que otros paradigmas.

Los primeros – conocidos – en utilizar Kanban, aunque no lo llamaran así, fueron los equipos de producción de Toyota, con sus entregas “Just in Time” o JIT (en el tiempo preciso). Los ítems, ordenes, tareas, entran en una cadena de pasos que fluye hacía su entrega o culminación, pero es consciente de las limitaciones que puede haber para trabajar en un número de piezas o ítems en una misma maquina o proceso (para nosotros son columnas).

Así como Scrum es muy bueno en limitar el número de tareas o trabajos que se pueden terminar en un Ciclo o Sprint, Kanban es muy bueno para limitar el número de tareas similares por tanto eliminado así mucho de los problemas de la estimación para todo el lote.

Para mi, personalmente, es una adición a los conceptos de Scrum que mejora la metodología. Esto no es decir que Kanban es mejor que el Scrum tradicional. De hecho, en la práctica, Kanban es más lento, pero constante. A veces eso puede ser importante para el cliente.

Otro gran valor de Kanban es que hace que el equipo de trabajo aprecie cuán importante es terminar lo que se comienza. Porque Kanban necesita que los ítems vayan moviéndose para hacer lugar a otros. Como una autentica cadena de producción.

Yo no veo la hora de empezar a usar Kanban en proyectos Scrum en el futuro. Estoy seguro que mejora la moral del equipo.

Otra característica que tiene Kanban es lo de las Retrospectivas un poco diferentes a las que tenemos en Scrum. En Kanban las retrospectivas se llaman Kaizen (que en japonés sería algo así como “Mejora continua”.  Se diferencian de las típicas reuniones de Scrum en el hecho de que son más positivas, pierden menos tiempo en lo que fue mal y mucho más en cómo ajustar cada columna, la capacidad y la velocidad en la que podemos encarar el próximo ciclo. Mirando al futuro.  Hay menos gente a la defensiva, y por ende, los desarrolladores están más entusiasmados.

La única crítica que tiene Karban, en general, es que la estructura es tan dinámica y la secuencia de pasos tan explícita, que se pierde un poco el sentido de urgencia en algunas tareas.  Muchos equipos optan por hacer otra línea en la pizarra marcando las urgencias y así contrarrestar ese efecto.

GQrr9

En conclusión: Si van a empezar un proyecto Ágil. Prueben con Kanban, al menos un par de Sprints o Ciclos. Se pueden llevar una sorpresa muy agradable.

 

share on:

Leave a Response