1. Arquitetura de Software em Equipes Ágeis
Formas de Trabalho em Projetos de Grande Escala
Prof. MSc. João Paulo Santos

2. Palestrante
 Titulação
 MSc Sistemas de Informação (UNIRIO)
 Bacharel Informática e TI (UERJ)
 Experiência
 Cargo
 Assessor Sênior do Banco do Brasil S/A cedido a BB DTVM
 Papel
 É Arquiteto de Sistemas do Banco do Brasil S/A, com atuação focada na
definição dos componentes de software e na interação entre as soluções
da BB Gestão de Recursos DTVM S/A
 Possui mais de 10 anos de experiência em TI, atuando nas áreas
de especificação e desenvolvimento de sistemas orientado a
objetos para o mercado financeiro
2

3. Atuação no INFNET
 Coordenador Executivo de Pós-Graduação
 MIT em Arquitetura de Software
 Professor de Graduação e Pós-Graduação
 MIT em Engenharia de Software com Desenvolvimento Java
 Rio de Janeiro e Porto Alegre (Parceria Decision – FGV-RS)
 MIT em Engenharia de Software com Desenvolvimento .NET
 Graduação em Análise e Desenvolvimento de Sistemas
 Graduação em Engenharia de Computação
3

4. Objetivos
 Apresentar formas efetivas de aplicação da
Arquitetura de Software em Processos baseados
nas Metodologias Ágeis
 Apresentar possíveis vantagens da Arquitetura Ágil
em Projetos de Grande Escala
4

5. Sumário
• A Força da Analogia com a Arquitetura Civil
• Conflitos entre a Arquitetura de Software e a Cultura Agile
• O que faz um Arquiteto de Software Agile
• Construindo a Arquitetura de Software em equipes Agile
• Trabalhando em Projetos de Larga Escala
5

6. A Força da Analogia com a Arquitetura Civil
 Semelhanças e
Diferenças
 O Arquiteto de Software
 Entendendo corretamente
a metáfora “Arquiteto”
 Arquitetura de Software
6

7. Arquitetura Civil
 Todo edifício possui uma arquitetura
 Arquitetura é um conceito separado da estrutura física
 Porém, intrinsecamente conectados
 Arquitetura inicialmente definida pode ser comparada
com a estrutura física obtida ao término do processo de
construção
7

8. A Analogia...
Arquiteto de Software Arquiteto Civil
 Decisões são tomadas  Decisões são tomadas
antes e durante a antes do início da
construção construção
 Planejamento iterativo  Planejamento completo
 O Arquiteto de Software  Arquiteto Civil entrega seu
deve acompanhar o trabalho ao engenheiro que
andamento ao longo de todo se encarrega das demais
processo de construção do etapas
software  cálculo estrutural
 O resultado (software) é  O resultado (edifício) é
maleável sólido e estático
 8 Acolhe mudanças  Não acolhe mudanças

9. O Arquiteto
Warnerbros – The Matrix Reloaded (2003)
Quais semelhanças e diferenças com um Arquiteto de Softw
9

10. Limitações da Analogia...
 Arquiteto “Torre de Marfin”
 Distanciamento da Equipe
 Dúvidas se a implementação reflete as decisões de Design
 Baixa comunicação
 Resposta à mudanças é lenta
 Assume a responsabilidade por todo sistema
 Concentra todas as decisões de Design
 Delega à equipe apenas a implementação
Arquiteto de Software é membro da equipe!
10

11. O Arquiteto de Software
Extraído do RUP – Rational Unified Process 2003
11

12. Visões 4 + 1
 É olhar para o software sob diferentes pontos de
vista
Adaptado de Kruchten 1995
12

13. Arquiteto de Software
 Análise do domínio do problema
 Gerenciamento de Risco
 Gerenciamento de Requisitos
 Projeto de Interface - Usabilidade
 Determinação das abordagens de implementação
 Definição de uma Arquitetura que atenda aos
 Requisitos do sistema
 Objetivos da organização
 Orçamento e cronograma do projeto
 Supervisão do mapeamento da arquitetura para o projeto e
implementação
 Comunicação da arquitetura a todos os intervenientes
 Manutenção da arquitetura de software em todo ciclo de vida de
projeto
13

14. “software architecture” is merely one imperfect
analogy from a large list of metaphors that could be
chosen
Craig Larman
“Arquitetura de software” é apenas uma analogia imperfeita
com uma grande lista de metáforas que podem ser
escolhidas
14

15. Arquitetura de Software
 Arquitetura esta presente em todos os tipos de software
 Intencional
 Há a preocupação em sua elaboração e manutenção
 Acidental
 Existe pura e simplesmente pelas decisões de implementação

 Arquitetura de Software não é estática!
 É algo vivo, que se degrada ou melhora dia a dia a cada nova linha de código
 Dinâmica viva e evolutiva do desenvolvimento de software
 Busca estabelecer uma plataforma tecnológica e tratar os atributos de
qualidade, atendendo às partes interessadas
 A Arquitetura deve ser perene ao ciclo de desenvolvimento do software
“em vez de construção, a programação é mais parecida com jardinagem.”
Andy Hunt e Dave Thomas
15

16. O Conflito entre Arquitetura de Software e Agile
 XP e Scrum
 Entendo a origem do
conflito
 Comunicação
 Documentação
16

17. XP e Scrum
 Características:
 Entregas rápidas e frequentes de software
 Rápida resposta às mudanças de requisitos
 Iniciar o desenvolvimento antes do total
entendimento
 Equipes auto-avaliam frequentemente o
andamento do processo com intuito de torná-lo
mais eficiente
17

18. O Conflito
 Equipes Ágeis tendem a criar e manter pouca
documentação (viewpoints) em comparação à
equipes com processos mais tradicionais
 Projetos grandes demandam um elevado número de
desenvolvedores e um aumento da necessidade por
treinamento e comunicação da arquitetura
18

19. O Conflito
 Arquitetos de Software querem gastar mais tempo
projetando o sistema, enquanto Programadores
querem iniciar a codificação
 Equipes Ágeis devem refletir sobre a documentação
produzida para comunicar o entendimento comum
da arquitetura visando manter o desenvolvimento
efetivo
 Utilizar o código-fonte para esta comunicação, torna o
processo ineficiente
19

20. 20

21. Documentação
 Para cada artefato ou documento produzido a
equipe e o arquiteto devem responder:
21

22. Solucionando o Conflito
 Estabelecer a Arquitetura de Software
 Representada por diferentes visões e diagramas –
viewpoints
 O Arquiteto de Software e a Equipe de
Desenvolvimento devem selecionar os artefatos
importantes para a adequada informação aos
intervenientes do sistema
22

23. A agilidade necessita frequentemente de uma espinha
dorsal para manter sua direção – algo que dê
sustentação, evitando perda de direção e foco. Trata-
se de conseguir o equilíbrio adequado entre o “osso”
da arquitetura e o “músculo” da agilidade
Tom Graves
23

24. O Arquiteto Agile
 Objetivos de um Arquiteto Agile:
 Entregar soluções
 Maximizar o valor aos intervenientes
 Buscar soluções que atendam a todos os intervenientes
 Viabilizar o próximo esforço (entregável)
 Gerir mudanças e complexidade
 Criação da arquitetura bottom-up
24

25. O Arquiteto Agile
 As regras de ouro:
 Valorização das Pessoas
 Comunicação
 Menos é Mais
 Acolha Mudanças: Planejar e Gerenciar
 Escolha a Solução Adequada para a
Empresa
 Entregue Qualidade
 Modelar e Documentar de Forma Ágil
25

26. Formas de Trabalhos em Grandes Projetos
 Case: Agile em Projetos
Grandes
 Scrum of Scrum – SoS
 Agile Architecture Interations
26

27. Agile em Projetos Grandes
 Diversas equipes ágeis trabalhando no mesmo
projeto de software
 O sucesso da Arquitetura está na comunicação!
Caso contrário:
 Equipes tendem a “reinventar a
roda”
 Usa diferentes padrões de
desenvolvimento
 Limitam-se a objetivos específicos
e esquecem as metas globais
27

28. Afinal de
contas...
O que é preciso
comunicar!?
28

29. Caso de Sucesso – Arquitetura e Processo Ágil
 Cenário:
 Projeto de grande escala
 Processo de software baseado no Scrum para lidar
com freqüentes mudanças de requisitos
 Desenvolver um subsistema era uma “novela” , pois
até os especialistas do domínio tinham dificuldades
em escrever bons requisitos
 No auge das atividades
 40 desenvolvedores no subsistema
 250 no projeto
Case extraído e adaptado do livro:
Large-Scale Software Architect – A Pactical Guide Using UML.
Jeff Garland, Richard Anthony
Pg.46
29

30. Caso de Sucesso – Arquitetura e Processo Ágil
 Após alguns Sprints:
 As equipes sentiram a necessidade de uma pessoa ou
equipe para a coordenação de assuntos cross-team
 Existência de muitos desenvolvedores experientes
 Autoridade restrita à sua equipe
 Dificuldade em estabelecer acordos entre as equipes de
desenvolvedores
 Aceitação de padronização (Ex: Code Conventions)
30

31. Caso de Sucesso – Arquitetura e Processo Ágil
 Solução:
 Nomeação de um Arquiteto ou Equipe de Arquitetos
 Mediar e conduzir questões para resolução do problema
 Pouco impacto no processo das equipes ágeis
 Questões arquiteturais foram incluídas nas reuniões diárias
 Reutilização de componentes comuns de infra-estrutura
 Redução da carga de trabalho das equipes
 O esforço “adicional” nos meetings para o
desenvolvimento do documento de arquitetura foi
pequeno comparado ao valor agregado obtido em
viabilizar a comunicação entre as equipes e o
correto entendimento do sistema
31

32. SoS – Scrum of Scrums
 Técnica para escalar o uso do Scrum em grandes
projetos
 Reunião para agrupar os times e discutir seus
trabalhos,
 foco em áreas de sobreposição e integração
Meta Equipe
Equipes
32

33. SoS - Meta Equipe
 Deve ser formada por profissionais experientes
 Engenheiros, Analistas ou desenvolvedores Seniores
 Frequência das reuniões definida pela equipe
 2, 3 vezes por semana, ou mesmo, diariamente
 Os participantes devem responder as seguintes
perguntas?
 O que sua equipe fez desde a última reunião?
 O que sua equipe fará até a próxima reunião?
 Existe algo atrapalhando o caminho de sua equipe?
 Você fará algo que atrapalhe o caminho de outra equipe?
33

34. Meta Equipe
 Objetivos:
 Definir padrões
 APIs, SLAs, logging de erros, estrutura de repositório de
código, processo de build automatizado, scripts de deployment
automatizados utilizados por todos os times, etc...
 Testes diários de integração (automatizados)
 Cruzamento de código de subprodutos
 Revisões de arquitetura
 Solucionar problemas apontados pelas equipes
34

35. SoS - Escalabilidade
 As reuniões de Scrum of Scrums podem ser
escaláveis indefinidamente por múltiplas camadas
35

36. Iterações em Arquitetura Agile
 Arquitetura ágil de sucesso requer um arquiteto que:
 Entenda de desenvolvimento ágil
 Saiba interagir com a equipe pontualmente
 Influencie os usando habilidades críticas facilmente
adaptado a partir da experiência em arquitetura com
outras abordagens
 Aplique funções arquiteturais independentes da
metodologia do projeto
James Madison. Agile Architecture Interactions, IEEE Software, vol. 27, no. 2, pp. 41-48,
Mar./Apr.
36

37. Pontos de
Interação da
Arquitetura
Framework hibrido para
Arquitetura Agile
XP e Scrum
Verde: Pontos de
Interação
Amarelo: Habilidades
críticas
Roxo: Funções de
Arquitetura
37

38. Funções de
Arquitetura
Funções tipicamente
desempenhadas por um
arquiteto em um projeto
38

39. Preocupações do
Arquiteto Agile
Funções Arquiteturais
Pontos de Interação
Preocupação do
Arquiteto
Framework extensível
39

40. Considerações Finais
 Agilidade e arquitetura não estão em desacordo
 O Arquiteto deve buscar seu trabalho em estreita colaboração com
equipes técnicas e de negócios
 visando a melhoria continua e a boa arquitetura
 Desafios de obter resultados de longo prazo usando uma série de
eventos de curta duração
 O Arquiteto deve ter a habilidade para adaptar-se ao
desenvolvimento Agile e manter-se focado no core da Arquitetura
 Maximizar o valor agregado para empresa e satisfazer as
necessidades do negócio de hoje
40

41. Referências
 Agilists and Architects: Allies not Adversaries
 http://blog.locaweb.com.br/eventos/qcon-agilists-and-architects-allies-not-
adversaries/
 Agile Architecture Interactions, IEEE Software, vol. 27, no. 2, pp. 41-48,
Mar./Apr.
 Who Needs An Architect
 http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
 The Role of the Agile Architect
 http://www.agilearchitect.org/agile/role.htm
 Agile Manifesto
 http://www.agilemanifesto.org
 Jeff Garland & Richard Anthony. Large Scale Software Architect: A Practice
Guide Using UML, John Wiley and Sons, 2003.
 Mark Levison. Scum of Scrums – Problemas e Valores.
 http://www.infoq.com/br/news/2008/12/scrum-of-scrums
 Mike Cohn. Agile Estimating and Planning
41

42. 42