Como o design de arquitetura é feito em um ambiente ágil?

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):

1. 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.
2. 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.
3. 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.
4. 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.

Aviso: Eu não sou um técnico / arquiteto ágil - isso é o que eu vi em projetos ágeis em que trabalhei e acho que funciona bem.

Eu não acho que seja bem definido pelo Agile como você faz arquitetura - o foco ágil em metodologias e práticas de desenvolvimento. A UML, por outro lado, é apenas uma linguagem para comunicar sua arquitetura que está além da agilidade (você a utiliza se ela se adequar ao seu projeto e à sua equipe).

Um dos princípios da arquitetura que realmente se aplica é tomar a decisão no último momento responsável possível - o que significa que é bom se você não tiver tomado todas as decisões no início do projeto, especialmente porque você tem menos informações este estágio. Com o tempo, você pode tomar decisões que "evoluem" a arquitetura. Sim, isso pode parecer um retrabalho, mas isso também se deve ao fato de você ter aprendido coisas novas sobre o ambiente, os requisitos, o que é possível, o que não é, etc.

A principal coisa que você gostaria de evitar é a rotatividade da arquitetura - em que o código não está realmente de acordo com qualquer qualquer arquitetura específica e é apenas uma confusão confusa. A principal diferença em relação à evolução de uma arquitetura é que, no segundo caso, você toma decisões conscientes periodicamente e documenta-as com motivos claros e, em seguida, segue para garantir que seu código a siga.

Ao fazer o desenvolvimento orientado a testes, você cria um código de teste que testa seus módulos de forma isolada (= como independente de outros módulos quanto possível)

Para facilitar a criação do código de teste, você introduz interfaces a outros módulos que podem ser facilmente ridicularizados.

Desta forma, como um lado, você recebe automaticamente uma arquitetura onde o acoplamento entre os módulos é o menor possível.

Na minha opinião, o tdd também é um trabalho arquitetônico.