El libro, escrito por Kniberg y Mattias Skarin (otro personaje dentro del mundo de las metodologías ágiles), explora ambas metodologías desde el punto de vista de la comparación. Vamos, que las compara entre sí para sacar los mejor de ambas en cada elemento específico, o cada situación en la que ambas pueden emplearse.

La lectura es muy amena y está plagada de imágenes que ilustran todas las situaciones que se van sucediendo a lo largo del libro, por lo que engancha de principio a fin.

La segunda parte del libro, además, es un ejemplo, con un proyecto real, de cómo se puede emplear kanban en el mundo real. Los problemas que pueden surgir y como este grupo los solventó.

No olvido también el mencionar que está disponible la versión en castellano (y en francés) tal y como la propia página oficial del libro informa. Así como agradecer a la comunidad ágil en español que se coordinase tan bien, bajo la dirección de Ángel Medinilla, para darnos la posibilidad de poder leer tan gran obra en nuestro idioma.

Recomiendo la lectura a todos aquellos que tengan o pertenezcan a un grupo de trabajo.

Las metodologías ágiles no es un tema muy de moda en los ambientes académicos y universitarios, puesto que el desarrollo de software no es algo que se haga de forma práctica en esos entornos (se realizan más actividades de tipo docente e investigación), por lo que el tema les sonó a todos nuevo y fresco.

Fuera de aburrir al personal, la charla, aunque larga (hora y media), abarcó muchos aspectos de lo que se refiere al desarrollo del software e incluí una visión práctica de cómo lo tengo montado en la empresa en la que trabajo.

Quizás una futura presentación la haga realizando un scrum de verdad seleccionando a algunos asistentes y proponiendo una actividad a realizar que, aunque no tenga que ver con la programación, se pueda llegar a emplear un tablero sin probleas, así como asumir los roles específicos de dueño de producto, scrum master y el resto de integrantes del equipo.

Dejo la presentación aquí:

NOTA: la presentación en sí, aunque tiene algunas diapositivas explicativas y un montón de imágenes, no aporta todo el texto que se dictó, por lo que, es muy posible que resulte incompleta, extraña y carente de sentido en algunas partes.

En este aspecto, he descubierto en Kanban un interesante aliado para aspectos de la metodología que quedaban algo descolgados, y son los procesos rutinarios, o solo tener presente la continuidad de las tareas, ya que las tareas que se realizan en Kanban pueden aparecer en el backlog en cualquier momento e ir haciéndose, según su importancia y/o prioridad.

¿Qué es Kanban?

La palabra kanban (en kanji 看板, en katakana カンバン) parte de las palabras kan (看 o カン) que significa visual y ban (板 o バン), que significa tarjeta o tablero. La idea surge en el seno de la metodología de Lean, la cual fue desarrollada por Toyota, para mejorar la producción, basándose en técnicas como just-in-time (JIT).

Los principios que se promueven son:
 

• Calidad perfecta a la primera. Todo lo que se hace, debe de intentar hacerse bien, no rápido, ya que cuesta más tiempo hacer algo rápido y tener que arreglarlo después, que hacerlo bien desde el principio.
• Minimización del despilfarro. Hacer lo justo y necesario (y hacerlo bien, como se decía antes) y no entretenerse en otras tareas secundarias o no necesarias (principio YAGNI).
• Mejora continua. Ir mejorando continuamente los desarrollos, según los objetivos a lograr y alcanzar.
• Flexibilidad. Lo siguiente a realizar se decide del backlog pendiente, con lo que las tareas entrantes se pueden priorizar y condicionar según las necesidades puntuales.
• Construcción y mantenimiento de una relación a largo plazo con los proveedores.

 
En el desarrollo del software, el sistema kanban se puede resumir como la visualización de las tareas mediante un tablero, en el que se van moviendo entre los sectores delimitados, con el objetivo de tener siempre presente el trabajo a realizar y lo que hace cada uno. Que nadie se quede sin trabajo y que todas las tareas importantes se realicen primero.

El tablero visual

El tablero de kanban, el cual debe estar visible a todo el equipo de trabajo, tiene la peculiaridad de ser un tablero continuo. Esto quiere decir que, no se rellena con tarjetas y se van desplazando hasta que toda la actividad ha quedado realizada (como pasa en Scrum), sino que a medida que se avanza, las nuevas tareas (mejoras, fallos o tareas del proyecto) se van acumulando en la sección inicial, en las reuniones periódicas con el dueño de producto (o el cliente) se priorizan las más importantes, y se encolan en las siguientes zonas.

Además, las secciones que se pueden incluir en el tablero, además de diseño, desarrollo y pruebas, son las de paso a producción, con lo que, se tendrían todas las tareas en un seguimiento exhaustivo, desde que se piensan que deben de hacerse, hasta el punto en que se ha llevado a producción.

Como se puede ver en la figura, cada sección vertical, puede anidarse en conjuntos, de modo que la tarea de desarrollo, por ejemplo, pueda descomponerse en otras más significativas como: en cola y en desarrollo.

Los grandes grupos verticales, pueden pertenecer incluso a grupos de desarrollo diferentes, por ejemplo, un grupo de desarrollo puede encargarse del desarrollo, y otro de las pruebas y subida a producción, o incluso entre departamentos, tomando un último grupo para puesta en producción o incluso un primer grupo para la toma de propuestas y priorización de tareas.

Lo más corriente es que exista un grupo inicial, el dueño del producto, que se encargue de organizar las propuestas o entradas, y sea el propio cliente o incluso, si es para desarrollos internos, los departamentos de comercial y/o marketing. Depende de la empresa.

Las tarjetas

La importancia de la identificación rápida de tarjetas, en un tablero de amplias dimensiones es vital para ahorrar tiempo, con lo que, se pueden asignar colores, como pueden ser: verde para las mejoras, amarillo para las tareas del proyecto y rojo para los errores.

Además de esto, las tarjetas de kanban suelen tener bastante más información, ya que el método consiste en tener todo visual, para saber de forma rápida la carga total de trabajo, ya sea de los grupos, como del departamento, etc.

Se suelen emplear tarjetitas con fotos o caricaturas que se ponen junto con la tarea que está desempeñando en cada momento cada persona, así como emplear post-it sobre las propias tarjetas para indicar observaciones sobre la tarea, o bloqueos que se puedan sueceder, es decir, que la tarea no se pueda realizar porque depende de algún factor no resuelto aún.

Es importante reseñar que las tarjetas debe de tener la estimación de tiempo que tiene asignada la tarea, así como se pueden anotar las fechas de entrada en cada cuadrante, para tener información, al término de la tarea, de si ha sido una buena estimación, así como obtener el rendimiento del equipo de trabajo.

Control del Flujo

El sistema kanban, a diferencia de scrum, no se dedica a llevar la pista de un solo proyecto, sino que se pueden entremezclar tareas y proyectos. El método se basa en tener a los trabajadores con un flujo de trabajo constante, las tareas más importantes en cola para ser realizadas y un seguimiento pasivo, a modo de no tener que interrumpir al trabajador para saber qué hace en cada momento.

Por otro lado, se puede seguir la pista del trabajo realizado por el grupo de trabajo almacenando los datos que las tarjetas nos proporcionan, una vez llegan a el sector final (cuando ya están en producción), con una gráfica de este estilo:

En el gráfico de áreas apiladas, se ve claramente el tiempo dedicado a cada sector. En el caso expuesto, por ejemplo, se ve que las tareas pasan más tiempo en backlog (el sector de propuestas o esperando a comenzar su desarrollo) que en la zona de desarrollo, propiamente dicha.

Conclusiones

El sistema de kanban tiene ciertas ventajas con relación a otras metodologías que ya había visto, ya que permite no solo llevar el seguimiento de un proyecto de forma individual, sino también de las incidencias que se van sucediendo, así cómo otros proyectos paralelos que tenga que hacer el mismo equipo de desarrollo, por lo que, nos damos cuenta de que, de lo que se lleva la pista en sí, no es de los proyectos, sino de los equipos de trabajo.

Lo veo indicado, sobre todo en sitios donde las operaciones (incidencias, tareas repetitivas y aisladas) son más comunes que el desarrollo puro y duro de proyectos, es decir, en entornos que necesiten de flexibilidad en la entrada de tareas, así como un seguimiento de las mismas, un sistema de priorización, control de un equipo de trabajo e informes de dedicación.