Uno de los mayores males que azota la productividad de las empresas de desarrollo de software es la metodología de desarrollo ASM: A Salto de Mata. Es decir “Aquí lo pillo y aquí lo mato“ o dicho de otra forma, la inexistencia de un método de producción ordenado.
Además, la nula visibilidad del flujo de trabajo produce efectos muy perniciosos como son la simultaneidad de los proyectos por encima de la capacidad de los desarrolladores o la existencia de la figura del “Hero” en contrapunto al equipo y el conocimiento compartido.
El Kanban (del japonés: kanban, donde kan significa “visual,” y ban significa “tarjeta“ o “tablero“) es, en la versión nacida y evolucionada en Toyota, una completa y compleja metodología de señalización. Pero en este artículo me refiero a la simple herramienta visual compuesta por el tablero y las tarjetas que soporta.
Es el primer paso que deben completar los desarrolladores para iniciar el camino de convertirse en un equipo Agile de desarrollo.
Descripción general del tablero
El concepto de Kanban es tan sencillo como poderoso. En un tablero dibujaremos tantas columnas como pasos por los que deba de pasar una tarea en nuestro flujo de trabajo. Por ejemplo, en desarrollo las columnas más comunes son ToDo, que son las tareas pendientes de ser iniciadas; Doing, que son aquellas que se están realizando; Testing, como indica su nombre son las tares que están en proceso de QA; y finalmente la columna de Done, aquellas que están acabadas (el difícil concepto de Done Agile).
Las tareas, plasmadas en postit, se van moviendo de derecha a izquierda completando cada una de las etapas. Se pasan hacia adelante o hacia atrás, aunque esto último siempre ha de ser considerado como un fallo. Pero esto no sería realmente de gran utilidad si no fuera por el concepto de WIP (Work In Progress). Este número que se coloca en el encabezado de la columna es el que indica cuantas tareas máximas (o mínimas) puede haber de forma simultanea en una etapa.
Flujo de trabajo
Con este simple mecanismo convertimos nuestro tablero en un indicador visual de los problemas de nuestro flujo de trabajo. Si hemos llegado al límite WIP de una columna, no podemos añadir más tareas. Siendo obligatoria acabar con una de las que están en esta etapa para mandarla a la siguiente, o asumir el fracaso de una de las tareas y reiniciarla mandándola a la columna de la izquierda. Esta claro que aquí tenemos un cuello de botella y que es necesario que el equipo encuentre el impedimento que lo produce.
También puede ocurrir al contrario, que una columna esté continuadamente vacia o con muy pocas tareas en relación a su WIP máximo. Lo cual puede indicar que hay un cuello de botella en alguna etapa anterior o que la carga de trabajo es muy baja.
Sea cual sea la incidencia en el flujo de trabajo, con un tablero Kanban obtenemos de un vistazo el estado del trabajo en todo momento y, en mucho casos, algo más importante como es que las personas que deciden sean consciente de una forma muy sencilla de la realidad de los proyectos.
Además cumplimos dos conceptos Agiles: los errores y los impedimentos son muy visibles y se ven muy pronto, y la comunicación que produce es la de cara a cara, que es la preferente a cualquier otra.
Prioridades y Filas
Otra ventaja de utilizar un Kanban es la prioridad de las tareas. Partiendo de la base que quien más sabe de desarrollar es el equipo de desarrollo, y quien más sabe de la importancia de las tareas es el dueño del producto (o el cliente), una de las trampas en las que más caemos los programadores es en priorizar nosotros la importancia de las tareas del proyecto y después que nos digan eso de “es obvio que esto es más importante“.
Así que en un Kanban las tareas han de ser priorizadas para evitar este tipo de confusión que tantas horas extras y frustración produce. Las tareas técnicas obviamente las prioriza el equipo, que es el que sabe desarrollar; y yo prefiero empezar por las más difíciles y dejar las más sencillas para el final.
Otra práctica que nos permite el tablero es el pintar filas o carriles. Es una forma de dividir un tablero en diferentes proyectos que comparten las mismas etapas. O se pueden dividir en tres filas que implican la criticidad de las tareas:
ASAP. Aquí se sitúan las tareas que algún día se harán. No están priorizadas ni se sabe cuando van a realizarse. Está pensado para aquellas que se dejan para los tiempos muertos y que, al no tener prioridad, cualquier tarea es más prioritaria que ella.
Priority. Tareas que han sido priorizadas y que están en el flujo de trabajo normal.
Fire. Tarea que provoca que todo el equipo, a veces toda la empresa, deje lo que esté haciendo y se centre al completo a resolver esta tarea hasta que llegue a Done. Se puede reforzar señalando de forma inequívoca que personas están involucradas en la tarea y que no deben ser interrumpidas en ningún caso. Por ejemplo con chalecos reflectantes.
Más información | Kanban vs Scrum en Presión Blogosférica, Scrummanager, LeanKitKanban
En GenbetaDev | Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?