Como tratar atividades de arquitetura em projetos Ágeis? Tradicionalmente, em metodologias Waterfall, conforme imagem abaixo, as atividades de arquitetura se concentram até a fase de design. É o que é tradicionalmente chamado de BDUF (Big Design Up Front).
Metodologia Waterfall - fonte: Martin Fowler - Waterfall process
Nesse tipo de metodologia, temos todo o desenho funcional e de arquitetura sendo feito antes de se iniciar o desenvolvimento e é fácil ver como as atividades de arquitetura se encaixam no projeto.
Contudo, hoje a maior parte das organizações já está adotando metodologias ágeis, em grande parte pois perceberam que as metodologias em cascatas demoram muito para entregar valor às organizações, gasta-se um grande tempo em desenho de uma solução, que quando fica pronta, normalmente não atende às novas demandas do mercado, que evolui muito rápido.
Isso nos deixa com a pergunta que abre esse artigo: como tratar as atividades de arquitetura em metodologias ágeis?
E complemento: Como tratar as atividades de arquitetura em metodologias ágeis se o foco é na entrega de valor e o backlog é determinado por um product owner com uma visão excelente de negócio, mas com pouca visão técnica?
Abordagens
O mercado tem adotado duas abordagens principais quando fala de arquitetura em projetos Ágeis:
A primeira abordagem, vinda da metodologia SAFE (Scaled Agile Framework que é voltada para iniciativas de maior porte e com múltiplos times colaborando), ela é chamada de Architecture Runway, que pode ser traduzida como "Pista de arquitetura" ou "Passarela de Arquitetura".
Nesta abordagem, é montada uma equipe de arquitetura com um Arquiteto como Product Owner. Este time trabalha em funcionalidades que habilitam os outros times a entregarem valor para o negócio.
A segunda abordagem mais utilizada é dar autonomia completa às equipes para tomada de decisão, e deixar as atividades de arquitetura como parte das sprints. Para essa abordagem ser bem sucedida é necessário um time com maior senioridade e um PO que consiga ver valor em atividades mais técnicas, visto que em geral essa abordagem tente a gerar necessidades mais frequentes de refatoração.
Ambas as abordagens tem benefícios e desafios, e irei no futuro fazer um artigo sobre elas, mas como bom Arquiteto, não poderia deixar de falar da parte técnica. Qual a chave para fazer uma arquitetura evolutiva?
A chave da Arquitetura Evolutiva
Independente da abordagem, a chave para obter uma arquitetura evolutiva é diminuir o acoplamento nos sistemas. Pensando em um cenário padrão de aplicações, como visto abaixo, o desacoplamento deve ser feito em vários níveis.
Tipos de desacoplamento
- Desacoplamento dentro de um módulo: Desacoplar as funcionalidades dentro de um módulo do sistema
- Desacoplamento dentro de um sistema: Desacoplar os diversos módulos dos sistemas
- Desacoplamento entre sistemas: Desacoplar os diversos sistemas dentro da empresa
- Desacoplamento com entes externos: Desacoplar sistemas externos á nossa empresa
Para cada um desses níveis, existem técnicas para obter o desacoplamento, irei criar uma série de artigos abordando individualmente esses tipos de desacoplamento, então fique de olho!
Top comments (4)
Excelente artigo Racz, de alguma forma esses desacoplamentos tem prioridade entre eles? Gostaria de saber mais e também se em um determinado desacoplamento podem haver postergação de decisões.
Como tudo em arquitetura, isso depende. A prioridade depende das necessidades que você tem.
Eu diria que o maior imperativo é não se acoplar a sistemas externos à empresa, poque você gera uma dependencia que está totalmente fora do seu controle.
Sobre postergar decisões, eu vejo que desacoplar é uma forma de habilitar isso, fazer um sistema desacoplado, te facilita tomada de decisões futuras, o que é muito importante pra conseguir ser ágil de fato.
Opa Racz, gostei da pegada, obrigado por compartilhar!
No aguardo do próximo! 🚀