4 min leer
El conocimiento es valioso, pero su verdadero poder reside en cómo lo ponemos en práctica. En Freyr , estábamos familiarizados con DevOps, sus prácticas asociadas y cómo podí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 del sector de las ciencias de la vida. Cuando comenzamos nuestro viaje, nuestros esfuerzos sentaron unas bases sólidas, pero para convertirnos realmente en una potencia de desarrollo, sabíamos que teníamos que adoptar un enfoque más estratégico y adaptable.
El principal reto a la hora de traducir los conocimientos en acciones consiste en saber cuándo dar los pasos adecuados. Dado que las acciones afectan a muchas personas de una organización, hacer lo correcto en el momento adecuado 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 proveedor de software especializado en soluciones a medida, 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 empresariales en resultados. 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, creando soluciones escalables y de gran impacto.
Teníamos una visión de dónde queríamos llegar: cómo queríamos trabajar, desarrollar, probar, implantar y lanzar software. Sin embargo, sabíamos que alcanzar esos objetivos requería una estrategia meditada, un aprendizaje continuo y un compromiso de mejora.
En el último año, hemos realizado más de 100 versiones sin apenas fallos de implantación y hemos logrado una automatización casi total en la introducción de cambios. Además, hemos visto un progreso significativo en los ingresos, equipos más ágiles y un cambio general hacia nuestra visión de convertirnos en una potencia en productos de software, soluciones y servicios. Aunque siempre queda mucho por hacer, estamos seguros de que hemos sentado unas bases sólidas y estamos preparados para acelerar.
A medida que avanzamos, nos tomamos un momento para reflexionar sobre nuestra transformación: lo que funcionó, lo que no y las lecciones que aprendimos. Al compartir nuestro viaje, esperamos ayudar a otras personas que se enfrentan a cambios similares.
Esta serie de blogs es principalmente empírica, compartiendo lo que hicimos, a la vez que conectamos nuestras acciones con las mejores prácticas y recomendaciones de varios recursos 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 progreso significativo.
Echando la vista atrás, podemos agrupar estas acciones en tres categorías: Herramientas y procesos, Arquitectura de software y Personas. Estas categorías están muy interrelacionadas, y los cambios en una repercuten en las demás. Sin embargo, fue posible introducir cambios graduales en cada categoría y medir el progreso hacia nuestros objetivos generales.
Las iniciativas de estas categorías a menudo dependían unas de otras. Los cambios en un área abren posibilidades de nuevas mejoras en otra.
Los primeros pasos
Para sentar unas bases sólidas, nos hemos centrado en tres iniciativas fundamentales:
- Integración de nuestras bases de código fuente con SonarQube para las métricas de calidad del código.
- Trasladar todos los equipos a una herramienta común para gestionar los requisitos, el código fuente y los planes de pruebas; en nuestro caso, Azure DevOps.
- Estructurar equipos con responsabilidades claras para mejorar la apropiación y la rendición de cuentas.
Estas tres iniciativas us proporcionaron us sobre:
- El trabajo que se realiza (requisitos y tareas).
- La calidad del código (métricas SonarQube).
- Las personas implicadas (responsabilidades del equipo).
Entre ellas, la más difícil fue definir claramente las responsabilidades del equipo. Al principio, las estructuras de los equipos eran fluidas, y las personas pasaban de un proyecto a otro en función de las necesidades. La transición a equipos dedicados con áreas funcionales diferenciadas fue un paso necesario, aunque complicado por nuestra arquitectura de producto existente, que no estaba totalmente diseñada para apoyar 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 que los equipos independientes pudieran responsabilizarse de su trabajo. Sin ella, nuestros esfuerzos por lograr que los equipos se responsabilizaran de su trabajo tendrían un impacto limitado.
La reestructuración de nuestra cartera fue un proceso complejo. Incluía pasar completamente a la nube y empezar a crear aplicaciones nativas de la nube utilizando una arquitectura de microservicios. Este tema se tratará en un próximo artículo. Sin embargo, lo más importante es que los cambios son graduales, y algunos pasos deben preceder a otros para desbloquear los beneficios y seguir avanzando.
Métricas y mejora continua
Tras empezar a trabajar en la reestructuración (una tarea en curso), pasamos a centrarnos en el seguimiento de las métricas y el establecimiento de 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 los equipos individuales.
- Adopción de servicios nativos de la nube.
Estas metas no eran mandatos rígidos, sino objetivos orientativos para ayudar a los equipos a alinear sus esfuerzos.
Capacitar a las personas
Una vez establecidas las métricas, se hizo evidente que los equipos necesitaban ayuda para alcanzar estos objetivos. Por ejemplo, si bien establecer objetivos de cobertura de pruebas unitarias y automatización de pruebas de API era sencillo, alcanzarlos suponía un reto, sobre todo en el caso del código heredado que no se había diseñado para su comprobabilidad.
Para solucionarlo:
- Establezca objetivos más bajos para el código heredado.
- Organización de talleres y formación práctica sobre la redacción de pruebas unitarias de calidad y el diseño de código comprobable.
- Orientación sobre la creación de stubs para pruebas de API.
- Realización de revisiones de pruebas unitarias por arquitectos superiores.
El triángulo de las herramientas, la arquitectura y las 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 supone una mejora de las herramientas, reveló una baja cobertura de las pruebas unitarias, lo que apuntaba a problemas arquitectónicos que limitaban la capacidad de comprobación. Las mejoras en la arquitectura y las habilidades del equipo condujeron a pruebas unitarias de mejor calidad, pero éstas no se ejecutaban con regularidad debido a las malas prácticas de ramificación. Para solucionarlo, estandarizamos las estrategias de bifurcación y garantizamos la integración periódica del código en la rama principal, lo que permitió que las canalizaciones CI ejecutaran todas las pruebas.
La secuencia correcta del cambio
Un enfoque de la transformación consiste en aplicar indiscriminadamente las mejores prácticas. Aunque esto puede reportar beneficios, los resultados a menudo no justifican el esfuerzo, lo que conduce a la frustración.
Seguimos un planteamiento distinto, basado en el principio del flujo: analizar el proceso de principio a fin, identificar los cuellos de botella y abordarlos de forma gradual.
Cada mejora revelaba nuevos cuellos de botella que exigían nuevas medidas. No se trataba de jugar al "topo", sino de un proceso deliberado de hacer lo correcto en el momento oportuno.
Por ejemplo, imponer la cobertura de las pruebas unitarias sin mejorar el diseño del código habría llevado a la frustración y al "teatro de la cobertura" (pruebas superficiales escritas para cumplir las métricas). Al abordar primero la arquitectura y las habilidades, nos aseguramos un progreso significativo.
De cara al futuro
La verdadera transformación no consiste en un único gran cambio, sino en tomar decisiones inteligentes y oportunas que impulsen el progreso continuo. Estamos encantados de compartir nuestro viaje y nuestros conocimientos para ayudar a otros a recorrer su propio camino hacia un cambio escalable y de gran impacto.
En los próximos blogs de esta serie, «DevOps for the Win», analizaremos cada fase de nuestra transformación en el triángulo DevOps (herramientas, arquitectura y personas) que us ayudó us un impacto duradero.
