Como dominar a dispersão de software

Os sintomas da dispersão de software podem ser difíceis de reconhecer no início. Eles podem começar como pequenos aborrecimentos que são deixados de lado para dar atenção a problemas com nível de prioridade mais alto. No entanto, se não for controlada, a dispersão de software pode prejudicar as equipes de desenvolvimento com carga cognitiva maior, reduzir o engajamento da equipe e reverter os benefícios associados a uma arquitetura pouco integrada. Como diz o provérbio, “o melhor momento para plantar uma árvore foi há 20 anos. O segundo melhor momento é agora”, o sucesso futuro se baseia em domar a dispersão de software antes que ela se torne um problema.

Abaixo estão três sinais da dispersão de software e o que você pode fazer para dominar o caos e, ao mesmo tempo, criar um ambiente inovador e dinâmico que libera o potencial de cada equipe.

Um sintoma precoce da dispersão de software é ter várias avaliações pós-incidentes (PIRs) indicando alterações upstream como a causa raiz de um incidente. Um número crescente de microsserviços e um maior volume de alterações em um ambiente podem sobrecarregar as normas existentes sobre colaboração de desenvolvedores e coordenação de alterações. Mesmo um pequeno aumento, de mensal para semanal, na frequência de alterações de um aplicativo modernizado pode resultar em um aumento de 100 vezes nos lançamentos por mês. Não é nenhuma surpresa que os desenvolvedores precisem adaptar a forma como colaboram. É mais provável que ocorram incidentes na produção quando as normas de colaboração dos desenvolvedores não escalam em um ambiente dinâmico.

Criar uma forma não intrusiva de os desenvolvedores ficarem por dentro das alterações upstream e downstream é uma ótima maneira de controlar o impacto da dispersão de software. Na Atlassian, usamos o Compass — um portal de desenvolvedores que ajuda na orientação das equipes em arquiteturas distribuídas — para enviar uma notificação no app para as equipes de desenvolvimento sobre alterações significativas nos serviços upstream e downstream. O reconhecimento dessa notificação indica ao iniciador da alteração que as equipes responsáveis pelos serviços dependentes estão cientes da alteração. Assim é possível colaborar na alteração caso haja algum problema esperado, reduzindo a probabilidade de impactos não intencionais na produção. Como é muito provável que incidentes aconteçam em um ambiente dinâmico, a colaboração dos desenvolvedores durante um incidente é fundamental para a restauração rápida dos serviços.

Em avaliações pós-incidentes em que as alterações upstream são a causa raiz, é comum que o tempo de restauração dos serviços seja afetado pelo tempo necessário para identificar a alteração upstream problemática, junto com a equipe ou a pessoa proprietária do serviço. Pela lógica, reduzir o tempo necessário para identificar a alteração upstream que causa o problema reduz o tempo médio de restauração (MTTR) ao longo do tempo. Isso se torna mais difícil em uma arquitetura de acoplamento fraco, em que os serviços têm uma hierarquia de dependências rica e a causa raiz de um incidente pode estar em qualquer lugar da pilha. Tradicionalmente, os respondentes de incidentes vasculham logs ou registros de alterações para identificar uma alteração que possa ter causado um incidente. Em um ambiente dinâmico, é como desmontar um formigueiro para encontrar a formiga que mordeu você.

Na Atlassian, usamos o feed de atividades do Compass para reduzir o MTTR. Ele mostra todos os eventos dos sistemas upstream, junto com as informações da equipe responsável. Assim, o tempo de triagem tem uma redução significativa, pois a colaboração dos desenvolvedores ganha suporte durante os incidentes. Incidentes vão acontecer, mas identificar uma alteração upstream como a causa raiz de um incidente em tempo hábil é fundamental para garantir que o impacto seja mínimo e a restauração dos serviços, rápida.

A mudança para uma arquitetura de acoplamento fraco é um dos principais ingredientes para a produtividade e a felicidade da equipe: ela traz a capacidade de se mover com independência e altos níveis de autonomia. Se não for controlada, a dispersão de software pode reverter alguns desses benefícios, resultando em uma equipe ocupada, mas improdutiva e infeliz. Uma reclamação comum ao falar com equipes de desenvolvimento é que “tudo funciona bem até precisarmos interagir com outra equipe”. Isso é amplificado quando a dispersão de software se torna um problema. Um ambiente que muda e se expande com rapidez reduz a capacidade dos desenvolvedores de acompanhar quem acionar para lidar com dependências upstream ou downstream, resultando em desaceleração e aumento da frustração para as equipes que estão tentando entregar em ritmo acelerado.

Imagine esta situação: o esquadrão Alpha e o esquadrão Beta movem um número idêntico de itens e pontos da história para “concluído” no Jira a cada semana. O esquadrão Alpha gasta 90% de seu trabalho enviando novas funções para a produção, enquanto o esquadrão Beta gasta 30% em novas funções e 70% tentando descobrir como interagir com os muitos serviços upstream dos quais eles dependem. Ambos os esquadrões têm o mesmo nível de produção, mas é provável que apenas o Alpha seja considerado produtivo. A dispersão de software aumenta a necessidade de colaboração entre as equipes. Identificar formas inteligentes de as equipes autônomas interagirem sob demanda é fundamental para liberar o poder de um ambiente de acoplamento fraco.

Em um ambiente dinâmico e em rápido crescimento, a capacidade de autoatendimento das informações é importante para a produtividade e a felicidade da equipe. Uma maneira de conseguir isso é implementar um catálogo centralizado de componentes de software com gerenciamento descentralizado; é um catálogo centralizado em que cada equipe é responsável por criar e atualizar os serviços de que é proprietária. Os ambientes tradicionais costumam ter um catálogo centralizado que é gerenciado por uma equipe ou função específica. Mas ele não é suficiente para acompanhar a taxa de alteração em um ambiente distribuído, resultando em equipes criando wikis paralelas sobre com quem e como interagir. Na Atlassian, descobrimos que uma abordagem descentralizada reduz o trabalho invisível e o desperdício entre as equipes, melhora os recursos de autoatendimento e cria um ambiente de interação sob demanda. Dominar a dispersão de software ao permitir o autoatendimento de informações sobre dependências upstream e downstream é uma excelente maneira de melhorar a produtividade da equipe com efeitos complementares na felicidade e no engajamento da equipe.