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.
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.
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