Uberlândia - MG
+55 (34) 3016-0600

Manifesto Ágil e suas consequências na Arquitetura de Software

Manifesto Ágil e suas consequências na  Arquitetura de Software

Ouvimos bastante falar do “Manifesto Ágil“, no qual basicamente resume a maioria da base das metodologias ágeis como XP, DSDM, Scrum, FDD etc.

O porém que menos se observa nas metodologias aplicadas é a presença de maturidade para a aplicação na Arquitetura de Software.

Reunindo bastante conhecimento de mercado e diversas experiências vividas com esse tipo de metodologia, irei citar o quão diferente os processos devem ser para o paradigma “Arquitetura de Software“.

001 – O que é Arquitetura de Software?

Manifesto Ágil e suas consequências na  Arquitetura de Software

De forma simplificada, Arquitetura de Software, é todo e qualquer padrão de desenvolvimento feito para atender os requisitos de desenvolvimento e “mais recentemente“, a própria escalabilidade de um sistema, baseado na complexidade dos requisitos definidos.

Um Arquiteto de Software tem como principal tarefa, prover padrões de mercado compatíveis com os requisitos do sistema apresentados, ou seja, todo o desenvolvimento da equipe dependeria do trabalho de um ou mais Arquitetos.

Um bom arquiteto irá definir o padrão de um ecosistema de software utilizando componentes altamente reutilizáveis, do tipo “easy as 1..2..3..“, visando a centralização dos algoritmos cruciais para o funcionamento de um sistema e o ganho na produtividade com a equipe de desenvolvimento.

A escalabilidade de uma aplicação depende diretamente das peças que a equipe de Arquitetura do software em questão define, ou seja, quanto mais dependências um sistema tem, mais complexa a missão de escalabilidade fica.

Métodos de Caching e Micro Serviços sem estado, que conseguem livremente se multiplicar ou se reduzir e o próprio acoplamento entre tais serviços é o que define a facilidade ou não da escala e performance da aplicação.

Aplicações prontas para a nuvem (ou Cloud-Native) são projetadas para escalar naturalmente, elevando a resiliência e diminuindo o tempo de resposta para o cliente, mas nem sempre é o que observamos no que é desenvolvido no mercado.

002 – Como muitas empresas e o próprio cliente atualmente enxergam Arquitetura de Software?

Manifesto Ágil e suas consequências na  Arquitetura de Software

Arquitetura de Software para muitas empresas ainda significa algo dispensável e não importante para o projeto.

Em muitos casos, o pensamento de conceitos de padronização somente aparece do meio para o final do projeto, causando massiva necessidade de refatoração no código quase “a todo o momento“.

Alguns itens a refletir:

  • Refatorar é preciso, mas é necessário saber dosar a quantidade de alterações, e o melhor momento para elas.
  • Falando de momento, o início do projeto seria a melhor época para se pensar em Arquitetura de Software, mas sabemos que em muitos casos isso é raro.
  • Nem todos os que aplicam metodologias ágeis de software sabem ou se importam com os benefícios de um software bem feito orientado a sólida arquitetura.

Para a maioria dos clientes finais, o que “menos” importaria seria como o software foi feito (mas ao mesmo tempo, não ficam satisfeitos em ver uma pobre experiência de uso dos usuários por conta de instabilidades no funcionamento do produto, além do alto custo de manutenção envolvido por conta da forma que o software foi desenvolvido).

Será mesmo que os clientes sabem dos riscos que tais práticas de execução trazem para o projeto que tanto planejaram investir?

Qual o parâmetro que atualmente os clientes utilizam para contratar a empresa de software X, Y ou Z? Será mesmo que clientes sabem que uma filosofia de Arquitetura de Software sólida muda a execução e o funcionamento final de um projeto da água para o vinho?

003 – Manifesto ágil na Arquitetura de Software sem know-how pode ser o maior fracasso de um projeto.

Manifesto Ágil e suas consequências na  Arquitetura de Software

Sprints, datas “cravadas” na pedra e outras muitas outras situações de metodogias ágeis são na maioria das vezes as mesmas para profissionais que desenvolvem a Arquitetura de um sistema.

Em Arquitetura de Software é preciso ter definições básicas de funcionamento a curto, médio e longo prazo, e o quão complexo será a evolução do mesmo entre os membros da equipe, mas muitas vezes nem o cliente sabe o que deseja.

Documentação, algo que cada vez mais vem perdendo sentido em metodologias ágeis é crucial para uma boa vivência entre Arquitetos de Software e Desenvolvedores, mas muitas vezes, o framework ágil “não permite” investimento de tempo em documentações que realmente ajudariam os executores do projeto a produzirem muito mais.

004 – Sem compreender os ganhos de uma boa Arquitetura de Software, não existe software bem feito.

Manifesto Ágil e suas consequências na  Arquitetura de Software

Um software com sólida arquitetura tem ganhos incalculáveis no desenvolvimento a curto, médio e longo prazo.

Quando menciono “sólida arquitetura“, estou me referindo a padrões de mercado amplamente utilizados implementados de forma correta (e isso é diferente de se aventurar com novas tecnologias na versão alpha cheia de bugs e problemas, muitas vezes de segurança) e inclusive, isso não é inovação, e sim risco, segue outro artigo escrito por mim nesse contexto:

Você realmente sabe o que é Inovar no mercado de software?

https://aag.solutions/voce-realmente-sabe-o-que-e-inovar-no-mercado-de-software/

Infelizmente o que mais se observa no mercado é a implementação de arquiteturas de software sem conceito, altamente acopladas e de alta complexidade tanto para o arquiteto quanto para o desenvolvedor (e isso indica que está tudo errado) ou ainda melhor: Software sem nenhum padrão orientado a Ctrl C + V (famoso Go-Horse que visa a entrega do serviço sem nenhum parâmetro de qualidade).

As formas mais “simples e rápidas” para desenvolver um software “para ontem” são as que mais deixam marcas no ciclo de vida de um software.

Falando de tecnologia, observamos no mercado empresas sem nenhum interesse em realmente pesquisar e definir software de forma correta (ou simplesmente reféns de metodologias ágeis [ou reféns do prazo do cliente]) se se aventurando na implementação de “qualquer jeito“, o final da história nem preciso comentar não é mesmo?

005 – Os maiores casos de sucesso na indústria da tecnologia envolvem projetos altamente padronizados.

Manifesto Ágil e suas consequências na  Arquitetura de Software

Empresas grandes são as que mais observam ganhos com software bem feito, tais como Nubank, Netflix, Uber etc, pois a qualidade e o funcionamento do produto definem a experiência do usuário, e para essas empresas, a maior base dos usuários acessam seus produtos pela internet.

Conclusão

Independentemente do tamanho do seu software / produto, você deve pensar como gente grande, se tem a pretensão de ser um deles, e isso começa pela estrutura do seu sistema.

Observo que grandes empresas estão preocupando tarde demais com a estrutura dos seus sistemas, mas pelo menos estão preocupando, e isso é bom.

Algumas empresas acreditam compensa contratar, por exemplo, 3 desenvolvedores pelo preço de 1 arquiteto, que no final das contas, causam um débito técnico relevante no projeto e insatisfação generalizada, já que desenvolvedor raramente tem interesse em arquitetura – E os que se interessam, são ou estão para ser arquitetos.

Conteúdo 100% autoral, baseado em experiências e fatos reais.

Escrito por Michel Oliveira, CEO da AAG Soluções em 20 de fevereiro de 2020.