8 min lectura • Guide 100 of 877
Balanceando Desarrollo de Features con Corrección de Bugs
Cada equipo de desarrollo enfrenta la tensión entre construir nuevas features y corregir bugs existentes. La configuración de tableros de GitScrum, sistema de labels, y herramientas de planificación de sprint ayudan a equipos a encontrar el balance correcto haciendo visible el trabajo de bugs, estableciendo políticas de asignación, y creando procesos que previenen que bugs sean perpetuamente despriorizados mientras se entrega valor al cliente.
Entendiendo la Tensión
El Problema del Balance
PRIORIDADES EN COMPETENCIA:
┌─────────────────────────────────────────────────────────────┐
│ POR QUÉ ES DIFÍCIL BALANCEAR │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRESIÓN DE FEATURES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Compromisos de roadmap con stakeholders ││
│ │ • Presión competitiva para shipear ││
│ │ • Nuevas features = progreso visible ││
│ │ • Revenue atado a entrega de features ││
│ │ • Trabajo más "emocionante" para equipo ││
│ │ ││
│ │ Resultado: Bugs se empujan a "después" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRESIÓN DE BUGS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Quejas de clientes y churn ││
│ │ • Volumen tickets soporte ││
│ │ • Deuda técnica ralentizando desarrollo ││
│ │ • Moral equipo (trabajar en producto roto) ││
│ │ • Riesgos seguridad y compliance ││
│ │ ││
│ │ Resultado: "Bancarrota de bugs" si se ignora mucho ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LA ESPIRAL DE MUERTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Saltear bugs → Shipear features → ││
│ │ Más bugs aparecen → Saltear bugs → ││
│ │ Shipear features más rápido (presión) → ││
│ │ Aún más bugs → Producto se desestabiliza → ││
│ │ Features no pueden shipear (todo rompe) → ││
│ │ Sprint emergencia bugs → Equipo se quema ││
│ │ ││
│ │ Romper ciclo requiere asignación intencional ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Estrategias Asignación
Asignación Porcentual
ENFOQUE ASIGNACIÓN FIJA:
┌─────────────────────────────────────────────────────────────┐
│ DIVISIÓN CAPACIDAD SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ MODELO: 70/20/10 │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Capacidad Sprint: 80 story points ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────┐ ││
│ │ │ FEATURES │ 56 pts │ ││
│ │ │ (Items roadmap, capacidades nuevas) │ 70% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ BUGS │ 16 pts │ ││
│ │ │ (Defectos, regresiones, calidad) │ 20% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ DEUDA TÉCNICA │ 8 pts │ ││
│ │ │ (Refactoring, tooling, upgrades) │ 10% │ ││
│ │ └───────────────────────────────────────┴────────┘ ││
│ │ ││
│ │ EN GITSCRUM: ││
│ │ • Usar labels: type/feature, type/bug, type/tech-debt ││
│ │ • Filtrar por labels para verificar asignación ││
│ │ • Trackear en analytics del sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AJUSTANDO BASADO EN ESTADO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Estado │ Features │ Bugs │ Deuda Técnica ││
│ │ ───────────────┼──────────┼──────┼─────────── ││
│ │ Saludable │ 70% │ 20% │ 10% ││
│ │ Backlog bugs │ 60% │ 30% │ 10% ││
│ │ Estabilización │ 50% │ 40% │ 10% ││
│ │ Crisis │ 30% │ 60% │ 10% ││
│ │ Post-crisis │ 80% │ 15% │ 5% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Días/Rotación Bugs
TIEMPO DEDICADO BUGS:
┌─────────────────────────────────────────────────────────────┐
│ ENFOQUES ROTACIÓN │
├─────────────────────────────────────────────────────────────┤
│ │
│ OPCIÓN 1: DÍA DE BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cada viernes: Día de corrección bugs ││
│ │ ││
│ │ Reglas: ││
│ │ • Todo equipo trabaja en bugs ││
│ │ • No trabajo de features permitido ││
│ │ • Triage en mañana, corregir todo el día ││
│ │ • Celebrar fixes al final del día ││
│ │ ││
│ │ Beneficios: ││
│ │ • Tiempo bugs predecible ││
│ │ • Sin cambio contexto durante semana ││
│ │ • Ritual equipo construye cultura ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPCIÓN 2: ROTACIÓN BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cada sprint: Un desarrollador en turno bugs ││
│ │ ││
│ │ Reglas: ││
│ │ • Rota cada sprint ││
│ │ • Turno bugs = solo bugs, no features ││
│ │ • Manejar bugs críticos inmediatamente ││
│ │ • Trabajar a través del backlog priorizado ││
│ │ ││
│ │ Beneficios: ││
│ │ • Respuesta rápida a bugs críticos ││
│ │ • Foco dedicado (sin atención dividida) ││
│ │ • Todos aprenden todas áreas del código ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPCIÓN 3: SPRINT DE BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cada 4to sprint: Sprint solo bugs ││
│ │ ││
│ │ Reglas: ││
│ │ • Sprint entero dedicado a calidad ││
│ │ • Bugs, deuda técnica, mejoras testing ││
│ │ • Sin features nuevas ││
│ │ ││
│ │ Mejor para: Equipos con deuda significativa acumulada ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Priorización Bugs
Severidad y Prioridad
CLASIFICACIÓN BUGS:
┌─────────────────────────────────────────────────────────────┐
│ SEVERIDAD VS PRIORIDAD │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEVERIDAD (Impacto del bug): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ S1 - CRÍTICO: ││
│ │ • Pérdida o corrupción datos ││
│ │ • Vulnerabilidad seguridad ││
│ │ • Feature completa rota ││
│ │ • Sin workaround posible ││
│ │ ││
│ │ S2 - ALTO: ││
│ │ • Feature mayor significativamente degradada ││
│ │ • Workaround existe pero doloroso ││
│ │ • Afecta muchos usuarios ││
│ │ ││
│ │ S3 - MEDIO: ││
│ │ • Feature funciona pero con problemas ││
│ │ • Workaround fácil disponible ││
│ │ • Afecta algunos usuarios ││
│ │ ││
│ │ S4 - BAJO: ││
│ │ • Problemas cosméticos ││
│ │ • Casos edge ││
│ │ • Impacto usuario mínimo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRIORIDAD (Cuándo corregir): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ P1: Corregir inmediatamente (soltar todo) ││
│ │ P2: Corregir este sprint ││
│ │ P3: Corregir pronto (próximos 2-3 sprints) ││
│ │ P4: Corregir eventualmente (backlog) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MAPEO SEVERIDAD → PRIORIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ │ Muchos Users │ Algunos Users │ Pocos Users ││
│ │ ─────────┼──────────────┼───────────────┼─────────── ││
│ │ S1 Crít │ P1 │ P1 │ P2 ││
│ │ S2 Alto │ P1 │ P2 │ P2 ││
│ │ S3 Med │ P2 │ P3 │ P3 ││
│ │ S4 Bajo │ P3 │ P4 │ P4 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Planificación Sprint
Selección Bugs
PLANIFICANDO PARA BUGS:
┌─────────────────────────────────────────────────────────────┐
│ ENFOQUE PLANIFICACIÓN SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ ANTES DE PLANIFICACIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Triage backlog bugs ││
│ │ • Actualizar prioridades ││
│ │ • Cerrar duplicados/inválidos ││
│ │ • Añadir estimados esfuerzo ││
│ │ ││
│ │ 2. Calcular presupuesto bugs ││
│ │ • Capacidad total × porcentaje bugs ││
│ │ • Ejemplo: 80 puntos × 20% = 16 puntos para bugs ││
│ │ ││
│ │ 3. Pre-seleccionar candidatos ││
│ │ • Bugs P1/P2 (requeridos) ││
│ │ • Bugs P3 más antiguos ││
│ │ • Bugs relacionados con features del sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DURANTE PLANIFICACIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Empezar con bugs requeridos (P1/P2) ││
│ │ • No negociables, deben caber ││
│ │ • Si muchos, escalar problema capacidad ││
│ │ ││
│ │ 2. Llenar presupuesto bugs restante ││
│ │ • Elegir de candidatos P3 ││
│ │ • Considerar: edad, impacto cliente, trabajo relac. ││
│ │ ││
│ │ 3. Planificar features con capacidad restante ││
│ │ ││
│ │ 4. Verificar balance ││
│ │ • ¿Asignación coincide con porcentajes objetivo? ││
│ │ • Ajustar si necesario ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘