¿Qué es Kanban?
Kanban es una metodología ágil basada en visualizar el trabajo, limitar el trabajo en progreso y optimizar el flujo. A diferencia de Scrum, Kanban no usa sprints con time-box. En su lugar, los items de trabajo fluyen continuamente a través de una serie de etapas desde “Por Hacer” hasta “Hecho”.
La palabra “Kanban” proviene del japonés y significa “señal visual” o “tarjeta”. La metodología se originó en el sistema de manufactura de Toyota en los años 1940 y fue adaptada para desarrollo de software por David J. Anderson en los años 2000.
Para ingenieros QA, Kanban ofrece una forma fundamentalmente diferente de trabajar comparada con Scrum. Entender ambas te ayuda a adaptarte a cualquier entorno de equipo.
Principios Fundamentales de Kanban
1. Visualizar el Flujo de Trabajo
Todo lo que el equipo está haciendo es visible en el tablero Kanban. Cada tarjeta representa un item de trabajo, y su posición en el tablero muestra su estado actual.
2. Limitar el Trabajo en Progreso (WIP)
Cada columna en el tablero tiene un número máximo de items permitidos. Este es el límite WIP. Cuando una columna está llena, no pueden entrar nuevos items hasta que los existentes avancen.
3. Gestionar el Flujo
El objetivo es un flujo suave y predecible de trabajo a través del sistema. Items bloqueados, cuellos de botella y colas largas son señales de que algo necesita atención.
4. Hacer Políticas Explícitas
Las reglas para mover items entre columnas están escritas y visibles. Por ejemplo: “Un item solo puede moverse a ‘Testing’ cuando un desarrollador lo marca como code-complete y los unit tests pasan.”
5. Implementar Ciclos de Feedback
Reuniones regulares (standups, reviews, retrospectivas) proporcionan feedback sobre cómo funciona el proceso.
6. Mejorar Colaborativamente
El equipo busca continuamente formas de mejorar el flujo de trabajo basándose en datos (cycle time, lead time, throughput).
El Tablero Kanban con QA
Un tablero Kanban para un equipo de software con actividades de QA dedicadas se ve así:
WIP: 3] B --> C[Desarrollo
WIP: 4] C --> D[Code Review
WIP: 2] D --> E[QA Testing
WIP: 3] E --> F[UAT
WIP: 2] F --> G[Hecho] end style A fill:#E0E0E0 style B fill:#BBDEFB style C fill:#C8E6C9 style D fill:#FFF9C4 style E fill:#F8BBD0 style F fill:#D1C4E9 style G fill:#A5D6A7
Columnas clave de QA:
| Columna | Límite WIP | Rol de QA |
|---|---|---|
| Backlog | Ninguno | Revisar items próximos por testeabilidad |
| Análisis | 3 | Clarificar criterios de aceptación, identificar enfoque de testing |
| Desarrollo | 4 | Preparar casos de prueba, configurar datos de prueba |
| Code Review | 2 | Revisar cobertura de tests en code reviews |
| QA Testing | 3 | Ejecutar testing funcional, de regresión y exploratorio |
| UAT | 2 | Apoyar testing de aceptación de usuario, verificar correcciones |
| Hecho | Ninguno | Verificar que todos los criterios de calidad se cumplan |
Límites WIP y Por Qué Importan para QA
Los límites WIP son el corazón de Kanban. Sin ellos, solo tienes una lista de tareas elegante.
Cómo los Límites WIP Previenen Cuellos de Botella en QA
Considera este escenario sin límites WIP:
- Los desarrolladores completan 8 features en una semana
- QA puede probar 4 features en una semana
- La columna QA Testing crece 4 items cada semana
- Después de un mes, QA tiene un backlog de 16 features sin probar
Esto es un cuello de botella. El trabajo se acumula antes de QA, y el throughput general del equipo está limitado por la capacidad de testing.
Con límites WIP:
- La columna QA Testing tiene un límite WIP de 3
- Cuando hay 3 items en testing, los desarrolladores no pueden empujar más items a Code Review
- Esto obliga a los desarrolladores a ayudar con testing, corregir bugs o mejorar la automatización
- El cuello de botella se hace visible inmediatamente, no después de un mes
Punto clave: Los límites WIP no desaceleran al equipo. Revelan dónde el equipo ya es lento. Si la columna QA siempre está llena, el equipo necesita más capacidad de testing — no un límite WIP más alto.
Establecer el Límite WIP Correcto para QA
Un buen punto de partida para el límite WIP de tu columna QA Testing:
| Tamaño del Equipo | Ingenieros QA | Límite WIP Sugerido |
|---|---|---|
| 3-5 personas | 1 QA | 2-3 items |
| 5-8 personas | 2 QA | 3-4 items |
| 8-12 personas | 3 QA | 4-5 items |
Comienza conservador y ajusta basándote en datos. Si la columna QA raramente está llena, baja el límite. Si los items frecuentemente esperan antes de QA, el límite podría estar bien pero necesitas más capacidad.
Testing Basado en Flujo
En Kanban, el testing no es una fase — es parte del flujo. Esto significa:
Probar Cuando Esté Listo, No por Calendario
En Scrum, el testing ocurre dentro de un sprint. En Kanban, pruebas un item tan pronto como entra en la columna QA Testing. No hay un “fin de sprint” presionándote para apresurarte.
Enfócate en Un Item a la Vez
Con límites WIP, te enfocas en menos items simultáneamente. Esto reduce el cambio de contexto y mejora la calidad del testing. Probar un feature a fondo es mejor que probar tres features superficialmente.
Pull, No Push
QA toma trabajo de la columna Code Review cuando está listo, en lugar de que los desarrolladores empujen trabajo a QA. Esto te da control sobre tu carga de trabajo y previene la sobrecarga.
Medir Cycle Time para Testing
Rastrea cuánto tiempo pasan los items en la columna QA Testing. Este es tu cycle time de testing. Si está aumentando, señala un problema:
- Los items están creciendo en complejidad
- Los entornos de prueba son inestables
- Los requisitos no están claros, causando ida y vuelta
Kanban vs Scrum: Perspectiva de QA
| Aspecto | Scrum | Kanban |
|---|---|---|
| Estructura temporal | Sprints fijos (1-4 semanas) | Flujo continuo |
| Cadencia de testing | Dentro de los límites del sprint | Continua, según fluyen los items |
| Planificación | Sprint Planning cada 1-4 semanas | Just-in-time, según la capacidad |
| Roles | PO, SM, Dev Team (con QA) | Sin roles prescritos |
| Métricas | Velocity, sprint burndown | Lead time, cycle time, throughput |
| Releases | Al final del sprint | En cualquier momento que un item llegue a Done |
| Mejor para QA cuando | El equipo necesita estructura y ritmo | El equipo necesita flexibilidad y entrega rápida |
Cuándo Elegir Kanban
Kanban funciona mejor para QA cuando:
- Corrección de bugs: Los bugs llegan impredeciblemente. Un sistema basado en flujo maneja esto naturalmente.
- Equipos de mantenimiento: El trabajo de soporte continuo no encaja en time-boxes de sprint.
- Múltiples prioridades: Los stakeholders cambian prioridades frecuentemente.
- Despliegue continuo: Los features salen a producción individualmente, no en lotes.
Cuándo Elegir Scrum
Scrum funciona mejor para QA cuando:
- Desarrollo de producto nuevo: El equipo se beneficia de sprint goals y esfuerzo enfocado.
- Features complejos: Sprint planning ayuda a coordinar testing de features interrelacionados.
- Construcción de equipo: Las ceremonias de Scrum construyen cohesión y comunicación.
Métricas Kanban para QA
Lead Time
Tiempo desde que se solicita un item de trabajo hasta que se entrega. QA contribuye al lead time a través de la duración del testing.
Cycle Time
Tiempo desde que se comienza a trabajar en un item hasta que está hecho. La porción de testing del cycle time está directamente bajo tu control.
Throughput
Número de items completados por período de tiempo (generalmente por semana). Rastrea el throughput específico de QA: cuántos items pasan por la columna QA Testing por semana.
Diagrama de Flujo Acumulativo
Este gráfico muestra el número de items en cada etapa a lo largo del tiempo. Revela cuellos de botella visualmente:
ensancha con el tiempo] --> B[Testing es un cuello de botella] B --> C[Soluciones: automatización,
más capacidad QA,
shift-left testing]
Ejercicio: Diseñar un Tablero Kanban para un Equipo de QA
Eres el QA lead de un equipo de 7 personas (4 desarrolladores, 2 ingenieros QA, 1 product manager). El equipo mantiene una plataforma de e-commerce en vivo y maneja tanto desarrollo de nuevos features como corrección de bugs en producción.
Problemas actuales:
- QA siempre está sobrecargado — 10+ items esperando testing en cualquier momento
- Las correcciones de bugs tardan 5+ días en llegar a producción
- Los desarrolladores comienzan nuevos features mientras sus features anteriores esperan QA
- No hay visibilidad sobre en qué está trabajando QA actualmente
Tu tarea:
Diseña un tablero Kanban que incluya:
- Nombres de columnas y límites WIP para cada columna
- Cómo las correcciones de bugs se manejan diferente a los features (carril expedite o clase de servicio separada)
- Políticas para mover items entre columnas (especialmente entrando y saliendo de QA Testing)
- Qué métricas rastrearías y por qué
- Cómo manejarías la transición inicial desde el estado actual sobrecargado
Pista
Considera estas decisiones de diseño:
- Un carril “Expedite” (o swimlane) sin límite WIP permite que bugs urgentes pasen por encima del flujo normal
- Podrías dividir QA Testing en sub-columnas: “En Testing” y “Probado” para mostrar progreso
- Políticas explícitas previenen discusiones: define qué significa “listo para QA”
- Para manejar el backlog inicial de 10+ items, podrías necesitar una estrategia temporal de “drenaje”
- Piensa en items bloqueados: ¿qué pasa cuando QA encuentra un bug? ¿El item regresa a Desarrollo?
Solución de Ejemplo
Diseño del Tablero Kanban
Layout del Tablero:
| Carril | Backlog | Ready | Dev (WIP: 4) | Review (WIP: 2) | QA Testing (WIP: 3) | QA Passed | Release (WIP: 2) | Done |
|---|---|---|---|---|---|---|---|---|
| Expedite | — | — | Sin límite WIP | Sin límite WIP | Sin límite WIP | — | Sin límite WIP | — |
| Features | Items | Items refinados | Dev activo | Code review | En Testing / Probado | Verificado | Desplegando | Live |
| Bugs | Items | Triageados | Corrigiendo | Review | Verificación | Verificado | Desplegando | Live |
Límites WIP:
- Dev: 4 (uno por desarrollador)
- Code Review: 2 (previene backlog de revisión)
- QA Testing: 3 (manejable para 2 ingenieros QA, ~1.5 items cada uno)
- Release: 2 (previene conflictos de deployment)
- Carril Expedite: Sin límites pero rastreado por separado
Políticas de Columnas:
Ready → Dev:
- Criterios de aceptación definidos y aprobados por PM
- QA ha revisado el story por testeabilidad
- Enfoque de testing documentado (aunque sea breve)
Dev → Code Review:
- Código completo con unit tests
- Cobertura de unit tests ≥ 80% para código nuevo
- Dev ha hecho self-testing del happy path
Code Review → QA Testing:
- Code review aprobado por al menos un par
- Feature desplegado en entorno de staging/test
- Desarrollador provee notas de testing (qué cambió, en qué enfocarse)
QA Testing → QA Passed:
- Todos los criterios de aceptación verificados
- Testing exploratorio completado
- Sin bugs abiertos críticos o de alta severidad
- Tests de regresión pasando
Métricas a Rastrear:
- Cycle time por tipo: Features vs. bugs — para asegurar que los bugs se corrijan rápido
- Cycle time de QA testing: Tiempo promedio en QA Testing — para detectar problemas de capacidad
- Throughput por semana: Items completados — para rastrear capacidad del equipo
- Tasa de bugs escapados: Bugs encontrados en producción vs. capturados en QA
- Tiempo de bloqueo: Frecuencia y duración de items bloqueados — para identificar problemas sistémicos
Estrategia de Transición:
- Semana 1: Aplicar límites WIP. Items ya en progreso se mantienen.
- Semana 2-3: A medida que items terminan, el tablero se normaliza. No iniciar nuevos items hasta que WIP esté bajo los límites.
- Semana 4: Revisar datos de cycle time. Ajustar límites WIP si es necesario.
- Continuo: Revisión semanal del diagrama de flujo acumulativo para detectar tendencias.
Prácticas Avanzadas de Kanban para QA
Clases de Servicio
No todos los items de trabajo son iguales. Kanban usa “clases de servicio” para manejar diferentes prioridades:
| Clase | Ejemplo | Tratamiento QA |
|---|---|---|
| Expedite | Caída en producción | Dejar todo, probar inmediatamente, regresión enfocada |
| Fecha Fija | Deadline regulatorio | Planificar testing temprano, sin retrasos permitidos |
| Estándar | Features regulares | Flujo normal a través del tablero |
| Intangible | Deuda técnica, refactoring | Probar cuando haya capacidad, menor prioridad |
Swarming
Cuando la columna QA alcanza su límite WIP y los items se acumulan, el equipo puede hacer “swarming” — los desarrolladores ayudan temporalmente con el testing. Este es uno de los mecanismos más poderosos de Kanban para resolver cuellos de botella.
Cómo pueden ayudar los desarrolladores:
- Ejecutar casos de prueba predefinidos
- Realizar testing a nivel de código (tests de integración, tests de API)
- Preparar datos o entornos de prueba
- Hacer pair-testing con ingenieros QA
Cadencias Kanban (Reuniones)
Kanban no prescribe reuniones específicas, pero la mayoría de equipos usan estas:
| Cadencia | Frecuencia | Enfoque QA |
|---|---|---|
| Daily standup | Diaria | Reportar items bloqueados, tomar nuevo trabajo |
| Reunión de reabastecimiento | Semanal | Revisar items próximos por testeabilidad |
| Review de entrega | Semanal/quincenal | Revisar métricas de calidad, tendencias de cycle time |
| Retrospectiva | Mensual | Mejorar flujo de testing, atender cuellos de botella |
Consejos Pro para QA en Kanban
Rastrea tu cycle time de testing religiosamente. Si el tiempo promedio de los items en QA Testing aumenta semana tras semana, plantealo inmediatamente. No esperes hasta que el backlog sea inmanejable.
Crea criterios explícitos de “listo para QA”. El mayor desperdicio en Kanban es tomar un item para testing solo para descubrir que no está realmente listo. Define criterios mínimos (desplegado en entorno de pruebas, unit tests pasando, notas de dev proporcionadas).
Usa sub-columnas dentro de QA Testing. Divide en “En Testing” y “Probado, Esperando Verificación” para mostrar progreso dentro de la etapa QA.
Automatiza testing de regresión. En Kanban, pruebas items continuamente. Ejecutar una regresión manual completa por cada item no es sostenible. Automatiza la suite de regresión para enfocarte en la funcionalidad nueva.
Visualiza items bloqueados. Cuando un test falla y el item regresa a desarrolladores, márcalo como bloqueado (bandera roja en la tarjeta). Esto hace visible el retrabajo y ayuda a identificar patrones.