4 min lectura • Guide 148 of 877
Métricas de Productividad de Desarrolladores
Medir la productividad de desarrolladores es esencial pero lleno de peligros. Métricas malas crean gaming, destruyen moral, y fallan en capturar lo que importa. Buenas métricas proporcionan insight, impulsan mejora, y respetan la complejidad del desarrollo de software.
Filosofía de Métricas
| Evitar | Abrazar |
|---|---|
| Líneas de código | Valor entregado |
| Commits por día | Tiempo de ciclo |
| Horas trabajadas | Throughput |
| Ranking individual | Performance del equipo |
| Métricas de actividad | Métricas de resultado |
Métricas Útiles
Métricas DORA
FRAMEWORK DE MÉTRICAS DORA
══════════════════════════
FRECUENCIA DE DEPLOYMENT
├── Qué tan seguido se deploya código a producción
├── Elite: Múltiples veces por día
├── Alta: Semanal a mensual
├── Media: Mensual a anual
├── Baja: Menos de anual
LEAD TIME PARA CAMBIOS
├── Tiempo desde commit hasta producción
├── Elite: Menos de una hora
├── Alta: Un día a una semana
├── Media: Una semana a un mes
├── Baja: Más de un mes
TASA DE FALLO DE CAMBIOS
├── Porcentaje de deployments causando issues
├── Elite: 0-15%
├── Alta: 16-30%
├── Media: 31-45%
├── Baja: 46-100%
TIEMPO MEDIO PARA RECUPERAR (MTTR)
├── Tiempo para restaurar servicio después de incidente
├── Elite: Menos de una hora
├── Alta: Menos de un día
├── Media: Un día a una semana
├── Baja: Más de una semana
Métricas de Flujo
MÉTRICAS DE FLUJO
═════════════════
TIEMPO DE CICLO
├── Tiempo desde trabajo iniciado a trabajo completado
├── Mide: Eficiencia de desarrollo
├── Bueno para: Identificar cuellos de botella
├── Objetivo: Consistente, tendiendo hacia abajo
Desglose Típico:
├── Desarrollo: 40%
├── Code review: 30%
├── QA/Testing: 20%
└── Deploy: 10%
LEAD TIME
├── Tiempo desde request hasta entrega
├── Mide: Responsividad total
├── Bueno para: Perspectiva del cliente
├── Incluye: Tiempo en cola antes de empezar
THROUGHPUT
├── Items completados por período de tiempo
├── Mide: Capacidad de entrega
├── Bueno para: Planificación, predictibilidad
├── Comparar: Semana a semana
TRABAJO EN PROGRESO (WIP)
├── Items actualmente en progreso
├── Mide: Enfoque vs context switching
├── Bueno para: Detección de sobrecarga
├── Objetivo: Bajo y estable
Métricas de Calidad
MÉTRICAS DE CALIDAD
═══════════════════
DENSIDAD DE BUGS
├── Bugs por feature o por release
├── Tendencia: Debería disminuir con el tiempo
├── Acción: Invertir en testing si alta
└── Contexto: Algunos features naturalmente más riesgosos
COBERTURA DE TESTS
├── Porcentaje de código cubierto por tests
├── Objetivo: 70-80% (no 100%)
├── Acción: Cubrir paths críticos
└── Advertencia: Cobertura ≠ calidad
MÉTRICAS DE CODE REVIEW
├── Tiempo a primer review
├── Ciclos de review por PR
├── Tendencia: Debería ser estable
└── Acción: Mejorar si aumentando
DEUDA TÉCNICA
├── Tiempo gastado en mantenimiento vs features
├── Tendencia: Balance saludable 80/20
├── Acción: Reservar tiempo para reducir
└── Medir: Rastrear en GitScrum con labels
Anti-Patrones de Métricas
ANTI-PATRONES A EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ LÍNEAS DE CÓDIGO │
│ → Incentiva código verbose │
│ → Penaliza refactoring que reduce código │
│ → Fácilmente gamed │
│ │
│ ❌ COMMITS POR DÍA │
│ → Incentiva commits pequeños sin sentido │
│ → No correlaciona con productividad real │
│ → Ignora calidad │
│ │
│ ❌ HORAS TRABAJADAS │
│ → Recompensa presencia sobre output │
│ → Ignora eficiencia │
│ → Lleva a burnout │
│ │
│ ❌ RANKING INDIVIDUAL │
│ → Destruye colaboración │
│ → Crea competencia tóxica │
│ → Gaming del sistema │
│ │
└─────────────────────────────────────────────────────────────┘