4 min de lectura
El conocimiento es valioso, pero su verdadero poder reside en cómo lo ponemos en práctica. En Freyr Digital, conocíamos bien DevOps, sus prácticas asociadas y cómo podía transformar nuestra organización en una central de desarrollo de productos de alto rendimiento, capaz de ofrecer productos y soluciones de calidad a nuestros clientes de ciencias de la vida. Al iniciar nuestro camino, nuestros esfuerzos sentaron una sólida base, pero para convertirnos verdaderamente en una central de desarrollo, sabíamos que debíamos adoptar un enfoque más estratégico y adaptable.
El principal desafío al traducir el conocimiento en acción radica en saber cuándo tomar las medidas adecuadas. Dado que las acciones afectan a muchas personas en una organización, hacer lo correcto en el momento oportuno depende de dónde nos encontremos como organización, de nuestros procesos y prácticas actuales, y de las habilidades y capacidades de nuestro personal.
Esto marcó un punto de inflexión en nuestra transformación. Como cartera de proveedores de software especializados en soluciones personalizadas, contábamos con un equipo dedicado que se esforzaba al máximo para ofrecer resultados. Sin embargo, vimos la oportunidad de mejorar la calidad, aumentar la productividad y acelerar la conversión de los requisitos comerciales en entregables. En lugar de centrarnos en soluciones de última hora, nuestro objetivo era pasar de la resolución reactiva de problemas a la innovación proactiva, construyendo soluciones escalables y de alto impacto.
Teníamos una visión de dónde queríamos estar: cómo queríamos trabajar, desarrollar, probar, implementar y lanzar software. Sin embargo, sabíamos que para alcanzar esos objetivos se necesitaba una estrategia meditada, un aprendizaje continuo y un compromiso con la mejora.
Avanzando rápidamente hasta la actualidad: en el último año, hemos realizado más de 100 lanzamientos con fallos de implementación cercanos a cero y hemos logrado una automatización casi total en el despliegue de cambios. Además, hemos observado un progreso significativo en los ingresos, equipos más ágiles y eficientes, y un cambio general hacia nuestra visión de convertirnos en un referente en productos, soluciones y servicios de software. Aunque siempre hay más metas que alcanzar, confiamos en que hemos sentado unas bases sólidas y estamos listos para acelerar.
A medida que avanzamos, nos tomamos un momento para reflexionar sobre nuestra transformación: qué funcionó, qué no y las lecciones que aprendimos. Al compartir nuestro recorrido, esperamos ayudar a otros que se enfrentan a cambios similares.
Esta serie de blogs es principalmente empírica, y comparte lo que hicimos, al tiempo que vincula nuestras acciones con las mejores prácticas y recomendaciones de diversos recursos de DevOps y Agile.
Hacer lo correcto en el momento adecuado
Uno de los aspectos clave de nuestra transformación fue identificar las acciones adecuadas en el momento oportuno. Con múltiples iniciativas posibles, necesitábamos un enfoque estructurado para garantizar un avance significativo.
En retrospectiva, podemos agrupar estas acciones en tres categorías: Herramientas y procesos, arquitectura de software y personas. Estas categorías están muy entrelazadas, de modo que los cambios en una repercuten en las demás. No obstante, fue posible realizar cambios de forma gradual en cada categoría y medir el avance hacia nuestros objetivos generales.
Las iniciativas de estas categorías solían depender unas de otras. Los cambios en un área abrían posibilidades para seguir mejorando en otra.
Los primeros pasos
Para establecer una base sólida, nos centramos en tres iniciativas principales:
- Integrar nuestras bases de código fuente con SonarQube para obtener métricas de calidad del código.
- Migrar a todos los equipos a una herramienta común para gestionar los requisitos, el código fuente y los planes de prueba; en nuestro caso, Azure DevOps.
- Estructurar los equipos con responsabilidades claras para potenciar la apropiación y la rendición de cuentas.
Estas tres iniciativas nos brindaron visibilidad sobre:
- El trabajo que se está realizando (requisitos y tareas).
- La calidad del código (métricas de SonarQube).
- Las personas involucradas (responsabilidades del equipo).
Entre ellas, definir responsabilidades claras para los equipos fue lo más complejo. Al principio, las estructuras de los equipos eran flexibles y las personas se trasladaban entre proyectos según era necesario. La transición hacia equipos dedicados con áreas funcionales bien definidas fue un paso necesario, aunque se vio dificultada por nuestra arquitectura de producto existente, que no se había diseñado por completo para respaldar una titularidad clara.
El papel de la arquitectura de software
Pronto comprendimos que la arquitectura del producto era una de las áreas más críticas para el cambio. Una arquitectura modular era esencial para permitir que los equipos independientes asumieran la responsabilidad de su trabajo. Sin esto, nuestros esfuerzos por lograr que los equipos asumieran la titularidad habrían tenido un impacto limitado.
Rediseñar la arquitectura de nuestra cartera fue un proceso complejo. Incluyó el paso completo a la nube y el inicio del desarrollo de aplicaciones nativas de la nube mediante una arquitectura de microservicios. Este tema se tratará en una próxima publicación. Sin embargo, la conclusión clave es que los cambios son graduales y algunos pasos deben preceder a otros para desbloquear beneficios y continuar avanzando.
Métricas y mejora continua
Tras comenzar con el rediseño de la arquitectura (una labor en curso), centramos nuestra atención en supervisar métricas y establecer objetivos:
- Métricas de calidad del código en SonarQube.
- Métricas de integración de código en Azure DevOps.
- Métricas de rendimiento de funcionalidades para cada equipo.
- Adopción de servicios nativos de la nube.
Estos objetivos no eran mandatos estrictos, sino directrices orientativas para ayudar a los equipos a alinear sus esfuerzos.
Empoderamiento de las personas
Una vez establecidas las métricas, se hizo evidente que los equipos necesitaban apoyo para alcanzar estas metas. Por ejemplo, aunque fijar objetivos para la cobertura de pruebas unitarias y la automatización de pruebas de API era sencillo, cumplirlos resultaba complicado, especialmente en el caso del código heredado que no se había diseñado para facilitar las pruebas.
Para abordar esto, nosotros:
- Establecimos objetivos más bajos para el código heredado.
- Organizamos talleres y formación práctica sobre cómo escribir pruebas unitarias de calidad y diseñar código comprobable.
- Proporcionamos orientación sobre la creación de stubs para pruebas de API.
- Realizamos revisiones de las pruebas unitarias a cargo de arquitectos sénior.
El triángulo de herramientas, arquitectura y personas
Un buen ejemplo de la interacción entre estas categorías fue la gestión de código y repositorios. La integración con SonarQube, que representa una mejora en las herramientas, reveló una baja cobertura de pruebas unitarias, lo que apuntaba a problemas arquitectónicos que limitaban la comprobabilidad. Las mejoras en la arquitectura y en las habilidades del equipo condujeron a pruebas unitarias de mejor calidad, pero estas no se ejecutaban con regularidad debido a malas prácticas de ramificación. Abordamos esto estandarizando las estrategias de ramificación y asegurando la integración regular del código en la rama principal, lo que permitió que las canalizaciones de CI ejecutaran todas las pruebas.
La secuencia correcta de cambio
Un enfoque para la transformación consiste en implementar las mejores prácticas de manera indiscriminada. Si bien esto puede aportar beneficios, los resultados a menudo no justifican el esfuerzo, lo que genera frustración.
Seguimos un enfoque diferente, basado en el principio de flujo: analizar el proceso End-to-End, identificar los cuellos de botella y abordarlos de forma incremental.
Cada mejora reveló nuevos cuellos de botella, lo que requirió medidas adicionales. Esto no fue un juego de adivinanzas, sino un proceso deliberado de hacer lo correcto en el momento adecuado.
Por ejemplo, exigir obligatoriamente una cobertura de pruebas unitarias sin mejorar el diseño del código habría generado frustración y «teatro de cobertura» (pruebas superficiales escritas solo para cumplir con las métricas). Al abordar primero la arquitectura y las habilidades, garantizamos un progreso significativo.
Mirando hacia el futuro
La verdadera transformación no consiste en un único gran cambio, sino en decisiones inteligentes y oportunas que impulsan el progreso continuo. Nos entusiasma compartir nuestro recorrido y nuestras perspectivas para ayudar a otros a recorrer su propio camino hacia un cambio escalable y de alto impacto.
En las próximas publicaciones de esta serie, DevOps para ganar, explicaremos cómo cada fase de nuestra transformación dentro del triángulo de DevOps (herramientas, arquitectura y personas) nos ayudó a lograr un impacto duradero.
