Kanban para Equipos de Desarrollo | GitScrum
Transforma flujo de trabajo de tu equipo con Kanban. Visualiza trabajo, limita WIP y optimiza flujo para entrega continua de software.
6 min de lectura
Kanban proporciona un framework flexible para gestionar trabajo de desarrollo con mínima sobrecarga de proceso. Los tableros Kanban de GitScrum ayudan a los equipos a visualizar su flujo de trabajo, identificar cuellos de botella y mejorar continuamente su proceso a través de la optimización de flujo.
Fundamentos de Kanban
Principios Fundamentales
PRINCIPIOS KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. VISUALIZAR TRABAJO │
│ Hacer todo el trabajo visible en el tablero │
│ Incluir tipo de trabajo, estado, bloqueadores │
│ │
│ 2. LIMITAR TRABAJO EN PROGRESO (WIP) │
│ Enfocarse en terminar, no en empezar │
│ Los límites WIP crean flujo │
│ │
│ 3. GESTIONAR FLUJO │
│ Optimizar para entrega suave y predecible │
│ Medir y mejorar cycle time │
│ │
│ 4. HACER POLÍTICAS EXPLÍCITAS │
│ Documentar cómo el trabajo se mueve entre columnas │
│ Definir "listo" y "hecho" para cada etapa │
│ │
│ 5. IMPLEMENTAR CICLOS DE FEEDBACK │
│ Reviews regulares de trabajo y proceso │
│ Adaptar basándose en métricas y experiencia │
│ │
│ 6. MEJORAR COLABORATIVAMENTE │
│ El equipo es dueño del proceso │
│ Cambio continuo y evolutivo │
└─────────────────────────────────────────────────────────────┘
Kanban vs Scrum
CARACTERÍSTICAS DE KANBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ KANBAN: SCRUM: │
│ • Flujo continuo • Sprints time-boxed │
│ • Límites WIP • Compromiso de sprint │
│ • Basado en pull • Push en sprint planning │
│ • Cambiar en cualquier momento • Cambio en límite de sprint│
│ • Roles opcionales • Roles definidos │
│ • Métricas: cycle time • Métricas: velocity │
│ │
│ ELEGIR KANBAN CUANDO: │
│ • Trabajo es impredecible (soporte, ops) │
│ • Se necesita deployment continuo │
│ • Equipo maneja tipos de trabajo variados │
│ • Cambios frecuentes de prioridad │
│ • Se prefiere mínima sobrecarga de proceso │
│ │
│ ELEGIR SCRUM CUANDO: │
│ • Trabajo es planificable │
│ • Equipo necesita estructura │
│ • Stakeholders quieren compromisos predecibles │
│ • Construyendo features complejas iterativamente │
└─────────────────────────────────────────────────────────────┘
Configuración del Tablero Kanban
Diseño Básico del Tablero
TABLERO KANBAN PARA DESARROLLO:
┌─────────────────────────────────────────────────────────────┐
│ BACKLOG │ LISTO │ EN PROGRESO │ REVIEW │ QA │ HECHO │
│ (sin WIP)│ (5) │ (4) │ (3) │ (2) │(sin WIP)│
├─────────┼────────┼─────────────┼─────────┼───────┼─────────┤
│ │ │ │ │ │ │
│ □ #130 │ □ #125 │ ■ #120 │ ■ #115 │■ #110 │ ✓ #105 │
│ □ #131 │ □ #126 │ ■ #121 │ ■ #116 │ │ ✓ #106 │
│ □ #132 │ □ #127 │ │ │ │ ✓ #107 │
│ □ #133 │ │ │ │ │ │
│ │ │ WIP: 2/4 ✅ │ WIP:2/3 │ │ │
└─────────┴────────┴─────────────┴─────────┴───────┴─────────┘
TIPOS DE COLUMNAS:
• Backlog: Todo trabajo no priorizado
• Listo: Refinado, puede comenzar inmediatamente
• En Progreso: Desarrollo activo
• Review: Code review
• QA: Testing
• Hecho: Completado y deployado
Flujo Pull
SISTEMA PULL EN ACCIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGLAS DE PULL: │
│ │
│ 1. Pull solo cuando hay capacidad │
│ (columna bajo su límite WIP) │
│ │
│ 2. Pull del trabajo más prioritario disponible │
│ │
│ 3. Terminar antes de empezar nuevo │
│ │
│ EJEMPLO: │
│ │
│ Desarrollador A termina tarea #120 │
│ ├── Mueve #120 a Review │
│ ├── Verifica: ¿En Progreso < límite WIP? │
│ ├── Sí: Pull de #125 desde Listo │
│ └── Comienza trabajo en #125 │
│ │
│ Si Review está en límite: │
│ ├── No puede mover #120 a Review │
│ ├── Ayuda con reviews existentes primero │
│ └── O espera a que Review se libere │
└─────────────────────────────────────────────────────────────┘
Métricas de Flujo
MÉTRICAS KANBAN CLAVE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ LEAD TIME: Tiempo desde solicitud hasta entrega │
│ Actual: 12 días (objetivo: 10 días) │
│ │
│ CYCLE TIME: Tiempo desde inicio hasta completado │
│ Actual: 5 días │
│ │
│ THROUGHPUT: Items completados por período │
│ Actual: 15 items/semana │
│ │
│ WIP: Trabajo actualmente en progreso │
│ Actual: 8 items │
│ │
│ EFICIENCIA DE FLUJO: │
│ (Tiempo trabajado / Lead time) × 100 │
│ Actual: 42% (objetivo: >50%) │
│ │
│ DISTRIBUCIÓN DE EDAD DE ITEMS: │
│ <3 días: ████████████ 60% │
│ 3-7 días: ██████ 30% │
│ >7 días: ██ 10% ← Investigar estos │
└─────────────────────────────────────────────────────────────┘
Políticas Explícitas
EJEMPLO DE POLÍTICAS DE COLUMNA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEFINICIÓN DE "LISTO" (para mover a En Progreso): │
│ □ Criterios de aceptación definidos │
│ □ Diseño aprobado │
│ □ Sin dependencias bloqueadoras │
│ □ Estimación completada │
│ │
│ DEFINICIÓN DE "HECHO" (para mover a Review): │
│ □ Código completo y funcional │
│ □ Tests unitarios escritos y pasando │
│ □ Documentación actualizada │
│ □ PR creado con descripción │
│ │
│ POLÍTICA DE REVIEW: │
│ □ Review en 4 horas laborales │
│ □ Mínimo 1 aprobación requerida │
│ □ CI pasando │
│ │
└─────────────────────────────────────────────────────────────┘