Disclaimer: Eu sou um arquiteto em um ambiente ágil, mas, como Helmuth von Moltke diz: "Não plano de batalha sobrevive ao contato com o inimigo". Em outras palavras, praticidade significa que nem sempre é possível seguir a letra exata das diretrizes.
A maioria dos pontos acima mencionados é seguida da melhor maneira possível. No entanto, o princípio 1 (as equipes que codificam o sistema projetam o sistema) é realmente difícil de seguir quando a equipe consiste em dezenas (ou centenas) de desenvolvedores divididos em diferentes continentes e fusos horários . Isso não tem nada a ver com as habilidades ou atitudes dos desenvolvedores, mais o problema logístico de todos eles estarem presentes para reunir requisitos dos clientes e entender os sistemas complexos existentes.
Então, como é feito o design do sistema? Usando UML? Ou um documento que define interfaces e principais blocos? Talvez algo mais?
Frequentemente, o arquiteto identifica os principais componentes e depois define as interfaces entre eles (incluindo requisitos não funcionais, como segurança, velocidade e confiabilidade) e delega o design interno dos componentes para equipes individuais . Esse é um bom compromisso entre permitir que as equipes projetem seus próprios componentes sem exigir que todos saibam tudo sobre o sistema.
Toda organização tem seu próprio conjunto de padrões para projetos de arquitetura e isso às vezes varia de projeto para projeto dentro da organização. Esse design foi feito antes da equipe começar a codificar ou o mais cedo possível e geralmente contém (e não é uma lista completa):
- Requisitos expandidos e definição de escopo. Isso inclui casos de uso ou histórias de usuários que detalham os requisitos de negócios de nível superior. Pessoalmente, gosto de usar o RFC 2119 para requisitos não funcionais. O design é baseado e rastreado até eles. Embora possa não se encaixar na definição comum de design, elas geralmente são igualmente importantes.
- Uma visão geral que consiste em um diagrama de rede ou componente de alto nível e uma página de texto. Isso é para um público muito amplo, desde a alta gerência até o desenvolvedor e o controle de qualidade. Isso raramente usa UML ou uma notação definida devido ao grande público.
- Detalhes para componentes individuais, geralmente focados nas interfaces ou APIs entre eles, conforme mencionado acima. As interfaces podem ser especificadas como assinaturas de método no idioma de destino com detalhes de pré-condição e pós-condição. Os componentes podem ter diagramas de rede, como mostrar o layout das VMs em uma nuvem ou datacenter e seus arranjos de rede. Os bancos de dados relacionais geralmente terão diagramas de Entidade-Relacionamento.
- Uma lista de riscos arquitetônicos e suas mitigações, se conhecidas. Como os requisitos, eles demonstram decisões de design e trade-offs.
Em resumo, o design de um sistema em um processo ágil é exatamente o mesmo que em um processo em cascata tradicional. No entanto, em ambientes ágeis, menos do design é feito antecipadamente e mais é delegado às equipes de componentes . A chave é determinar o quão profundo deve ser inicialmente, quais decisões adiar e identificar quando as decisões precisam ser tomadas. As decisões que impactam várias equipes de desenvolvimento devem ser tomadas antes, principalmente escalabilidade e segurança. Decisões como adicionar idiomas adicionais a um produto já internacionalizado podem ser adiadas até muito tarde.
Após a criação do design inicial, o arquiteto trabalha com cada uma das equipes e revisa seus projetos. Se forem necessárias alterações adicionais no projeto ou no projeto para uma unidade de trabalho (como um sprum de scrum), o arquiteto pretende disponibilizá-lo quando a unidade de trabalho iniciar. O arquiteto também é responsável por comunicar quaisquer alterações às equipes ou partes interessadas afetadas.