Post on 04-Jul-2015
description
Arquitetura de Software em Equipes ÁgeisFormas de Trabalho em Projetos de Grande Escala
Prof. MSc. João Paulo Santos
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
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
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
• 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
Sumário
5
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
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
A Analogia...
Arquiteto de Software Arquiteto Civil
Decisões são tomadas antes e durante a construção
Planejamento iterativo
O Arquiteto de Software deve acompanhar o andamento ao longo de todo processo de construção do software
O resultado (software) é maleável
Acolhe mudanças
Decisões são tomadas antes do início da construção
Planejamento completo
Arquiteto Civil entrega seu trabalho ao engenheiro que se encarrega das demais etapas
cálculo estrutural
O resultado (edifício) é sólido e estático
Não acolhe mudanças8
O Arquiteto
Warnerbros – The Matrix Reloaded (2003)
Quais semelhanças e diferenças com um Arquiteto de Software?
9
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
O Arquiteto de Software
Extraído do RUP – Rational Unified Process 2003
11
Visões 4 + 1
É olhar para o software sob diferentes pontos de
vista
Adaptado de Kruchten 1995
12
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 projeto13
“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
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
O Conflito entre Arquitetura de Software e Agile
XP e Scrum
Entendo a origem do conflito
Comunicação
Documentação
16
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
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
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
Documentação
Para cada artefato ou documento produzido a
equipe e o arquiteto devem responder:
21
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
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
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
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
Formas de Trabalhos em Grandes Projetos
Case: Agile em Projetos Grandes
Scrum of Scrum – SoS
Agile Architecture Interations
26
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
Afinal de
contas...
O que é preciso
comunicar!?
28
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
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
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 odesenvolvimento do documento de arquitetura foipequeno comparado ao valor agregado obtido emviabilizar a comunicação entre as equipes e ocorreto entendimento do sistema
31
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çãoMeta Equipe
Equipes
32
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
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
SoS - Escalabilidade
As reuniões de Scrum of Scrums podem ser
escaláveis indefinidamente por múltiplas camadas
35
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
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
Funções de
Arquitetura
Funções tipicamente
desempenhadas por um
arquiteto em um projeto
38
Preocupações do
Arquiteto Agile
Funções Arquiteturais
Pontos de Interação
Preocupação do
Arquiteto
Framework extensível
39
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
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 PracticeGuide 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 Planning41
42