Con el objetivo de evaluar el desempeño de sus equipos de desarrollo, cada vez son más las organizaciones que descubren el potencial de las métricas DORA y lo aprovechan. Frente a esto, la Cámara de la Industria Argentina del Software (CESSI) organizó el webinar “Métricas de Performance Ingenieril (DORA)”, en el que Diego Colombo, CTO de Visma Latam, brindó una exposición exhaustiva sobre su uso para mejorar la productividad.
“La idea es tratar de llevar las buenas prácticas que hay en el mercado como para bajarnos nosotros en nuestros equipos y poder tener buenas mediciones de nuestros equipos”, dijo Colombo para introducir el evento.
Índice de temas
Productividad, deuda técnica y el mito de la velocidad
Luego de una breve encuesta inicial a los asistentes, Colombo retomó conceptos fundamentales sobre el desarrollo de software como la Ley de Lehman. “Si yo uso siempre lo mismo, la satisfacción que le va dando al usuario empieza a bajar y empieza a perderse”, explicó, por lo que remarcó la necesidad de estar en un continuo cambio. Tras esto, destacó otra ley: “A medida que pasa el tiempo, más se complejiza”.
Esta complejidad creciente genera un fenómeno conocido como deuda técnica, que impacta de forma directa en la capacidad de evolución del producto. Según Colombo, esto hace que “la velocidad y la estabilidad del ecosistema estén un poquito contrariadas”. Esta idea llevó durante años a pensar que es difícil ser rápido y estable al mismo tiempo. “Si no te caés muy seguido es porque no estás yendo muy rápido”, citó Colombo en referencia a una de las máximas comunes del sector.
Lo cierto es que la tensión entre desarrollo y operaciones también se manifiesta en la cultura DevOps. “Los Dev quieren sacar cosas a producción y muchas veces los de operaciones dicen ‘no voy a poner nada de esto porque el código no está bien’”, explicó Colombo a modo de ejemplo. De esta forma, el famoso trade-off entre velocidad y estabilidad parecía ineludible, al menos hasta la llegada de las métricas DORA.
Las métricas DORA y el fin del mito
El fin de esta visión llegó con la publicación de Accelerate en 2018. Se trata de un libro basado en un estudio científico iniciado en 2016 que realizó 23.000 encuestas a más de 2.000 organizaciones. Este libro “revolucionó bastante la industria porque lo que dijo es: el mito de la velocidad y estabilidad no existe”, afirmó Colombo. “No hay un trade-off entre una cosa y la otra. Yo puedo ser rápido y a la vez puedo ser estable”, añadió.
El libro divide sus contenidos en dos partes: resultados y metodología. Colombo recomendó el apéndice A, en donde se identifican 24 capacidades o capabilities que correlacionan con un mejor rendimiento organizacional. Algunas de ellas son control de versiones, integración continua, automatización de tests, cultura colaborativa y ausencia de “la cultura del miedo”.
“Trabajar bien hoy generando software es implementar esto, es tener esto como un ABC”, sostuvo Colombo. “Estas son características, capabilities que me van a permitir a mí generar software de mejor calidad”, continuó.
Los indicadores esenciales de las Métricas DORA
El núcleo de la propuesta de Accelerate, y del modelo DORA, son cuatro métricas fundamentales para evaluar la performance del desarrollo de software que se dividen en las dimensiones de velocidad y estabilidad.
Por un lado, las métricas de velocidad son:
- Frecuencia de despliegue (Deployment Frequency): indica cuántas veces un equipo puede llevar cambios a producción. “En el año 2018, Amazon hacía una release a producción cada 10 segundos”, ejemplificó Colombo.
- Tiempo de entrega (Lead Time for Changes): mide el tiempo que pasa desde que un desarrollador finaliza un cambio hasta que ese cambio está en producción. No obstante, Colombo afirmó que en Visma utilizan una variante denominada Delivery Lead Time.
Por su parte, las métricas de estabilidad son:
- Porcentaje de fallos por cambio (Change Failure Rate): refleja el porcentaje de despliegues que causan errores, regresiones o interrupciones del servicio. “Es, de todos los deploy que yo hice a producción, en cuántos se me cayó la plataforma”, aclaró Colombo.
- Tiempo de restauración del servicio (Time to Restore Service): mide cuánto tiempo toma volver a un estado funcional tras una falla. De esta forma, “luego podré sacar promedios”, comentó Colombo.
Por último, Colombo se refirió a una métrica de estabilidad que fue agregada al modelo más tarde. Se trata de la disponibilidad (availability), que es el porcentaje de tiempo que la plataforma está disponible para los usuarios. “Esto depende mucho de qué plataforma tengo”, dijo. “Si yo tengo una red social y justamente no puedo ver fotos, ahí vamos a considerar que no está disponible”, ejemplificó.
Métricas DORA en la práctica
Durante la presentación, Diego Colombo destacó que no es necesario tener un ecosistema de herramientas sofisticadas para comenzar a medir. De hecho, alentó a los asistentes a empezar de manera simple: “Podemos empezar mañana con un Excel”.
En este sentido, las herramientas más comunes en los equipos, como Git, Jenkins, Jira, entre otras, pueden complementarse con procesos manuales como tickets que registren despliegues, incidentes o caídas.
Por otro lado, Colombo advirtió sobre el mal uso de las métricas: “Siempre hablamos de equipos, no de individuos. ¿Podemos llegar a ver el nivel individual? Sí, lo podemos ver. Pero, dentro de las capabilities, lo que buscamos es un grupo colaborativo”.
Para ilustrarlo, Colombo citó un paper en el que el reconocido especialista Norton cuenta que el peor desarrollador con el que trabajó, en cuanto a métricas, era la persona que más ayudaba al equipo. El mensaje es claro: las métricas DORA deben servir para generar conversaciones y detectar oportunidades, y no para establecer rankings individuales ni castigos.
Los datos que dejó una encuesta local
Colombo compartió los resultados de una encuesta que realizaron junto a CESSI entre empresas del sector. Una de las preguntas más reveladoras estuvo vinculada al uso de integración continua: “40% es un volumen bastante grande que no está utilizando integración continua”, advirtió.
El dato sorprende, ya que se trata de una práctica recomendada desde hace décadas. “La integración continua tiene un poder muy grande que es, primero, compilar, correr los tests y verificar que el artefacto que yo construyo esté bien”, señaló Colombo.
Otro dato relevante fue que el 28% de los equipos mantiene feature branches por más de una semana, lo que puede ser problemático: “la tendencia es que si uno utiliza feature branch tenga menos de un día de duración”, dijo Colombo. Esto, además de facilitar el merge, reduce el riesgo y mejora la comunicación entre integrantes del equipo.
Casos reales: qué pasa cuando se usan las métricas DORA
Por último, Colombo mostró dos ejemplos reales con datos de productos de Visma. El primero tenía un delivery lead time de 7,85 días, una frecuencia de 82 deploys al mes, un change failure rate del 10%, time to restore de 10 minutos y disponibilidad del 99,99%. Aunque llegaban seguido a producción, el proceso era lento: “Es probable que este equipo no tenga buenos test, no tenga test automatizados y todos los test sean manuales”, afirmó.
El segundo caso presentaba un lead time muy bajo, de una hora, pero con solo 17 deploys mensuales y un time to restore elevado, de tres horas. Este software “está en un estado mucho más maduro que no requiere tanto cambio”, reconoció Colombo. Sin embargo, en un caso de alto time to restore como este, “podemos mejorar en que haya más resiliencia”, explicó.
En definitiva, las métricas DORA sirven para aprender, mejorar y construir software de calidad de forma colaborativa y sostenible. A modo de cierre, Colombo dejó una invitación concreta: “Empecemos a usarlo y mejoremos nuestra industria. Mejoremos con estos estándares”.
