Kanban y la gestión del flujo

Kanban: hacer visible el trabajo

Mientras Scrum organiza en sprints, Kanban organiza el flujo continuo. Su corazón es el tablero: columnas que representan los estados del trabajo (por hacer → en desarrollo → en pruebas → listo) y tarjetas que se mueven de izquierda a derecha. Lo primero que aporta es visibilidad: de un vistazo, todo el equipo ve qué hay, dónde está atascado y quién está sobrecargado.

Límites de WIP: la clave

La regla más poderosa de Kanban son los límites de WIP (Work In Progress): un tope de cuántas tarjetas pueden estar en una columna a la vez.

Por hacer   | En desarrollo (máx 3) | En pruebas (máx 2) | Listo

El cuello de botella en el tablero

Para un QA, el tablero cuenta una historia. Si la columna "En pruebas" siempre está llena mientras "En desarrollo" sigue produciendo, el mensaje es claro: se desarrolla más rápido de lo que se prueba. La solución no es que el QA "vaya más rápido" (eso baja la calidad), sino ajustar el flujo: limitar el WIP aguas arriba, que el equipo ayude a probar, o automatizar la regresión que consume el tiempo del QA.

Kanban vs Scrum: cuándo cada uno

• Scrum encaja con trabajo planificable en sprints de alcance acordado (construir features).
• Kanban encaja con trabajo continuo e impredecible: soporte, mantenimiento, bugs que llegan sin aviso. No tiene sprints de alcance fijo; el trabajo fluye y se prioriza sobre la marcha.

Muchos equipos mezclan ambos ("Scrumban"). Lo importante para el QA es entender el flujo, hacerlo visible y usar los límites de WIP para que la calidad no se sacrifique por velocidad.

Comprueba lo aprendido en el quiz y diagnostica el tablero en el reto.