Mejorando Performance del Equipo con Métricas
Usa datos para impulsar mejora del equipo sin crear cultura de medición tóxica. Selecciona métricas que importan e interprétalas sabiamente.
6 min de lectura
Las métricas iluminan el performance del equipo y guían la mejora cuando se usan con cuidado. GitScrum proporciona analytics de equipo incluyendo velocity, cycle time y métricas de calidad que ayudan a los equipos a identificar oportunidades de mejora sin fomentar competencia dañina.
Filosofía de Métricas
Cultura Saludable de Métricas
PRINCIPIOS DE MÉTRICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HACER: │
│ ✓ Usar métricas para aprendizaje y mejora del equipo │
│ ✓ Enfocarse en tendencias con el tiempo, no valores absolutos│
│ ✓ Dejar que equipos elijan y sean dueños de sus métricas │
│ ✓ Discutir métricas en retrospectivas │
│ ✓ Celebrar mejoras │
│ ✓ Usar múltiples métricas (scorecard balanceado) │
│ │
│ NO HACER: │
│ ✗ Comparar individuos usando métricas │
│ ✗ Vincular métricas directamente a compensación │
│ ✗ Usar métricas de forma punitiva │
│ ✗ Optimizar para métricas individuales │
│ ✗ Ignorar contexto al interpretar │
│ ✗ Establecer objetivos arbitrarios │
│ │
│ LEY DE GOODHART: │
│ "Cuando una medida se convierte en objetivo, deja de ser │
│ una buena medida." │
│ │
│ Ejemplo: Si mides líneas de código, la gente escribirá │
│ código más verboso, no mejor código. │
└─────────────────────────────────────────────────────────────┘
Categorías de Métricas
FRAMEWORK DE MÉTRICAS BALANCEADO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ENTREGA: │
│ ¿Cuánto trabajo se está haciendo? │
│ • Velocity (story points/sprint) │
│ • Throughput (items/semana) │
│ • Tasa de completación de sprint │
│ │
│ VELOCIDAD: │
│ ¿Qué tan rápido fluye el trabajo? │
│ • Cycle time (inicio a terminado) │
│ • Lead time (solicitud a terminado) │
│ • Turnaround de review │
│ │
│ CALIDAD: │
│ ¿Qué tan bueno es el trabajo? │
│ • Tasa de defectos (bugs por feature) │
│ • Defectos escapados (bugs en producción) │
│ • Ratio de deuda técnica │
│ │
│ SALUD DEL EQUIPO: │
│ ¿Cómo está el equipo? │
│ • Encuestas de satisfacción del equipo │
│ • Tasa de rotación │
│ • Burnout indicators │
│ │
└─────────────────────────────────────────────────────────────┘
Métricas Clave
Métricas DORA
MÉTRICAS DORA PARA EQUIPOS DE DESARROLLO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEPLOYMENT FREQUENCY: │
│ ¿Con qué frecuencia deployamos? │
│ Elite: Múltiples/día | Low: <1/mes │
│ │
│ LEAD TIME FOR CHANGES: │
│ Tiempo desde commit hasta producción │
│ Elite: <1 hora | Low: >6 meses │
│ │
│ CHANGE FAILURE RATE: │
│ % de deploys que causan incidentes │
│ Elite: 0-15% | Low: >45% │
│ │
│ TIME TO RESTORE: │
│ Tiempo para restaurar servicio después de incidente │
│ Elite: <1 hora | Low: >6 meses │
│ │
│ CORRELACIÓN: │
│ Equipos con mejores métricas DORA también tienen: │
│ • Mayor satisfacción del equipo │
│ • Menor burnout │
│ • Mejor calidad │
│ │
│ → Velocidad y calidad no son trade-offs │
│ │
└─────────────────────────────────────────────────────────────┘
Dashboard de Equipo
DASHBOARD DE MÉTRICAS DEL EQUIPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ VELOCITY (últimos 6 sprints): │
│ 28 → 32 → 34 → 30 → 35 → 36 │
│ Promedio: 32.5 | Tendencia: ↗️ +15% │
│ │
│ CYCLE TIME: │
│ Promedio: 4.2 días | Meta: <5 días ✅ │
│ Distribución: 60% <3 días, 30% 3-7 días, 10% >7 días │
│ │
│ CALIDAD: │
│ Bugs por release: 3.2 (↓ de 5.1) ✅ │
│ Bugs en producción: 1 (↓ de 2.5) ✅ │
│ │
│ SALUD DEL EQUIPO: │
│ Satisfacción: 4.1/5 | Trend: Estable │
│ Overtime: 2 horas/semana promedio ⚠️ │
│ │
│ SPRINT COMPLETION: │
│ Último sprint: 88% | Promedio: 85% │
│ │
└─────────────────────────────────────────────────────────────┘
Usando Métricas para Mejora
PROCESO DE MEJORA BASADO EN MÉTRICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. OBSERVAR │
│ Revisar métricas en retrospectiva │
│ "Cycle time aumentó 30% este sprint" │
│ │
│ 2. INVESTIGAR │
│ Buscar causas raíz │
│ "Code reviews tomaron 2 días en promedio" │
│ │
│ 3. HIPÓTESIS │
│ Proponer mejora │
│ "Si implementamos SLA de review de 4h, cycle time bajará"│
│ │
│ 4. EXPERIMENTAR │
│ Probar por 2-3 sprints │
│ "Implementamos SLA, rotación de reviewer" │
│ │
│ 5. EVALUAR │
│ ¿Funcionó? │
│ "Cycle time bajó 25%, adoptar permanentemente" │
│ │
│ REGLA: Cambiar una cosa a la vez para medir impacto │
│ │
└─────────────────────────────────────────────────────────────┘
Anti-Patrones
ERRORES COMUNES CON MÉTRICAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✗ MÉTRICAS DE VANIDAD │
│ Líneas de código, commits por día, horas trabajadas │
│ → No correlacionan con valor entregado │
│ │
│ ✗ GAMING DE MÉTRICAS │
│ Inflar story points para aumentar velocity │
│ → Métricas pierden significado │
│ │
│ ✗ COMPARACIÓN INDIVIDUAL │
│ "Carlos completó más tickets que María" │
│ → Ignora complejidad, calidad, colaboración │
│ │
│ ✗ OBJETIVOS ARBITRARIOS │
│ "Deben aumentar velocity 20% este quarter" │
│ → Lleva a shortcuts de calidad o burnout │
│ │
│ ✗ MEDICIÓN SIN ACCIÓN │
│ Colectar datos pero nunca discutir ni actuar │
│ → Desperdicio de esfuerzo │
│ │
└─────────────────────────────────────────────────────────────┘