BT

Arquitetura e Agile: Casados, divorciados, ou apenas bons amigos?

Postado por Frank Buschmann and Kevlin Henney , traduzido por Tulius Lima em 26 Ago 2014 |

O desenvolvimento ágil precisa de arquitetura? A arquitetura necessita do desenvolvimento ágil? Será possível ao menos responder essas perguntas sem polarizar o debate caracterizado mais por uma visão caricatural e arraigada, do que por definições claras e abertas à razão - um debate que lembra mais dois monólogos sem fim que um diálogo? Talvez reformular a pergunta em termos mais genéricos ofereça um ponto de partida melhor: em vez de se concentrar especificamente em abordagens ágeis, devemos considerar os processos de desenvolvimento de forma mais ampla. E, ao invés de levantar uma suposição como pergunta, devemos considerar uma questão mais aberta e neutra: qual é a relação entre arquitetura e processo?

Arquitetura e processo

Arquitetura é comumente definida como "a decomposição estrutural de um sistema, incluindo a sua decomposição em partes, sua conectividade, os mecanismos de interação e os princípios orientadores que informam o desenho do sistema." [1]

Embora não seja incorreta do ponto de vista técnico, esta definição está aberta a uma gama de interpretações. Pode significar qualquer coisa, desde um esboço de design de alto nível com pouca relação com tecnologia, código ou o sistema real sendo construído [2] - até um design antecipado grande e rígido com minúcias no nível de classe e de código.

Na prática, nenhuma visão oferece orientação suficiente para o próprio processo de desenvolvimento, uma contribuição necessária para uma "boa" arquitetura. A primeira forma é abstrata demais para dar orientações concretas; o segundo é muito prematuro, por demais definitivo antes de detalhes relevantes serem realmente conhecidos. Portanto, não é surpresa que alguns na comunidade ágil afirmem que, na prática, arquitetura não é uma preocupação central no desenvolvimento de software.

Grady Booch [3] e Martin Fowler [4], em contrapartida, propõem definições diferentes para o valor da arquitetura de software. Ambos definem Arquitetura em termos de decisões importantes que são caras e difíceis de mudar. Paul Dyson e Andy Longshaw ampliam a consideração estrutural de arquitetura com uma lógica - o porquê - que orienta as decisões de design [5]. Essas definições ajudam a ver a arquitetura como algo que responda a um conjunto de necessidades, tais como requisitos funcionais, características operacionais e a habitabilidade do desenvolvedor.

Na prática, expressar uma arquitetura de software pode incluir uma divisão transversal de decisões, desde um esboço feito em papel de pão até detalhes importantes, alguns dos quais são adequadamente e explicitamente reconhecidos como decisões, outros são pressupostos ou fatos, e alguns são decisões feitas de forma não intencional e reconhecidas como significativas apenas em uma retrospectiva.

Dessa forma, a arquitetura torna-se um serviço para orientar e desenvolver um sistema de software para a realização de um conjunto de objetivos comerciais e técnicos [6]. Esses objetivos são expressos de forma a melhorar a comunicação e o compartilhamento. A arquitetura não é um artefato técnico expresso numa descrição puramente formal.

Um processo pode ser considerado a resposta a um conjunto de perguntas: quem faz o quê, quando, como, por que e para quem? Todos os projetos de desenvolvimento de software, portanto, têm um processo, mesmo que isso não seja explícito. As respostas a essas perguntas, não importando quais sejam, podem ser consideradas o processo - seja ele formal ou informal, não dependendo de fornecer ou não à uma equipe o controle direto sobre o desenvolvimento.

No entanto, podemos ver que o modo como contratamos, orçamos e planejamos um projeto são decisões que influenciam significativamente a escolha e a viabilidade de qualquer arquitetura. Isso é verdade para muitas coisas, desde como a Lei de Conway [7] se aplica à forma como um sistema é particionado, independentemente de sua visão original, até as questões de escolha de tecnologia e de competências, escopo previsto e modelo de lançamento, e, em última análise, o projeto do sistema desenvolvido.

A relação entre essas influências e a tendência de mudança ao longo do tempo, exigem processos que estabeleçam as cadeias de decisão para a arquitetura e ciclos de feedback, de forma a ajustar quaisquer decisões em relação a novas informações. Um processo deve apoiar uma equipe de projeto, e não vice-versa. Equipes de projetos não são pagas para atender um processo, mas sim para entregar software funcionando! E esse é exatamente o objetivo dos processos ágeis.

O que a arquitetura significa para o desenvolvimento ágil

Diferentemente do que se vê em algumas discussões da comunidade de software, o desenvolvimento ágil não se trata de adotar religiosamente o Scrum ou outro processo, ferramenta ou método, embora isso exista e seja considerado um problema. A essência da agilidade é a capacidade de resposta, a aprendizagem e a auto-suficiência. A agilidade se reflete em sustentabilidade e qualidade no software e em seu desenvolvimento- por definição, desenvolvimento insustentável e de pouca qualidade contradiz e reduz a agilidade. O Manifesto para Ágil observa que "a atenção contínua à excelência técnica e ao bom design aumenta a agilidade". Isso oferece à arquitetura um papel claro dentro do Agile, embora esta não seja expressa por meio de um grande design antecipado(up-front).

Jens Coldewey comentou que a arquitetura é aquilo que contribui para o aumento de velocidade. Mesmo com toda a vontade ágil no mundo, uma arquitetura pode ser mal concebida, ou estar desalinhada com a finalidade do sistema, e irá dificultar a criação de um processo e de um sistema. Uma má arquitetura irá jogar contra a equipe de desenvolvimento e contra o fluxo de requisitos, ao invés de de jogar a favor da equipe e sua compreensão do propósito do sistema.

Quando se trata de Agile, arquitetos pragmáticos precisam se concentrar em uma pergunta simples: quais questões arquitetônicas bloqueiam a agilidade de uma equipe? Embora seja uma pergunta simples, a excelência técnica e conhecimento em design necessárias para negociar as questões significa que a resposta não é simples nem fácil. Modularização que esteja em conflito com o modelo de domínio da aplicação, acoplamento desnecessário, e interação intensa de componentes, tudo isso degrada a compreensão do desenvolvedor e eleva o tempo de construção e os prazos. Desestimula os programadores a realizar testes, a fazer pequenas mudanças, a experimentar. Qualquer forma de irreversibilidade desnecessária em design e dívidas técnicas imprudentes e não estruturadas provavelmente elevariam os custos e ao mesmo tempo, diminuiriam a habitabilidade e consequentemente a agilidade.

O que a arquitetura necessita dos processos

De onde vem a arquitetura? Nasce totalmente formada a partir da cabeça de um arquiteto onisciente? Surge por acaso, como que num passe de mágica?

Vamos parar um momento para considerar que a arquitetura é uma expressão de conhecimento. O desenvolvimento de software é trabalho intelectual, o que implica em aprendizagem: aprender sobre tecnologias, aprender o que o cliente quer, aprender a se comunicar com quem molda os requisitos de produto; aprender a melhor forma de desenvolver uma solução. Desde quais práticas serão utilizadas, decisões de design, aprender como trabalhar em conjunto, e assim por diante. Em suma, o conhecimento vem do aprendizado, e aprender leva tempo, o que é precisamente o que um processo estrutura.

O ponto de menor conhecimento e de maior ignorância ocorre no início de todo desenvolvimento, seja para um produto completo ou para apenas um release. Com isso em mente, é imprudente e irresponsável tomar todas as decisões importantes no início. Por outro lado, ao final de um projeto, temos o maior aprendizado, mas a menor oportunidade de utilizá-lo.

O que a arquitetura precisa do processo é espaço e tempo para aprender, algo que exige que tudo não esteja feito e decidido de forma definitiva no início, para que ela possa ser considerada uma atividade empírica, com cada decisão arquitetural vista como uma hipótese a ser validada e realimentada para a próxima decisão.

Equipes de projetos não são pagas para atender um processo, mas sim para entregar software funcionando!

Tal abordagem baseada em resposta e aprendizagem também acomoda um fluxo de requisitos. É importante ressaltar que, mesmo quando os requisitos possam parecer definitivos e imutáveis, ainda há um fluxo de requisitos pois a necessidade de esclarecimentos, os mercados e a política causam um fluxo constante (ou instável) de mudanças.

Em software, como na vida, muitas vezes entendemos as coisas ao tentar classificá-las e a raciocinar sobre elas. E no software, como na vida, muitas vezes percebemos à medida que aprendemos que muitas de nossas classificações criam distinções e dicotomias nítidas e falsas que obscurecem o que estamos tentando entender. O mesmo acontece com arquitetura e agilidade.

O que se pode construir é influenciado e limitado pela forma como se quer construí-lo; a forma como se constrói é influenciada e limitada pelas características de design mais significativas. Essa relação estreita entre arquitetura e processo significa que os arquitetos precisam pensar além de estrutura e tecnologia e pensar como o desenvolvimento de um sistema se desenrola no tempo.

Um planejamento inicial detalhado não atende bem o software ou seus desenvolvedores, ou a organização ao redor deles. Um processo ágil reage ao fluxo de descoberta e de mudanças que cerca qualquer sistema. Arquitetos pragmáticos precisam reconhecer e remover todos os obstáculos que frustram desenvolvedores e outros envolvidos,, fazendo que trabalhem com a arquitetura em no lugar de em volta dela.

Referências

[1] J. Rumbaugh, I. Jacobsen, and G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1998.

[2] J. Spolsky, "Architecture Astronauts Take Over," 1 May 2008.

[3] G. Booch, "On Design," blog, Mar. 2006.

[4] M. Fowler, "Who Needs an Architect?," IEEE Software, vol. 20, no. 5, 2003, pp. 11-13.

[5] P. Dyson and A. Longshaw, Architecting Enterprise Solutions, John Wiley & Sons, 2004.

[6] R. Faber, "Architects as Service Providers,"IEEE Software, vol. 27, no. 2, 2010, pp.33-40.

[7] M. Conway, "How Do Committees Invent?,"Datamation, Apr. 1968, pp. 28-31.

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

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-2014 C4Media Inc.
Política de privacidade
BT