Después de haber aplicado un alto porcentaje de Scrum en los proyectos de software en los que trabajo, siento curiosidad por todas las demás metodologías ágiles que existen, sobre todo, para saber si hay alguna práctica que pueda emplear que me permita optimizar algún aspecto de la actividad diaria a desarrollar.
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.
)