Este documento fornece um resumo da experiência profissional e formação de Rodrigo Branas. Ele tem 10 anos de experiência na plataforma Java, ministrou mais de 1000 horas de aula e fez mais de 50 palestras. Atualmente é instrutor na Academia Java e Agile da Globalcode e criador de treinamentos da Agile Code.

1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br
Lean Software Development

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ígitro, Softplan, Unimed,
Suntech, Vale do Rio Doce, Senai, NET.

5. Lean no contexto da agilidade

6. Tudo começa com a história do
Toyota Production System...

7. A tecelagem sempre foi um trabalho
puramente manual

8. Como funciona um tear?

10. Em 1890, Toyoda Sakichi observava
sua mãe em um desses teares

11. Como facilitar o processo de
tecelagem?

12. Sakichi chegou a aumentar em 50%
a produtividade com suas melhorias

13. Primeiro tear mecânico do Japão,
em 1896

14. Muitas melhorias foram feitas e o
tear foi ficando mais rápido

15. Seu filho, Toyoda Kiichiro, começou
a ajudar no processo de fabricação

16. Nasce o Model G, o primeiro tear de
alta velocidade do mundo

17. Que tipo de problemas poderiam
acontecer conforme a velocidade do
tear aumentava?

18. Era comum os fios arrebentarem

19. Sistema automatizado que parava a
maquina caso algo errado ocorresse

20. Que vantagens existem em ter uma
maquina que para automaticamente
caso qualquer problema ocorra?

21. Evitar a produção de produtos
defeituosos

22. Manter a maquina
funcionando, seria um imenso
desperdício de matéria prima

23. Quanto mais cedo um problema
puder ser descoberto, menor será
seu impacto no final

24. Separação entre o homem e a
maquina

25. Um operador poderia, ao mesmo
tempo, cuidar de mais de 30 teares

26. Permite que os operadores
mantenham o foco nas atividades
que geram mais valor

27. Como apenas um operador cuidava
de tantas maquinas?

28. Andon (アンドン)

29. Originado das antigas lanternas de
papel japonesas

30. Permite ao operador visualizar
problemas na linha e chamar ajuda

35. Genchi Genbutsu (現地現物)

36. “Dados são importantes, mas eu
coloco maior ênfase nos fatos!”
(Taiichi Ohno)

37. Gemba

38. Vá e veja com seus próprios olhos

41. Jidoka (自働化)

42. Automação com um toque humano

43. Princípios básicos do Jidoka:

44. Princípios básicos do Jidoka:
• Detectar o problema

45. Princípios básicos do Jidoka:
• Detectar o problema
• Parar a linha de produção

46. Princípios básicos do Jidoka:
• Detectar o problema
• Parar a linha de produção
• Corrigir imediatamente o
problema que causou a parada

47. Princípios básicos do Jidoka:
• Detectar o problema
• Parar a linha de produção
• Corrigir imediatamente o
problema que causou a parada
• Achar a causa raiz e agir para
que o problema não ocorra
novamente

48. Como gerenciar o conhecimento
para encontrar a causa raiz e evitar
que os problemas voltem a ocorrer?

49. Root-Cause Analysis

50. Os 5 porquês
(The 5 Why’s)

51. Toyota A3
Problem-Solving Report

52. A maioria dos problemas são
corrigidos de forma superficial

53. O processo A3 busca entender e
eliminar os problemas para que não
voltem a acontecer

55. Com o tempo e a eliminação da
recorrência dos problemas, é
possível alcançar fluxos produtivos
cada vez mais contínuos, suaves e
estáveis. O resultado é o aumento
constante de produtividade

56. Muitas vezes, os erros são inseridos
pelo operador da maquina

57. Poka-Yoke (ポカヨケ)

58. Fail-Saving ou Mistake-Proofing

59. Dispositivos para a prevenir a
ocorrência de erros

63. Shigeo Shingo, responsável por
desenvolver a técnica, batizou
inicialmente os mecanismos de
baka-yoke (fool-proofing or idiot-
proofing) mas depois foi levado a
alterar o nome para poka-yoke
(mistake-proofing)

64. Como podemos aplicar o conceito
de poka-yoke tanto no
desenvolvimento quanto no produto
de software que produzimos?

65. Criar software a prova de
falhas, eliminando ao máximo a
ocorrência de problemas e a
necessidade de suporte técnico

66. Garantir que todo o código
produzido seja, se possível, livre de
defeitos

67. Princípio do Não Custo

68. Custos + Lucro = Preço de Mercado

69. Preço de Mercado – Custos = Lucro

70. O sucesso e aumento dos lucros da
Toyota é perseguido pela eliminação
dos desperdícios e redução dos
custos de produção

71. Anos depois, em 1929, Kiichiro viaja
para os Estados Unidos

72. Impressionado com tantos veículos,
Kiichiro decide que iria começar a
fabricar carros no Japão

73. Que tipo de problemas econômicos
estavam acontecendo naquela
época (em 1929)?

74. Recursos limitados e falta de base
econômica e tecnológica para
produzir carros

75. Produzir apenas o necessário, na
quantidade necessária e no
momento necessário

76. Surgimento do modelo Just in Time

77. Em nossos cenários atuais, como
produzir apenas o necessário, na
quantidade e momento necessário?

78. Kiichiro continuou aprimorando o
modelo Just in Time quando a
Segunda Guerra Mundial (1941)
interrompeu seus esforços

79. Após a guerra, o Japão estava
arrasado

80. Em situação difícil, a Toyota demitiu
quase mil funcionários para poder
sobreviver

81. Kiichiro renuncia a presidência logo
após as demissões e passa o sonho
para seu primo Toyoda Eiji

82. Hansei (反省)

83. A Auto-Reflexão é uma das ideias
centrais da cultura japonesa

84. Admitir o próprio erro e garantir a
melhoria

85. Sucesso com humildade

86. Parar o Hansei significa parar o
aprendizado. Com ele, ninguém se
torna convencido de sua
superioridade e busca melhorar
continuamente.

87. Kaizen (反省)

88. Melhoria contínua e gradual

89. Para o Kaizen, é sempre possível
fazer melhor, nenhum dia deve
passar sem que alguma melhoria
tenha sido implantada, seja ela na
estrutura da empresa ou no
indivíduo.

90. O Tesouro de Bresa

91. Eiji tem como desafio superar a
produção americana (8 vezes
maior) dentro de 3 anos

92. Eiji procurou Ohno Taichii, chefe do
setor de maquinas da Toyota, para
evoluir o sistema de produção!

93. Com o objetivo de aumentar a
produtividade de cada operário,
Ohno utilizou os conceitos do Jidoka
(criado por Sakichi) em todas as
operações da Toyota

94. Como o Jidoka, ou Autonomation,
podem ajudar a aumentar a
produtividade no desenvolvimento?

95. Para lidar com os recursos
limitados, Ohno buscou aprimorar o
modelo Just in Time iniciado por
Kiichiro

96. Em 1950, Ohno vai para os Estados
Unidos visitar fábricas de
automóveis, mas fica encantado
com os supermercados

97. Venda de porta em porta

98. Como funciona a logística de um
sistema de supermercados?

99. Sistema de produção puxado ou
Pull System

100. Cada processo se torna um cliente
do processo anterior

101. É como se o processo anterior fosse
uma loja

102. Dinâmica: Simulação da diferança
entre um sistema empurrado e
puxado

103. Faz sentido produzir produtos com
defeito utilizando o modelo Just in
Time?

104. Sem estoque não é possível
substituir nenhum produto!

105. Por isso as metodologias e
processos ágeis se baseiam em
produzir software com qualidade e
antecipar o ROI!

106. Problemas com a confusão quando
a demanda aumentava muito

107. Como organizar a produção com a
utilização do modelo Just in Time?

108. Kanban (看板)

109. Registro ou placa visível

110. Sincronizar o processo de produção
buscando suavizar o seu fluxo

111. Dinâmica: Realizar a simulação da
produção puxada com a utilização
de Kanban

112. O Sistema Toyota de Produção
ganhou espaço em 1973 com a
crise do petróleo

113. O termo Lean Manufactoring ficou
conhecido após a publicação do
trabalho de James Womack, do
MIT, chamado “A máquina que
mudou o mundo”

114. Desperdícios

115. Muda (無駄)

116. Atividades que não agregam valor

117. Mura (斑)

118. Variabilidade na produção

119. Muri (無理)

120. Sobrecarga

121. Principais desperdícios

122. Estoques no processo

123. Trabalho inacabado

124. Tipos de trabalho inacabado:

125. Tipos de trabalho inacabado:
• Documentação não codificada

126. Tipos de trabalho inacabado:
• Documentação não codificada
• Código ainda não sincronizado

127. Tipos de trabalho inacabado:
• Documentação não codificada
• Código ainda não sincronizado
• Código ainda não testado

128. Tipos de trabalho inacabado:
• Documentação não codificada
• Código ainda não sincronizado
• Código ainda não testado
• Código ainda não instalado

129. A lenda do código comitado

130. Task-Switching

131. Custo do chaveamento

132. Dinâmica: Problemas com o Task-
Switching nos processos

133. Convivência com problemas

135. Funcionalidades extras

137. “Não há nada mais inútil do que
fazer de forma eficiente algo que
sequer deveria ter sido feito”

138. Transferência de controle

139. Quando transferimos o trabalho a
um colega, uma grande quantidade
de conhecimento tácito é deixada
na mente de seu criador.

140. Que tipo de soluções podem ser
adotadas para previnir a perda de
conhecimento em uma empresa?

141. Esperas

142. Uma das principais causa de atrasos

143. A importância das equipes multi-
disciplinares

144. Defeitos

145. Testes automatizados são custo ou
investimento?

146. Quanto antes os defeitos forem
descobertos maior será a economia

147. Como investigar os desperdícios no
processo de desenvolvimento?

148. Value Stream Mapping

149. “Tudo que estamos fazendo é olhar
na linha do tempo, do momento em
que o cliente nos entrega o pedido
até o ponto em que recemos o
dinheiro. Estamos reduzindo esse
linha do tempo removendo os
desperdícios que não agregam
valor.” (Ohno Taiichi)

150. Por onde devemos iniciar e finalizar
o Value Stream?

151. O relógio começa a contar em um
Value Stream quando uma
demanda é gerada pelo cliente e só
para quando ela é satisfatoriamente
entregue, resolvendo o problema do
cliente.

152. Mapear todo um processo, não
apenas um evento isolado

154. Dinâmica: Realizar um Value Stream
Mapping em um cenário simples

155. Theory of Constraints

156. O caso do investimento do
restaurante

157. Criado por Eliyahu Goldratt
(A Meta – 1984)

158. Concebida para ajudar as
organizações a alcançar seus
objetivos continuamente

159. ”Toda organização tem - em um
dado momento no tempo - pelo
menos uma restrição que limita a
performance do sistema em relação
à sua meta.”

160. Baseado em 3 perguntas:

161. Baseado em 3 perguntas:
• O que mudar?

162. Baseado em 3 perguntas:
• O que mudar?
• Por que mudar?

163. Baseado em 3 perguntas:
• O que mudar?
• Por que mudar?
• Como mudar?

164. Identificar a restrição

165. Dica: Antes da restrição,
geralmente existe uma fila

166. Decidir como explorar a restrição

167. Subordinar os outros processos à
restrição

168. Elevar a restrição

169. Se a restrição for quebrada, voltar
ao início

170. Dinâmica: Realizar um Value Stream
Mapping de seu cenário atual

171. Cuidado: Pense bem antes de
automatizar um processo complexo

172. Qualidade

173. 5S

174. Você já perdeu tempo tentando
descobrir aonde está algo?

175. Eu me encontro na minha própria
bagunça!

176. O problema são os outros se
encontrarem

177. Seiri (Ordenar)

178. Distinguir sobre o que não é mais
necessário:

179. Distinguir sobre o que não é mais
necessário:
• Código Morto

180. Distinguir sobre o que não é mais
necessário:
• Código Morto
• Importações não utilizadas

181. Distinguir sobre o que não é mais
necessário:
• Código Morto
• Importações não utilizadas
• Variáveis não utilizadas

182. Distinguir sobre o que não é mais
necessário:
• Código Morto
• Importações não utilizadas
• Variáveis não utilizadas
• Métodos não utilizados

183. Distinguir sobre o que não é mais
necessário:
• Código Morto
• Importações não utilizadas
• Variáveis não utilizadas
• Métodos não utilizados
• Classes não utilizadas

184. Distinguir sobre o que não é mais
necessário:
• Código Morto
• Importações não utilizadas
• Variáveis não utilizadas
• Métodos não utilizados
• Classes não utilizadas
• Código duplicado

185. Seiton (Sistematizar)

186. Definir um lugar para cada coisa:

187. Definir um lugar para cada coisa:
• Organização da documentação
do projeto

188. Definir um lugar para cada coisa:
• Organização da documentação
do projeto
• Criação de projetos específicos

189. Definir um lugar para cada coisa:
• Organização da documentação
do projeto
• Criação de projetos específicos
• Empacotamento

190. Seiso (Limpar)

191. Limpe constantemente:

192. Limpe constantemente:
• Resolva falhas e erros nos
testes

193. Limpe constantemente:
• Resolva falhas e erros nos
testes
• Melhore a cobertura de testess

194. Limpe constantemente:
• Resolva falhas e erros nos
testes
• Melhore a cobertura de testes
• Resolva os alertas de
checkstyle

195. Limpe constantemente:
• Resolva falhas e erros nos
testes
• Melhore a cobertura de testes
• Resolva os alertas de
checkstyle
• Resolva falhas em documentos

196. Quando vai ser limpo? De que
forma vai ser limpo?

197. Seiketsu (Padronizar)

198. Criar padrões visuais para manter
as coisas organizadas

201. Padronizar ou não o ambiente de
desenvolvimento?

202. Shitsule (Manter)

203. Que tipo de problemas existem em
seus ambientes relacionados a
organização e limpeza?

204. Utilizando o Kanban para
desenvolvimento de software

205. 1/3 - Visualize the workflow!

206. 2/3 - Limit WIP!

207. 3/3 – Measure and optimize the flow!

208. Fluxo contínuo!

209. O seu processo te amarra?

210. Nem sempre é saudável utilizar Scrum

211. Como fica a Revisão, Retrospectiva e
Planejamento?

212. Visualize the workflow!

214. Como fazemos para mapear o workflow
do nosso projeto?

215. PROCESSO PROCESSO
DEMANDA ENTREGA
1 N+1
Definir o Value Stream

216. Exemplo de workflow simplificado!

217. Em andamento? Etapas escondidas?

218. Definition of Done

221. TODO DONE
Stories Doing Test Deploy

223. Dependências!

224. Quem são seus fornecedores?!

225. Demanda Tempo? Entrega

226. Demanda Tempo? Entrega
Análise de
Requisitos

227. Demanda Tempo? Entrega
Análise de
Requisitos
Modelo de
Dados

228. Demanda Tempo? Entrega
Análise de
Requisitos
Modelo de
Dados
Layout

229. Demanda Tempo? Entrega
Análise de Revisão e
Requisitos Aceitação
Modelo de
Deploy
Dados
Desenvolvi Code
Layout QA
mento Review

230. Cuidado com o estoque!

240. Reunião de Revisão! Como faz?

241. Foco no Término!

242. Task 1
3 sp.
Task 2
3 sp.
Task 3
3 sp.
Task 4
3 sp.
Adiando o ROI

243. Task 1
3 sp.
Task 2
3 sp.
Task 3
3 sp.
Task 4
3 sp.
Antecipando o ROI

244. Limit WIP (Work in Progress)

245. Adequar o sistema a sua capacidade!

246. Você sabe a sua capacidade?

247. By Henrik Kniberg – http://www.crisp.se/henrik.kniberg

248. By Henrik Kniberg – http://www.crisp.se/henrik.kniberg

249. By Henrik Kniberg – http://www.crisp.se/henrik.kniberg

250. By Henrik Kniberg – http://www.crisp.se/henrik.kniberg

251. Stop-the-line!

252. Realizar a análise da causa raiz

253. Lembra? Fluxo contínuo!

254. Measure and optimize the flow!

255. “All we are doing is looking at the timeline,
from the moment the customer gives us an
order to the point where we collect the
cash. And we are reducing the time line by
reducing the non-value adding wastes.”
(Taiichi Ohno)

256. Demanda Tempo? Entrega
Quanto tempo existe entre a
demanda e a entrega?

257. T-Shirt Sizing!

258. T-Shirt Sizing
P – 3,5 dias
M – 7 dias
G – 10 dias

259. Demanda Tempo? Entrega
Análise de Revisão e
Requisitos Aceitação
Modelo de
Deploy
Dados
Desenvolvi Code
Layout QA
mento Review

262. Lembra? Fluxo contínuo!