7 min lectura • Guide 665 of 877
Cómo Usar Columnas de Tablero Kanban y Límites WIP de GitScrum
Columnas Kanban y límites WIP bien diseñados transforman tu tablero de una simple lista de tareas en un sistema de optimización de flujo. La configuración flexible de tableros de GitScrum ayuda a los equipos a visualizar su flujo de trabajo, limitar trabajo en progreso y mejorar continuamente su proceso.
Diseño de Columnas del Tablero
Tablero de Desarrollo Estándar
TABLERO KANBAN BÁSICO DE DESARROLLO:
┌─────────────────────────────────────────────────────────────┐
│ BACKLOG │ LISTO │ EN PROGRESO │ REVIEW │ HECHO │
│ (sin lím.)│ (5) │ (4) │ (3) │ │
├───────────┼─────────┼─────────────┼─────────┼──────────────┤
│ │ │ │ │ │
│ □ Story 8 │ □ #125 │ ■ #122 │ ■ #118 │ ✓ #115 │
│ □ Story 9 │ □ #126 │ ■ #123 │ ■ #119 │ ✓ #116 │
│ □ Story 10│ □ #127 │ ■ #124 │ │ ✓ #117 │
│ □ Bug #46 │ │ │ │ │
│ □ Bug #47 │ │ WIP: 3/4 ✅ │ WIP:2/3 │ │
│ │ │ │ ✅ │ │
└───────────┴─────────┴─────────────┴─────────┴──────────────┘
PROPÓSITOS DE COLUMNA:
• Backlog: Todo trabajo aún no listo para comenzar
• Listo: Refinado, priorizado, puede comenzar inmediatamente
• En Progreso: Siendo trabajado activamente
• Review: Code review y testing
• Hecho: Completado y deployado
Tablero Avanzado con Sub-Columnas
TABLERO AVANZADO CON SUB-COLUMNAS:
┌─────────────────────────────────────────────────────────────┐
│ BACKLOG │ LISTO │ EN PROGRESO │ REVIEW │ HECHO │
│ │ │ HACIENDO│HECHO │ HACIENDO│HECHO│ │
├─────────┼───────┼─────────┼──────┼─────────┼─────┼─────────┤
│ │ │ │ │ │ │ │
│ □ #130 │ □ #128│ ■ #122 │◆ #120│ ■ #118 │◆#115│ ✓ #110 │
│ □ #131 │ □ #129│ ■ #123 │ │ ■ #119 │ │ ✓ #111 │
│ □ #132 │ │ │ │ │ │ ✓ #112 │
│ │ │ │ │ │ │ │
└─────────┴───────┴─────────┴──────┴─────────┴─────┴─────────┘
LEYENDA:
□ No comenzado ■ En progreso ◆ Hecho (esperando pull) ✓ Completo
POR QUÉ SUB-COLUMNAS:
Sub-columnas "Hecho" muestran trabajo esperando siguiente etapa.
Revela demoras de handoff entre etapas del flujo.
Tablero Integrado con QA
TABLERO DESARROLLO + QA:
┌─────────────────────────────────────────────────────────────┐
│BACKLOG│LISTO│DEV │CODE │QA │STAGING │HECHO │
│ │ │ │REVIEW │TESTING │ │ │
├───────┼─────┼───────┼───────┼────────┼────────┼────────────┤
│ │ │ │ │ │ │ │
│ □ #140│□#138│ ■ #135│ ■ #132│ ■ #128 │ ■ #125 │ ✓ #120 │
│ □ #141│□#139│ ■ #136│ ■ #133│ ■ #129 │ │ ✓ #121 │
│ □ #142│ │ │ │ ■ #130 │ │ ✓ #122 │
│ │ │ │ │ │ │ │
│ │(4) │ (3) │ (3) │ (4) │ (2) │ │
└───────┴─────┴───────┴───────┴────────┴────────┴────────────┘
LÍMITES WIP POR COLUMNA:
• Listo: 4 (mantiene trabajo fluyendo sin acumulación)
• Dev: 3 (enfoque en completar, no comenzar)
• Code Review: 3 (previene cuello de botella de review)
• QA Testing: 4 (permite lotes de testing)
• Staging: 2 (limita trabajo no liberado)
Estrategia de Límites WIP
Estableciendo Límites WIP
GUÍAS DE LÍMITES WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FÓRMULA INICIAL: │
│ Límite WIP = (Miembros del equipo para esa etapa) × 1.5 │
│ │
│ EJEMPLO: │
│ Equipo: 4 desarrolladores, 1 QA │
│ • En Progreso WIP: 4 × 1.5 = 6 (redondear a 6) │
│ • Code Review WIP: 4 × 0.5 = 2 (todos hacen review) │
│ • QA Testing WIP: 1 × 2 = 2 (buffer para QA) │
│ │
│ SEÑALES DE AJUSTE: │
│ │
│ WIP MUY ALTO: │
│ • Trabajo queda inactivo entre etapas │
│ • Cambio de contexto aumenta │
│ • Lead time creciendo │
│ → Bajar el límite │
│ │
│ WIP MUY BAJO: │
│ • Miembros del equipo frecuentemente inactivos │
│ • Trabajo bloqueado en items individuales │
│ • Sin flujo en absoluto │
│ → Subir el límite ligeramente │
└─────────────────────────────────────────────────────────────┘
Aplicación de Límites WIP
COMPORTAMIENTOS DE LÍMITE WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INDICADORES VISUALES: │
│ │
│ Bajo límite: [3/5] ██████████░░░░░░░░░░ Verde │
│ En límite: [5/5] ████████████████████ Amarillo │
│ Sobre límite: [7/5] ████████████████████ Rojo + Alerta │
│ │
│ CUANDO SE ALCANZA EL LÍMITE: │
│ │
│ ✓ HACER: │
│ • Ayudar a terminar trabajo existente │
│ • Colaborar en items bloqueados │
│ • Abordar cuellos de botella upstream │
│ • Pair programming en items complejos │
│ │
│ ✗ NO HACER: │
│ • Comenzar nuevo trabajo de todos modos │
│ • Mover items hacia atrás │
│ • Subir límite sin discusión │
│ │
│ POLÍTICA DE EXCEPCIÓN: │
│ Bugs críticos/emergencia pueden exceder límite │
│ Equipo debe reconocer y trackear excepciones │
└─────────────────────────────────────────────────────────────┘
Optimización de Flujo
Detección de Cuellos de Botella
IDENTIFICANDO CUELLOS DE BOTELLA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANÁLISIS DE TIEMPO DE ESPERA POR COLUMNA: │
│ │
│ Listo ██░░░░░░░░░░░░░░░░░░░░░░░░ 0.5 días prom │
│ En Progreso ████████░░░░░░░░░░░░░░░░░░ 2.0 días prom │
│ Code Review ████████████████████░░░░░░ 4.0 días prom ⚠️ │
│ QA Testing ██████░░░░░░░░░░░░░░░░░░░░ 1.5 días prom │
│ Staging ██░░░░░░░░░░░░░░░░░░░░░░░░ 0.5 días prom │
│ │
│ CUELLO DE BOTELLA: Code Review │
│ │
│ OPCIONES DE MEJORA: │
│ • Bloques de tiempo dedicados a review │
│ • Review antes de trabajo nuevo │
│ • Pair programming (reduce necesidad de review) │
│ • Checks automatizados antes de review humano │
│ • Cross-training de más reviewers │
└─────────────────────────────────────────────────────────────┘
Métricas de Columna
MÉTRICAS DE FLUJO KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LEAD TIME: Tiempo total desde Listo hasta Hecho │
│ Actual: 8.5 días (objetivo: 7 días) │
│ │
│ CYCLE TIME: Tiempo trabajado activamente (Progreso + Review)│
│ Actual: 3.5 días │
│ │
│ WAIT TIME: Lead Time - Cycle Time │
│ Actual: 5.0 días (indica tiempo en cola) │
│ │
│ THROUGHPUT: Items completados por semana │
│ Actual: 12 items/semana │
│ │
│ EFICIENCIA DE FLUJO: │
│ (Cycle Time / Lead Time) × 100 │
│ Actual: (3.5 / 8.5) × 100 = 41% │
│ Objetivo: >50% │
│ │
│ INSIGHT: Alto wait time sugiere problemas de cola │
│ Enfócate en reducir tiempo en "Listo" y entre etapas │
└─────────────────────────────────────────────────────────────┘
Personalización del Tablero
Tipos de Columnas
OPCIONES DE CONFIGURACIÓN DE COLUMNAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ COLUMNAS DE COLA (pull desde): │
│ • Sin límite WIP o límite alto │
│ • Items esperan aquí por capacidad │
│ • Ejemplos: Backlog, Listo │
│ │
│ COLUMNAS DE TRABAJO (trabajo activo): │
│ • Límites WIP estrictos │
│ • Items trabajados activamente │
│ • Ejemplos: En Progreso, Code Review │
│ │
│ COLUMNAS BUFFER (handoff): │
│ • Límite WIP pequeño │
│ • Trabajo esperando siguiente etapa │
│ • Ejemplos: "Dev Done", "Listo para QA" │
│ │
│ COLUMNAS HECHO (completado): │
│ • Sin límite WIP │
│ • Archivar trabajo completado │
│ • Puede tener sub-estado "deployado" │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Columnas que reflejan flujo real no proceso ideal
- Límites WIP que crean tensión sin bloquear
- Sub-columnas para revelar esperas entre etapas
- Métricas para optimización continua
- Revisar y ajustar regularmente
- Visualizar todo el trabajo incluyendo interrupciones