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