Conseguir estabilidad y velocidad en la entrega de software

Creo que estamos de acuerdo en que queremos que nuestros equipos de entrega de software tengan éxito, cumpliendo con los plazos y el presupuesto previsto. Ser "exitoso" generalmente se reduce a dos cosas: velocidad y estabilidad. Las organizaciones quieren que sus equipos de entrega de software puedan crear y entregar productos rápidamente para que puedan estar en manos de sus clientes antes y permitir que la organización reaccione mejor a las demandas del mercado.

Las organizaciones también quieren un alto grado de confianza en los resultados que producen sus equipos de entrega de software. El software defectuoso, con errores o incorrecto hará que los clientes no estén contentos y probablemente dañen la reputación de la organización y / o provoquen pérdidas financieras.

Por lo general, este equilibrio entre estabilidad y velocidad se ha visto como una compensación que los equipos tenían que hacer: si los equipos van lento y a velocidad constante construyen productos de calidad o bien si se apresuran, toman atajos y probablemente introduzcan algunos fallos y errores en el camino.

Sin embargo, la empresa DORA (DevOps Research and Assessment), fundada por la Dra. Nicole Forsgren, Jez Humble y Gene Kim, argumenta que no tiene por qué ser una compensación: es posible crear software estable a gran velocidad. También tienen datos para respaldar esto, muchos de ellos. A través de su trabajo de investigación, han recopilado una gran cantidad de datos sobre diferentes organizaciones y han analizado detalladamente esos datos. Así, descubrieron que los equipos de software con mejor rendimiento obtuvieron un alto resultado en cuatro métricas: Deployment Frequency, Change Failure Rate, Mean Time To Recover (MTTR), Lead Time.

Frecuencia de despliegue (Deployment Frequency)

En pocas palabras: ¿con qué frecuencia despliega tu equipo en el entorno de producción? Cuanto más a menudo se desplieguen los cambios a producción y se pongan en manos de los clientes, más estrecho será el bucle de retroalimentación entre la empresa y el cliente. Una alta frecuencia de despliegue también significa que se está entregando valor a los clientes a un ritmo más rápido.

Tasa de fallo de cambios (Change Failure Rate)

Está muy bien desplegar el software a producción con frecuencia, pero si estos despliegues dan lugar a la introducción de cambios de ruptura que afectan a la capacidad de los clientes para utilizar el producto, entonces la entrega no es eficiente. Queremos desplegar nuevos cambios a producción con regularidad, pero no a costa de la calidad. El Change Failure Rate mide la frecuencia con la que un despliegue a producción tiene como resultado algún tipo de fallo.

Tiempo medio de recuperación (Mean Time To Recover - MTTR)

Si un equipo introduce un fallo en el sistema a través de un nuevo despliegue en la producción, es clave que el equipo sea capaz de detectarlo rápidamente y restablecer el estado de funcionamiento del sistema. El MTTR es una medida de esto: cuánto tiempo tarda un equipo en darse cuenta de que se ha introducido una regresión en el entorno de producción, en comprenderla y en restaurar el sistema a un estado saludable. En última instancia, para que los equipos lo hagan bien, deben invertir en una buena monitorización y observabilidad. Cada vez es más importante que los registros se envíen automáticamente a un repositorio central donde puedan consultarse fácilmente. Muchos equipos utilizan esto para construir paneles que reflejen la salud de su aplicación y la infraestructura relacionada y también para configurar alertas automáticas.

Tiempo de entrega (Lead Time)

El plazo de entrega es una medida del tiempo que transcurre desde que se confirma un cambio de código en el repositorio de control de versiones hasta que dicho cambio se ejecuta con éxito en producción. El análisis del tiempo de entrega permite a los equipos analizar todo su sistema de entrega y comprender dónde están los cuellos de botella. Una vez que los equipos conocen su plazo de entrega, puede ser una poderosa herramienta no sólo para identificar las partes del sistema que requieren optimización, sino que también puede desempeñar un papel clave en la toma de decisiones, tanto dentro del equipo como en toda la organización, ya que puede ayudar a responder a preguntas como: si empezamos a trabajar en esto hoy, ¿cuándo podremos ponerlo en producción? o ¿Se puede entregar esta característica a tiempo?

Estas cuatro métricas han resultado ser un fuerte indicador del éxito de los equipos de entrega de software. Los informes sobre el estado de los DevOps indican que los equipos que obtienen una puntuación alta en estas métricas tienden a obtener los mejores resultados. Mientras que los equipos que obtuvieron una puntuación baja tendieron a tener un menor rendimiento, como se indica en la siguiente tabla:

Credit: Forsgren PhD, Nicole. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

*Se comprobó que los equipos de bajo rendimiento tenían una media más baja (a un nivel estadísticamente significativo), pero tenían la misma mediana que los de rendimiento medio.

Las 4 métricas funcionan bien juntas porque seguirlas obliga a los equipos a adoptar buenas prácticas técnicas que se apoyan y refuerzan mutuamente. Por ejemplo, para poder desplegar el software con frecuencia, es necesario automatizar el proceso de despliegue. Lo que significa que hay un proceso repetitivo que está documentado en el código y que no depende únicamente del esfuerzo manual. Para tener una baja tasa de fracaso en los cambios, los equipos deben adoptar el testing. Pero si estas pruebas son totalmente manuales, afectarán a la capacidad del equipo para desplegar en el entorno de producción con frecuencia. Por lo tanto, la mayor parte de estas pruebas deben ser automatizadas. Para tener una buena medida del MTTR, los equipos necesitan invertir en alertas, monitorización y observabilidad. Esto les permite tener una buena comprensión de lo que su software está haciendo en producción, cómo está siendo utilizado por los clientes y, sobre todo, recibir alertas en caso de fallos. Pero no sólo eso, sino que también anima a los equipos a centrarse en su " Path to Production".

El MTTR no sólo consiste en ser capaz de detectar cuándo se produce un fallo y comprenderlo, sino también en resolver la situación. Para poder remediar rápidamente los fallos en la producción, los equipos deben tener un "Path to Production " fiable, es decir, una ruta bien establecida para introducir su software en el entorno de producción y tener confianza en ello. Por último, para que los equipos logren una buena medición del lead time, se requiere la automatización en torno a las pruebas, el packaging y el despliegue. El trabajo debe fluir sin problemas en el equipo y cualquier bloqueo que surja debe abordarse rápidamente y solucionarse. La unión de estas buenas prácticas es lo que, en última instancia, permite a los equipos ir rápido pero con un buen nivel de estabilidad. Permiten que la calidad sea intrínseca y crean mecanismos de retroalimentación rápidos.

Yo recomendaría que los equipos invirtieran tiempo en entender estas cuatro métricas y empezaran a capturarlas. Según mi experiencia, no recomendaría a los equipos que busquen valores absolutos en ninguna de las métricas. En su lugar, que empiecen por crear medidas de referencia en las cuatro. Esto permitirá conocer el rendimiento actual del equipo y las posibles áreas de mejora. Establecer mecanismos para medir regularmente las métricas e, idealmente, tener el proceso automatizado. Lo más importante es buscar la tendencia, es decir, si el rendimiento del equipo en cada métrica está mejorando.

En general, tener un control de cada una de las cuatro métricas analizadas en este artículo no sólo proporcionará una imagen completa del rendimiento del equipo, sino que también aportará información sobre los puntos de mejora y bloqueos. También, facilita un mecanismo de retroalimentación muy útil a la hora de introducir cambios en el equipo. Esforzarse por mejorar en cada una de las cuatro métricas asegurará que el equipo de entrega de software se mueva en la dirección adecuada para poder entregar productos de calidad a gran velocidad.