< Insights

Há compatibilidade entre arquitetura de software e metodologias ágeis?

  • Metodologias
  • Uncategorized

A arquitetura de software descreve a organização de um sistema ou a sua estrutura e fornece uma explicação de como ele se comporta. Um sistema representa a junção de componentes que executam uma função específica ou conjunto de funções. Em outras palavras, a arquitetura do software fornece uma base sólida para a construção de um sistema.

Conforme o número de soluções de software cresce, um grau de homogeneização entre essas soluções fica cada vez mais necessário. Na maioria dos casos, esse processo tem implicações econômicas, reduzindo custos direta ou indiretamente e essa é uma das razões que torna a arquitetura de software valiosa. No entanto, essa só valerá a pena se atender aos drivers arquitetônicos (de princípios e restrições), fornecendo as bases necessárias para o resto do código.

Com essas soluções tecnológicas cresce a implementação das metodologias ágeis. Se entendermos o Agile como: Mover-se rapidamente e abraçar mudanças, estamos falando de um processo de melhoria contínua, que fornece uma solução com alto grau de qualidade em um curto espaço de tempo. Também se trata de remover resíduos, ou seja, tudo o que não vale a pena dentro de um processo.

Existe um conceito interessante dentro de alguns Frameworks que tenta tirar proveito de ambas as abordagens, que recebe o nome de Arquitetura Ágil. A ideia dessa combinação é ter uma arquitetura de referência que constrói soluções, com um grau de inovação que vai alimentar a arquitetura ao mesmo tempo que outras equipes possam tirar proveito disso. No entanto, esses dois universos podem soar um pouco contraditórios ou incompatíveis para alguns profissionais.

As questões que geram conflitos entre a arquitetura de software e as metodologias ágeis são:

  • A arquitetura é qualidade, então existe agilidade sem arquitetura?
  • Uma área de arquitetura não é antagônica aos modelos de squads?
  • A arquitetura emergente funciona?

São várias perguntas e as respostas são complexas, portanto, vamos por partes.

O conflito entre a arquitetura de software e o Agile

Por experiência própria, em um evento de arquitetura de software que aconteceu em 2018, em San Diego, podemos afirmar que os nossos palestrantes receberam olhares desconfiados do público ao discursarem sobre metodologias ágeis. Felizmente, fomos capazes de esclarecer o Agile como um aliado para todos os processos, dissolvendo o antagonismo que os profissionais da área costumam interpretar sobre os dois assuntos.

Ao observarmos as características da arquitetura de software e compará-las com as metodologias ágeis, ambas podem parecer um tanto quanto desconexas:

Arquitetura de software  Metodologias ágeis
Alta definição
Regras
Alto planejamento
BDUF (Big Design Up to Front)
Especialização
Centralização
Imutabilidade
Direcionamento
Poucas restrições
Replanejamento constante
Design emergente
Multidisciplinaridade
Distribuição
Adaptabilidade

No entanto, os conflitos não se resumem às divergências teóricas. No evento XPConf de 2019, em Montreal, um grupo de cientistas da computação elaborou uma pesquisa reunindo diversas empresas que usam as metodologias ágeis e uma das perguntas era sobre as desvantagens da agilidade e as respostas foram as seguintes:

  • 58% dos entrevistados informaram que o comprometimento caiu;
  • 49% relataram dívidas técnicas;
  • 42% baixa documentação;
  • 40% refactoring ou reestruturação;
  • 26% arquitetura mal estruturada;
  • 16% alto custo de desenvolvimento.

Os últimos 5 itens dessa lista estão relacionados com a qualidade, ou seja, com as atividades da arquitetura. Mas quais são as causas dessas experiências negativas?

A grande bola de lama

Um dos maiores problemas que afetam a arquitetura de softwares é o termo cunhado por Joseph Yoder, Cientista da computação e Consultor ágil dos EUA, como “uma grande bola de lama”. Um padrão onde todos os softwares carecem de uma arquitetura perceptível. Embora indesejáveis do ponto de vista da engenharia de software, tais sistemas são comuns na prática em razão das pressões de negócios, rotatividade de desenvolvedores e entropia de código.

Segundo Yoder, muitos de nossos sistemas de software são, arquitetonicamente, pouco mais do que favelas. O investimento em ferramentas e infraestrutura é inadequado na grande maioria dos casos. As ferramentas geralmente são primitivas e a infraestrutura, como bibliotecas e estruturas, recebem pouco investimento. Partes individuais do sistema crescem sem controle e a falta de infraestrutura e arquitetura abre precedentes para problemas em uma parte do sistema, causando erosão e poluição das partes adjacentes. Os prazos se aproximam como monções, e a elegância arquitetônica fica cada vez mais inatingível.

Portanto, o primeiro prognóstico que temos aqui é:

A falta de qualidade é um fato e um problema abrangente do desenvolvimento de software. Não se trata de um reflexo da implementação das metodologias ágeis.

Arquitetura incremental

A segunda razão é que a agilidade prega a arquitetura incremental, ou seja, melhorar a arquitetura de acordo com o desenvolvimento do sistema. Para os desenvolvedores, esse conceito soa como a política da Nike, o Just Do it, “simplesmente faça”, método também conhecido como Extreme Go Horse (práticas questionáveis de programação), relacionando a arquitetura incremental com a falta de planejamento e tomada de decisão reativa, ou até mesmo com uma “gambiarra”, o que é um grande equívoco.

A arquitetura incremental foca na maneira como os desenvolvedores e a operação interagem com o projeto, portanto, é sobre encontrar a ótica ágil mais adequada para a arquitetura do software. Nesse cenário, unimos métodos e práticas que ajudam a evitar falhas na comunicação e no processo.

Como conciliar a arquitetura de software com a agilidade?

Existe uma solução para unir de forma construtiva as metodologias ágeis com a arquitetura de software. Essa solução nós desenvolvemos através da prática com os nossos clientes e para alcançar esse objetivo, nós utilizamos uma tática que chamamos de Approach Evolutivo. Nesse processo, nós identificamos as necessidades que surgem no projeto, avaliamos a capacidade (tempo para mudar) de implementação de melhorias e procuramos uma solução de baixo risco.

1.    Encontrar as necessidades – Visibilidade

Essa primeira etapa do approach evolutivo também é chamada de percepção da dor. Na arquitetura de software, dores surgem a qualquer momento e é por isso que precisamos desenvolver uma percepção apurada sobre essas dores, ou seja, é importante antever os impactos de possíveis problemas que podem vir a acontecer. Para isso, nós utilizamos algumas aplicações que indicam as dependências dos módulos do sistema e, em muitos casos, encontramos diversas ligações que demonstram uma alta probabilidade de falhas, como um “emaranhado de fios” e, da mesma forma que isso é um risco em um poste de energia, por exemplo, é um risco para o software.

2.    Tempo para mudar – Qualitividade

Se é necessário ter tempo para mudar, significa que o projeto precisa de um planejamento detalhado? Não! Até mesmo porque a ideia é somar a agilidade com a arquitetura, ou seja, ir melhorando o projeto constantemente e a forma mais adequada que encontramos para fazer isso é através do PDCA:

  • Plan: Planejar melhorias:    
  • Do: Executar testes;
  • Check: Checar resultados;
  • Act: Agir/Implementar.

Para alguns gestores essa estratégia pode caminhar para modelo Go Horse, com paradas totais do desenvolvimento para resolver pontos críticos, mas o PDCA não vai por esse caminho. A tática para evitar essas paradas é dispor de tempo constante para melhoria. Ou seja, previamente ao projeto, uma quantidade de tempo (semanal ou diário) é definida para a melhoria do sistema.

Portanto, não esperamos os problemas surgirem, afinal nós já sabemos que vão surgir em algum ponto, e a saída é alocar o tempo. A nossa indicação é separar em torno de 20% das horas semanais, para todos os membros do time focarem somente na qualidade e isso nós chamamos de “qualitividade”, palavra inexistente no dicionário brasileiro, mas expressa o tempo investido em qualidade para melhorar a produtividade.

3.    Segurança para mudar – Continuous testing

Quando falamos em segurança para mudar, estamos falando em baixo risco e para garantirmos isso, geralmente trabalhamos com cofres cujo acesso é exclusivo para os especialistas responsáveis pela arquitetura, mas esse não é o único método e nem o mais indicado, pois volta para o approach sem agilidade, ou seja, sem multidisciplinaridade.

A saída ágil é buscar a confiabilidade para todo o sistema, dessa forma é possível criar em colaboração, promovendo autonomia.

A forma mais adequada para alcançar a segurança no sistema, possibilitando mudanças sem riscos é uma abordagem com testes automatizados. Em todas as etapas, desde o planejamento e desenvolvimento de códigos até a operação e o lançamento, aplicamos o continuous testing, eliminando os riscos sobre as mudanças que queremos implementar.

Sim! Há compatibilidade entre arquitetura de software e metodologias ágeis!

Como podemos entender até aqui, a ideia de incompatibilidade entre a arquitetura de software e o Agile parte de princípios pouco aprofundados sobre o que são as otimizações ágeis de fato. Nós preparamos um webinar completo abordando esse case de forma detalhada para você acompanhar, confira:

É importante conversar com um especialista que entenda das duas áreas e nós podemos te ajudar com isso.

Aqui na Objective temos alguns cases de sucesso da implementação do Agile em sistemas que utilizavam uma abordagem Go Horse e, ao invés de dívidas técnicas e arquitetura mal estruturada, como relatado na XPconf de 2019, os nossos clientes se depararam com uma estrutura bem organizada do seu sistema, com um processo mais fluido e assertivo.

Insights do nosso time

Obtenha insights do nosso time de especialistas sobre metodologias de desenvolvimento de software, linguagens, tecnologia e muito mais para apoiar o seu time na operação e estratégia de negócio.