1) O documento apresenta Rodrigo Branas, palestrante e instrutor de modelagem ágil, Clean Code, Selenium e Maven. 2) A modelagem ágil é baseada em valores e princípios como simplicidade, feedback e YAGNI, e deve ser usada em conjunto com métodos como XP e Scrum. 3) Ferramentas simples como protótipos em papel e diagramas UML coloridos são recomendadas para modelagem ágil, que deve ter como foco produzir software funcionando de forma incremental.

1. Rodrigo Branas - @rodrigobranas – http://www.agilecode.com.br
Modelagem Ágil

2. http://www.slideshare.net/rodrigobranas

3. @rodrigobranas
rodrigo.branas@gmail.com
http://www.agilecode.com.br
Formação Acadêmica
Ciências da Computação – UFSC
Gerenciamento de Projetos - FGV
Certificações
SCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM

4. Rodrigo Branas – rodrigo.branas@gmail.com
10 anos de experiência na plataforma Java
1000 horas em sala de aula
Mais de 50 palestras em eventos
Líder da área de desenvolvimento na Gennera
Autor da revista Java Magazine
Palestrante
Instrutor da Academia Java e Agile da Globalcode
Criador dos treinamentos de Clean Code, Selenium e
Maven da Agile Code
Trabalhou com as empresas:
EDS, HP, GM, Citibank, OnCast, Globalcode, V.Office, Dígitr
o, Softplan, Unimed, Suntech, Vale do Rio

5. Modelagem Ágil é uma atitude

6. Apoiada em valores e princípios

7. Com foco no que é suficiente

8. Não é um processo prescritivo

9. Não é uma metodologia

10. Deve ser utilizado em conjunto com
um outro método (XP, Scrum, FDD)

11. Estimula o trabalho em equipe

12. Funciona na prática, não na teoria
acadêmica

13. Valores da Modelagem Ágil

14. O que é um valor?

15. “Uma concepção do desejável
explícita e implícita, característica
de um indivíduo ou grupo, e que
influencia a seleção dos
modos, meios e fins da ação“
(Clide Kluckhon, antropólogo)

16. “Um valor é uma crença em que o
homem se baseia para atuar por
referência“
(Alpport, psicólogo)

17. Comunicação

19. Simplicidade

21. Over-Architecture pensando em um
possível futuro

22. Aplicar padrões de projeto
complexos muito cedo

23. Generalidade especulativa

24. Condensar hierarquia quando
houver classes abstratas
desnecessárias

25. Internalizar classe quando houver
uma delegação desnecessária

26. Deletar métodos e variáveis que
não forem utilizadas

27. YAGNI (You Ain’t Gonna Need It)
- Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.
- Novas funcionalidades precisam ser
debugadas, documentadas e suportadas.
- Seu código ocupa espaço e aumenta a
complexidade do software como um todo.
- Novas funcionalidades geram novas
necessidades e o efeito snowball.

28. "Always implement things when you
actually need them, never when
you just foresee that you need
them.“
(Ron Jeffries)

29. YAGNI (You Ain’t Gonna Need It)
- Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.
- Novas funcionalidades precisam ser
debugadas, documentadas e suportadas.
- Seu código ocupa espaço e aumenta a
complexidade do software como um todo.
- Novas funcionalidades geram novas
necessidades e o efeito snowball.

30. YAGNI (You Ain’t Gonna Need It)
- Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.
- Novas funcionalidades precisam ser
debugadas, documentadas e suportadas.
- Seu código ocupa espaço e aumenta a
complexidade do software como um todo.
- Novas funcionalidades geram novas
necessidades e o efeito snowball.

31. YAGNI (You Ain’t Gonna Need It)
- Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.
- Novas funcionalidades precisam ser
debugadas, documentadas e suportadas.
- Seu código ocupa espaço e aumenta a
complexidade do software como um todo.
- Novas funcionalidades geram novas
necessidades e o efeito snowball.

32. YAGNI (You Ain’t Gonna Need It)
- Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.
- Novas funcionalidades precisam ser
debugadas, documentadas e suportadas.
- Seu código ocupa espaço e aumenta a
complexidade do software como um todo.
- Novas funcionalidades geram novas
necessidades e o efeito snowball.

33. Feedback

34. Desenvolver o modelo em grupo

35. Revisar o modelo com a audiência

36. Implementar o modelo

37. Derrubando os servidores

38. Coragem

39. Humildade

40. O que são modelos ágeis?

41. Cumprem seu propósito

42. São compreensíveis

43. Quem é a sua audiência?

44. São suficientemente
precisos, consistentes e detalhados

45. Mais simples possível

46. Realmente é necessário utilizar uma
ferramenta mais complexa?

47. Que tipo de ferramentas vocês
utilizam para modelar?

48. Código-fonte é um modelo? É um
modelo ágil?

49. Ferramentas simples
- Priorizam a comunicação
- São baratas, flexíveis e inclusivas
- Utilização rápida e portável
- Podem ser combinadas com
outras mais complexas
- Promovem o desenvolvimento
iterativo e incremental

50. Ferramentas simples
- Priorizam a comunicação
- São baratas, flexíveis e inclusivas
- Utilização rápida e portável
- Podem ser combinadas com
outras mais complexas
- Promovem o desenvolvimento
iterativo e incremental

51. Ferramentas simples
- Priorizam a comunicação
- São baratas, flexíveis e inclusivas
- Utilização rápida e portável
- Podem ser combinadas com
outras mais complexas
- Promovem o desenvolvimento
iterativo e incremental

52. Ferramentas simples
- Priorizam a comunicação
- São baratas, flexíveis e inclusivas
- Utilização rápida e portável
- Podem ser combinadas com
outras mais complexas
- Promovem o desenvolvimento
iterativo e incremental

53. Ferramentas simples
- Priorizam a comunicação
- São baratas, flexíveis e inclusivas
- Utilização rápida e portável
- Podem ser combinadas com
outras mais complexas
- Promovem o desenvolvimento
iterativo e incremental

54. Ferramentas simples
- Priorizam a comunicação
- São baratas, flexíveis e inclusivas
- Utilização rápida e portável
- Podem ser combinadas com
outras mais complexas
- Promovem o desenvolvimento
iterativo e incremental

55. Agile Draw

56. Prototipação em papel

57. Image Box

58. UML em cores

59. Conceitos errados sobre modelagem

60. Modelo == Documentação

61. Sempre conseguimos modelar tudo
no início

62. Modelar é obrigatoriamente um
processo pesado

63. Você deve utilizar uma ferramenta
CASE para modelar

64. Modelar é uma grande perda de
tempo

65. Todos os desenvolvedores sabem
modelar

66. Princípios da Modelagem Ágil

67. Assuma a simplicidade

68. Abrace as mudanças

69. Enabling the next effort is your
secondary goal

70. Incremental change

71. Maximaze stakeholder ROI

72. Modele com um propósito

73. Utilize múltiplos modelos

74. Obtenha feedback rapidamente

75. Seu objetivo principal é software
funcionando

76. Travel light

77. Conteúdo é mais importante do que
representação

78. Se comunique de maneira aberta e
honesta

79. Práticas da Modelagem Ágil

80. Participação ativa dos stakeholders

81. O modelo deve ser coletivo

82. Crie vários modelos em paralelo

83. Exponha os modelos publicamente

84. Itere para outro artefato

85. Modele em conjunto

86. Comprove com código

87. Use a ferramenta mais simples

88. Jogue fora os modelos temporários

89. Update Only When It Hurts

90. Just barely good enough artifacts

91. Model storming