Disclaimer: Eu sou um arquiteto em um ambiente ágil, mas, como Helmuth von Moltke, o Ancião, diz: "Nenhum plano de batalha sobrevive ao contato com o inimigo". Em outras palavras, os aspectos práticos significam que a letra exata das diretrizes nem sempre pode ser seguida.
A maioria dos pontos acima são seguidos da melhor maneira possível. No entanto, o princípio 1 (As equipes que codificam o sistema projetam o sistema) é realmente difícil de ser seguido 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 os requisitos dos clientes e entender os sistemas complexos existentes.
So, how is the system design done? Using UML? Or a document that defines interfaces and major blocks? Maybe something else?
Muitas vezes, o arquiteto identifica os principais componentes e define as interfaces entre eles (incluindo requisitos não funcionais, como segurança, velocidade e confiabilidade) e delega o design interno dos componentes a equipes individuais . Este é um bom compromisso entre deixar as equipes projetarem 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 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. Estes incluem casos de uso ou histórias de usuários que detalham os requisitos de negócios de nível superior. Eu pessoalmente gosto de usar RFC 2119 para requisitos não-funcionais. O design baseia-se e remonta a estes. Embora possa não se encaixar na definição comum de design, estas são muitas vezes tão 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 o gerenciamento superior até o dev e o controle de qualidade. Isso raramente usa UML ou uma notação definida devido ao amplo público.
- Detalhes para componentes individuais, geralmente com foco nas interfaces ou APIs entre eles, conforme mencionado acima. Interfaces podem ser especificadas como assinaturas de métodos 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 data center e seus arranjos de rede. Bancos de dados relacionais geralmente terão diagramas de Entidade-Relacionamento.
- Uma lista de riscos arquiteturais e suas atenuações, se conhecidas. Como os requisitos, eles demonstram decisões de design e trade-offs.
Em suma, o design de um sistema em um processo ágil é exatamente o mesmo que em um processo tradicional de cascata. No entanto, em ambientes ágeis, menos projeto é feito antecipadamente e mais dele é delegado a equipes de componentes . A chave é determinar a que profundidade ir inicialmente, quais decisões adiar e identificar quando as decisões precisam ser tomadas. Decisões que afetam várias equipes de desenvolvimento devem ser tomadas anteriormente, especialmente escalabilidade e segurança. Decisões como adicionar idiomas adicionais a um produto já internacionalizado podem ser adiadas até muito tarde.
Depois que o design inicial é criado, o arquiteto trabalha com cada uma das equipes e analisa seus projetos. Se forem necessárias alterações adicionais de design ou design para uma unidade de trabalho (como um scrum sprint), o arquiteto terá a intenção de disponibilizá-lo no momento em que a unidade de trabalho for iniciada. O arquiteto também é responsável por comunicar quaisquer alterações às equipes ou partes interessadas afetadas.