Arquitetura de Software em Equipes Ágeis

  • 1,799 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,799
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
49
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 Escala5
  • 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. 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 200311
  • 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 escolhidas14
  • 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ção16
  • 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 Graves23
  • 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 Interations26
  • 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 Arquitetura37
  • 38. Funções de Arquitetura Funções tipicamente desempenhadas por um arquiteto em um projeto38
  • 39. Preocupações do Arquiteto Agile Funções Arquiteturais Pontos de Interação Preocupação do Arquiteto Framework extensível39
  • 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