9 min lectura • Guide 26 of 877
Equilibrando Trabajo de Features con Corrección de Bugs
Los equipos de desarrollo luchan constantemente con la tensión entre construir nuevas features y corregir bugs existentes. Demasiado enfoque en features lleva a deuda técnica y frustración del usuario, mientras que demasiado enfoque en bugs estanca el progreso del producto. GitScrum permite una asignación equilibrada a través de workflows dedicados de bugs y métricas que ayudan a mantener el equilibrio correcto.
El Dilema Feature vs. Bug
La asignación desequilibrada crea problemas:
- Sprints pesados en features — Usuarios sufren de issues no resueltos
- Sprints pesados en bugs — Roadmap se retrasa, stakeholders frustrados
- Cambio de contexto — Desarrolladores pierden productividad saltando entre
- Bugs ocultos — Features se envían con issues conocidos
- Acumulación de deuda técnica — Fixes rápidos crean problemas futuros
- Problemas de moral del equipo — Turno de bugs visto como castigo
Soluciones de Balance GitScrum
Herramientas para mantener el equilibrio:
Mecanismos de Balance
| Mecanismo | Implementación GitScrum |
|---|---|
| Asignación de sprint | Capacidad basada en porcentaje |
| Priorización de bugs | Labels de severidad + impacto |
| Rotación de bugs | Políticas de auto-asignación |
| Gates de calidad | Checklists que previenen releases |
| Seguimiento de métricas | Velocidad de bugs vs. features |
| Visibilidad | Vistas y reportes separados |
Estrategias de Asignación de Sprint
Asignación Basada en Capacidad
Planificación de Capacidad del Sprint:
Capacidad del Equipo: 60 story points
Modelo de Asignación A: Porcentaje Fijo
────────────────────────────────────────
├── Nuevas Features: 70% (42 puntos)
├── Corrección de Bugs: 20% (12 puntos)
├── Deuda Técnica: 10% (6 puntos)
└── Total: 100% (60 puntos)
Modelo de Asignación B: Promedio Móvil
──────────────────────────────────────
├── Features Base: 60% (36 puntos)
├── Bugs Base: 15% (9 puntos)
├── Buffer: 25% (15 puntos)
│ └── Asignado durante sprint basado en bugs emergentes
└── Total: 100% (60 puntos)
Modelo de Asignación C: Disparado por Calidad
─────────────────────────────────────────────
├── Si bugs P0/P1 abiertos < 5:
│ └── Features: 80% / Bugs: 15% / Deuda: 5%
├── Si bugs P0/P1 abiertos 5-10:
│ └── Features: 60% / Bugs: 35% / Deuda: 5%
├── Si bugs P0/P1 abiertos > 10:
│ └── Features: 40% / Bugs: 55% / Deuda: 5%
└── Ajustar automáticamente cada sprint
Asignación Sprint 15 (Modelo A):
┌─────────────────────────────────────────────────┐
│ CAPACIDAD SPRINT: 60 puntos │
├─────────────────────────────────────────────────┤
│ Features (42 pts) │████████████████████░░░░│ │
│ Bugs (12 pts) │██████░░░░░░░░░░░░░░░░░░│ │
│ Deuda Téc (6 pts) │███░░░░░░░░░░░░░░░░░░░░░│ │
├─────────────────────────────────────────────────┤
│ Comprometido: │ 55 puntos │
│ Capacidad Restante: │ 5 puntos (buffer) │
└─────────────────────────────────────────────────┘
Reserva de Presupuesto de Bugs
Reservando Capacidad de Bugs:
Protocolo de Planificación de Sprint:
─────────────────────────────────────
1. Comenzar con Capacidad Total (60 puntos)
2. Reservar Asignación de Bugs Primero
├── Verificar conteo de bugs P0/P1 (actualmente 7)
├── Estimar puntos de bugs (promedio 2 pts cada uno)
├── Reservado: 7 × 2 = 14 puntos para bugs
└── Más buffer: +4 puntos para bugs descubiertos
Total Reserva Bugs: 18 puntos
3. Reservar Deuda Técnica (si hay crítica)
├── Items de deuda críticos: 2
├── Puntos: 6 puntos
└── Total Reserva Deuda: 6 puntos
4. Restante para Features
├── Total: 60 puntos
├── Menos bugs: -18 puntos
├── Menos deuda: -6 puntos
└── Disponible para features: 36 puntos
5. Llenar Backlog de Features
├── Seleccionar features totalizando ≤36 puntos
├── Priorizar por valor de negocio
└── Confirmar con Product Owner
Resultado Backlog del Sprint:
├── Features: 34 puntos (5 items)
├── Bugs: 18 puntos (9 items)
├── Deuda Técnica: 6 puntos (2 items)
└── Buffer: 2 puntos (sin asignar)
Sistema de Priorización de Bugs
Matriz Severidad-Impacto
Clasificación de Prioridad de Bugs:
IMPACTO
Bajo Medio Alto
┌─────────┬──────────┬──────────┬──────────┐
Alto │ │ P1 │ P0 │ P0 │
│ │ 24-48h │ 4-8h │ <4h │
SEVERIDAD├─────────┼──────────┼──────────┼──────────┤
Medio │ │ P2 │ P1 │ P0 │
│ │ Sprint │ 24-48h │ 4-8h │
├─────────┼──────────┼──────────┼──────────┤
Bajo │ │ P3 │ P2 │ P1 │
│ │ Backlog │ Sprint │ 24-48h │
└─────────┴──────────┴──────────┴──────────┘
Definiciones de Severidad:
├── Alto: Crash del sistema, pérdida de datos, brecha de seguridad
├── Medio: Feature rota, existe workaround
└── Bajo: Cosmético, inconveniencia menor
Definiciones de Impacto:
├── Alto: Todos los usuarios afectados, impacto en ingresos
├── Medio: Segmento significativo de usuarios afectado
└── Bajo: Pocos usuarios, caso extremo
Tiempo de Respuesta (SLA):
├── P0: Dejar todo, arreglar inmediatamente
├── P1: Arreglar en 24-48 horas
├── P2: Arreglar en el sprint actual
└── P3: Agregar al backlog, priorizar después
Workflow de Triaje de Bugs
Proceso de Triaje de Bugs:
Nuevo Bug Reportado:
────────────────────
Paso 1: Triaje Inicial (Dentro de 4 horas)
├── Asignar a Líder de Triaje (rotación)
├── Verificar que el bug es reproducible
├── Evaluar severidad (Alto/Medio/Bajo)
├── Evaluar impacto (Alto/Medio/Bajo)
├── Determinar prioridad (P0/P1/P2/P3)
└── Agregar labels apropiados
Paso 2: Categorización
├── Agregar labels:
│ ├── severity/high, severity/medium, severity/low
│ ├── impact/high, impact/medium, impact/low
│ ├── priority/P0, priority/P1, priority/P2, priority/P3
│ ├── component/[área] (UI, API, Database, etc.)
│ └── regression/yes o regression/no
└── Vincular a issues relacionados si hay
Paso 3: Enrutamiento
├── P0: Asignar inmediatamente a dev senior disponible
├── P1: Agregar a columna "Bugs Urgentes", asignar dueño
├── P2: Agregar a asignación de bugs del sprint actual
├── P3: Agregar a Bug Backlog, esperar priorización
└── Actualizar estado del bug a "Triado"
Paso 4: Comunicación
├── P0/P1: Notificar al equipo inmediatamente (alerta Slack)
├── P2: Incluir en standup diario
├── P3: Revisar en grooming semanal del backlog
└── Reportador notificado de decisión de triaje
Sistema de Rotación de Bugs
Distribución Justa
Política de Rotación de Bugs:
Principios:
├── Cada desarrollador toma turno de bugs
├── Rotación es justa y predecible
├── Emparejamiento Senior/Junior para aprendizaje
└── Nadie atascado en bugs indefinidamente
Calendario de Rotación:
──────────────────────
Semana │ Dev Principal Bugs │ Respaldo │ Foco
───────┼────────────────────┼─────────────┼─────────────
1 │ Alice │ Bob │ Bugs UI
2 │ Bob │ Carol │ Bugs API
3 │ Carol │ David │ Bugs DB
4 │ David │ Emma │ Bugs UI
5 │ Emma │ Alice │ Bugs API
(repetir)
Durante Semana de Turno de Bugs:
├── Responsable de respuesta inmediata P0/P1
├── Primero en triar nuevos bugs en área de componente
├── Se espera completar 60% de bugs asignados del sprint
├── Emparejado con respaldo para issues complejos
└── Trabajo de features reducido proporcionalmente
Automatización GitScrum:
├── Auto-asignar nuevos bugs P0/P1 al dev de rotación actual
├── Notificar en Slack cuando bug asignado
├── Alertar si bug sin asignar >4 horas
└── Recordatorio de rotación semanal domingo en la noche
Configuración del Board para Balance
Kanban de Doble Pista
Estructura del Board:
Opción 1: Swimlanes Separados
─────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ BOARD SPRINT 15 │
├─────────────────────────────────────────────────────────────┤
│ Features │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ Por Hacer(5) │ En Progreso │ Review (2) │ Hecho (3) │
│ │ (3) │ │ │
├──────────────┴──────────────┴─────────────┴────────────────┤
│ Bugs │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ Por Hacer(8) │ En Progreso │ Review (1) │ Hecho (5) │
│ │ (2) │ │ │
├──────────────┴──────────────┴─────────────┴────────────────┤
│ Deuda Técnica │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ Por Hacer(2) │ En Progreso │ Review (0) │ Hecho (1) │
│ │ (1) │ │ │
└──────────────┴──────────────┴─────────────┴────────────────┘
Opción 2: Filtrado Basado en Labels
───────────────────────────────────
Board único con toggles de filtro:
├── [Todo] [Solo Features] [Solo Bugs] [Solo Deuda Téc]
├── Labels: type/feature, type/bug, type/tech-debt
├── Cambio rápido entre vistas
└── Progreso combinado visible en vista "Todo"
Seguimiento de Métricas de Calidad
Dashboard de Balance
Dashboard de Balance Feature/Bug:
Progreso Sprint 15:
───────────────────
Distribución de Trabajo:
├── Features: ████████████████░░░░ 80% completo (34/42 pts)
├── Bugs: ████████████░░░░░░░░ 60% completo (7/12 pts)
├── Deuda Téc:█████████░░░░░░░░░░░ 50% completo (3/6 pts)
└── General: ███████████████░░░░░ 73% completo
Métricas de Bugs:
├── Bugs Abiertos: 23 (↓5 desde inicio del sprint)
├── P0/P1 Abiertos: 2 (objetivo: 0)
├── Bugs Corregidos Este Sprint: 9
├── Nuevos Bugs Este Sprint: 4
├── Cambio Neto de Bugs: -5 (¡bien!)
└── Tasa de Escape de Bugs: 2% (1 bug por 50 features)
Tendencia de Calidad (Últimos 6 Sprints):
────────────────────────────────────────
Sprint │ Features │ Bugs │ Bugs Neto │ Tasa Escape
───────┼──────────┼──────┼───────────┼────────────
10 │ 38 pts │ 12 │ +3 │ 5%
11 │ 42 pts │ 10 │ -2 │ 4%
12 │ 45 pts │ 8 │ -4 │ 3%
13 │ 40 pts │ 14 │ +2 │ 4%
14 │ 44 pts │ 11 │ -3 │ 2%
15 │ 42 pts │ 12 │ -5 │ 2%
Tendencia: Conteo de bugs disminuyendo, tasa de escape mejorando ✓
Mejores Prácticas
Para Product Owners
- Presupuestar para bugs — Incluir asignación de bugs en planificación
- Priorizar por impacto — No todos los bugs son iguales
- Aceptar trade-offs — No se pueden corregir todos los bugs inmediatamente
- Comunicar balance — Explicar a stakeholders por qué importan los bugs
- Rastrear tendencias — Monitorear conteos de bugs con el tiempo
Para Desarrolladores
- Ser dueño de tus bugs — Enorgullecerse del trabajo de calidad
- Escribir tests primero — Prevenir bugs antes de que ocurran
- Investigar a fondo — Encontrar causa raíz, no solo síntomas
- Compartir conocimiento — Ayudar al equipo a aprender de bugs
- Equilibrar justamente — Tomar tu turno en duty de bugs
Para Team Leads
- Establecer asignación clara — Definir y comunicar porcentajes
- Rotar justamente — Nadie debe sentirse señalado
- Reconocer trabajo de calidad — Celebrar victorias de bugs
- Monitorear balance — Ajustar asignación basado en métricas
- Construir cultura — Hacer que trabajo de bugs sea valorado, no castigado