7 min lectura • Guide 673 of 877
Implementando Límites WIP
Los límites de trabajo en progreso son el motor de la optimización de flujo en Kanban. Cuando se implementan correctamente, los límites WIP reducen cambio de contexto, revelan cuellos de botella y ayudan a los equipos a enfocarse en terminar trabajo en vez de empezar nuevas tareas. GitScrum proporciona límites WIP configurables con aplicación visual.
Fundamentos de Límites WIP
Por Qué Funcionan los Límites WIP
IMPACTO DE LÍMITES WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SIN LÍMITES WIP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ EN PROGRESO: 12 items (sin límite) ││
│ │ ││
│ │ SÍNTOMAS: ││
│ │ • Todo empezado, nada terminado ││
│ │ • Alto cambio de contexto ││
│ │ • Entrega impredecible ││
│ │ • Cuellos de botella ocultos ││
│ │ • Cycle times largos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CON LÍMITES WIP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ EN PROGRESO: 4 items (límite: 5) ││
│ │ ││
│ │ BENEFICIOS: ││
│ │ • Enfoque en terminar ││
│ │ • Reducción de cambio de contexto ││
│ │ • Cuellos de botella visibles inmediatamente ││
│ │ • Flujo predecible ││
│ │ • Cycle times más cortos ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Ley de Little
LEY DE LITTLE EXPLICADA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FÓRMULA: │
│ │
│ Cycle Time = WIP / Throughput │
│ │
│ EJEMPLO: │
│ Equipo completa 10 items/semana (throughput) │
│ │
│ Escenario A: WIP = 20 │
│ Cycle Time = 20 / 10 = 2 semanas │
│ │
│ Escenario B: WIP = 10 │
│ Cycle Time = 10 / 10 = 1 semana │
│ │
│ INSIGHT: │
│ Menor WIP = Menor cycle time │
│ (asumiendo mismo throughput) │
│ │
│ Por esto los límites WIP aceleran la entrega │
└─────────────────────────────────────────────────────────────┘
Estableciendo Límites WIP
Guías Iniciales
FÓRMULAS PARA LÍMITES WIP INICIALES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ POR COLUMNA DE TRABAJO ACTIVO: │
│ Límite = Número de personas trabajando en esa etapa │
│ │
│ EJEMPLO - Equipo de 6: │
│ ├── 4 desarrolladores │
│ ├── 1 QA │
│ └── 1 tech lead (hace code review) │
│ │
│ LÍMITES SUGERIDOS: │
│ ├── Listo: 6 (buffer de trabajo preparado) │
│ ├── En Progreso: 4 (= desarrolladores) │
│ ├── Code Review: 2 (= reviewers activos) │
│ ├── QA: 2 (= QA × 2 para buffer) │
│ └── Deploy: 2 (controlar cambios simultáneos) │
│ │
│ AJUSTAR DESPUÉS DE 2-4 SEMANAS basándose en datos │
│ │
└─────────────────────────────────────────────────────────────┘
Señales de Ajuste
CUÁNDO AJUSTAR LÍMITES WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LÍMITE DEMASIADO ALTO (bajar): │
│ • Trabajo esperando mucho tiempo en columna │
│ • Items "olvidados" en progreso │
│ • Cycle time aumentando │
│ • Cambio de contexto frecuente │
│ • Cuellos de botella no visibles │
│ │
│ LÍMITE DEMASIADO BAJO (subir): │
│ • Equipo frecuentemente inactivo │
│ • Esperando para poder empezar trabajo │
│ • Throughput menor que capacidad │
│ • Bloqueos frecuentes sin alternativas │
│ │
│ LÍMITE CORRECTO (mantener): │
│ • Ligera tensión pero flujo suave │
│ • Cuellos de botella visibles y siendo atendidos │
│ • Cycle time estable o mejorando │
│ • Equipo enfocado en terminar │
│ │
└─────────────────────────────────────────────────────────────┘
Aplicación de Límites WIP
Indicadores Visuales
INDICADORES VISUALES EN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BAJO LÍMITE (Verde): │
│ ┌─────────────────────────────────────────┐ │
│ │ EN PROGRESO [3/5] │ │
│ │ ██████████████░░░░░░░░░░░░░░ │ │
│ │ │ │
│ │ ✓ Puede aceptar más trabajo │ │
│ └─────────────────────────────────────────┘ │
│ │
│ EN LÍMITE (Amarillo): │
│ ┌─────────────────────────────────────────┐ │
│ │ EN PROGRESO [5/5] ⚠️ │ │
│ │ ██████████████████████████████ │ │
│ │ │ │
│ │ ⚠ Terminar algo antes de empezar nuevo │ │
│ └─────────────────────────────────────────┘ │
│ │
│ SOBRE LÍMITE (Rojo): │
│ ┌─────────────────────────────────────────┐ │
│ │ EN PROGRESO [7/5] 🔴 │ │
│ │ ██████████████████████████████████████ │ │
│ │ │ │
│ │ 🔴 Límite excedido! Enfocar en terminar │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Qué Hacer al Alcanzar el Límite
OPCIONES CUANDO SE ALCANZA LÍMITE WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. AYUDAR A TERMINAR TRABAJO EXISTENTE │
│ ├── Pair programming en item complejo │
│ ├── Revisar PRs pendientes │
│ └── Ayudar con testing │
│ │
│ 2. ELIMINAR BLOQUEADORES │
│ ├── Escalar impedimentos │
│ ├── Conseguir respuestas necesarias │
│ └── Resolver dependencias │
│ │
│ 3. MEJORAR FLUJO DOWNSTREAM │
│ ├── Liberar cuellos de botella │
│ ├── Automatizar pasos manuales │
│ └── Documentar para futuro │
│ │
│ 4. TRABAJO DE MEJORA │
│ ├── Refactoring de bajo riesgo │
│ ├── Documentación │
│ └── Preparar trabajo futuro │
│ │
│ NO HACER: │
│ ✗ Empezar nuevo trabajo de todos modos │
│ ✗ Subir límite sin discusión de equipo │
│ ✗ Mover items hacia atrás para hacer espacio │
│ │
└─────────────────────────────────────────────────────────────┘
Tipos de Límites WIP
LÍMITES WIP POR TIPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LÍMITE POR COLUMNA: │
│ Más común. Limita items en cada columna individual. │
│ Ejemplo: Máximo 5 items en "En Progreso" │
│ │
│ LÍMITE POR PERSONA: │
│ Limita items asignados a cada persona. │
│ Ejemplo: Máximo 2 items por desarrollador │
│ │
│ LÍMITE POR SWIMLANE: │
│ Limita items por tipo de trabajo o equipo. │
│ Ejemplo: Máximo 3 bugs en progreso │
│ │
│ LÍMITE GLOBAL: │
│ Limita total de items entre columnas de trabajo. │
│ Ejemplo: Máximo 12 items total entre Ready y Done │
│ │
│ COMBINACIÓN: │
│ Usar múltiples tipos juntos para control fino. │
│ Ejemplo: 5 por columna + 2 por persona │
│ │
└─────────────────────────────────────────────────────────────┘
Políticas de Excepción
CUÁNDO PERMITIR EXCEPCIONES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXCEPCIONES VÁLIDAS: │
│ ✓ Incidente crítico de producción │
│ ✓ Bug bloqueador para cliente importante │
│ ✓ Deadline legal/regulatorio │
│ │
│ NO SON EXCEPCIONES VÁLIDAS: │
│ ✗ "Este item es importante" │
│ ✗ "El stakeholder está presionando" │
│ ✗ "Ya empecé, déjame terminar" │
│ │
│ PROTOCOLO DE EXCEPCIÓN: │
│ 1. Declarar excepción explícitamente │
│ 2. Documentar razón │
│ 3. Trackear frecuencia de excepciones │
│ 4. Revisar en retrospectiva │
│ │
│ SI EXCEPCIONES SON FRECUENTES: │
│ → Los límites son incorrectos │
│ → O el proceso tiene problemas sistémicos │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Empezar conservador y ajustar basándose en datos
- El equipo decide los límites, no management
- Visualizar límites claramente en el tablero
- Revisar regularmente en retrospectivas
- Medir impacto en cycle time y throughput
- Respetar los límites - son compromisos del equipo