Arquitetura de Software em Equipes Ágeis

2.883 visualizações

Publicada em

Arquitetura de Software em Equipes Ágeis - Formas de Trabalho em Equipes de Grande Escala

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.883
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
82
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Arquitetura de Software em Equipes Ágeis

  1. 1. Arquitetura de Software em Equipes Ágeis Formas de Trabalho em Projetos de Grande Escala Prof. MSc. João Paulo Santos
  2. 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. 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. 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. 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 Escala5
  6. 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 Software6
  7. 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. 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. 9. O Arquiteto Warnerbros – The Matrix Reloaded (2003)Quais semelhanças e diferenças com um Arquiteto de Softw 9
  10. 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. 11. O Arquiteto de Software Extraído do RUP – Rational Unified Process 200311
  12. 12. Visões 4 + 1 É olhar para o software sob diferentes pontos de vista Adaptado de Kruchten 1995 12
  13. 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. 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 escolhidas14
  15. 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. 16. O Conflito entre Arquitetura de Software e Agile  XP e Scrum  Entendo a origem do conflito  Comunicação  Documentação16
  17. 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. 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. 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. 20
  21. 21. Documentação Para cada artefato ou documento produzido a equipe e o arquiteto devem responder: 21
  22. 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. 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 Graves23
  24. 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. 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. 26. Formas de Trabalhos em Grandes Projetos  Case: Agile em Projetos Grandes  Scrum of Scrum – SoS  Agile Architecture Interations26
  27. 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. 28. Afinal de contas... O que é preciso comunicar!?28
  29. 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. 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. 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. 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. 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. 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. 35. SoS - Escalabilidade As reuniões de Scrum of Scrums podem ser escaláveis indefinidamente por múltiplas camadas 35
  36. 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. 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 Arquitetura37
  38. 38. Funções de Arquitetura Funções tipicamente desempenhadas por um arquiteto em um projeto38
  39. 39. Preocupações do Arquiteto Agile Funções Arquiteturais Pontos de Interação Preocupação do Arquiteto Framework extensível39
  40. 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. 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. 42

×