Implementa el sistema de métricas de ingeniería que mide la velocidad, la calidad y la salud técnica del equipo con los frameworks DORA y SPACE y las herramientas que los hacen accionables.
Cuándo usarlo: Implementación de métricas DORA y cycle time para equipos de ingeniería
Herramienta recomendada: Claude
Actúa como un Engineering Manager o VP of Engineering con experiencia implementando sistemas de métricas de ingeniería en equipos de desarrollo de software. Quiero diseñar e implementar el sistema de métricas que da visibilidad real sobre la velocidad, la calidad y la salud del equipo de ingeniería, que sea útil tanto para el equipo como para la dirección. **Preguntas iniciales:** 1. ¿Cuál es el tamaño del equipo de ingeniería y su estructura (squads, capas, fullstack vs especialistas)? 2. ¿Qué herramientas de desarrollo usáis (GitHub/GitLab, Jira, Datadog, Sentry, etc.)? 3. ¿Cuál es el ciclo de despliegue actual: varias veces al día, una vez a la semana o menos frecuente? 4. ¿El objetivo de las métricas es para visibilidad interna del equipo, para reportar a la dirección o para ambos? 5. ¿Hay algún problema específico que las métricas deben iluminar: velocidad de entrega, calidad del código, deuda técnica o satisfacción del equipo? **EL FRAMEWORK DORA: LAS CUATRO MÉTRICAS CLAVE:** Las métricas DORA (DevOps Research and Assessment) son el estándar de la industria para medir el rendimiento de los equipos de ingeniería de software. Se componen de cuatro métricas que miden la velocidad y la estabilidad del sistema de entrega: DEPLOYMENT FREQUENCY (FRECUENCIA DE DESPLIEGUE) La frecuencia con la que el equipo despliega código a producción. Los equipos de élite despliegan varias veces al día; los de alto rendimiento despliegan una vez por semana o más; los de rendimiento medio despliegan entre una vez a la semana y una vez al mes; los de bajo rendimiento despliegan menos de una vez al mes. Ayúdame a medir esta métrica, a establecer el objetivo para mi equipo y a diseñar las prácticas (feature flags, trunk-based development, CI/CD maduro) que aumentan la frecuencia de despliegue. LEAD TIME FOR CHANGES (TIEMPO DE ENTREGA DE CAMBIOS) El tiempo desde que el código es commiteado hasta que está en producción. Mide la agilidad del sistema de entrega: un lead time corto significa que el equipo puede responder rápidamente a las prioridades cambiantes y a los bugs en producción. Ayúdame a medir el lead time de mi equipo, a identificar los cuellos de botella en el pipeline de entrega y a diseñar las mejoras que lo reducen. MEAN TIME TO RESTORE (TIEMPO MEDIO DE RECUPERACIÓN) El tiempo medio que tarda el equipo en restaurar el servicio después de un incidente en producción. Mide la resiliencia del sistema y la madurez de los procesos de respuesta a incidentes. Ayúdame a medir el MTTR de mi equipo, a diseñar los runbooks y las prácticas de on-call que lo reducen y a establecer los objetivos de recuperación por nivel de severidad del incidente. CHANGE FAILURE RATE (TASA DE FALLOS DE CAMBIOS) El porcentaje de cambios en producción que generan un fallo que requiere un rollback, un hotfix o un parche. Mide la calidad del proceso de entrega. Los equipos de élite tienen una tasa de fallos del 0-15%; los de alto rendimiento del 16-30%. Ayúdame a medir esta métrica en mi equipo y a diseñar las prácticas de testing, revisión y despliegue que la reducen. **CYCLE TIME: LA MÉTRICA DE VELOCIDAD DEL EQUIPO:** El cycle time (tiempo de ciclo) mide el tiempo que tarda una tarea desde que el equipo empieza a trabajar en ella hasta que está disponible para el usuario. Es la métrica más útil para el equipo porque es completamente bajo su control. Ayúdame a medir e interpretar el cycle time: DESCOMPOSICIÓN DEL CYCLE TIME El cycle time se descompone en: tiempo de coding (desde que el developer empieza hasta que abre el PR), tiempo de review (desde que abre el PR hasta que se aprueba), tiempo de merge (desde la aprobación hasta el merge) y tiempo de despliegue (desde el merge hasta que está en producción). Cada fase puede ser un cuello de botella diferente. Ayúdame a identificar dónde está el mayor cuello de botella en mi pipeline de entrega. **MÉTRICAS DE CALIDAD DE CÓDIGO:** CODE COVERAGE Y DEUDA TÉCNICA Las métricas de calidad del código que importan: la cobertura de tests (qué porcentaje del código tiene tests automatizados), la tendencia de la deuda técnica (está aumentando o disminuyendo), el número de bugs por sprint (regresiones) y el tiempo de build (un proxy de la complejidad del sistema). Ayúdame a establecer los umbrales de aceptabilidad para cada una de estas métricas y el proceso de revisión regular que las mantiene bajo control. **EL FRAMEWORK SPACE PARA LA SATISFACCIÓN DEL EQUIPO:** Las métricas DORA miden el rendimiento del sistema de entrega pero no miden la satisfacción del equipo, que es el predictor más importante del rendimiento a largo plazo. El framework SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) añade la dimensión humana. Ayúdame a implementar una encuesta trimestral del equipo que mide las dimensiones del SPACE y que produce insights accionables. **EL DASHBOARD DE INGENIERÍA:** PARA EL EQUIPO El dashboard que el equipo ve en su día a día: el cycle time de las tareas en curso, el estado del pipeline de CI/CD, la tasa de fallos de la última semana y el número de bugs abiertos por prioridad. Ayúdame a diseñar este dashboard en las herramientas que ya usamos. PARA LA DIRECCIÓN El dashboard mensual para el CEO o el CPO: las métricas DORA del mes comparadas con el mes anterior y con los objetivos, el rendimiento del equipo en términos de features entregadas versus planificadas y la salud técnica del sistema (deuda técnica, incidentes, tiempo de build). Ayúdame a diseñar la presentación mensual de las métricas de ingeniería para la dirección que sea comprensible para no-técnicos. Dame el sistema completo de métricas de ingeniería que da visibilidad real sobre la velocidad, la calidad y la salud del equipo.