Cómo controlar la expansión del software

Puede que los síntomas de la expansión del software no se reconozcan al principio. Pueden aparecer como pequeñas molestias que se van dejando a un lado en favor de otras prioridades más importantes. Sin embargo, si no se controla, la expansión del software puede paralizar a los equipos de desarrollo generando una mayor carga cognitiva, reducir la implicación del equipo y anular las ventajas asociadas con una arquitectura poco vinculada. Como dice el refrán: «el mejor momento para plantar un árbol fue hace 20 años; el segundo mejor momento es ahora». El éxito futuro pasa por controlar la expansión del software antes de que se convierta en un problema.

A continuación, te explicamos tres indicadores de la expansión descontrolada del software, y te contamos lo que puedes hacer para dominar el caos y crear un entorno innovador y dinámico en el que cada equipo pueda dar rienda suelta a su potencial.

Uno de los primeros síntomas de la expansión descontrolada del software es que varias revisiones posteriores a los incidentes (PIR) indiquen que los cambios en un nivel superior han sido la causa principal de un incidente. Un número creciente de microservicios y un mayor volumen de cambios en un entorno pueden poner a prueba las normas existentes de colaboración entre desarrolladores y coordinación de cambios. Incluso un pequeño aumento en la frecuencia de los cambios en una aplicación modernizada, de mensual a semanal, puede multiplicar por 100 el número de publicaciones al mes. No es ninguna sorpresa que los desarrolladores tengan que adaptar su forma de colaborar. Es más probable que se produzcan incidentes en la producción cuando las normas de colaboración entre desarrolladores no se escalan en un entorno rápido y dinámico.

Ofrecer a los desarrolladores una forma no intrusiva para que estén al tanto de los cambios en niveles superiores e inferiores es una excelente manera de controlar el impacto de la expansión descontrolada del software. En Atlassian utilizamos Compass, un portal para desarrolladores que ayuda a los equipos a navegar por las arquitecturas distribuidas, para enviar una notificación dentro de la aplicación a los equipos de desarrollo sobre los cambios importantes en los servicios de nivel superior e inferior. Confirmar la recepción de esta notificación indica al iniciador del cambio que los equipos responsables de los servicios dependientes están al corriente del cambio. Esto brinda la oportunidad de colaborar en el cambio si se espera alguna incidencia, lo que reduce la probabilidad de que se produzcan impactos no deseados en la producción. Dado que los incidentes suelen ocurrir en un entorno dinámico, la colaboración entre desarrolladores durante un incidente es fundamental para restablecer los servicios rápidamente.

En las revisiones posteriores a los incidentes, en las que los cambios en niveles superiores son la causa principal, es común que el tiempo de restauración de los servicios se vea afectado por el tiempo que se tarda en identificar el cambio que ha provocado el problema, junto con el equipo o la persona propietaria del servicio. Lógicamente, reducir el tiempo que se tarda en identificar dicho cambio reduce el tiempo medio de restauración (MTTR) a lo largo del tiempo. Esto resulta más difícil en una arquitectura poco vinculada, en la que los servicios tienen una jerarquía de dependencias compleja y la causa principal de un incidente puede estar en cualquier parte de la pila. Tradicionalmente, las personas encargadas del incidente consultan los logs o los registros de cambios para identificar un cambio que pueda haber provocado un incidente. En un entorno dinámico, es como desmantelar un hormiguero para encontrar a la hormiga que te ha mordido.

En Atlassian utilizamos la fuente de actividades de Compass para reducir el MTTR. La fuente muestra todos los eventos de los sistemas de nivel superior junto con los detalles del equipo propietario. Esto reduce significativamente el tiempo de clasificación al facilitar la colaboración entre desarrolladores durante un incidente. Seguirán produciéndose incidentes, pero identificar de manera oportuna un cambio en un nivel superior como causa principal de un incidente es fundamental para minimizar el impacto y restablecer los servicios rápidamente.

Uno de los ingredientes clave para la productividad y la felicidad del equipo es avanzar hacia una arquitectura poco vinculada: la capacidad de moverse de forma independiente con altos niveles de autonomía. Si no se le pone freno, la expansión descontrolada del software puede anular algunos de estos beneficios y resultar en un equipo ocupado pero poco productivo e infeliz. Una queja habitual de los equipos de desarrollo es que "todo funciona bien hasta que necesitamos colaborar con otro equipo". Esto empeora cuando la expansión descontrolada del software se convierte en un problema. Si el entorno se expande y cambia rápidamente, los desarrolladores lo tienen más difícil para saber a quién deben contactar para las dependencias de nivel superior o posterior, lo que se traduce en una ralentización y en una acumulación de frustración a largo plazo para los equipos que intentan entregar de forma dinámica.

Hipotéticamente, digamos que el equipo Alfa y el equipo Beta pasan a "listo" un número idéntico de incidencias y puntos de historia en Jira cada semana. El equipo Alfa dedica el 90 % de su esfuerzo a enviar nuevas funciones a producción, mientras que el equipo Beta dedica el 30 % a nuevas funciones y el 70 % a averiguar cómo interactuar con los numerosos servicios de nivel superior de los que depende. Ambos equipos tienen el mismo nivel de producción, pero es probable que solo el equipo Alfa se considere productivo. La expansión descontrolada del software aumenta la necesidad de colaboración entre los equipos. Identificar formas inteligentes para que los equipos autónomos colaboren cuando sea necesario es clave para aprovechar el potencial de un entorno poco vinculado.

En un entorno dinámico y de rápido crecimiento, la capacidad de autogestionar la información es importante para la productividad y la felicidad del equipo. Una forma de lograrlo es implementar un catálogo centralizado de componentes de software con una gestión descentralizada, en el que cada equipo es responsable de crear y actualizar los servicios de su propiedad. Los entornos tradicionales suelen tener un catálogo centralizado gestionado por un equipo o función específicos. Sin embargo, esto no basta para seguir el ritmo de los cambios en un entorno distribuido, lo que hace que los equipos creen wikis paralelas que recojan cómo y con quién deben colaborar. En Atlassian descubrimos que un enfoque descentralizado reduce el esfuerzo invisible e inútil en los equipos, mejora las capacidades de autoservicio y crea un entorno de colaboración bajo demanda. Una excelente manera de mejorar la productividad, felicidad y participación del equipo es dominar la expansión descontrolada del software habilitando la información de autoservicio sobre las dependencias de nivel superior e inferior.