6 min lectura • Guide 667 of 877
Implementando Kanban para Equipos de Desarrollo
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 │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Empezar donde estás - no cambiar todo a la vez
- Visualizar todo el trabajo incluyendo trabajo no planificado
- Límites WIP estrictos para crear flujo
- Métricas para decisiones no para culpar
- Mejora continua pequeña y frecuente
- El equipo es dueño del proceso