6 min lectura • Guide 789 of 877
Límites de WIP y Gestión del Flujo
Menos trabajo en progreso significa entrega más rápida. GitScrum soporta límites de WIP para ayudar a los equipos a terminar trabajo antes de empezar trabajo nuevo.
Entendiendo el WIP
El Problema del Flujo
POR QUÉ IMPORTAN LOS LÍMITES DE WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SIN LÍMITES DE WIP: │
│ ─────────────────── │
│ │
│ POR HACER EN PROGRESO TESTING DONE │
│ ───────── ──────────── ─────── ──── │
│ ┌────┐ ┌────┐ │
│ ┌────┐ │ │ │ │ ┌────┐ ┌────┐ │
│ │ │ │ │ │ │ │ 🕐 │ │ ✅ │ │
│ └────┘ │ │ │ │ │ │ │ │ │
│ ┌────┐ └────┘ └────┘ └────┘ └────┘ │
│ │ │ ┌────┐ ┌────┐ │
│ └────┘ │ │ │ │ │
│ ┌────┐ │ │ │ │ ← 6 en progreso │
│ │ │ └────┘ └────┘ ← 1 bloqueado en testing │
│ └────┘ ┌────┐ ┌────┐ ← Muy poco done │
│ │ │ │ │ │
│ └────┘ └────┘ │
│ │
│ PROBLEMAS: │
│ • Todos ocupados, poco terminando │
│ • Cambio de contexto entre tareas │
│ • Testing atrasado │
│ • Cuello de botella oculto │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CON LÍMITES DE WIP: │
│ ─────────────────── │
│ │
│ POR HACER EN PROGRESO (3) TESTING (2) DONE │
│ ───────── ─────────────── ─────────── ──── │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ ┌────┐ │ │ │ │ │ │ │ │ ┌────┐ │
│ │ │ │ │ │ │ │ │ │ │ │ ✅ │ │
│ └────┘ │ │ │ │ └────┘ └────┘ │ │ │
│ ┌────┐ └────┘ └────┘ └────┘ │
│ │ │ ┌────┐ ┌────┐ │
│ └────┘ │ ⏸️ │ ← Esperando (límite alcanz.)│ ✅ │ │
│ ┌────┐ │ │ │ │ │
│ │ │ └────┘ └────┘ │
│ └────┘ │
│ │
│ BENEFICIOS: │
│ • Cuello de botella visible │
│ • Enfoque en terminar │
│ • Flujo más rápido │
└─────────────────────────────────────────────────────────────┘
Estableciendo Límites
Cómo Establecer Límites de WIP
GUÍA PARA ESTABLECER LÍMITES DE WIP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PUNTO DE PARTIDA: │
│ │
│ Límite de etapa = Número de personas trabajando ahí │
│ │
│ Ejemplo: │
│ • En Progreso: 3 desarrolladores → Límite = 3 │
│ • Testing: 1 QA → Límite = 2 (buffer pequeño) │
│ • Revisión: todos revisan → Límite = 2 │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AJUSTANDO: │
│ │
│ LÍMITE MUY BAJO: │
│ • Síntoma: Gente ociosa esperando │
│ • Solución: Subir límite ligeramente │
│ │
│ LÍMITE MUY ALTO: │
│ • Síntoma: Multitasking, nada terminando │
│ • Solución: Bajar límite │
│ │
│ LÍMITE CORRECTO: │
│ • Pequeña tensión ocasional │
│ • Trabajo fluyendo consistentemente │
│ • Cuellos de botella visibles y manejables │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EJEMPLO DE TABLERO: │
│ │
│ │ Backlog │ To Do │ Dev (3) │ Review (2) │ QA (2) │ Done │ │
│ │ ∞ │ 5 │ 3 │ 2 │ 2 │ ∞ │ │
│ │
│ Backlog/Done: Sin límite (cola de entrada/salida) │
│ To Do: Límite suave (próximo trabajo) │
│ Dev/Review/QA: Límites duros (trabajo activo) │
└─────────────────────────────────────────────────────────────┘
Gestionando el Flujo
Cuando se Alcanza el Límite
QUÉ HACER CUANDO SE ALCANZA EL LÍMITE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SITUACIÓN: │
│ "In Progress" está en 3/3, quiero empezar algo nuevo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ OPCIONES (en orden de preferencia): │
│ │
│ 1. AYUDAR A TERMINAR ALGO EN PROGRESO │
│ ¿Puedo hacer pair con alguien para terminar? │
│ ¿Puedo desbloquear algo? │
│ │
│ 2. AYUDAR EN EL CUELLO DE BOTELLA │
│ Si Review está lleno, hacer revisiones │
│ Si QA está atrasado, ayudar a probar │
│ │
│ 3. MEJORAR ALGO │
│ Escribir documentación │
│ Refactorizar código existente │
│ Pagar deuda técnica │
│ │
│ 4. ESPERAR (último recurso) │
│ A veces la espera breve es correcta │
│ Mejor que empezar más trabajo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LO QUE NO HACER: │
│ │
│ ❌ Ignorar el límite y empezar de todos modos │
│ ❌ Subir el límite cada vez que se alcanza │
│ ❌ Quejarse del límite sin analizar el cuello de botella │
└─────────────────────────────────────────────────────────────┘
Beneficios del Flujo
BENEFICIOS DE GESTIONAR EL FLUJO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES (sin límites de WIP): │
│ │
│ • Lead time promedio: 12 días │
│ • Tareas en progreso: 15 simultáneas │
│ • Terminadas por semana: 3 │
│ • Cambios de contexto: constantes │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DESPUÉS (con límites de WIP): │
│ │
│ • Lead time promedio: 5 días (↓ 58%) │
│ • Tareas en progreso: 6 simultáneas (↓ 60%) │
│ • Terminadas por semana: 5 (↑ 67%) │
│ • Cambios de contexto: mínimos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LEY DE LITTLE: │
│ │
│ Lead Time = WIP / Throughput │
│ │
│ Para reducir Lead Time: │
│ • Reducir WIP (más fácil) │
│ • Aumentar Throughput (más difícil) │
│ │
│ Los límites de WIP son la palanca más efectiva │
└─────────────────────────────────────────────────────────────┘