Rodrigo Branas tem experiência em desenvolvimento Java, certificações em programação e gerenciamento de projetos. Ele ministra treinamentos em diversas tecnologias e métodos ágeis como Extreme Programming.

1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br
Extreme Programming

3. @rodrigobranas
rodrigo.branas@gmail.com
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

6. 1995 – Projeto C3
Chrysler Comprehensive Compensation

7. Payroll System

8. Migrar a base de código legada
escrita em COBOL e integrar com
outros sistemas

9. Com a complexidade, a situação
ficou caótica e o software instável

10. Kent Beck
(Criador do Extreme
Programming)
É chamado para ajudar
a salvar o projeto!

11. Parando de cavar...

12. Praticamente todo o código
foi jogado fora!

13. Reescrever tudo em menos
tempo e com metade
da equipe trabalhando de forma
diferente!

14. O conjunto de práticas
propostas por Kent para
escrever o código deram origem
ao Extreme Programming

15. Entre as principais práticas
utilizadas estão:
Pair Programming

16. Entre as principais práticas
utilizadas estão:
Pair Programming
TDD

17. Entre as principais práticas
utilizadas estão:
Pair Programming
TDD
Refactoring

18. Entre as principais práticas
utilizadas estão:
Pair Programming
TDD
Refactoring
Build automatizado

19. Entre as principais práticas
utilizadas estão:
Pair Programming
TDD
Refactoring
Build automatizado
Integração contínua

20. Em 1997 o Projeto C3 foi para
produção! Mais de 10.000
funcionários foram pagos por
meio do novo software!

21. Extreme Programming
é uma mudança social!

22. Abandonar velhos hábitos

23. Foco em técnicas de
programação

24. Na comunicação aberta e direta!

25. Muito trabalho em equipe!

26. Buscando a excelência em
desenvolvimento de software

27. Como fica o Extreme Programming
no contexto da agilidade em geral?

30. Valores do Extreme Programming

31. Comunicação

33. Face-a-face

34. Simplicidade

35. YAGNI
(You Ain’t Gonna Need It)

36. YAGNI (You Ain’t Gonna Need It)
Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.

37. Tempo gasto adicionando novas
funcionalidades são apenas a
ponta do iceberg!

38. YAGNI (You Ain’t Gonna Need It)
Tempo gasto adicionando, testando e
corrigindo novas funcionalidades.
Novas funcionalidades precisam ser
debugadas, documentadas e suportadas.

39. 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.

40. 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 Snowball Effect.

41. Cuidado com o Snowball Effect

42. O caso da Agenda
Telefônica

43. Feedback

44. Fail Fast

45. Perdendo as chaves...

46. Coragem

47. Assumir responsabilidades

48. Trabalhar de formas diferentes

49. Se adaptar as mudanças

50. Reconhecer as falhas

51. “Não importa o quão longe você
andou na direção errada, volte
imediatamente.”
(Provérbio turco)

52. Primary Practices

53. Sit Together

54. Desenvolver software envolve o
aprendizado

55. Compartilhar o conhecimento

56. Barreiras na comunicação

57. Times distribuidos podem ser ágeis?

58. Whole Team

59. Que tipo de profissionais são
necessários?

60. Problemas na comunicação entre
diferentes setores

61. Teoria das restrições

62. Equipes multi-disciplinares!

63. Diferença entre equipes e pessoas
multi-disciplinares

64. Informative Workspace

65. Irradiadores de informação

66. Ferramentas Eletrônicas x Físicas

67. Energized Work

68. Desenvolvimento envolve estimular
a criatividade, idéias e o raciocínio

69. Condições ideais de trabalho

70. Produtividade x Carga Horária

71. Horário fixo para entrar e sair

72. Baixa motivação com o trabalho

73. Ficou doente?

74. Pair Programming

75. Piloto + Copiloto

76. Será que a velocidade do projeto
será reduzida?

77. Era uma vez um cliente: “Sem pair
programming por favor!”

78. Onde está o gargalo no
desenvolvimento de software?

79. O caso dos digitadores

80. Vantagens do Pair Programming:
Código de melhor qualidade

81. Vantagens do Pair Programming:
Código de melhor qualidade
Aumento do foco

82. Vantagens do Pair Programming:
Código de melhor qualidade
Aumento do foco
Disseminação de conhecimento
na equipe

83. Vantagens do Pair Programming:
Código de melhor qualidade
Aumento do foco
Disseminação de conhecimento
na equipe
Melhora na produtividade

84. É obrigatório trabalhar em par
durante todo o dia?

85. Técnica do Pomodoro!

86. Escolha a tarefa

87. Acerte o seu Pomodoro para 25
minutos

88. Trabalhe até o fim do Pomodoro

89. Faça um intervalo de 5 minutos

90. A cada 4 Pomodoros faça um
intervalo longo de 15 a 20 minutos

91. A importância da rotação dos
pares

92. Dica: Não se apaixone pelo seu par!

93. Slack

94. “Aliviar a tensão”
(Babylon)

95. Problemas com o overcommitment

96. Frustração por não atingir a meta!

97. Atolado?

98. É necessário finalizar todas as user
stories para atingir uma meta?

99. Decompor as user stories deixando
os detalhes menos importantes
para o final

100. Incluir tarefas técnicas importantes
mas que possam ser canceladas

101. Reservar um tempo livre caso seja
necessário utilizá-lo

102. Ten-Minute Build

103. Ainda existe build manual?

104. Tarefas mecânicas e repetitivas
são desperdício puro!

105. Desperdício Puro
Desperdício Incidental
Valor

106. Gestão de dependências

107. Ao baixar o código do repositório
pela primeira vez, funciona?

108. Por que realizar o build em no
máximo “10 minutos”?

109. Se demorar demais o build
começará a ser evitado

110. Perda da oportunidade de feedback

111. Exercício: Quanto tempo dura o
build em seu ambiente atual? O que
pode ser feito para melhorá-lo?

112. Estratégias para reduzir a demora
no processo de build:
Modularizar o build

113. Estratégias para reduzir a demora
no processo de build:
Modularizar o build
Distribuir ou delegar a execução
do build (CI)

114. Estratégias para reduzir a demora
no processo de build:
Modularizar o build
Distribuir ou delegar a execução
do build (CI)
Otimizar os testes

115. Estratégias para reduzir a demora
no processo de build:
Modularizar o build
Distribuir ou delegar a execução
do build (CI)
Otimizar os testes
Utilizar a base se possível em
memória

116. Continuous Integration

117. Feedback integrado e
instantâneo!

120. Desenvolvendo uma cultura
“Stop-the-line”

121. Por que eu não realizo esse
processo apenas na minha própria
maquina?

122. Evitando a síndrome do...

123. Última versão
sempre pronta
para o cliente!

124. Ferramentas para integração
contínua

125. Test-First Programming

127. Qual é a vantagem de escrever o
teste antes?

128. Escopo limitado evita escrever
código além do necessário

129. Acoplamento e coesão

130. Confiança no código

131. Ganhando ritmo
Teste, Código e Refactoring

132. Métricas

133. Como é a cobertura de testes dos
softwares em que vocês trabalham
atualmente?

134. Incremental Design

135. Investir apenas o necessário para
implementar as funcionalidades

136. Como evitar que o projeto da
aplicação vire uma bagunça?

137. Refactoring

138. As práticas primárias são
responsáveis pela base da
comunicação e feedback. Os times
podem usá-las para aumentar a
confiança e a competência para
construir relacionamentos dentro e
fora do time.

139. Corollary Practices

140. O que aconteceria se você
começasse a realizar o Daily
Deployment tendo uma taxa de
defeitos ainda alta?
As práticas a seguir devem ser
utilizadas quando a confiança
estiver consolidada.

141. Real customer involvement

142. Metáfora do Alfaiate

143. O que são clientes reais?

144. Agile Anti-Pattern: Customer Proxy

145. Fábrica de salsichas

146. Beta testers

147. Incremental Deployment

148. Antecipar o ROI

149. Guiar o desenvolvimento do
produto com base em feedbacks

150. Mitigar riscos na hora de virar a
chave

151. Definindo uma versão mínima para
colocar em produção

152. Cuidado com o resultado caso o
produto esteja muito crú

153. Sistemas legados

154. Vai doer!

155. Team Continuity

156. “Value in software is created not
only just by people know and do
but also by their relationships and
what they accomplish together.”
(Kent Beck)

157. Problemas nas empresas grandes

158. Move people around!

159. Shrinking Teams

160. Qual é o tamanho ideal de uma
equipe?

161. Manter a capacidade produtiva
reduzindo o tamanho da equipe

162. Root-Cause Analysis

163. Eliminar a causa raiz do defeito

164. Escreva um teste que evidencie o
defeito

165. Corrija o defeito

166. Descubra porque o defeito foi
inserido chegando a sua causa raiz

167. Trabalhe na causa raiz previnindo a
ocorrência de defeito semelhantes

168. Shared Code

170. De quem é a responsabilidade pelo
código produzido?

171. Ao encontrar um defeito, corrija!

172. Quais são os problemas
relacionados a falta de compartilhar
a responsabilidade sobre o código
fonte? (10 min.)

173. Code and Tests

174. Os únicos artefatos criados são
código e testes

175. Toda documentação precisa ser
gerada

176. Single Code Base

177. Por que utilizar um SCM
(Source Code Management)?
CVS, SVN, SourceSafe, ...

178. Apenas medo de perder os
dados?

179. Quando e como são realizados
commits de código?

180. A importância do versionamento a
cada commit

181. Baby Steps

182. Always shippable code!

183. Estratégias de branching

184. Nunca criar branches

185. Prós:
Fácil de seguir

186. Prós:
Fácil de seguir
Menos barreiras para novos
desenvolvedores

187. Prós:
Fácil de seguir
Menos barreiras para novos
desenvolvedores
Ninguém precisa saber criar
branches

188. Contras:
Baseline pode se tornar instável
a qualquer momento

189. Contras:
Baseline pode se tornar instável
a qualquer momento
Desenvolvimento caótico

190. Sempre criar branches

191. Prós:
Baseline sempre estável

192. Prós:
Baseline sempre estável
Nenhum desenvolvedor precisa
manter código em suas
maquinas por muito tempo

193. Contras:
Desenvolvedores isolados

194. Contras:
Desenvolvedores isolados
Criação de muitos conflitos

195. Contras:
Desenvolvedores isolados
Criação de muitos conflitos
Muito tempo gasto com merges

196. Estratégia híbrida
(também conhecida como bom senso)

197. Regras:
1. O código do baseline deve
sempre passar nos testes

198. Regras:
1. O código do baseline deve
sempre passar nos testes
2. Uma operação de commit
não pode ser muito grande
ao ponto de desestimular a
revisão de um colega

199. Daily Deployment

200. Quanto maior a distância entre o
que está em produção e em
desenvolvimento maior é o risco!

201. Quais são as maiores dificuldades
para viabilizar essa prática?

202. Riscos:
Baixo número de defeitos

203. Riscos:
Baixo número de defeitos
Ambiente totalmente
automatizado

204. Riscos:
Baixo número de defeitos
Ambiente totalmente
automatizado
Estratégias de recovery

205. Ambiente de Stagging

206. Negotiated Scope Contract

207. A maioria dos projetos fracassam!
(Standish Chaos Report – 2009)

208. 24% são simplesmente cancelados!
(Standish Chaos Report – 2009)

209. 44% fora do prazo, custo ou escopo!
(Standish Chaos Report – 2009)

210. Apenas 32% tem sucesso!
(Standish Chaos Report – 2009)

211. Sucesso?

212. Quantos % do Microsoft Word você
realmente utiliza?

213. A maioria das funcionalidades não
são utilizadas!

215. Por que?

216. Necessidade de segurança!

217. Quanto custa?

218. Quando fica pronto?

219. Tentando prever o futuro!

220. Fechar o escopo para tentar
responder a essas perguntas!

221. Qual é o maior risco de um projeto
de software?

222. Não era nada disso que eu queria!

223. O que toda essa segurança
garante?

224. A quantidade de dinheiro que
poderá ser jogada fora no final do
projeto!

225. Tipos de Contrato

226. Contrato de Tempo e Material

227. Alto risco para o cliente

228. Fornecedor não tem incentivo
para finalizar o escopo

229. Custos fora de controle

230. Desentendimentos constantes
entre o cliente e o fornecedor

231. Contrato de Preço Fixo

232. Alto custo para montar o contrato

233. Risco por conta do fornecedor

234. Engessado

235. Qualidade pode ser negligenciada
em caso de atrasos

236. Contratos Híbridos

237. Custos parcialmente fixos e
adicional reduzido
Exemplo:
80hs com 200 reais por hora =16k
8k fixo e 100 reais por hora

238. Pré-Pago
Um orçamento é definido no início
do projeto.
Conforme as entregas vão
acontecendo, um determinado
valor é descontado.

239. Preço Fixo por Release