A arquitetura de software é o projeto e a especificação das regras pelas quais o software será construído, mantido e evoluído. É o DNA do sistema.
Pode ser de alto nível como “Vamos construir a solução usando serviços REST” ou tão detalhados quanto nomear os serviços específicos a serem desenvolvidos e quais dados esperamos que passem dentro e fora de cada um (ex: diagrama de sequência da UML / POO).
O Manifesto Ágil, destaca vários princípios que orientam o desenvolvimento de uma arquitetura de software ágil. Vejamos nesse post:
Especificações de arquitetura, documentos de design, processos de aprovação, etc., são importantes. Devem ser elaborados apenas quando nos aproximam do objetivo de que é o software funcionando. Esses artefatos são um meio para um fim, não um objetivo em si. A prioridade deve ser a geração de valor através de entrega de artefatos.
Este princípio está intimamente ligado ao valor do Manifesto Ágil sobre documentação abrangente. Se passarmos muito tempo documentando nossa arquitetura em vez de desenvolver software, estaremos nos afastando dos princípios ágeis.
Uma colaboração criativa envolve quem estará usando a arquitetura de software. Esta prática vai gerar valor a equipe, bem como atender aos requisitos de negócio da empresa.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.
Os projetos arquitetônicos iniciais geralmente tentam acomodar necessidades futuras antecipadas que podem nunca ser realmente realizadas. Isso causa mais trabalho para um pagamento que nunca chega. Construir e projetar com base na necessidade futura percebida não é ágil e desperdiça esforços. Tente usar o projeto baseado em equipe, em que seu design é construído de forma incremental junto com o código, refatorando-o à medida que avança.
A arquitetura está lá para guiar a equipe para uma solução que atenda às necessidades do software e da empresa. Se os membros da equipe não estão envolvidos com o desenvolvimento da arquitetura, eles podem não entender os objetivos e valores, gerando reação e descontentamento. Dê a eles o ambiente e o suporte de que precisam e confie neles para realizar o trabalho.
Agile não significa “sem design” ou “sem arquitetura”. As melhores práticas ainda se aplicam e ajudarão a equipe a se desenvolver com mais eficiência.
Uma arquitetura bem pensada facilita a inovação e evolução do produto. A evolução deve ser orientada aos requisitos de negócio.
Arquitetura demais pode dificultar a adaptação. A arquitetura ágil deve encontrar o equilíbrio certo para a equipe, o software, o ambiente e a empresa.
O que se esperava nos estágios iniciais de um projeto quase nunca corresponde à realidade. Ao projetar iterativamente e refletir sobre o que está gerando valor e o que está prejudicando a equipe, a equipe pode ajustar a arquitetura à medida que ela é testada e comprovada por meio do uso real e pode reavaliar e adaptá-la à medida que o projeto muda.
Para uma organização em transição para o desenvolvimento ágil, considere os princípios do Manifesto Ágil, envolva os membros da equipe que usarão a arquitetura em seu desenvolvimento, reflitam e adaptem com frequência e você terá uma arquitetura que atenda às necessidades de sua equipe e de sua empresa.