Entrega continua: valor corporativo, ventajas, desafíos y métricas

1. Velocidad

Con las canalizaciones automatizadas de entrega de software, las organizaciones pueden responder mejor ante los cambios del mercado. La velocidad es de suma importancia para reducir el tiempo de lanzamiento de nuevas funciones. Con un tiempo de lanzamiento corto, las organizaciones tienen más oportunidades de superar a la competencia y mantenerse en el negocio.

Recuerda que la velocidad en sí no es un parámetro indicador del éxito. Sin calidad, la velocidad no sirve de nada. No aporta ningún valor que las canalizaciones de entrega continua lancen código erróneo a la producción a toda velocidad.

2. Productividad

La productividad es sinónimo de felicidad, y los equipos que son felices están más involucrados.

La productividad aumenta cuando las tareas tediosas y repetitivas (como rellenar un informe de errores por cada defecto que se detecta) se pueden llevar a cabo mediante canales sin intervención humana. De esta forma, los equipos pueden centrarse en la visión mientras los canales se encargan de la ejecución. Al fin y al cabo, ¿quién no quiere delegar a las herramientas las tareas más pesadas?

Los equipos investigan las incidencias que detectan los canales y, una vez que confirman que se han solucionado, se ejecutan de nuevo los canales para validar si se ha solucionado el problema y si han surgido nuevos sin querer.

3. Sostenibilidad

Las empresas tienen como objetivo ganar maratones, no solo correr rápido. Sabemos que hace falta coraje para poder destacar. Hacerlo de forma constante puede ser aún más difícil: requiere disciplina y rigor. Trabajar duro de forma incesante acabará provocando un agotamiento extremo prematuro. En su lugar, es mejor trabajar de forma inteligente y delegar las tareas repetitivas en las máquinas, que no se quejan ni paran a tomar un café.

Todas las organizaciones, ya sean o no tecnológicas, emplean tecnología para diferenciarse de las demás. Los canales automatizados reducen las labores manuales y permite ahorrar, ya que las plantillas son más costosas que las herramientas. La gran inversión inicial puede provocar problemas para los líderes sin experiencia. Sin embargo, los canales correctamente diseñados permiten a las organizaciones innovar de forma más eficiente y rápida para satisfacer las necesidades de los clientes. La CD ofrece a las empresas más flexibilidad en la forma en que ofrecen funciones y soluciones de problemas. Pueden publicarse series de funciones específicas para clientes específicos, o para un subconjunto de clientes, a fin de garantizar que funcionan y escalan según lo previsto. Las funciones pueden someterse a pruebas y desarrollarse, pero permanecer inactivas en el producto, preparándose para varias versiones. ¿Tu departamento de marketing quiere ese "gran salto" en la convención anual del sector? Con la entrega continua, no solo es posible, sino que es una solicitud trivial.

¿Tu presupuesto es demasiado bajo?

La construcción de canales de entrega continua consume a los mejores trabajadores. No se trata de un proyecto secundario cuyo coste puede pasarse por alto. Siempre me ha sorprendido la forma en que algunas organizaciones empiezan asignando estas tareas a los miembros nuevos e intentando ahorrar en la compra de herramientas modernas. En algún momento, hacen correcciones y las asignan a sus arquitectos expertos para invertir en el desacoplamiento de arquitecturas y en canales potentes de entrega continua.

No pagues más por menos. Basándote en tu visión, deja a un lado una cantidad adecuada de fondos para asegurarte de que no se interrumpe la ejecución. Ofrece un producto viable mínimo (MVP) mediante un canal de entrega continua y amplíalo por toda la organización.

¿Cuentas con pensadores estratégicos?

Aunque dispongas de presupuesto, la ejecución podría ser un problema de personas.

Los equipos deben automatizarse sin miedo a perder su puesto de trabajo o de pasar a nuevos proyectos. Si en tu equipo se recela de los agentes automatizados que realizan tareas que se hacían manualmente, tienes a las personas equivocadas.

En caso de que te veas estancado, cambia de marcha. Busca la forma de darle a tu equipo un coche cuando lo único que te pedían era un caballo más rápido. Ponte en marcha con la ayuda de campeones con experiencia perfectos para ti. Las personas, después de todo, son tus mayores activos y debes enseñarles a hacer lo correcto. Haz que lo correcto les sea fácil de hacer y lo incorrecto, difícil: los resultados te sorprenderán gratamente.

Falta de prioridad

Nunca ningún propietario de un producto ha dicho: "¡Detengamos la línea y creemos canales de entrega continua!".

En su defensa, se centran en ir por delante de la competencia con nuevas funciones que sorprendan al mundo. Al mismo tiempo, sabes que tienes un problema si, en cada planificador de sprints, los canales se sopesan frente a las funciones de los productos y se cambian unos por otros.

En el backlog de algunos productos, los canales (si es que aparecen) aguardan en la parte inferior. Los líderes cortos de miras clasifican el trabajo relacionado con los canales como gastos, en lugar de inversiones que colocarán a los equipos en un buen lugar. Siguen negando el daño a largo plazo que han provocado y, por desgracia, a veces se salen con la suya.

Las canalizaciones son una buena práctica y seguro que eres consciente de la importancia de las buenas prácticas para seguir al pie del cañón.

Los canales ven montones de datos transaccionales

Imagina un día cualquiera de un equipo de desarrollo de software. El equipo confirma una función priorizada por la empresa, confirma pruebas para la función e integra las implementaciones con la canalización de entrega continua, de modo que cada cambio se implemente automáticamente. El equipo se da cuenta de que la aplicación se ha ralentizado después de incorporar esta función y confirma una corrección para el problema de rendimiento. El equipo también añade pruebas de rendimiento para detectar malos tiempos de respuesta antes de promover la aplicación de las pruebas al entorno de ensayo.

Imagina cada una de esas confirmaciones como si fuese una transacción. Y así es como trabajan los equipos de desarrollo de software (una transacción detrás de otra), hasta que surge un producto que sorprende al mundo. Y luego, vuelta a empezar. Multiplica estas transacciones por todos los ingenieros y equipos de la organización, y tendrás montones de datos transaccionales a tu disposición.

Analicemos los datos transaccionales del canal

¿Podemos analizar los datos transaccionales para extraer porciones de información? ¡Claro que podemos!

Como siempre que se tiene un gran volumen de datos transaccionales, puede ser complicado encontrarles sentido. Así, para obtener información útil sobre nuestra organización debemos agregar y analizar esos datos. Los análisis nos ayudan a ver el bosque a través de los árboles. Vamos a ver tres ejemplos de cómo mejoramos nuestras prácticas a partir de la información y los análisis de canalización.

A partir de los cientos de implementaciones que ocurren cada semana, averiguamos que el número de fallos de implementación de la aplicación A es el triple que el de la aplicación B. Este descubrimiento nos llevó a investigar las opciones de diseño de la aplicación A sobre gestión de la configuración y estabilidad del entorno. Descubrimos que el equipo usaba máquinas virtuales no fiables en su centro de datos para la implementación, mientras que la aplicación B usaba contenedores. Priorizamos una inversión en infraestructura inmutable y, al cabo de un mes, revisamos la situación para comprobar que el retorno de esa inversión fuera bueno. Y lo era. Lo que se puede medir, se puede arreglar.

Otro ejemplo es cuando descubrimos que los errores de análisis del código estático de la aplicación B han ido ascendiendo constantemente en los últimos trimestres. Esto podría suponer que el equipo que hay detrás de la aplicación B debe (volver a) recibir formación para escribir código más eficiente. Asimismo, descubrimos que los analizadores de código estático informaron de falsos positivos, lo que significa que se detectaron infracciones de programación cuando no había ninguna. Entonces, actualizamos su analizador a una conocida herramienta estándar del sector y redujimos los falsos positivos en cierta medida. Organizamos un taller de programación en el que tratábamos los errores legítimos de análisis estáticos y los resolvíamos. Al acabar, el equipo volvía a ponerse manos a la obra.

Otro dato interesante era que las pruebas unitarias de la aplicación A tenían menos cobertura de código que las aplicaciones B y C, pero la aplicación A era la que menos incidencias de producción tuvo en el último año. Escribir pruebas unitarias y medir la cobertura de código está bien. Sin embargo, pasarse con ese ejercicio es improductivo para el equipo e inútil para los clientes. Lecciones aprendidas.

Indicadores clave de rendimiento (KPI)

No podemos depender de las opiniones cuando se trata de llevar la organización por la dirección correcta. En primer lugar, debemos definir los KPI en función de lo que queramos conseguir. En segundo lugar, debemos tomar decisiones basadas en datos analizando los KPI durante meses, trimestres y años.

KPI de la organización frente a KPI de los departamentos

Hemos visto a muchos departamentos individuales definir sus propias métricas de éxito. A ellos les conviene saber bien cuál es el éxito que buscan, siempre y cuando estas métricas se ajusten a los objetivos de la organización.

Comparación de fallos en pruebas, entorno de ensayo y producción

Algunas organizaciones requieren que los organizadores posean el entorno de pruebas, que el departamento de control de calidad posea el entorno de ensayo, y que el departamento de operaciones de encargue de la producción. En lugar de ahogar a los desarrolladores con informes de cobertura de código de pruebas unitarias que se ejecutan en el entorno de pruebas, es importante que den un paso atrás y adopten una perspectiva más amplia en todos los entornos, los posean o no.

El porcentaje de fallos en el entorno de ensayo debidos a las pruebas de rendimiento podría ser alto y deberse a referencias de rendimiento incorrectas o a código lento. Un análisis comparativo podría mostrar que las canalizaciones fallan más en las pruebas de humo de integración en producción, y eso justificaría una investigación. La causa raíz podrían ser errores reales en el producto o defectos en el código de prueba, datos de prueba inexactos, configuración de prueba incorrecta o malentendidos entre los equipos de producto e ingeniería, entre otros.

Si se sigue indagando, puede que se detecte que las configuraciones de pruebas incorrectas están descontroladas, y se podría dar prioridad a la resolución de esas incidencias para hacer lo propio con fallos frecuentes de integración. Además, el hecho de que los desarrolladores cuentan con su código durante toda la producción sigue también el paradigma de DevOps.

Índice de estabilidad

Una vez definidos los KPI, es fundamental para nosotros saber si un KPI tiene sesgo y se inclina fuertemente hacia alguna dirección. Si es así, tenemos que equilibrarlo con otros KPI que ajusten el centro de gravedad. Uno de ellos es la estabilidad.

Los desarrolladores miden la estabilidad con FeatureLeadTime, que es el tiempo que tarda una función en ponerse en marcha en la producción. Una función consta de varias confirmaciones y, por ello, una medición más detallada de FeatureLeadTime es CheckIn2GoLive, que es el tiempo que tarda una comprobación en ponerse en marcha en la producción.

Mide CheckIn2goLive a través de canalizaciones, ya que puedes aproximarte a este parámetro por el tiempo que tarda una canalización en pasar el código desde la prueba y el entorno de ensayo a la producción. Además, CheckIn2GoLive también muestra defectos en el MTTR (tiempo medio de resolución), ya que la corrección de error recorre la misma canalización desde la prueba y el entorno de ensayo hasta la producción.

Lo interesante es que, cuando pregunté al departamento de operaciones, la velocidad suele tener una connotación negativa, ya que ahí procuran ser reacios a los riesgos. Lo que hacen es medir la cantidad de defectos de escape para reflejar el fallo, y definen la estabilidad con el porcentaje de defectos detectados por el canal, al contrario que los defectos de escape.

La empresa define la estabilidad según la satisfacción del cliente o el número de clientes repetidos. Aunque parece subjetivo, puedes aproximarte a este parámetro por el número de defectos notificados por los clientes o con encuestas de feedback de clientes.

El índice de estabilidad es un clásico ejemplo, en el que la empresa y los departamentos de desarrollo y operaciones están obstinados desde su propio punto de vista; sin embargo, es mejor que la organización opte por crear una mezcla, en lugar de depender solo de una parte. Por ello, debes crear un índice organizativo para la estabilidad que sea imparcial.

Índice de calidad del código

Otro ejemplo en el que se tienen en cuenta distintos puntos de vista es la calidad en el código. Algunos dicen que la calidad de nuestro código se refleja en la cobertura de código medida por las pruebas unitarias, mientras que otros sostienen que se trata de complejidad ciclomática. Los analizadores estáticos estándar informan sobre código duplicado, vulnerabilidades de seguridad y posibles fugas de memoria. Estas son verdaderas mediciones de la calidad en el código y, por ello, crean un índice en el que todas ellas (y, posiblemente, otras más) desempeñan un rol.

KPI empresariales frente a KPI técnicos

Otro KPI popular al que las organizaciones les gusta tener en cuenta es el valor entregado en un sprint. Una mala práctica habitual es registrar el número de versiones, que no añaden valor. Podrías mover bits desde el punto A al punto B sin cambiar nada en tu empresa, y eso obviamente no es suficiente. Algunas organizaciones miden la cantidad de pruebas recién añadidas en ese sprint o la cantidad total de pruebas ejecutadas, y estas tampoco reflejan los resultados empresariales, solo el trabajo de ingeniería. El valor entregado en un sprint debe ser relevante para el negocio.

Un par de ejemplos de KPI empresariales podría ser la cantidad de adquisiciones de los clientes en el último trimestre y la cantidad de clics en anuncios en el último mes. Los canales no influyen directamente en estas métricas empresariales. El único motivo por el que tratamos de asignar KPI empresariales a KPI técnicos es para entender la relación entre la habilidad técnica y los objetivos empresariales.

Cuando se asignan a los canales, los KPI empresariales también nos permiten calcular el retorno de la inversión (ROI) de los canales. Los equipos de liderazgo usan estas métricas para entender las posibles áreas de mejora y para planificar el presupuesto.

Embárcate en tu viaje