,
4 min de lectura
El conocimiento es valioso, pero su verdadero poder reside en cómo lo ponemos en práctica. En Freyr Digital, estábamos familiarizados con DevOps, sus prácticas asociadas y cómo podría transformar nuestra organización en una potencia 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 base sólida, pero para convertirnos realmente en una potencia de desarrollo, sabíamos que necesitábamos adoptar un enfoque más estratégico y adaptable.
El principal desafío al traducir el conocimiento en acción reside en saber cuándo tomar las medidas correctas. Dado que las acciones impactan a muchas personas en una organización, hacer lo correcto en el momento adecuado depende de nuestra posición como organización, de nuestros procesos y prácticas actuales, y de las habilidades y capacidades de nuestra gente.
Esto marcó un punto de inflexión en nuestra transformación. Como un conjunto de proveedores de software especializados en soluciones personalizadas, teníamos un equipo dedicado que se esforzaba al máximo para ofrecer resultados. Sin embargo, vimos una oportunidad para 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 lograr esos objetivos requería una estrategia bien pensada, aprendizaje continuo y un compromiso con la mejora.
Avancemos hasta hoy: en el último año, hemos realizado más de 100 lanzamientos con casi cero fallos de implementación y hemos logrado una automatización casi completa en la implementación de cambios. Además, hemos observado un progreso significativo en los ingresos, equipos más eficientes y ágiles, y un cambio general hacia nuestra visión de convertirnos en una potencia en productos, soluciones y servicios de software. Si bien siempre hay más por lograr, estamos seguros de haber sentado una base sólida 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 viaje, esperamos apoyar a otros que navegan por cambios similares.
Esta serie de blogs es principalmente empírica, compartiendo lo que hicimos y conectando nuestras acciones con las mejores prácticas y recomendaciones de diversas fuentes de DevOps y Agile.
Hacer lo correcto en el momento adecuado
Uno de los aspectos clave de nuestra transformación fue identificar las acciones correctas en el momento adecuado. Con múltiples iniciativas posibles, necesitábamos un enfoque estructurado para garantizar un progreso significativo.
Retrospectivamente, podemos agrupar estas acciones en tres categorías: Herramientas y Procesos, Arquitectura de Software y Personas. Estas categorías están muy interconectadas, y los cambios en una impactan a las otras. Sin embargo, fue posible realizar cambios de forma incremental en cada categoría y medir el progreso hacia nuestros objetivos generales.
Las iniciativas en estas categorías a menudo dependían unas de otras. Los cambios en un área abrieron posibilidades para mejoras adicionales en otra.
Los Primeros Pasos
Para establecer una base sólida, nos centramos en tres iniciativas clave:
- Integrando nuestras bases de código fuente con SonarQube para métricas de calidad de código.
- Trasladar a todos los equipos a una herramienta común para gestionar requisitos, código fuente y planes de prueba; en nuestro caso, Azure DevOps.
- Estructuración de equipos con responsabilidades claras para mejorar la apropiación y la rendición de cuentas.
Estas tres iniciativas nos dieron visibilidad sobre:
- El trabajo realizado (requisitos y tareas).
- La calidad del código (métricas de SonarQube).
- Las personas involucradas (responsabilidades del equipo).
Entre estos, definir responsabilidades claras del equipo fue lo más desafiante. Inicialmente, las estructuras de equipo eran fluidas, con personas moviéndose entre proyectos según fuera necesario. La transición a equipos dedicados con áreas funcionales distintas fue un paso necesario, aunque complicado por nuestra arquitectura de producto existente, que no estaba completamente diseñada para soportar una propiedad clara.
El Papel de la Arquitectura de Software
Rápidamente nos dimos cuenta de 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 para crear un sentido de propiedad en el equipo tenían un impacto limitado.
Reestructurar nuestro portafolio fue un proceso complejo. Incluyó la migración completa a la nube y el inicio de la construcción de aplicaciones nativas de la nube utilizando una arquitectura de microservicios. Este tema se abordará en una publicación futura. La conclusión clave, sin embargo, es que los cambios son incrementales, y algunos pasos deben preceder a otros para desbloquear beneficios y lograr un mayor progreso.
Métricas y Mejora Continua
Después de comenzar a trabajar en la re-arquitectura (un esfuerzo continuo), cambiamos nuestro enfoque a monitorear métricas y establecer objetivos:
- Métricas de calidad de código en SonarQube.
- Métricas de integración de código en Azure DevOps.
- Métricas de rendimiento de funciones para equipos individuales.
- Adopción de servicios nativos de la nube.
Estos objetivos no eran mandatos estrictos, sino objetivos orientativos para ayudar a los equipos a alinear sus esfuerzos.
Capacitando a las personas
Con las métricas establecidas, se hizo evidente que los equipos necesitaban apoyo para lograr estos objetivos. Por ejemplo, si bien establecer objetivos para la cobertura de pruebas unitarias y la automatización de pruebas de API era sencillo, lograrlos era un desafío, especialmente para el código heredado que no había sido diseñado para la capacidad de prueba.
Para ello, nosotros:
- Establecer objetivos más bajos para el código heredado.
- Talleres organizados y formación práctica sobre la escritura de pruebas unitarias de calidad y el diseño de código comprobable.
- Se proporcionó orientación sobre la creación de stubs para pruebas de API.
- Se realizaron revisiones de pruebas unitarias por 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 indicaba problemas arquitectónicos que limitaban la capacidad de prueba. Las mejoras en la arquitectura y las habilidades del equipo condujeron a pruebas unitarias de mejor calidad, pero estas no se ejecutaban regularmente 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 del Cambio
Un enfoque para la transformación es implementar las mejores prácticas de forma indiscriminada. Si bien esto podría traer beneficios, los resultados a menudo no justifican el esfuerzo, lo que lleva a la 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 revelaba nuevos cuellos de botella, lo que requería acciones adicionales. Esto no era un proceso de ir resolviendo problemas a medida que surgían, sino un proceso deliberado de hacer lo correcto en el momento adecuado.
Por ejemplo, exigir la cobertura de pruebas unitarias sin mejorar el diseño del código habría provocado frustración y un "teatro de cobertura" (pruebas superficiales escritas para cumplir con las métricas). Al abordar primero la arquitectura y las habilidades, aseguramos un progreso significativo.
Perspectivas
La verdadera transformación no se trata de un único gran cambio, sino de decisiones inteligentes y oportunas que impulsan un progreso continuo. Nos entusiasma compartir nuestra trayectoria y conocimientos para ayudar a otros a navegar su propio camino hacia un cambio escalable y de alto impacto.
En las próximas entradas de blog de esta serie, "DevOps para la victoria", desglosaremos cada fase de nuestra transformación en el Triángulo de DevOps —Herramientas, Arquitectura y Personas— que nos ayudó a lograr un impacto duradero.
