La teoría es útil, pero la práctica lo es todo. En este capítulo, pondremos en acción los conceptos de Kanban a través de un ejemplo concreto y fácil de seguir. Usaremos una herramienta gratuita y popular, Trello, para ilustrar el proceso.
El Escenario: Imaginemos un pequeño equipo encargado de mantener y mejorar un sitio web. El equipo está compuesto por:
- David: El Product Manager, que también se encarga de las pruebas finales (QA).
- Ana: La diseñadora UI/UX.
- Ben y Carla: Dos desarrolladores.
Su próximo gran proyecto es añadir una sección de blog al sitio web. Deciden usar Kanban para gestionar el flujo de trabajo.
11.1. Creación de un tablero Kanban simple en Trello
El primer paso es crear un espacio de trabajo visual. David inicia sesión en Trello, crea un nuevo "Tablero" y lo nombra "Proyecto Blog". Invita a Ana, Ben y Carla. En menos de cinco minutos, el esqueleto de su sistema Kanban está listo. La simplicidad es una de las grandes ventajas de estas herramientas: el foco está en el flujo, no en la configuración.
11.2. Definición de columnas y límites WIP
Ahora viene la parte más importante: definir el flujo de trabajo. El equipo se reúne y acuerda las etapas por las que pasará cada tarea. Deciden crear las siguientes columnas (listas en Trello):
- Backlog: Aquí irán todas las ideas y tareas en bruto. No hay límite.
- Por Hacer (Priorizado): Tareas refinadas y listas para ser trabajadas.
- Diseño UI/UX: Tareas que requieren el trabajo de Ana.
- En Desarrollo: Tareas que están siendo codificadas por Ben o Carla.
- En Pruebas (QA): Tareas terminadas por los desarrolladores y listas para la revisión de David.
- Hecho: ¡Trabajo completado y entregado!
Luego, discuten los límites de Trabajo en Progreso (WIP). David explica que esto es crucial para evitar el caos y enfocarse en terminar. Acuerdan lo siguiente:
- Diseño UI/UX (WIP: 1): Ana es una sola persona, por lo que solo puede trabajar en una cosa a la vez.
- En Desarrollo (WIP: 2): Con dos desarrolladores, un límite de 2 les obliga a terminar su trabajo actual antes de empezar algo nuevo. Fomenta la colaboración si uno de ellos se atasca.
- En Pruebas (QA) (WIP: 1): David es el único que realiza las pruebas finales.
En Trello, pueden añadir estos límites usando un "Power-Up" gratuito llamado "List Limits", que mostrará una advertencia visual si una columna excede su límite.
11.3. Carga inicial de tareas (cards)
Con el tablero listo, el equipo realiza una lluvia de ideas y llena la columna "Backlog" con tarjetas (cards) que representan las piezas de trabajo. Crean tarjetas como:
- "Diseñar la maqueta de la página principal del blog"
- "Crear el esquema de la base de datos para los artículos"
- "Desarrollar la vista de un solo artículo"
- "Implementar un sistema de comentarios"
- "Añadir botones para compartir en redes sociales"
David, como Product Manager, prioriza las más importantes. Junto con el equipo, refina la tarjeta "Diseñar la maqueta...", añadiéndole una descripción más detallada y una checklist. Una vez que está lista, la mueve a la columna "Por Hacer (Priorizado)".
11.4. Seguimiento visual del flujo
Aquí es donde la magia de Kanban se hace visible. Veamos cómo transcurre la primera semana:
- Lunes: Ana ve la tarjeta de diseño en "Por Hacer" y la mueve a "Diseño UI/UX". La columna alcanza su límite WIP de 1. Ben y Carla, aunque están listos para trabajar, no tienen nada que hacer en el flujo principal. Aprovechan el tiempo para investigar una nueva librería que podrían usar para el sistema de comentarios.
- Martes: Ana termina el diseño, adjunta los archivos a la tarjeta y la mueve a la columna "En Desarrollo". La columna "Diseño UI/UX" queda libre. Ben inmediatamente toma la tarjeta y la pone bajo su nombre. Al mismo tiempo, Carla toma otra tarea que ya estaba priorizada, "Crear el esquema de la base de datos", y la mueve a "En Desarrollo". La columna alcanza su límite WIP de 2.
- Jueves: Ben termina de maquetar el diseño y mueve su tarjeta a "En Pruebas (QA)". David la toma para revisarla. La columna "En Pruebas" llega a su límite de 1. Poco después, Carla termina con la base de datos. Intenta mover su tarjeta a "En Pruebas", pero... ¡no puede! El límite WIP se lo impide.
11.5. Identificación de bloqueos y mejoras posibles
El tablero ha revelado un problema de forma visual e innegable. La tarjeta de Carla está terminada pero bloqueada. La columna "En Desarrollo" está vacía, pero no se puede empezar nuevo trabajo porque el flujo está atascado en la fase de pruebas. Se ha formado un cuello de botella.
En la reunión diaria del viernes, el equipo no busca culpables. La pregunta es: "¿Qué podemos hacer para que el flujo se mueva?".
- Solución a corto plazo: Carla, que no puede empezar una nueva tarea de desarrollo, se ofrece a ayudar a David. Revisa los criterios de aceptación con él y le ayuda a preparar los datos para las pruebas. Colaboran para mover la tarjeta de Ben a "Hecho" lo antes posible. Esto es Kanban en estado puro: el equipo se une para resolver el bloqueo.
- Mejora a largo plazo: En la siguiente reunión de retrospectiva, el equipo analiza el patrón. Se dan cuenta de que las pruebas manuales de David son un cuello de botella recurrente. Proponen un experimento (Ciclo PDCA): "A partir de ahora, cada nueva funcionalidad debe ir acompañada de tests automatizados escritos por los desarrolladores". Planean probar este nuevo enfoque durante las próximas semanas (Do), y luego revisarán las métricas (Check) para ver si el tiempo en la columna "En Pruebas" disminuye (Act).
Este simple ejemplo demuestra cómo los principios de Kanban —visualizar el trabajo, limitar el WIP y gestionar el flujo— guían de forma natural a un equipo no solo a hacer el trabajo, sino a mejorar continuamente su forma de hacerlo.