Como o projeto arquitetônico é feito em um ambiente ágil?

Eu li Princípios para o Agile Architect , onde eles definiram os próximos princípios:

Princípio # 1 As equipes que codificam o sistema projetam o sistema.
Princípio # 2 Crie a arquitetura mais simples que possa funcionar.
Princípio # 3 Em caso de dúvida, codifique-o.
Princípio # 4 Eles constroem, eles testam.
Princípio # 5 Quanto maior o sistema, maior a pista.
Princípio # 6 A arquitetura do sistema é uma colaboração de funções.
Princípio # 7 Não há monopólio da inovação.

O artigo diz que a maior parte do design da arquitetura é feita durante a fase de codificação, e somente o design do sistema antes disso. Está bem.

Então, como é feito o design do sistema? Usando UML? Ou um documento que define interfaces e principais blocos? Talvez algo mais?

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

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

Isenção de responsabilidade: Eu não sou um coach / arquiteto ágil - foi o que vi em projetos ágeis nos quais trabalhei e acho que funciona bem.

Eu não acho que seja bem definido pelo Agile como você faz a arquitetura - o Agile se concentra nas metodologias e práticas de desenvolvimento. A UML, por outro lado, é apenas uma linguagem para comunicar sua arquitetura que está além do ágil (você a usa se ela se encaixa no seu projeto e na sua equipe).

Um dos princípios de arquitetura que realmente se aplica é tomar a decisão no último momento responsável possível - ou seja, tudo bem se você não tiver tomado todas as decisões no início do projeto, principalmente porque você tem menos informações nesse 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 podridão da arquitetura - onde o código não está realmente em conformidade com nenhuma arquitetura específica e é apenas uma bagunça emaranhada. A principal diferença em relação à evolução de uma arquitetura é que, na última, você toma decisões conscientes periodicamente e as documenta com motivos claros, e depois 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 isoladamente (= o mais independente possível de outros módulos)

Para facilitar a criação do testingcode, você introduz interfaces para outros módulos que podem ser facilmente zombados.

Dessa forma, como efeito colateral, você obtém automaticamente uma arquitetura em que o acoplamento entre os módulos é o menor possível.

Na minha opinião, tdd também é obra de arquitetura.