Si estás en el mundo del desarrollo de software es posible que hayas oído hablar de algo llamado método Kanban. En este artículo vamos a hablar este método de gestión de tareas para ver en qué consiste y que puedas evaluar si introducirla en el modus operandi de tu negocio.
Lo primero a decir sobre Kanban es que es una metodología ágil de desarrollo muy popular y que se usa en un gran número de empresas dedicadas al software. No voy a entrar en sus orígenes (en muchos lugares podréis obtener información sobre ello), y me voy a centrar en qué persigue y cómo funciona.
Básicamente, Kanban es una forma de trabajar y repartir tareas a un equipo, asegurándose de que las mismas llegan en las medidas adecuadas y evitando que se solapen o haya cuellos de botella.
Dicho así, probablemente no hayáis entendido mucho. Incluso un purista que sepa de qué va Kanban habrá enarcado una ceja. Veremos más adelante cómo esta frase cobra sentido.
PRINCIPIOS DEL MÉTODO KANBAN
Vamos a hablar primero de los principios básicos de esta metodología:
COMIENZA CON LO QUE HACES AHORA
Esto quiere decir que empezar a trabajar con Kanban no implica que tengas que empezar de cero o reconfigurar tu modo de realizar una tarea. Kanban nos va a ayudar a organizarnos, pero no pretende inmiscuirse demasiado en cómo realizamos las nuestras obligaciones al día de hoy.
COMPROMÉTETE A BUSCAR CAMBIOS INCREMENTALES Y EVOLUTIVOS
La idea es trabajar sobre iteraciones en las que vamos mejorando/cambiando poco a poco aquello que estamos desarrollando. Kanban está en contra de los cambios drásticos, pues los mismos tienen una tasa de fracaso más alta que los cambios incrementales y evolutivos.
RESPETA EL PROCESO ACTUAL, INCLUIDOS LOS ROLES, LAS RESPONSABILIDADES Y LOS CARGOS
Kanban trata de ser respetuoso con la organización y no te exige que cambies la misma, ni el cargo de sus miembros, así como tampoco sus responsabilidades.
ANIMA AL LIDERAZGO EN TODOS LOS NIVELES
Kanban trata de que cada miembro del equipo (ya sea desde el miembro de más alta jerarquía hasta el último de los becarios) adquiera liderazgo, promoviendo que todo el mundo contribuya con ideas, recomendaciones, autoformación y cualquier otro tipo de actividad que sea positiva para el devenir del proyecto.
La idea es que no te dediques sólo a hacer lo que te manden, sino que des un paso más y te centres también en qué es lo mejor para la empresa en su conjunto.
CÓMO FUNCIONA KANBAN
Vale, una cosa es cómo funciona Kanban en un proceso industrial y otra cosa es cómo funciona en el día a día en un equipo de desarrollo.
Respecto al día a día, me atrevería a decir que cada empresa adapta el tablero Kanban a su modus operandi habitual. Eso no es malo ni bueno, simplemente es que el kanban puro, el industrial, es demasiado complejo para la estructura de una pyme, por lo que se suele rebajar un tanto la complejidad de esta metodología. Si os habéis fijado en los principios de Kanban, uno de ellos trataba del hecho de que se respetan las estructuras y roles actuales de la compañía. Esto nos invita a no tener que hacer un esfuerzo grande de adaptación a esta metodología.
Así pues, hablemos de cómo podría funcionar Kanban en una empresa que se dedica a desarrollar software. Aquí he metido algún elemento que os recordará a Scrum, pero que considero que nos ayuda a trabajar mejor con Kanban.
Luego, para los más curiosos, explicaré un poco cómo funciona el Kanban “complejo”, pero sin entrar en todos sus detalles.
PASO 1. NOS REUNIMOS PARA CREAR LA LISTA DE REQUISITOS
El jefe o responsable del proyecto, junto con el cliente se encargarán de poner en una lista todo aquello necesitan que se incluya en el producto. Estos requisitos vendrán dados de la misma forma en que solemos tratar los requisitos normalmente, Kanban no te obliga a documentarlos de ninguna manera concreta.
Si me lo permitís, yo daría los requisitos en forma de historias de usuario (Scrum) o bien con suposiciones e hipótesis (Lean Startup).
Una vez tengamos la lista, tendremos que priorizar la misma, asumiendo qué tareas son las primeras en desarrollarse (por lógica o por riesgo).
PASO 2. CREAMOS UN TABLERO KANBAN VACÍO (O VARIOS)
Ahora vamos a crear un tablero Kanban. Este tablero tendrá una serie de columnas que especificarán el estado de cada tarea que vayamos a introducir. Dependiendo de cómo trabajes, las columnas podrían definir distintos estados. Por ejemplo, un Kanban muy básico sería el clásico de tres columnas:
- ToDo: tareas pendientes de abordar.
- Doing: tareas que se están haciendo en estos momentos.
- Done: tareas que ya hemos finalizado.
Pero puede que tu flujo de trabajo habitual requiera de más estados, por lo que tu tablero podría incluir los mismos siempre y cuando sean secuenciales, es decir, que una tarea necesite ir pasando de un estado a otro hasta llegar a su estado de finalizado.
En mi caso, pondría cinco columnas:
- Stories: estas son las tareas. Aquí se acumulan antes de entrar en ToDo. ¿Por qué no meterlas directamente en el ToDo? Porque puede que no sea el momento, ya que una tarea puede depender de otra, o porque no queremos atiborrar la columna ToDo.
- ToDo: tareas pendientes de abordar.
- Doing: tareas que se están haciendo en estos momentos.
- Testing: tareas que está testeando el equipo de calidad.
- Done: tareas que ya hemos finalizado y testado.
La prioridad de las tareas vendrá definida por el orden en que las coloquemos. Una tarea situada encima de otra será más importante y deberíamos intentar abordarla primero.
También podemos usar colores en las tareas para identificar su dificultad (o su duración estimada, si es algo que tenemos claro).
Si tenemos un equipo multidisciplinar, puede haber más de un tablero canvas. Por ejemplo, si tenemos un equipo de desarrollo de software y otro de diseño, cada uno puede tener su propio tablero, o bien pueden incluirse nuevas columnas en el tablero actual para que queden reflejados todas las acciones que vamos a realizar sobre cada tarea.
PASO 3. COLUMNA STORIES
Metemos en la columna Stories aquellas tareas/requisitos que habíamos acordado en el paso uno.
PASO 4. DETERMINAMOS LÍMITES DEL TRABAJO EN CURSO
Según los recursos de los que dispongamos, vamos a limitar el número de tareas que puede haber en cada columna. Por ejemplo, si tenemos dos desarrolladores a lo mejor no queremos que haya más de 4 tareas en la columna ToDo. Sin embargo, si tenemos a seis personas en el departamento de control de calidad, ahí sí que podemos dejar que el límite de la columna Testing sea más alto.
Aquí es bueno, normalmente, el poner unos límites más altos que el número de personas que se encarga de la tarea. Imaginad que una tarea, por lo que sea, nos bloquea. Así siempre podríamos dejarla en su sitio y coger otra, evitando quedarnos sin trabajo.
PASO 5. RELLENAMOS LA COLUMNA TODO
Rellenamos la columna ToDo con los requisitos a los que consideramos que ya se pueden abordar ( aquellos que queremos que se desarrollen inmediatamente), teniendo en cuenta los límites que habíamos acordado en el paso tres.
Aquí debemos, también, documentar qué tareas hemos puesto en ToDo y la fecha y hora exacta en que lo hicimos.
Inmediatamente después, nos reunimos con el equipo y explicamos cada tarea de la lista ToDo, permitiendo todas las preguntas necesarias para aclarar cada requisito.
PASO 6. EMPEZAMOS A TRABAJAR EN LAS TAREAS
Cada miembro del equipo empieza a trabajar en cadena. Las tareas pasarán del ToDo al Doing, luego al Testing y finalmente al Done (suponiendo que no hayamos incluido más columnas de por medio).
PASO 7. REUNIÓN DIARIA
Cada día tenemos, a primera hora, una reunión de 15 o 30 minutos donde cada miembro del equipo da a conocer los siguientes datos:
- Qué hizo ayer.
- Qué piensa hacer hoy.
- Con qué problemas se ha topado.
El objeto de esto no es otro que el de poder actuar rápidamente en caso de que un miembro del equipo tenga algún impedimento o vaya con retraso.
PASO 8. REFLEJAR CUÁNDO HEMOS ACABADO UNA TAREA
Cada vez que alguien acaba una tarea, deja reflejado el algún documento la fecha y hora. A esto se lo denomina Lead Time, y esto nos servirá para tener el dato de cuánto nos cuesta cada tarea.
Además, debe avisar al responsable del proyecto para que éste se asegure de que siempre hay tareas en la columna ToDo y nadie se queda parado.
PASO 9. BUCLE
Seguimos trabajando (repetimos desde el apartado seis) hasta que toque hacer una entrega al cliente. Una vez hecha, los responsables del proyecto se reúnen con el cliente y sacan conclusiones sobre la satisfacción del mismo. Esto nos ayudará a ir mejorando el proceso.
Como veis, Kanban, que realmente es el tablero, más que una metodología, es un método que nos permite gestionar tareas de forma progresiva, impidiendo que se acumule o falte trabajo.
Alguno se habrá dado cuenta de que el tablero Kanban se puede utilizar para cualquier cosa, desde un proyecto de software hasta tareas personales. Efectivamente, de hecho, ya usamos sistemas similares en nuestro día a día, sólo que algo más simplificados.
LAS VENTAJAS DE USAR KANBAN
Después de todo lo que hemos visto, podemos enumerar algunas de las ventajas que obtendrías si trabajaras con tableros kanban.
- Se evita la producción excesiva. Los tableros nos obligan a llevar un índice de producción óptimo, pues se buscar que no haya ni cuellos de botella ni falta de trabajo.
- Es necesario destinar menos tiempo la planificación.
- Nos dota de de una mayor flexibilidad, ya que estamos trabajando sobre un stock de tareas o requisitos poco a poco, módulo a módulo, lo que permite que estos requisitos puedan mutar o evolucionar.
- Queda más claro qué está haciendo cada miembro de equipo y cómo vamos en el proyecto.
- Aumenta la implicación del equipo.
CONCLUSIONES
Estas conclusiones son totalmente subjetivas y personales. Bajo mi punto de vista, el tablero Kanban funciona bien en procesos reiterativos que no son excesivamente complejos. Por ejemplo, para el mantenimiento de tu servicio.
Se puede usar en desarrollos de todo tipo de ámbito, por supuesto, pero exige que el jefe del proyecto haga un gran trabajo a la hora de crear las tareas y sus asignaciones.
Mi forma personal de mejorarlo es, como habréis visto antes, mezclarlo con Scrum, pero si el proyecto es demasiado grande o complejo, yo optaría por usar un diagrama de Gantt antes de usar un Kanban.
Pero vamos, que es una herramienta genial. Lo único que digo es que no es obligatorio usarla si el tipo de proyecto no es el adecuado.
HERRAMIENTAS CON LAS QUE PUEDO HACER UN TABLERO KANBAN
Hay multitud de herramientas con las que puedes montar tu propio Kanban, ni siquiera hace falta que sean especializadas. Una hoja de cálculo de Googledocs te vale. Tan sólo has de poner las columnas adecuadas y rellenar las celdas con estados o colores.
Sin embargo, si quieres algo más orientado, se me ocurren varias alternativas:
- Trello: la más famosa y de las pocas que tiene un plan gratuito.
- Kambanize: especializada en Kanban pero de pago.
- Zenhub: de pago.
- Monday: no es específica para Kanban pero es tan extremadamente versátil que te valdría para casi todo, entre ello para crear tableros Kanban. Lo malo: es de pago.
- Airtable: no es específica para Kanban pero su sistema basado en columnas te permite crear tableros de forma muy sencilla. Además, con el plan gratuito puedes tirar perfectamente.
¿Y EL KANBAN «INDUSTRIAL»?
Muy bien, y esto ya va para los curiosos: ¿cómo funciona realmente la estructura Kanban cuando se usa en un entorno industrial con su planteamiento original?
Voy a explicarlo brevemente. No lo conozco tan en profundidad como me gustaría, por lo que no entraré en detalle.
En la siguiente imagen vais a poder a ver el ciclo de reuniones en Kanban, o lo que normalmente se denomina cadencias.
REPLENISHMENT MEETING
Se cada semana. El objeto de esta reunión es establecer prioridades y seleccionar cuales son las siguientes tareas a abordar. Aquí es donde meteríamos la tarea en la columan Stories.
DAILY KANBAN
Se da cada día. Es una reunión en la que los miembros del equipo de un sistema o parte de un sistema evalúan el trabajo en curso.
Aquí veremos los problemas con los que nos encontramos y trataremos de darle solución.
SERVICE DELIVERY REVIEW
Esta reunión, cuya fecha depende de cuándo se entregue software al cliente, busca comparar las expectativas del cliente y el producto entregado. Se enfoca en verificar el desempeño del equipo contra compromisos, calidad, tiempo de entrega, etc.
Vamos, un control de calidad de nuestro servicio de toda la vida.
DELIVERY PLANNING MEETING
Esta reunión se produce a demanda para revisar y planificar nuestras entregas al cliente. A diferencia del Service Delivery Review es que, mientras esta se orienta a planificar actividades de entrega, la anterior se orientaba a examinar y mejorar el servicio que estamos dando.
STRATEGY REVIEW
Esta es la reunión de más alto nivel. Se trata de revisar y ajustar la estrategia comercial general basada en los comentarios de los clientes y los cambios del mercado. También analiza las capacidades organizativas y los principales objetivos comerciales.
Es decir, los jefes (jefazos) se reúnen para hablar de la estrategia de la compañía, teniendo en cuenta aspectos externos como los cambios del mercado y aspectos internos como las operaciones del equipo.
OPERATIONS REVIEW
El objetivo de esta reunión es analizar la eficiencia de los diferentes equipos y la organización en su conjunto. Aquí se revisa la demanda y la capacidad de cada equipo Kanban, enfocándose en las dependencias y sus efectos. También es un buen momento para identificar cualquier capacidad infrautilizada a través de la organización que pueda mejorar los plazos de entrega.
RISK REVIEW
El objetivo de esta reunión es identificar riesgos y cuellos de botella antes de que afecten sustancialmente el flujo de trabajo para, luego, tomar las medidas necesarias para mitigar esos riesgos.
Para explorar más sobre cómo manejar eficazmente tareas y proyectos en entornos ágiles, te recomendamos leer nuestro artículo complementario sobre tipos y flujos de tareas en proyectos Agile. Este post te proporcionará una visión detallada de las diversas clases de tareas que puedes encontrar y cómo los flujos de trabajo Agile pueden ser optimizados para mejorar la entrega de proyectos y la eficiencia del equipo.
