Medir y mejorar el rendimiento de un equipo o un proceso es un objetivo que desde que existe la industria se persigue, con diferentes enfoques. Ya sea en fábricas donde se mide el rendimiento de una cadena de construcción, o, en nuestro caso, en equipos de desarrollo software. Pero para poder medir y tomar decisiones conforme a datos, primero hay que analizar. Analizar y decidir qué KPIs (Key Performance Indicator) vamos a usar y cómo. En este post vamos a analizar cuatro métricas bien conocidas y establecidas en el mercado, basadas en métricas DORA (DevOps Research and Assessment) y qué podemos hacer en nuestro día a día para mejorar, desde el mismo momento que estás leyendo estas líneas.
¿Qué son las Four Key Metricts o Métricas DORA?
Las cuatro métricas clave (Four Key Metrics) o Métricas DORA, no son unos KPIs al uso. Indicadores que nos ayudan a tomar buenas decisiones para mejorar el rendimiento organizativo pero también son buenos indicadores que nos alertan en caso de deterioramiento del proceso y prácticas de desarrollo software. Estas cuatro métricas están categorizadas en dos áreas para medir tanto el rendimiento del proceso de desarrollo (cuánto entregamos) y la estabilidad de lo que entregamos (cómo lo entregamos). Los estudios demuestran que equipos que son top-performers en las cuatro métricas, lo son en conjunto, ya que están correlacionadas, tal y como veremos ahora, así como las prácticas recomendadas para mejorar cada una de ellas.
Throughput
La primera categoría sobre la que se definen dos de las cuatro métricas claves es el «throughput«, que podríamos traducir como rendimiento o la velocidad de realizar cambios en entornos productivos en nuestro software. Tenemos los dos siguientes KPIs:
Frecuencia de despliegue (Deployment Frequency)
Está métrica nos indica cómo de frecuentemente estamos desplegando o haciendo releases en producción. Se considera que un equipo que entrega frecuentemente tiene un proceso de delivery muy maduro y resistente. Hay dos puntos importantes para conseguir mejorar nuestra frecuencia de despliegue:
- Infraestructura: es necesario disponer de una infraestructura que permita de forma rápida desplegar cualquiera de nuestros artefactos en cualquier entorno de la forma más automática posible
- Releases pequeñas: para conseguir piezas de código pequeñas sean desplegables, tendremos que poner el foco en la definición de historias de usuario también pequeñas. Para ello, el PO puede dividir en escenarios los diferentes criterios de aceptación y, junto con el equipo en sesiones de refinamientos, dividir en historias más pequeñas, manejables, que puedan llegar a producción de forma independiente. Pero claro, ¿qué consideramos una historia pequeña? Cada equipo puede estimar de una forma. Por ello, se recomienda realizar un estudio del tamaño de las historias entregadas en el último periodo (6 meses es una buena muestra) para determinar qué consideramos una historia de usuario pequeña y a partir de ahí, refinar y dividir.
Tiempo de entrega de cambios (Change Lead Time)
Esta métrica mide el tiempo que tarda un commit o un cambio en llegar a producción. Es diferente del tiempo de ciclo (realmente engloba el change lead time). Un buen valor aquí significa un proceso de entrega de software muy maduro. Lo primero que tendríamos que hacer para mejorar en esta métrica es analizar nuestro proceso completo de entrega de código y detectar aquellos puntos de desperdicio (el famoso «waste» que Lean nos indica) para erradicarlos. Algunos puntos típicos donde podemos mejorar desde hoy mismo:
- Tiempo de programación: la pieza de código es demasiado grande, por ello, hay que usar historias de usuario pequeñas, como en el punto anterior.
- Tiempo de primera revisión de PR (pick up time): suponiendo que trabajamos con revisión de Pull Request, el tiempo entre que se solicita y alguien revisa es clave para eficientar. Es un punto de mejora accionable muy rápido. El punto aquí es mejorar la comunicación, por ejemplo, con un canal del equipo sólo y exclusivamente para solicitar revisión de PR.
- Falta de automatización: si no tenemos una infraestructura suficiente y nuestro proceso de despliegue implica muchos pasos manuales, nos perjudicará en tiempos.
No tenemos que caer en el error de pensar que cuanto más entreguemos, mejor. Podemos tener un proceso muy fino en el que entregamos software en producción frecuentemente pero, sin embargo, son todo fixes a problemas encontrados. ¿Somos entonces realmente eficientes aunque el KPI nos diga que sí? ¿De qué vale que un equipo esté constantemente entregando si al usuario no llega verdadero valor o el sistema no es estable? Por eso, es importante también trabajar en los dos siguientes KPIs.
Estabilidad
Bajo este paraguas vamos a medir dos aspectos claves: qué calidad tiene lo que entregamos a los usuarios y cómo de preparado está el equipo para reaccionar ante un problema.
Tiempo medio de restauración (o MTTR Mean Time To Restore)
Con esta métrica medimos el tiempo que tardamos en recuperar el sistema de un despliegue fallido (o el despliegue ha ido bien pero hemos introducido un bug crítico por ejemplo). Si el tiempo de recuperación es pequeño, indica que somos capaces de responder rápido y bien. ¿Cómo mejorar? La primera respuesta es, por supuesto, infraestructura. Tenemos que tener las herramientas necesarias para hacer rollback de forma transparente al usuario lo más rápido posible. ¿Es esto suficiente? No. Esto es solo la mitad de la solución. No nos sirve de nada tener la mejor infraestructura del mercado si el problema o la orden de hacer rollback tarda o no llega al equipo. Posibles acciones:
- Revisar (y si no existe crearlo) el proceso de gestión de incidentes para asegurar que la información llega con la criticidad que se espera para poder actuar en consecuencia.
- Implementar un sistema de checkeos y alertas, con la intención de adelantarnos a los problemas
- Realizar sesiones de post-mortem una vez solventado los problemas para mejorar
Tasa de fallo de cambio (Change Failure Rate)
Esta métrica nos indica el porcentaje de despliegues que han dado error en producción y hayan requerido hotfixing o rollbacks. Podemos tener una gran velocidad respondiendo ante los errores, pero si, por ejemplo, el 50% de nuestros desplieguen dan error, tenemos un grave problema. ¿Qué podemos hacer para reducir este valor?
- Tener una buena red de tests incluyendo unitarios, de integración y end-to-end. Los tests automáticos nos permiten detectar problemas antes de que sucedan.
- Uso de feature flags siempre que sea posible. Una feature flag nos permite código «oculto» para el usuario, lo que permite subir de forma controlada nuevas funcionalidades y reducir riesgos
- Usar un sistema de monitorización. Definir bien los umbrales de error que no queremos pasar y, como en el punto anterior, adelantarnos a los problemas para solucionarlos.
Conclusión sobre Métricas DORA
Las métricas DORA, bien interiorizadas, y con buenas prácticas de DevOps en el equipo, hará que de forma natural mejore el rendimiento, el bienestar de los miembros y la confianza en el mismo. Primero hay que medir para saber dónde estamos, y luego intentar aplicar algunos de los puntos que hemos comentado. La mejora de tiempos llegará de forma natural.
¿Quieres mejorar el rendimiento de tu equipo de software? Contáctanos y te ayudaremos a implementar las mejores prácticas.
Síguenos en Redes Sociales y Canal de YouTube para mantenerte al tanto en lo último en programación, tecnología, Agile y ¡mucho más!
