Entrega rápido

¿Cómo se mide la entrega de valor dentro del equipo de desarrollo?

oct 31, 2023

La semana pasada oí a Paul Adams, CPO de Intercom, hablar de uno de los principios de Intercom respecto al desarrollo de software.

Ship fast, learn fast

Fue oír la frase y querer una camiseta. Es verdad que esta frase compite con el famoso Fail fast, learn faster.

Pero el matiz para mí es importante. Si de verdad quieres triunfar, no basta con fracasar. También tienes que acertar alguna vez y además tienes que hacerlo rápido.

La semana pasada analizamos cómo medir cuánto acertamos con herramientas como Amplitude.

Cuando analizamos este impacto, es importante enteder, que las métricas de Amplitude pueden mejorar por otros motivos como campañas de marketing o eventos externos a la empresa (elecciones, un estreno, subida de precios, …). Ahora bien, ¿cómo podemos saber si estamos entregando rápido dentro del equipo de desarrollo?

Si desplegamos valor rápido, esto implica que:

El código que contiene la funcionalidad se tiene que programar rápido
Ese código se tiene que desplegar en producción en el menor tiempo posible
Al subir ese código, no puede romper otras funcionalidades
Si rompemos algo, hay que arreglarlo rápido

Si intentamos mejorar cualquiera de estas cuatro condiciones, las otras empeoran. Si me quiero asegurar de que no rompo ninguna funcionalidad existente, tardaré más en desplegar el código en producción, revisando que no afecte a ninguna otra funcionalidad. Si intento programar en poco tiempo, es más probable que suba código con algún error que no funcione como se espera.

¿Cómo podemos controlar que estamos cumpliendo estas cuatro necesidades, sin perjudicar al resto?

¡Midiendo!

Las métricas DORA

Estas métricas ofrecen una forma de medir y evaluar el rendimiento de un equipo en términos de eficiencia, calidad y confiabilidad en el proceso de desarrollo y despliegue de software. Las cuatro métricas principales son:

Frecuencia de despliegue: Frecuencia con la que un equipo despliega cambios en producción. Mide cuánto se actualiza el software con nuevas funcionalidades o mejoras. Por ejemplo, si un equipo despliega cambios una vez al trimestre, su frecuencia de despliegue es baja.
Tiempo de entrega: Tiempo que transcurre desde que se empieza una tarea hasta que termina en producción. Mide cuánto tarda un equipo en entregar valor al usuario final. Por ejemplo, si un equipo tarda una semana en pasar de una idea a un producto funcional, su tiempo de entrega es bajo.
Tiempo de restauración: Tiempo que lleva restaurar el servicio normal después de un fallo o incidente. Mide cuánto tarda un equipo en resolver los problemas que afectan al usuario final. Por ejemplo, si un equipo tarda una hora en arreglar un error que impide el acceso al software, su tiempo de restauración es bajo.
Tasa de fallo: Proporción de despliegues que resultan en fallos o errores en producción. Mide cuánta calidad tiene el software que se entrega al usuario final. Por ejemplo, si un equipo tiene un 30% de despliegues que causan problemas en el software, su tasa de fallo es alta.

Un extremo de las métricas DORA

Imagínate una gran empresa. Lleva 20 años desarrollando software. Su producto es líder en el mercado porque tiene cientos de funcionalidades que sus usuarios usan. Además, tiene fama de incluir funcionalidades sorprendentes en cada lanzamiento y nunca introducir ningún error sobre las funcionalidades existentes.

Su secreto reside en su equipo de lanzamiento. Todos los meses, el día 20, empieza el proceso de verificación y despliegue. Realizan test automáticos, corrigen las incidencias, preparan los ejecutables para el lanzamiento y el día 30, como un reloj, publican la nueva versión.

Frecuencia de despliegue: Una vez al mes
Tiempo de entrega: 30 días
Tiempo de restauración: 0 horas
Tasa de fallo: 0%

En sí, estas métricas no son ni buenas ni malas… La empresa lanza una nueva actualización cada mes, los usuarios están encantados con el contenido de la actualización y además no hay errores que afecten al servicio a los clientes.

Pero ¿qué pasa si esta empresa lanza su primera funcionalidad con un error que deja a los clientes sin servicio?

Detectan el error, lo desarrollan y cuando la solución está implementada, el tercer día, comienza el ciclo de 10 días para revisar todas las funcionalidades, compilar y distribuir la versión corregida.

Frecuencia de despliegue: 2 veces al mes
Tiempo de entrega: 13 días
Tiempo de restauración: 240 horas
Tasa de fallo: 0.01%

En este caso, se evidencian dos conclusiones de cómo optimizar las métricas DORA:

Con frecuencias de despliegue bajas, en caso de desastre, el impacto es muy alto.
Con tiempos de entrega altos, la solución del error es más compleja que en un desarrollo pequeño.

El otro extremo de las métricas DORA

En este caso, tenemos una startup pequeña con un equipo de desarrollo de tres personas. No tienen clientes, por lo que, si la plataforma se estropea, no afecta a nadie. Imaginemos que cada hora, el código de los tres se une en una rama y se sube a producción. En caso de que se rompa algo, los tres se unen y arreglan lo que se ha roto; de lo contrario, siguen trabajando. La cantidad de código que eres capaz de desarrollar en una hora es relativamente baja y si la nueva librería, o tu nueva operación, o la función que has modificado no es compatible con el código de los otros dos desarrolladores, el tiempo para identificarlo y resolverlo será casi inmediato.

Frecuencia de despliegue: 8 veces al día
Tiempo de entrega: 5 días
Tiempo de restauración: 10 minutos
Tasa de fallo: 30%

¿Qué otra conclusión podemos sacar?

Al aumentar el número de despliegues a producción, reduces el tamaño de los cambios, haciendo que los errores se identifiquen más rápido y que su solución sea más sencilla de identificar.

No creo que sea funcional forzar commits cada hora para comprobar si algo se ha roto en la última hora, pero si esos cambios se despliegan de forma voluntaria cada vez que hay una nueva función, se reduce el tiempo total dedicado a la resolución de bugs. Puede que ese campo nuevo en la base de datos no se exponga al usuario final, pero ya está en producción y funciona. Es importante destacar que no por desplegar más veces a producción estamos “entregando rápido”. Hay que alinear esos despliegues pequeños con casos de uso completos que nos permitan validar si nuestras ideas funcionan para el usuario.

Los dos ejemplos que hemos visto muestran dos formas opuestas de enfocar el desarrollo y el despliegue de software. La primera empresa tiene una frecuencia de despliegue muy baja, pero una calidad muy alta. La segunda empresa tiene una frecuencia de despliegue muy alta, pero una calidad muy baja. Ambas estrategias tienen sus ventajas y sus inconvenientes, pero también sus riesgos. La primera empresa corre el riesgo de perder clientes si tiene un fallo grave que tarda mucho en solucionar, como hemos visto con el tiempo de fuera de servicio de 240 horas. La segunda empresa corre el riesgo de perder la confianza de los usuarios si tiene muchos fallos que afectan a la experiencia de uso, como hemos visto con la tasa de fallo del 30%. Por eso, lo ideal sería encontrar un equilibrio entre las dos métricas, es decir, desplegar con una frecuencia suficiente para entregar valor rápido y validar las ideas con los usuarios, pero también con una calidad suficiente para evitar errores que perjudiquen al servicio o al producto.

Shipping fast, learning fast

En conclusión, las métricas DORA nos ayudan a medir y mejorar nuestra capacidad de entregar software de calidad a los usuarios de forma rápida y confiable. Estas métricas reflejan el principio de ship fast, learn fast, que consiste en desplegar rápido para aprender rápido, y así mejorar nuestro producto y nuestro proceso de forma continua.

Al aumentar nuestra frecuencia de despliegues, podemos entregar valor más a menudo a los usuarios, ofreciéndoles nuevas funcionalidades o mejoras que resuelvan sus problemas o necesidades. Al reducir nuestro tiempo de entrega, podemos acortar el ciclo de desarrollo, desde que se empieza una tarea hasta que se termina en producción, y así obtener feedback más rápido de los usuarios reales.

Al disminuir nuestro tiempo de restauración, podemos garantizar un servicio continuo y fiable que satisfaga las expectativas de los usuarios, minimizando el impacto negativo de los fallos o incidentes que puedan ocurrir. Al reducir nuestra tasa de fallo, podemos asegurar una calidad alta del software que entregamos a los usuarios, evitando errores que afecten a la experiencia de uso o al funcionamiento del producto.

Así, podemos aplicar el principio de ship fast, learn fast, que nos permite validar nuestras hipótesis con los usuarios, aprender de sus feedbacks y adaptarnos a sus cambios. De esta forma, podemos mejorar nuestro producto y nuestro proceso de forma iterativa e incremental.

Si quieres saber más sobre las métricas DORA, te recomiendo este artículo de Juan, el CTO de Clevergy, en el que comparte cómo fue el proceso de implantación de este framework en su equipo anterior en Packlink.