8 min lectura • Guide 744 of 877
Implementación de Política Zero-Bug
Una política zero-bug significa corregir bugs cuando aparecen, no acumularlos. GitScrum ayuda a los equipos a rastrear y priorizar bugs efectivamente para mantener un backlog limpio.
Filosofía Zero-Bug
Qué Significa Zero-Bug
POLÍTICA ZERO-BUG DEFINIDA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ZERO-BUG SIGNIFICA: │
│ │
│ ✅ Los bugs se corrigen cuando se encuentran, no después │
│ ✅ El backlog de bugs se mantiene en o cerca de cero │
│ ✅ La calidad es una constante, no una fase │
│ ✅ Todos son dueños de la calidad │
│ ✅ Nunca se necesita "bancarrota de bugs" │
│ │
│ ZERO-BUG NO SIGNIFICA: │
│ │
│ ❌ Nunca ocurren bugs │
│ ❌ No lanzar hasta que esté perfecto │
│ ❌ Todo se detiene por cualquier bug │
│ ❌ No existe priorización │
│ │
└─────────────────────────────────────────────────────────────┘
Comparación de Enfoques
TRADICIONAL vs ZERO-BUG
═══════════════════════
ENFOQUE TRADICIONAL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Sprint 1: Dev dev dev... 5 bugs encontrados │
│ Sprint 2: Dev dev dev... 8 bugs más │
│ Sprint 3: Dev dev dev... 12 bugs más │
│ Sprint 4: "Bug bash" - intentar arreglar 25 bugs │
│ (Solo arreglamos 15, quedan 10) │
│ │
│ 6 meses después: 150+ bugs en backlog │
│ → "Bug bankruptcy" - cerrar todos los bugs viejos │
│ │
└─────────────────────────────────────────────────────────────┘
ENFOQUE ZERO-BUG:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Sprint 1: Dev... Bug encontrado → Corregido │
│ Dev... Bug encontrado → Corregido │
│ Fin del sprint: 0 bugs abiertos │
│ │
│ Sprint 2: Dev... Bug encontrado → Corregido │
│ Fin del sprint: 0 bugs abiertos │
│ │
│ 6 meses después: Backlog limpio, calidad alta │
│ │
└─────────────────────────────────────────────────────────────┘
Proceso de Triage
TRIAGE PARA ZERO-BUG
════════════════════
CUANDO SE REPORTA UN BUG:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Nuevo Bug Reportado │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ ¿Es realmente │──NO──► Convertir a feature request │
│ │ un bug? │ o cerrar │
│ └────────┬────────┘ │
│ │ SÍ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ ¿Crítico para │──SÍ──► ARREGLAR HOY │
│ │ usuarios? │ (drop everything) │
│ └────────┬────────┘ │
│ │ NO │
│ ▼ │
│ ┌─────────────────┐ │
│ │ ¿Arreglo rápido │──SÍ──► Arreglar esta semana │
│ │ (<2 horas)? │ │
│ └────────┬────────┘ │
│ │ NO │
│ ▼ │
│ ┌─────────────────┐ │
│ │ ¿Vale la pena │──NO──► CERRAR (no hacer) │
│ │ arreglarlo? │ │
│ └────────┬────────┘ │
│ │ SÍ │
│ ▼ │
│ Agregar al siguiente sprint │
│ (máximo 1-2 bugs pendientes) │
│ │
└─────────────────────────────────────────────────────────────┘
Categorización de Bugs
| Categoría | Acción | Tiempo Máximo |
|---|---|---|
| Crítico | Drop everything | Hoy |
| Alto | Sprint actual | 1-2 días |
| Medio | Arreglo rápido | Esta semana |
| Bajo | Evaluar cerrar | Decidir ahora |
Definición de Categorías
SEVERIDADES DE BUGS
═══════════════════
CRÍTICO (P0):
┌─────────────────────────────────────────────────────────────┐
│ • Usuarios no pueden usar funcionalidad core │
│ • Pérdida de datos │
│ • Problema de seguridad │
│ • Sistema caído │
│ │
│ ACCIÓN: Detener todo, arreglar inmediatamente │
└─────────────────────────────────────────────────────────────┘
ALTO (P1):
┌─────────────────────────────────────────────────────────────┐
│ • Feature importante no funciona correctamente │
│ • Workaround existe pero es malo │
│ • Afecta a muchos usuarios │
│ │
│ ACCIÓN: Arreglar en el sprint actual │
└─────────────────────────────────────────────────────────────┘
MEDIO (P2):
┌─────────────────────────────────────────────────────────────┐
│ • Feature secundaria con problema │
│ • Workaround fácil existe │
│ • Afecta a pocos usuarios │
│ │
│ ACCIÓN: Arreglar si es rápido, sino siguiente sprint │
└─────────────────────────────────────────────────────────────┘
BAJO (P3):
┌─────────────────────────────────────────────────────────────┐
│ • Cosmético o menor │
│ • Edge case raro │
│ • Casi no afecta usuarios │
│ │
│ ACCIÓN: Cerrar o arreglar si toma < 30 minutos │
└─────────────────────────────────────────────────────────────┘
Implementación Paso a Paso
Fase 1: Limpiar Backlog Existente
LIMPIEZA INICIAL
════════════════
PASO 1: AUDITAR BUGS ACTUALES
┌─────────────────────────────────────────────────────────────┐
│ Contar bugs abiertos: ___ │
│ Bugs > 30 días: ___ │
│ Bugs > 90 días: ___ │
└─────────────────────────────────────────────────────────────┘
PASO 2: TRIAGE MASIVO
┌─────────────────────────────────────────────────────────────┐
│ Para cada bug, decidir: │
│ ├── ¿Sigue siendo válido? (Cerrar si no) │
│ ├── ¿Es reproducible? (Cerrar si no) │
│ ├── ¿Es bug o feature? (Recategorizar) │
│ └── ¿Vale la pena arreglar? (Cerrar si no) │
└─────────────────────────────────────────────────────────────┘
PASO 3: BUG BANKRUPTCY (si necesario)
┌─────────────────────────────────────────────────────────────┐
│ Si hay > 50 bugs viejos: │
│ ├── Cerrar todos los bugs > 90 días │
│ ├── Notificar: "Si sigue pasando, reabrir" │
│ └── Empezar limpio │
└─────────────────────────────────────────────────────────────┘
Fase 2: Establecer Nuevos Procesos
NUEVAS REGLAS
═════════════
REGLA 1: DEFINICIÓN ESTRICTA DE BUG
┌─────────────────────────────────────────────────────────────┐
│ Bug = "El sistema no hace lo que la spec dice" │
│ │
│ NO es bug: │
│ ├── "Sería mejor si..." │
│ ├── "Me gustaría que..." │
│ └── "Otros sistemas hacen..." │
└─────────────────────────────────────────────────────────────┘
REGLA 2: TRIAGE DIARIO
┌─────────────────────────────────────────────────────────────┐
│ Cada mañana (15 min): │
│ ├── Revisar nuevos bugs reportados │
│ ├── Categorizar cada uno │
│ ├── Asignar o cerrar │
│ └── Objetivo: Inbox zero para bugs │
└─────────────────────────────────────────────────────────────┘
REGLA 3: FIX IT NOW
┌─────────────────────────────────────────────────────────────┐
│ Si el bug toma < 2 horas: │
│ → Arréglalo ahora, no agregues al backlog │
│ │
│ Si toma > 2 horas: │
│ → Agregar al sprint (máx 1-2 en cola) │
└─────────────────────────────────────────────────────────────┘
Métricas Zero-Bug
KPIs A MONITOREAR
═════════════════
MÉTRICAS DE SALUD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Bugs Abiertos │ Objetivo: < 5 │
│ Edad Promedio │ Objetivo: < 3 días │
│ Bug más viejo │ Objetivo: < 1 semana │
│ Bugs cerrados/semana │ ≈ Bugs abiertos/semana │
│ │
└─────────────────────────────────────────────────────────────┘
DASHBOARD EJEMPLO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 📊 ESTADO ZERO-BUG │
│ │
│ Bugs Abiertos: 3 ✅ (< 5) │
│ Edad Promedio: 1.2 días ✅ (< 3) │
│ Bug más viejo: 4 días ✅ (< 7) │
│ │
│ Esta semana: │
│ Reportados: 7 │ Cerrados: 8 │ Balance: +1 ✅ │
│ │
└─────────────────────────────────────────────────────────────┘
Resistencia Común
OBJECIONES Y RESPUESTAS
═══════════════════════
"No tenemos tiempo para arreglar bugs"
┌─────────────────────────────────────────────────────────────┐
│ RESPUESTA: Los bugs acumulados toman MÁS tiempo. │
│ Un bug de 2 horas hoy es un bug de 8 horas en 6 meses │
│ (contexto perdido, código cambiado, regresiones). │
└─────────────────────────────────────────────────────────────┘
"Los stakeholders quieren features, no fixes"
┌─────────────────────────────────────────────────────────────┐
│ RESPUESTA: Calidad ES un feature. │
│ Producto estable = usuarios contentos = retención. │
│ Bugs acumulados = deuda que bloquea features futuros. │
└─────────────────────────────────────────────────────────────┘
"Tenemos demasiados bugs para empezar"
┌─────────────────────────────────────────────────────────────┐
│ RESPUESTA: Bug bankruptcy. │
│ Cerrar todos los bugs viejos. │
│ Si el bug es real, será reportado de nuevo. │
│ Empezar limpio es mejor que arrastrar deuda. │
└─────────────────────────────────────────────────────────────┘
Configuración en GitScrum
SETUP PARA ZERO-BUG EN GITSCRUM
═══════════════════════════════
LABELS:
┌─────────────────────────────────────────────────────────────┐
│ 🔴 bug:critical → Drop everything │
│ 🟠 bug:high → Este sprint │
│ 🟡 bug:medium → Rápido o siguiente sprint │
│ 🟢 bug:low → Evaluar cerrar │
└─────────────────────────────────────────────────────────────┘
FILTRO RÁPIDO:
┌─────────────────────────────────────────────────────────────┐
│ Guardar vista: "Bugs Abiertos" │
│ Filtro: label contains "bug" │
│ Ordenar: Por prioridad, luego por fecha creación │
└─────────────────────────────────────────────────────────────┘
AUTOMATIZACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ Trigger: Bug > 7 días sin actividad │
│ Acción: Notificar al asignado + líder │
└─────────────────────────────────────────────────────────────┘
Checklist de Implementación
CHECKLIST ZERO-BUG
══════════════════
PREPARACIÓN:
☐ Auditar bugs actuales
☐ Decidir si hacer bug bankruptcy
☐ Definir categorías de severidad
☐ Comunicar al equipo la nueva política
PROCESO:
☐ Establecer triage diario
☐ Definir qué es y no es un bug
☐ Crear regla de "< 2 horas = arreglar ahora"
☐ Establecer límite de bugs en cola (máx 2)
MONITOREO:
☐ Configurar dashboard de bugs
☐ Revisar métricas semanalmente
☐ Celebrar "zero bug days"
☐ Retrospectiva mensual sobre bugs