A crescente procura por software de qualidade com baixo custo vem causando grande pressão nas empresas que trabalham com desenvolvimento. Nesse sentido, as empresas procuram por metodologias que propiciem o desenvolvimento de produtos com qualidade e que respeitem custos e prazos previstos. Em resposta a isso, o mercado de software tem adotado um conjunto de metodologias ágil (SCRUM, XP, KANBAN, LEAN START-UP, etc.) para disciplinar o desenvolvimento de soluções de software. Esta palestra tem por objetivo apresentar uma introdução às principais práticas e estratégias para potencializar o desenvolvimento ágil por pequenos e grandes times de desenvolvimento por meio da Arquitetura de Software no contexto ágil.

1. Práticas para Arquitetura Ágil
Denis Pinheiro
denis@dcc.ufmg.br

2. Agenda
 Introdução
 Rumo a Arquitetura Ágil
 Arquitetura ao longo do Ciclo de Vida
 Responsável pela Arquitetura
 Novo Papel: “Dono da Arquitetura”
 Arquitetura Ágil para Projetos de Grande Porte
– Baseie a Arquitetura nos Requisitos
– Modele a Arquitetura
– Prove a Arquitetura
– Comunique a Arquitetura
 Conclusão
2

3. Introdução
 Arquitetura é um aspecto importante no
desenvolvimento de software e é
considerada uma parte crítica na adoção de
abordagens ágeis dentro de grandes
organizações.
 Porém, agilistas abordam Arquitetura de
maneira diferente da forma como os
tradicionalistas o fazem.

4. Rumo a Arquitetura Ágil
 Arquitetura provê a fundação para construção de
sistemas.
 Um modelo arquitetural define a visão na qual a
arquitetura é baseada.
 O escopo da arquitetura pode ser diversa:
– De uma simples aplicação.
– De uma família de aplicações.
– Para uma organização.
– Para uma infraestrutura compartilhada por organizações
(ex. Internet).

5. Rumo a Arquitetura Ágil
 Práticas ágeis podem ser adotadas para
modelar, desenvolver e evoluir uma arquitetura.
 Manifesto ágil valoriza:
– Indivíduos e interação entre eles mais que processos e
ferramentas
– Software em funcionamento mais que documentação
abrangente
– Colaboração com o cliente mais que negociação de contratos
– Responder a mudanças mais que seguir um plano
http://agilemanifesto.org/

6. Rumo a Arquitetura Ágil
 Reflexão:
– Não há nada especial em arquitetura
– Tome cuidado com arquiteturas "Torre de marfim"
• Aceitação, risco, incompleta, faz mais que o
necessário
– Todo sistema tem uma arquitetura
• modele se agregar valor (comunicação)
– Arquitetura escala agilidade
• Escalar: tamanho de time, distribuição de time,
complexidade técnica.
• Abordagens arquiteturais possibilitam lidar com
problemas de escala.

7. Arquitetura ao longo do Ciclo de Vida
 Agile Model Driven Development (AMDD)

8. Arquitetura ao longo do Ciclo de Vida
 Iteração 0 (Concepção):
– Questões a serem resolvidas:
• escopo
• custo
• cronograma
• estratégias técnicas
 Visão inicial dos requisitos
 Visão inicial da arquitetura

9. Arquitetura ao longo do Ciclo de Vida
 Visão inicial da arquitetura
– Direção técnica para o time.
– Riscos potenciais (Provas de Conceito - PoC).
– Detalhes são identificados durante as iterações via
tarefa de Modelagem inicial da iteração.

10. Arquitetura ao longo do Ciclo de Vida
 Resultado:
– A arquitetura evolui por meio de incrementos.
– Início rápido, com a criação da fundação do projeto,
mas evolui no tempo.
 Prática: Modelagem em Pequenos Incrementos
http://www.agilemodeling.com/practices.htm#ModelInSmallIncrements

11. Arquitetura ao longo do Ciclo de Vida
 Abordagem alternativa:
– Definir a Arquitetura completamente antes da
implementação.
– BDUF - Big Design Up Front
 Resultados:
– Arquitetura (potencialmente "Torre de marfim") que atende a
todos os requisitos.
– Times de desenvolvimento que seguem o desenvolvimento
em frente, sem uma definição arquitetural estabelecida,
simplesmente porque não podem esperar o Arquiteto
terminar o trabalho.
http://www.agilemodeling.com/essays/bmuf.htm

12. Responsável pela Arquitetura
 Quem é responsável pela arquitetura?
– Para pequenos times a resposta pode parecer direta:
• "A arquitetura é responsabilidade de todos (time)“.
• "O time toma as decisões arquiteturais em conjunto“.
 Prática: Modele em Conjunto
– Não programe sozinho - pair-programming
http://www.agilemodeling.com/practices.htm#ModelWithOthers

13. Responsável pela Arquitetura
 Argumentos a favor para a estratégia "a arquitetura é de
todos":
– A arquitetura é muito importante para estar na mão de apenas
uma pessoa (por mais brilhante que seja). A arquitetura deve
ser um esforço do time.
– Aumenta o entendimento e aceitação da arquitetura pelo time.
– Aumenta a disposição dos desenvolvedores em aceitar
alterações na arquitetura quando ela se revelar insuficiente
(arquitetura é do grupo).
– Quando algo é desenvolvido apenas por uma pessoa, ele se
torna o Pai e responsável. Ninguém gosta de ouvir que seu
filho é feio - existe uma resistência natural a críticas e
mudanças nas soluções se houver necessidade.

14. Responsável pela Arquitetura
 Existem dois problemas básicos:
1 - Algumas vezes as pessoas não entram em
consenso.
2 - Essa estratégia não escala para times maiores.

15. O “Dono da Arquitetura”
 Sistemas minimamente complexos necessitam
de uma arquitetura.
– Precisam ser arquitetados.
 Em projetos ágeis, uma visão inicial da
arquitetura deve ser construída e
posteriormente evoluída.
http://www.agilemodeling.com/essays/initialArchitectureModeling.htm

16. O “Dono da Arquitetura”
 Muitos times ágeis chegam a conclusão que
precisam de alguém no papel de 'Dono da
arquitetura' (Architecture Owner - AO).
 Perfil do “Dono da Arquitetura”:
– Desenvolvedor mais experiente do time.
– Responsabilidade: facilitar a modelagem arquitetural e
o esforço de evolução.
– Comparação com o papel "Dono do Produto" (Product
Owner - PO)
• PO: responsável do time pelos requisitos do sistema
• AO: responsável do time pela arquitetura do sistema

17. O “Dono da Arquitetura”
Arquiteto
Dono da
arquitetura:
• Criador da arquitetura. • Trabalha coletivamente com o time
para desenvolver e evoluir a
• Desenvolve e apresenta (impõe) ao arquitetura;
time de desenvolvimento. • Possui autoridade para tomar decisões a
cerca da arquitetura, mas de maneira
colaborativa com o time.
• Desenvolvedor experiente na tecnologia
utilizada pela organização. • Desenvolvedor experiente na tecnologia
utilizada pela organização;
• Possui habilidade de explorar novas
• Possui habilidade de explorar novas
possibilidades e estratégias para a
possibilidades e estratégias para a
arquitetura.
arquitetura.
• Possui bom entendimento do domínio
do negócio.
• Possui habilidade necessária para
comunicar a arquitetura para os
desenvolvedores e outros
interessados no projeto
(stakeholders).

18. Arquitetura Ágil para Projetos de Grande Porte
 Desenvolvimento ágil para Projetos de grande
porte (> 15 ?):
– Grandes Times de Desenvolvimento Ágil dentro da
Organização.
– Times de Desenvolvimento Ágil Geograficamente
Distribuídos.

19. Arquitetura Ágil para Projetos de Grande Porte
 Arquitetura Ágil com um time de "Donos da Arquitetura“:
19

20. Arquitetura Ágil para Projetos de Grande Porte
 Estratégias para organizar um time ágil de grande
porte:
– Abordagem dirigida pela arquitetura.
– Abordagem dirigida por características (features).
– Abordagem Open Source (internal open-source).
– Combinação das abordagens anteriores.
20

21. Arquitetura Ágil para Projetos de Grande Porte
 Atividades de arquitetura em um Processo ágil para
Projetos de grande porte:
21

22. Arquitetura Ágil para Projetos de Grande Porte
 Criar a visão inicial da arquitetura
– O time de "Donos da arquitetura" é responsável pela
criação da visão inicial da arquitetura, apresentação
para revisão dos times e subsequente evolução.
– Membros do time ágil envolvidos:
• Dono do produto
• Stakeholders chave
• Arquitetos de solução
– Pode durar de alguns dias a várias semanas
dependendo da complexidade.
22

23. Arquitetura Ágil para Projetos de Grande Porte
 Trabalhar com o time de desenvolvimento
– Membros do time de "Donos da arquitetura"
trabalharão em conjunto com os times de
desenvolvedores
• Comunicando arquitetura
• realizando provas de conceito (PoC)
– No contexto corporativo, há a necessidade que os
"Donos da Arquitetura" (Arquitetos Corporativos)
serem membros efetivos do projeto (evitar
Arquitetura "Torre de marfim").
23

24. Arquitetura Ágil para Projetos de Grande Porte
 Comunicar a arquitetura aos Stakeholders
– Stakeholders da Arquitetura:
• Dono do Produto (Product Owner).
• Stakeholders chave do projeto.
• Times de desenvolvimento.
– Informações a serem compartilhadas:
• Visão arquitetural.
• As decisões arquiteturais tomadas.
• Situação atual da implementação da arquitetura.
24

25. Arquitetura Ágil para Projetos de Grande Porte
 Atualizar artefatos arquiteturais
– Com o progresso do projeto, mudanças
arquiteturais podem ocorrer.
– Os artefatos arquiteturais (modelos
arquiteturais, diagramas, etc.) devem ser
atualizados.
– Mudanças arquiteturais são mais frequente no
início do projeto
– Membros do time de desenvolvimento podem
precisar reportar alterações arquiteturais:
25

26. Arquitetura Ágil para Projetos de Grande Porte
 Atualizar artefatos arquiteturais
– Recomendações:
• Reunião rápida com o Dono da Arquitetura (ou o
time de "Donos da arquitetura");
• Duração de não mais que 1 hora.
• Reunião em pé, em frente a um quadro branco.
• Todos devem estar preparados para discutir a
alteração.
26

27. Baseie a Arquitetura nos Requisitos
 Arquitetura deve ser baseada nos requisitos.
– Crie uma visão inicial dos requisitos primeiro.
 Prática: Participação Ativa dos Stakeholders
• "Dono do Produto“
• Usuários
• Funcionários da Operação
• Gerentes da organização cliente
27

28. Baseie a Arquitetura nos Requisitos
 Prática: Aplique os Artefatos Corretos
 Prática: Crie vários modelos em paralelo
 Erros comuns de "Donos de arquitetura":
– Ignorar artefatos existentes e pertinentes
• Modelos de negócio da organização
• Diagramas da estrutura técnica da organização
• Restrições técnicas da organização
– máquinas, servidores, localização dos escritórios.
 Prática: Reuse os Artefatos Existentes
28

29. Modele a Arquitetura
 Modelos arquiteturais comunicam a Visão de como o
sistema será construído.
 Um Diagrama de Navegação simples pode comunicar
em uma conversa presencial.
 Porém, comunicar arquitetura para desenvolvedores
remotamente localizados exige modelos mais
elaborados.
 A atividade de modelagem envolve o time de "Donos da
Arquitetura".
 Leva de algumas horas a vários dias (não mais que 2
semanas).
29

30. Modele a Arquitetura
 Práticas para modelar de maneira ágil a arquitetura:
– Prática: Descarte Modelos Temporários
– Prática: Aplique os Artefatos Corretos
– Prática: Múltiplos Modelos
– Prática: Assuma a Simplicidade
– Prática: Crie Conteúdo Simples
– Prática: Retrate com Simplicidade os Modelos
– Prática: Use as Ferramentas mais Simples
30

31. Modele a Arquitetura
– Prática: Utilize Padrões de Projetos Arquiteturais
– Prática: Aplique Padrões com Gentileza
– Prática: Modele em Pequenos Incrementos
– Prática: Formalize Modelos de Contratos
– Prática: Considere Diversas Alternativas
• LEAN Software Development
– Prática: Viaje Leve
31

32. Prove a Arquitetura
 Bons modelos na teoria podem apresentar-se
problemáticos na prática.
 Prática: Prove a Arquitetura com Código
 Prática: Feedback Rápido
 Prática: Priorize os requisitos arquiteturais
32

33. Comunique a Arquitetura
 Audiências:
– Times de desenvolvimento
– Stakeholders do Projeto
 Práticas para comunicação com o Time de
desenvolvimento:
Prática: Exiba Modelos Publicamente ("Mural de modelos"
ou "Mural das Maravilhas")
Prática: Comunicação Aberta e Honesta
Prática: Propriedade coletiva
33

34. Comunique a Arquitetura
 Para comunicar com os Stakeholders, modele com
atenção especial:
– "Modele para comunicar e orientar de maneira que
outras pessoas (potencialmente não técnicas)
possam entender."
Prática: Modele com um propósito
Prática: Participação Ativa dos Stakeholders
 Esteja preparado para apresentar a arquitetura para os
Stakeholders
Prática: Apresentação ágil
34

35. Conclusão
 Fatores que aceleram a adoção de práticas ágeis (por
Scott Ambler, 2012):
– Pessoas designadas a apenas um time
– Times de desenvolvimento com acesso facilitado à Expertise do
Negócio (PO)
– Times são organizados para entrega ágil (pequenos
incrementos) e não tradicional (tudo de uma vez)
– A organização tem um grupo/comunidade de suporte ágil de
excelência
– A organização está explicitamente quebrando as barreiras
contra a agilidade
– Existe um financiador executivo para a agilidade
– Times ágeis são avaliados pela criação de valor
– A estratégia de governança da organização inclui um caminho
ágil
35

36. Conclusão
 Fator que desacelera a adoção de práticas
ágeis:
– Times ágeis avaliados por métricas tradicionais
 Alguns mitos sobre Ágil e Arquitetura.
– Agilistas não fazem arquitetura.
– É necessário fazer inicialmente uma modelagem
completa da arquitetura.
– Arquitetos são responsáveis pela arquitetura.
36

37. Obrigado!
 Dúvidas?
 Principal Referência:
 Agile Architecture: Strategies
for Scaling Agile Development
37