El Lead Time for Changes es una de las métricas más interesantes en la actualidad para evaluar la eficiencia del proceso de desarrollo de software y la efectividad de las iniciativas DevOps. En este artículo explicaremos en qué consiste y detallaremos cómo se calcula, cómo podemos medirlo y cómo reducirlo para conseguir mejores resultados comerciales.
Lo que vas a ver en este post:
¿Qué son las métricas DevOps?
Las métricas DevOps son medidas que reflejan el rendimiento del proceso de desarrollo de software y permiten conocer si los esfuerzos DevOps están funcionando o no, así como qué aspectos pueden mejorarse. Permiten conocer la productividad de nuestra pipeline de desarrollo de software DevOps y ayudan a identificar y eliminar rápidamente cuellos de botella.
Estas métricas miden factores como la velocidad de desarrollo, la frecuencia de implementación y errores o el tiempo de reparación. De este modo, suelen centrarse en los despliegues, las operaciones y el soporte, las áreas donde DevOps invierte la mayoría de sus esfuerzos. Gracias a ellas obtenemos una visión completa del proceso DevOps y podemos conocer exactamente dónde nos encontramos, hacia dónde vamos, a dónde queremos ir y cómo llegar allí.
Es muy difícil mejorar un proceso si no lo medimos. Y esto se aplica también a DevOps. Si las organizaciones quieren entregar productos digitales de mayor calidad más rápido, necesitan medir. Las métricas DevOps proporcionan a los equipos la información que necesitan para tener visibilidad y control sobre su pipeline, promoviendo que consigan resultados comerciales significativamente mejores.
¿Qué es el Lead Time for Changes?
El Lead Time for Changes o tiempo de ejecución para cambios mide el tiempo que un commit (una corrección de errores, una nueva funcionalidad u otro cambio en el código) tarda en llegar a producción. Es decir, cuánto tiempo dedica el equipo a implementar, testear y entregar código a los usuarios. También se conoce como Change Lead Time o Mean Time to Change.
Es una de las cuatro medidas clave (Four Key Metrics) para analizar el rendimiento del desarrollo de software con un enfoque DevOps y, sin duda, una de las métricas de velocidad más interesantes para que una organización pueda trabajar la reducción de sus tiempos de entrega.
Esta medida es un buen indicador de la eficiencia del proceso de desarrollo, de la complejidad del código y de la capacidad del equipo. Un Lead Time for Changes demasiado elevado advierte de que es posible que existan ineficiencias o cuellos de botella. Mientras que un Lead Time reducido muestra que el equipo es capaz de reaccionar rápidamente al feedback o los cambios en el mercado.
En definitiva, el Lead Time for Changes es una de las métricas más valiosas para medir las iniciativas DevOps. Por un lado, a nivel de equipo, analiza sus capacidades midiendo la frecuencia con la que realiza despliegues. Por otro, en relación a los objetivos comerciales, muestra cómo la organización responde a las necesidades cambiantes de los usuarios.
¿Qué Lead Time for Changes debe tener un equipo?
El tiempo que un equipo tarda en entregar cambios a los usuarios varía en función de su capacidad. Según el informe Accelerate State of DevOps de 2021, el Lead Time for Changes de un equipo de élite es de menos de una hora; de un equipo de alto nivel es de entre un día y una semana; de un equipo de medio rendimiento de entre un mes y seis meses; y de un equipo de bajo rendimiento de más de seis meses.
La idea es que, con el paso del tiempo, esta métrica sea cada vez menor. Uno de los objetivos fundamentales de DevOps es reducir los tiempos de entrega. Por lo que la meta es tener un Lead Time pequeño que permita al equipo recibir feedback continuamente y entregar software de calidad rápidamente.
¿Cómo calcular el Lead Time for Changes?
El Lead Time for Changes se calcula capturando el momento en el que se inicia una revisión (commit) en la pipeline y cuándo esa misma actualización del código se despliega en producción. La diferencia entre ambos tiempos nos da el tiempo que el equipo tarda en desplegar en producción el cambio en el código.
Si hacemos una media del tiempo que el equipo emplea en desplegar commits durante periodo de tiempo, obtendremos el tiempo medio que tardan los cambios en desplegarse en producción.
Existen distintos acercamientos a DevOps en los que el principio y final que tomamos como referencia para aplicar esta medida varían. No obstante, la definición más extendida es que el Lead Time for Changes mide el tiempo que pasa desde que el código cambia (el equipo realiza el primer commit) hasta que llega a manos de los usuarios (es desplegado en producción).
¿Cómo medirlo?
Las plataformas de Value Stream Management como SENTRIO facilitan mucho la medición de esta métrica. Recopilan todos los datos necesarios conectando las herramientas que intervienen en el proceso y presentan la información de forma visual e intuitiva para que el equipo se centre solamente en tomar decisiones que mejoren sus resultados.
Concretamente, SENTRIO presenta en una gráfica (como la que vemos en esta imagen) el Lead Time for Changes de cada una de las tareas (funcionalidades, resolución de errores, tareas y spikes) y su correspondiente línea de tendencia.
Esto ayuda al equipo a poner el foco en las anomalías, las tareas que tienen un Lead Time elevado y, por tanto, han supuesto un mayor tiempo.
Como decíamos, el objetivo es que el Lead Time for Changes sea bajo o cada vez menor. Por lo que, si el equipo va por el buen camino, la línea de tendencia debería ir descendiendo.
Causas de un Lead Time alto
Las principales causas de un Lead Time for Changes elevado son:
- Que los cambios a introducir en el código sean muy grandes.
- Que las pruebas u otras fases se estén realizando de forma manual.
- Que haya ineficiencias durante el proceso de desarrollo (dependencias, bloqueos, código legacy…).
- Que se estén produciendo cuellos de botella.
¿Cómo reducir el Lead Time for Changes?
Para reducir el Lead Time for Changes resulta fundamental:
Automatizar pruebas
La automatización de pruebas es una medida muy eficaz para reducir los tiempos de entrega. Conlleva dos prácticas DevOps fundamentales: la integración continua (CI) y la entrega continua (CD).
Trabajar en pequeños cambios
Si el equipo tarda demasiado en entregar una innovación a los usuarios, puede que sus necesidades hayan cambiado y el esfuerzo realizado ya no sea útil. Por ello, resulta más beneficioso realizar entregas pequeñas y frecuentes. Además, trabajar con versiones más pequeñas de cambios facilita que los desarrolladores puedan recibir feedback más rápido e identificar y resolver defectos antes.
Conclusión
El Lead Time for Changes es una métrica fundamental para analizar y mejorar la efectividad de las iniciativas DevOps. Una medida muy valiosa para conocer las capacidades de un equipo y de la organización para responder a las necesidades del mercado.
Junto con otras métricas como la frecuencia de despliegues, el tiempo medio de restauración o la tasa de cambios con fallos aporta información valiosa para que las organizaciones obtengan mejores resultados con sus productos digitales.
Con la plataforma de Value Stream Management SENTRIO podrás medir y analizar el Lead Time for Changes de tus iniciativas de forma sencilla y tomar mejores decisiones.
Visualiza en tiempo real la velocidad y calidad de tus productos de software, medidos con las DORA Four Key Metrics. ¡Solicita una demo gratuita ahora!
