1. Agilidade de Ponta-a-Ponta
com Arquiteturas Evolucionárias
Breno Barros
brenobarros@gmail.com
@brenoobarros
www.brenobarros.net

2. Um pouco sobre mim…
• Breno Barros
– Líder do Escritório de Arquitetura e Métodos Ágeis
da Stefanini
– Membro Técnico da Revista MundoJ
– Natural de Belém/PA
– Morando a 6 anos em Belo Horizonte/MG
• Horas Vagas
– Video Game (XBox 360)
– Fotografia
– Empreendimentos próprios

3. Hoje, vamos falar sobre…
Arquitetura
Evolucionária
Design
Emergente
Códigos

4. Pausa. O que está acontecendo no mundo?

5. www. thoughtworks.com/radar
Janeiro 2011

6. www. thoughtworks.com/radar
Julho 2011

7. Agilidade de Ponta-a-Ponta

8. Adaptabilidade
Agilidade é Transparência
Charter
Estratégia Simplicidade
Release Unitariedade
Iteração
Diário
Contínua
Integração
Burndown Arquitetura
Velocidade TDD Build
burnup Refactoring Delivery
Colaboração
Testes

9. Arquitetura Evolucionária -
Origem Lean Thinking
1. Elimine o Despedício
2. Amplifique o aprendizado
3. Decida o mais tarde possível
4. Entregue o mais rápido possível
5. Dê autonomia à equipe
6. Construa com integridade
7. Visualize o todo

10. Arquitetura Planejada versus
Evolucionária

11. Arquitetura Planejada versus
Evolucionária
Para não dizer impossível…
… isso será muito difícil.
100 metros

12. E com software? Temos que ter
essa preocupação toda no início?

13. O desconhecido…

14. O desconhecido…
• Se manifesta de duas formas:
– Aquilo que sabemos que desconhecemos
– Aquilo que NÃO sabemos que desconhecemos
Se não sabemos tantas coisas, porque
definir tudo antes?

15. Olha o tamanho do problema que
podemos arrumar…
Implementação
Design
Arquitetura

16. “Time que está
ganhando
não se mexe”.
Aumento da Entropia

17. A essência da Arquitetura Evolucionária
consiste na…
Quanto mais tempo você adiar suas
decisões…
…mais contextualizadas elas serão.
… Tomada de Decisões no momento certo.

18. Checklist Arquitetural
V É necessário tomar essa decisão agora?
V Posso adiar essa decisão com segurança?
V Como posso tornar essa decisão reversível?

19. Arquitetura dentro de um processo
Ágil Architecture
Notebook
criação
Product Backlog incremento
Iteration Model Design
(horas)
retroalimentação
Architecture Notebook Design Model Storm
Inicial (minutos)
Inception
Test-Driven Development
(dias)
Sprint 1
Sprint 2
Sprint N

20. (Architecture Notebook)
• Objetivos
• Necessidades e Dependências
• Requisitos Significantes
• Decisões, Restrições e Justificativas
• Camadas
• Mecanismos Arquiteturais
• Visões

21. Arquitetura dentro de um processo
Ágil
Giovanni Gomes – Sprint Phases Author
Breno Barros – Architect & Design Increments Author
Iteration
Model
Design
Design
Model
Storm
Iteration
Model Design
Design Model
Storm
Iteration
Model Design
Design Model
Storm

22. E como fica o Arquiteto?

23. Arquiteto Ágil X Arquiteto Tradicional

24. Arquiteto Ágil X Arquiteto Tradicional
Arquitetos Tradicionais Arquitetos Ágeis
São seres “diferenciados” São humildes e buscam soluções
conjuntas
Estão sempre “muito ocupados” para São membros ativos do time de
colocar as mãos no desenvolvimento desenvolvimento
Gostam de prever o futuro para não terem Sabem que não podem prever o futuro,
problemas mas podem estar preparados
Investem muito tempo para criarem Sem desperdícios. Focam em relatar o que
modelos arquiteturais com “todas” as é útil e importante
informações

25. Alguns Conceitos

26. Padrões Idiomáticos

27. Apenas como curiosidade ;-)

28. Como descobrí-los?
Métrica
Métrica 1
2
Técnicas
Padrões Idiomáticos

29. Como descobrí-los?
• Algumas Métricas
– Complexidade Ciclomática
– Acoplamento Aferente
– % de Duplicação de Código
• Algumas Práticas
– Domain Specific Languages (DSL)
– Test-Driven Development (TDD)
– Monitorar a Dívida Técnica

30. Complexidade Ciclomática
public boolean realizarSaque(Conta conta, Double valor)
throws SaldoInsuficienteException{ // +1
if(conta.getSaldo() >= valor){ // +1
conta.setSaldo(conta.getSaldo() - valor);
} else{ // +1
throw new SaldoInsuficienteException(); // +1
}
return true; // +1
}
Complexidade = 11 -> Menor propabilidade de falhas (cerca de 28%)
Complexidade = 38 -> Propabilidade de falhas em cerca de 50%
Complexidade >= 74 -> Propabilidade de falhas em cerca de 90%

31. Acoplamento
• Acoplamento Aferente
– Representa a contagem de quantas classes
diferentes usam a classe corrente (aquela que está
sendo analisada).
• Acoplamento Eferente
– Constitui a contagem de quantas classes
diferentes são usadas pela classes corrente.

32. DSL – Domain Specific Language
• Escrever códigos que se pareçam menos com
o código de origem. Mas sim, com o problema
a ser resolvido.
• Facilidade de comunição e manutenção.
• Podemos fazer isso com:
– DSL’s externas: Com o uso de ANTLR, por exemplo
– DSL’s internas: Com Fluent Interfaces

33. DSL Interna com Fluent Interfaces
EmailMessage mail = new EmailMessage();
mail.setSender(”brenobarros@gmail.com");
mail.setDestination(”contato@agilevale.com.br");
mail.setSubject(”Palestra");
mail.setContent(”…Descrição da Palestra");
mail.send();
new EmailMessage()
.from(”brenobarros@gmail.com")
.to(”contato@agilevale.com.br")
.withSubject(”Palestra")
.withBody(”…Descrição da Palestra")
.send();

34. Test-Driven Development (TDD)
picture By klaus Laube

35. Quando começar?

36. AGORA!!!
Mas como?

37. O Raio X para o Time de Desenvolvimento

38. Sonar (www.sonarsource.org)

39. Acoplamento Aferente

40. Dependências Cíclicas

41. Dívida Técnica

42. A evolução do seu Design

43. Uma pequena demo…

44. Premissas
• Ser descentralizado
• Possuir um time auto-organizado
• Ser transparente
• Não lute contra mudanças
• Foco em simplicidade
• Foco em flexibilidade
• Promover a inspeção e adaptação
• Promover a presença da língua de
negócio

45. Outras Referências
Neal Ford: http://www.ibm.com/developerworks/java/library/j-eaed1/index.html

46. Q&A
picture by -bast-

47. Muito obrigado!
[]’s