Agilidade versus Arquitetura de Software
Atualmente, existe uma aparente tensão entre a comunidade de praticantes de métodos ágeis e arquitetos de software ortodoxos. Os chamados agilistas entendem que os arquitetos produzem “muito papel”, enquanto que mudança nos requisitos (principalmente arquiteturais) provoca incômodo a alguns arquitetos de software em qualquer estágio do projeto. Comentaremos rapidamente alguns mitos de agilidade versus arquitetura de software.
| Mito |
Quem costuma acreditar nisto |
Realidade |
| Arquitetura de software produz “muito papel”. |
Alguns adeptos de métodos ágeis. |
O processo de software adotado determina quais documentos são realmente necessários. Comunica-se somente o estritamente necessário. |
| Arquitetura de software implica em big design up front (intenção de criar todos os modelos no início do projeto). |
Alguns agilistas e arquitetos. |
A arquitetura deve respeitar a natureza do método. Em projetos ágeis, a arquitetura do software deve ser evolutiva. |
| Requisitos arquiteturais não podem mudar a partir de um certo momento. |
Alguns arquitetos e engenheiros de processos. |
Métodos ágeis aceitam mudanças a qualquer momento, tendo impacto ou não sobre a arquitetura. O cliente deve sempre estar ciente das consequências de uma mudança de requisito (arquitetural ou não) |
| Softwares desenvolvidos com métodos ágeis não tem arquitetura. |
Ignorantes da engenharia de software. |
Todo software tem uma arquitetura, independente se alguém a projetou intencionalmente ou não. |
| “Arquiteto de software é somente um novo e pomposo título que programadores pedem para ter em seus cartões.”(*) Projetos ágeis não precisam do arquiteto. |
Alguns adeptos de métodos ágeis. |
Vários métodos ágeis prescidem de papéis. Mesmo que ninguém na equipe tenha o papel ou cargo de arquiteto de software, convém planejar a arquitetura. |
| Toda a arquitetura deve ser modelada no início do projeto. |
Alguns arquitetos de software. |
Novamente: o arquiteto deve respeitar a natureza do projeto. Se o método prescreve “prove com código sempre que possível”, é interessante realizar a arquitetura em software executável mesmo que não esteja completamente modelada. |
(*) Esta é uma resposta atribuída a Kent Beck em OOPSLA 1992, segundo Philippe Kructhen.
Nossa convicção é que a disciplina de arquitetura de software pode contribuir para a redução de riscos técnicos mesmo em projetos que empreguem métodos ágeis. Para tal, em primeiro lugar, os trabalhos arquiteturais devem respeitar a natureza evolutiva de tais projetos. Em segundo, deve se ater a comunicar modelos arquiteturais apenas na medida exigida pelo método. Por exemplo, se a filosofia de desenvolvimento prega abandonar diagramas após a realização no modelo através do código, o arquiteto assim deve proceder. Outra situação: caso a equipe não faça uso de ferramentas CASE ou de modelagem avançadas, o arquiteto pode considerar a modelagem coletiva usando um quadro ou flip chart.
Algumas referências:
[...] De Architectura Post visualizado 2 [...]
Boa Tarde Eros,
Com relação ao ultimo mito (Toda a arquitetura deve ser modelada no início do projeto) fiquei com uma duvida.
Como a arquitetura não será modelada 100% no inicio do projeto, alterações na mesma serão frequentes. Para isso, quais tecnicas (dentro de metodologia agil) utilizamos para levantamento de impacto?
Obrigado e parabéns pelo POST!
Ewerton
Obrigado, Ewerton,
No nosso ponto de vista, não existem técnicas para avaliação de impacto ou algo parecido no mundo ágil. A gestão de mudanças ocorre de forma bastante pragmática pela própria filosofia baseada em práticas e valores como Coragem, Simplicidade, YAGNI, etc.
Agradecemos sua participação. Fique à vontade para expor suas idéias sobre o assunto.
Eros
No sistemas reais es miuto comun que seis requirimentos funcionais alteren com frecuencia, por isso é muito importante façer uma arquitetura base onde o arquitecto representa os casos de uso é os requisitos de qualidade mais importantes (securidade, desempenho, escalabilidade etc).
Então a arquitectura vão evolucionando com o projecto refinando seu modelo em cada iteração.