BT

O conflito entre Agile e Arquitetura

por Vikas Hazrati , traduzido por Giovanni Abner em 20 Jun 2011 |

Existe um conflito constante entre seguir técnicas ágeis e conseguir fazer arquitetura corporativa. Enquanto o desenvolvimento ágil concentra-se em ajustar a modelagem e o planejamento à medida que se ganha conhecimento sobre o domínio, a arquitetura estabelece uma plataforma tecnológica e trata dos atributos de qualidade, atendendo às partes interessadas. Uma combinação desses dois aspectos será bem-sucedida quando as técnicas ágeis forem usadas para atingir a arquitetura desejada.

Tom Graves sugere que a agilidade precisa um suporte fornecido pela arquitetura:

A agilidade necessita frequentemente de uma espinha dorsal para manter sua direção – algo que dê sustentação, evitando perda de direção e foco. Trata-se de conseguir o equilíbrio adequado entre o "osso" da arquitetura e o "músculo" da agilidade.

Jan Van Til concorda com Graves ao sugerir que, sem uma espinha dorsal subjacente, seria difícil enxergar o Agile acontecendo em primeiro plano:

Precisamos de um segundo plano que se movimente mais lentamente, para que seja possível distinguir a agilidade no primeiro plano. Se tudo for moda, ningém seria capaz de distinguir uma moda de outra. Em outras palavras: precisamos de tradição. Sem tradição não existe moda.

Simon Brown sugere que mesmo o "mais ágil dos projetos" traz certo nível de preocupações arquiteturais. Estas preocupações precisam ser tratadas durante as primeiras iterações. De acordo com Brown, o conflito entre Agile e Arquitetura acontece devido à entrega de valor em pequenos blocos, em vez da realização de um grande investimento inicial no projeto arquitetural. O segredo é projetar apenas o suficiente. É importante estabelecer uma estrutura de alto nível, mas isso não significa criar uma infinidade de diagramas de classes detalhados.

Por outro lado, John Bauer menciona um padrão que observou em vários projetos.

Abordagens ágeis têm um efeito colateral muito positivo: reduzir a ocorrência de soluções de software com excesso de arquitetura, que sobrecarregam a entrega do software e aumentam os custos de desenvolvimento e manutenção, geralmente de maneira desproporcional ao valor de negócio produzido.

James Coplien e Kevlin Henney apresentam uma forma eficaz de começar apenas com a arquitetura suficiente e assegurar o sucesso do projeto.

Mas como tudo isso funciona no mundo real?

Simon Brown postou um desafio interessante sobre como substituir um sistema de Internet banking que está ficando obsoleto em cerca de quatro meses. A ideia seria trabalhar de forma ágil e mesmo assim entregar o produto. Há algumas soluções propostas no próprio post, bem como outras sugeridas por Kero e John Bauer. É possível acompanhar as soluções e propor soluções adicionais.

Portanto, Agile e Arquitetura precisam coexistir; não são excludentes. É importante fazer "apenas o suficiente", o que Simon Brown explica da seguinte forma:

Defina apenas a arquitetura suficiente para obter clareza e visão, ou seja, para identificar o seu objetivo e como vai atingi-lo. A arquitetura representa as decisões importantes. A importância é medida pelo custo em se fazer mudanças: aspectos com custo alto de modificação devem ser definidos corretamente o mais cedo possível. Por exemplo, qualidades como alta escalabilidade, segurança e alta disponibilidade geralmente precisam estar embutidas desde o início, nos alicerces do sistema, porque são difíceis de incorporar a uma base de código preexistente. Outros exemplos de aspectos que devem ser tratados com atencedência são os que não podem ser refatorados facilmente em uma tarde, como escolhas de tecnologia e de padrões de arquitetura, frameworks básicos a serem utilizados, e assim por diante.

 

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

O conflito entre Agile e Arquitetura by Rodolfo Mendes

Foi bastante esclarecedor esse artigo. Ainda não tive a oportunidade de utilizar Scrum e XP na vida real. Mas com o material que se tem na internet, a idéia que é passada é que você pega uma estória do whiteboard e começa a escrever testes unitários até o sistema ficar pronto. Acho que é por isso que muita gente tem a idéia errônea que não existe planejamento em metodologias ágeis.

É impossível um projeto evoluir sem a arquitetura também evoluir. by Roberto Nogueira

é impossível um projeto evoluir sem a arquitetura também evoluir. Logo o design sempre vai estar sujeito a mudanças. Acredito até que tentar prever essa evolução no futuro através de uma arquitetura tecnicamente chutada colabore mais com a estagnação do que com a evolução. Por isso o design deve ser emergente, visto a evolução não pode ser prevista ou controlada.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT