Rodrigo Branas é um especialista em Scrum e Java com mais de 10 anos de experiência. Ele possui diversas certificações como Scrum Master, Product Owner e Project Management Professional. Atualmente é instrutor da Agile Code, onde ministra treinamentos sobre Clean Code, Selenium e Maven.

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

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. 1986 – Takeuchi e Nonaka
The New New Product Development Game

6. Processo de desenvolvimento de
produtos no Japão e EUA

7. Como as empresas que se
destacavam faziam?

8. Abordagem Rugby
• Permitia grande tolerância a mudanças
• Era conduzido por equipes
multifuncionais e auto-organizadas
• Havia sobreposição nas fases do projeto
• O controle das atividades era sutil e
ocorria grande transferência de
conhecimento no processo

9. Lançar produtos bem sucedidos
no mercado cada vez mais rápido

10. Criado por
Jeff Sutherland e Ken Schwaber

11. Framework para gerenciar projetos
de forma ágil

12. Scrum no contexto da
agilidade

13. Framework?

14. “Framework é um conjunto de
códigos, comuns entre vários
projetos de software, provendo
base para implementação de
funcionalidades de forma
genérica.” (Wiki)

15. Scrum precisa ser
extendido

16. Refletir a cultura da
empresa

17. Cuidado com o ScrumBut...

18. Algumas causas para o
ScrumBut
• O cliente não quer se envolver no
processo.
• Tudo tem prioridade alta.
• Membros da equipes trabalham em
vários projetos.
• Cerimônias importantes são ignoradas.

19. Scrum é baseado no modelo
iterativo e incremental

20. Resposta ao modelo de
desenvolvimento em cascata

21. Qual é o problema com o modelo
em cascata?

22. Desperdício!

23. A maioria das funcionalidades não
são utilizadas

24. Perda de tempo e dinheiro, adiando
o ROI do projeto

25. Na minha empresa ninguém utiliza o
modelo em cascata! Será?

26. Cuidado: Existe o pensamento
cascata dentro de outros modelos

27. Metáfora do Lenhador

28. Desenvolvimento iterativo utilizando
ciclos PDCA

29. Entregar o máximo de valor de
negócio possível incrementalmente

30. O que significa desenvolver
software de forma incremental?

31. Formado por uma equipe multi-
disciplinar e auto-organizada

32. Em que tipo de projetos devemos
utilizar Scrum?

34. Qual é a diferença entre
complicado e complexo?

35. Overview: Ciclo de vida do Scrum

37. Papéis do Scrum

38. Product Owner

39. Responsável pelo produto

40. Define e prioriza o escopo do
projeto

41. Representa os interesses dos
Stakeholders

42. Tem como objetivo garantir o
retorno do investimento (ROI)

43. Responsável por aceitar ou rejeitar
as entregas feitas pelo time

44. Participa do processo de
planejamento junto com o time

45. Cuidado: É um dos papéis mais
negligenciados do Scrum

46. Time

47. Altamente colaborativo

48. Multi-disciplinar

49. Responsável pelo processo de
desenvolvimento

50. Qual é o tamanho ideal de um time
Scrum?

51. Cuidado: Participar de uma equipe
ágil envolve algumas mudanças!

52. Auto-gerenciamento

53. Se auto-gerenciar é um dos maiores
desafios da mudança de cultura

54. Buscamos nossos líderes desde que
nascemos

55. Medo de assumir responsabilidades
e tomar decisões

56. Síndrome de Estocolmo

57. Arquitetura organizacional
verticalizada

58. Que tipo de benefícios o auto-
gerenciamento proporciona?

59. Diminuição dos níveis da
arquitetura
organizacional, melhorando a
comunicação e proporcionando
uma tomada de decisão mais
rápida.

60. Foco dos gestores na estratégia
da empresa, deixando as decisões
chaves do projeto para as
equipes.

61. Surgimento de líderes, fazendo
com que a empresa assuma
novas oportunidades.

62. Debate: Auto-gerenciamento
parece um mito? É realmente
possível?

63. XP Practice: Energized Work

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

65. Produtividade x Carga Horária

66. Horários

67. Baixa motivação com o trabalho

68. Ficou doente?

69. ScrumMaster

70. Responsável pela utilização correta
do Scrum e disseminação da cultura
ágil dentro do projeto

71. Facilita as cerimônias do Scrum

72. Auxilia o Product Owner a realizar
seu trabalho corretamente

73. Remoção de impedimentos

74. Proteje o time contra interrupções
externas

75. Cuidado: Problemas famosos com o
papel de ScrumMaster nos projetos

76. Good: ScrumMaster totalmente
dedicado a gestão e liderança de
um único projeto.

77. Bad: ScrumMaster acumulando o
papel de desenvolvedor na equipe
e dividindo as responsabilidades
de gestão e liderança.

78. Ugly: ScrumMaster acumulando o
papel de Product Owner, definindo
o direcionamento do produto e
tendo responsabilidade na gestão e
liderança do projeto.

80. Fluxo do Scrum: Product Backlog

81. Product Backlog

82. Lista de requisitos de alto nível
priorizada por valor de negócio

84. Quando o Product Backlog deve ser
criado e modificado?

85. Story Writing Workshop

86. Foco na quantidade

87. Pensando alto nível

88. Não julgar as ideias

89. Cuidado: Uma lista de requisitos
sem qualquer priorização não é um
Product Backlog!

90. Como priorizar sem ter idéia do
tempo de desenvolvimento?

91. Story Points

92. Medida relativa de esforço

93. Variação grande de produtividade
entre desenvolvedores

94. Por que não utilizar uma medida
absoluta como o tempo?

95. Construindo uma parede de tijolos

96. Os Números de Fibonacci
0, 1, 2, 3, 5, 8, 13, 21, 34, 55 ...

97. Trabalhando com a incerteza

98. Utilizando a triangulação

99. Estimando em equipe com o
Planning Poker

100. Baixo nível de influência!

101. Processos de priorização

102. Maximização do Retorno do
Investimento

103. Técnicas de priorização

104. Análise de MoSCoW

105. Análise MoSCoW
Os requisitos são divididos em
apenas quatro categorias:
Must, Should, Could, Won’t

106. Must (Deve)
Descreve um requisito que deve ser
atendido na solução final para que a
mesma seja considerada um sucesso.
(Babok, pag. 108)

107. Should (Deveria)
Representa um item de alta
prioridade que deveria ser incluído na
solução caso possível.
(Babok, pag. 108)

108. Could (Poderia)
Descreve um requisito que é
considerado desejável, mas não
necessário, e que será incluído caso o
tempo e os recursos permitam.
(Babok, pag. 108)

109. Won’t (Não irá)
Representa um requisito que as
partes interessadas concordam em
não implementar em uma
determinada entrega.
(Babok, pag. 108)

110. Análise de Kano

111. Recomendado para avaliar
grandes grupos de usuários

112. Baseado na satisfação dos usuários

113. Como você se sentiria se o requisito
estivesse presente?

114. Como você se sentiria de o requisito
não estivesse presente?

115. Respostas possíveis:
Desejo, Espero, Tanto faz, Não gostaria
Observação importante
Desejo = gosto, me agrado, aprecio
Espero = quero, imagino.

116. Devem ser feitos (D), São atrativos (A), Quanto mais
melhor (Q), Indiferente (I), Não devem ser feitos (N)

117. Fluxo do Scrum: Release Backlog

118. O que é uma release?

119. Cuidado: Falta de definição de
release.

120. Cuidado: Release longa demais.

121. Fluxo do Scrum: Sprint

122. Qual é o conceito de Sprint?

123. Período de tempo, de tamanho
fixo (conhecidos como
timebox), em que o time se
compromete com a realização de
uma determinada meta.

124. Qual é o tamanho ideal do timebox?

125. Preferencialmente entre 2 e 4
semanas!

126. Por que não uma Sprint menor que
2 ou maior que 4 semanas?

127. As sprints devem ter um tamanho
fixo ao longo do projeto.

128. Manter o ritmo

129. Velocidade da equipe

130. Está quase pronto, extender ou não
o tamanho da Sprint?

131. Stop-the-line: Cancelando a Sprint

132. Fluxo do Scrum: Planning 1

133. Objetivo: Ter um entendimento
muito claro em relação a “o que”
fazer para alcançar a meta da
sprint.

134. As User Stories de maior
prioridade são selecionadas de
acordo com a velocidade do time

136. Cuidado: Se comprometer com User
Stories demais, sem margem de
manobra.

137. XP Practice: Slack

138. Problemas com o overcommitment

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

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

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

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

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

144. O time busca um entendimento
detalhado de cada User Story

145. Os testes de aceitação são criados
para cada User Story

146. Definição da Meta da Sprint
O time deve se comprometer com
a meta. É onde o time deseja
chegar ao final da sprint.

147. Metas S.M.A.R.T.

148. Specific

149. “Eu quero viajar no carnaval”
Essa meta é específica?

150. Measurable

151. “Eu quero ser rico!”
Essa meta é mensurável?

152. Achievable

153. “Eu quero ser campeão da Copa
Libertadores da América”
(Torcendo para o Corinthians)
Essa meta é atingível?

154. Relevant

155. “Eu quero passar o carnaval em
Curitiba!”
Essa meta é relevante? Faz sentido
dentro do contexto do carnaval?

156. Timebox

157. “Eu quero tirar férias”
Quando?

158. Fluxo do Scrum: Planning 2

159. Objetivo: Ter um entendimento
muito claro em relação a “como”
fazer para alcançar a meta da
sprint.

160. Criação do Sprint Backlog

161. Formado apenas por atividades

162. Criado a partir da decomposição de
cada User Story selecionada em
atividades técnicas.

163. Estimar as atividades em
unidades de tempo

164. Fluxo do Scrum: Execução da
Sprint

165. Quadro Kanban

166. Fornece uma visão da situação das
atividades durante a Sprint

167. Cuidado: Utilização das ferramentas
eletrônicas.

169. Artefato responsável por fornecer
uma visualização do progresso da
Sprint ou Release

170. Cuidado: Falta de atualização pode
ser uma fonte de problemas

171. Hora de trabalhar!

172. Fluxo do Scrum: Daily Scrum

173. Feita sempre em pé

174. Planejamento tático diário

175. Estrutura da Daily Scrum
• O que eu fiz desde a última
reunião diária?
• O que eu farei até a próxima
reunião?
• Existe alguma coisa me
impedindo?

176. Cuidado: Mantenha sempre o foco
nos objetivos da reunião diária

177. Fluxo do Scrum: Sprint Review

178. Obter o aceite do Product Owner
para os resultados da Sprint

179. Fluxo do Scrum: Retrospective

180. Momento de reflexão

181. Oportunidade para inspecionar e
adaptar o processo

182. Estrutura da Retrospectiva
• O que foi bom?
• O que foi ruim?
• O que podemos fazer para
melhorar?

183. Cuidado: Busque a imparcialidade
de todos durante a retrospectiva