5 min lectura • Guide 779 of 877
Triage y Priorización de Bugs
No todos los bugs son iguales. GitScrum ayuda a los equipos a realizar triage de bugs sistemáticamente, priorizar por impacto y rastrear resolución sin perder foco en la entrega de valor al usuario.
Triage de Bugs
Clasificación de Severidad
Un sistema claro de severidad elimina debates y asegura que los bugs correctos reciban atención primero.
NIVELES DE SEVERIDAD DE BUGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRÍTICO (P0): │
│ ───────────── │
│ • Sistema caído o inutilizable │
│ • Pérdida o corrupción de datos │
│ • Vulnerabilidad de seguridad │
│ • Pagos/facturación rotos │
│ │
│ Respuesta: Dejar todo, arreglar inmediatamente │
│ SLA: 2-4 horas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ALTO (P1): │
│ ────────── │
│ • Feature mayor rota, sin workaround │
│ • Degradación significativa de rendimiento │
│ • Bloqueando muchos usuarios │
│ │
│ Respuesta: Arreglar este sprint │
│ SLA: 1-2 días hábiles │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MEDIO (P2): │
│ ──────────── │
│ • Feature parcialmente rota, workaround existe │
│ • Afectando algunos usuarios │
│ • Issues de UI que confunden usuarios │
│ │
│ Respuesta: Planificar para próximo sprint │
│ SLA: 1-2 semanas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BAJO (P3): │
│ ───────── │
│ • Issues menores, problemas cosméticos │
│ • Casos edge raros │
│ • Bueno arreglar pero no urgente │
│ │
│ Respuesta: Backlog, arreglar cuando convenga │
│ SLA: Mejor esfuerzo │
└─────────────────────────────────────────────────────────────┘
Proceso de Triage
El triage estructurado asegura que ningún bug importante se pierda y que el equipo mantenga foco en prioridades correctas.
REUNIÓN DE TRIAGE DE BUGS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRIAGE DIARIO/SEMANAL: │
│ │
│ QUIÉN: Producto + Ingeniería + QA (15-30 min) │
│ │
│ AGENDA: │
│ 1. Revisar bugs nuevos │
│ 2. Asignar severidad │
│ 3. Asignar dueño │
│ 4. Añadir a sprint o backlog │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PREGUNTAS DE TRIAGE: │
│ │
│ IMPACTO: │
│ • ¿Cuántos usuarios afectados? │
│ • ¿Qué tan severamente afectados? │
│ • ¿Hay un workaround? │
│ │
│ URGENCIA: │
│ • ¿Está bloqueando workflows críticos? │
│ • ¿Sensible al tiempo (evento, release)? │
│ • ¿Empeorando con el tiempo? │
│ │
│ COMPLEJIDAD: │
│ • ¿Fix rápido o trabajo significativo? │
│ • ¿Causa raíz conocida? │
│ • ¿Riesgo de introducir más bugs? │
│ │
└─────────────────────────────────────────────────────────────┘
Resultado del Triage
Cada sesión de triage debe producir decisiones claras y documentadas.
EJEMPLO DE DECISIÓN DE TRIAGE:
┌─────────────────────────────────────────────────────────────┐
│ BUG-123: Login falla intermitentemente │
│ │
│ Reportado: Ene 15 │
│ Reporter: Soporte al Cliente │
│ │
│ DECISIÓN DE TRIAGE: │
│ Severidad: P1 (Alta) │
│ Impacto: 5% de intentos de login fallando │
│ Urgencia: Alta - bloqueando usuarios │
│ Dueño: @desarrollador-backend │
│ Sprint: Actual │
│ │
│ Notas: Posiblemente relacionado con cambio de │
│ sesiones del sprint pasado. Investigar primero. │
└─────────────────────────────────────────────────────────────┘
Equilibrando Bugs con Features
Estrategias de Asignación
Reservar capacidad para bugs previene que se acumulen y afecten la calidad del producto.
MODELOS DE ASIGNACIÓN:
═════════════════════
MODELO A: Porcentaje Fijo
─────────────────────────
Cada Sprint:
├── Features: 70-80%
├── Bugs: 15-20%
└── Deuda técnica: 5-10%
MODELO B: Bug Budget
────────────────────
Por Sprint:
├── Reservar 8 puntos para bugs
├── Si sobran, añadir features pequeñas
└── Si faltan, escalar prioridades
MODELO C: Rotación
──────────────────
Por Semana:
├── 1 desarrollador en "bug duty"
├── Rota cada semana
├── Responsable de bugs P0/P1
└── Resto del equipo en features
Métricas de Bugs
KPIs para Seguimiento
Las métricas correctas ayudan a identificar tendencias y mejorar calidad sistemáticamente.
MÉTRICAS CLAVE:
═══════════════
Volumen:
├── Bugs reportados por sprint
├── Bugs cerrados por sprint
├── Backlog total de bugs
└── Ratio entrada/salida
Velocidad:
├── Tiempo medio de resolución
├── Tiempo medio hasta primera respuesta
├── % dentro de SLA
└── Tiempo en cada estado
Calidad:
├── Bugs por feature entregada
├── Bugs reabiertos
├── Regresiones encontradas
└── Cobertura de testing
Mejores Prácticas
Para Triage Efectivo
- Realizar triage regularmente — Diario o cada 2-3 días
- Incluir stakeholders correctos — Producto, Dev, QA
- Decidir rápido — Evitar análisis parálisis
- Documentar decisiones — Para referencia futura
- Revisar tendencias — Identificar causas raíz
Anti-Patrones
EVITAR ESTOS:
✗ Triage una vez al mes
✗ Una persona decide sola
✗ No documentar decisiones
✗ Todos los bugs son P1
✗ Ningún bug es urgente
✗ Ignorar métricas
✗ No cerrar bugs obsoletos