Scrum

733 views
672 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
733
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Scrum

  1. 1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br Scrum
  2. 2. @rodrigobranas rodrigo.branas@gmail.comFormação AcadêmicaCiências da Computação – UFSCGerenciamento de Projetos - FGVCertificaçõesSCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM
  3. 3. Rodrigo Branas – rodrigo.branas@gmail.com10 anos de experiência na plataforma Java1000 horas em sala de aulaMais de 50 palestras em eventosLíder da área de desenvolvimento na GenneraAutor da revista Java MagazinePalestranteInstrutor da Academia Java e Agile da GlobalcodeCriador dos treinamentos de Clean Code, Selenium eMaven da Agile CodeTrabalhou com as empresas: EDS, HP, GM, Citibank,OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed,Suntech, Vale do Rio Doce, Senai, NET.
  4. 4. 1986 – Takeuchi e NonakaThe New New Product Development Game
  5. 5. Processo de desenvolvimento de produtos no Japão e EUA
  6. 6. Como as empresas que se destacavam faziam?
  7. 7. Abordagem Rugby• Permitia grande tolerância a mudanças• Era conduzido por equipesmultifuncionais e auto-organizadas• Havia sobreposição nas fases do projeto• O controle das atividades era sutil eocorria grande transferência deconhecimento no processo
  8. 8. Lançar produtos bem sucedidosno mercado cada vez mais rápido
  9. 9. Criado porJeff Sutherland e Ken Schwaber
  10. 10. Framework para gerenciar projetos de forma ágil
  11. 11. Scrum no contexto da agilidade
  12. 12. Framework?
  13. 13. “Framework é um conjunto de códigos, comuns entre váriosprojetos de software, provendo base para implementação de funcionalidades de forma genérica.” (Wiki)
  14. 14. Scrum precisa ser extendido
  15. 15. Refletir a cultura da empresa
  16. 16. Cuidado com o ScrumBut...
  17. 17. Algumas causas para o ScrumBut• O cliente não quer se envolver noprocesso.• Tudo tem prioridade alta.• Membros da equipes trabalham emvários projetos.• Cerimônias importantes são ignoradas.
  18. 18. Scrum é baseado no modelo iterativo e incremental
  19. 19. Resposta ao modelo dedesenvolvimento em cascata
  20. 20. Qual é o problema com o modelo em cascata?
  21. 21. Desperdício!
  22. 22. A maioria das funcionalidades não são utilizadas
  23. 23. Perda de tempo e dinheiro, adiando o ROI do projeto
  24. 24. Na minha empresa ninguém utiliza o modelo em cascata! Será?
  25. 25. Cuidado: Existe o pensamentocascata dentro de outros modelos
  26. 26. Metáfora do Lenhador
  27. 27. Desenvolvimento iterativo utilizando ciclos PDCA
  28. 28. Entregar o máximo de valor denegócio possível incrementalmente
  29. 29. O que significa desenvolversoftware de forma incremental?
  30. 30. Formado por uma equipe multi- disciplinar e auto-organizada
  31. 31. Em que tipo de projetos devemos utilizar Scrum?
  32. 32. Qual é a diferença entrecomplicado e complexo?
  33. 33. Overview: Ciclo de vida do Scrum
  34. 34. Papéis do Scrum
  35. 35. Product Owner
  36. 36. Responsável pelo produto
  37. 37. Define e prioriza o escopo do projeto
  38. 38. Representa os interesses dos Stakeholders
  39. 39. Tem como objetivo garantir oretorno do investimento (ROI)
  40. 40. Responsável por aceitar ou rejeitar as entregas feitas pelo time
  41. 41. Participa do processo deplanejamento junto com o time
  42. 42. Cuidado: É um dos papéis mais negligenciados do Scrum
  43. 43. Time
  44. 44. Altamente colaborativo
  45. 45. Multi-disciplinar
  46. 46. Responsável pelo processo de desenvolvimento
  47. 47. Qual é o tamanho ideal de um time Scrum?
  48. 48. Cuidado: Participar de uma equipe ágil envolve algumas mudanças!
  49. 49. Auto-gerenciamento
  50. 50. Se auto-gerenciar é um dos maiores desafios da mudança de cultura
  51. 51. Buscamos nossos líderes desde que nascemos
  52. 52. Medo de assumir responsabilidades e tomar decisões
  53. 53. Síndrome de Estocolmo
  54. 54. Arquitetura organizacional verticalizada
  55. 55. Que tipo de benefícios o auto- gerenciamento proporciona?
  56. 56. Diminuição dos níveis da arquitetura organizacional, melhorando acomunicação e proporcionando uma tomada de decisão mais rápida.
  57. 57. Foco dos gestores na estratégiada empresa, deixando as decisões chaves do projeto para as equipes.
  58. 58. Surgimento de líderes, fazendo com que a empresa assuma novas oportunidades.
  59. 59. Debate: Auto-gerenciamentoparece um mito? É realmente possível?
  60. 60. XP Practice: Energized Work
  61. 61. Desenvolvimento envolve estimulara criatividade, idéias e o raciocínio
  62. 62. Produtividade x Carga Horária
  63. 63. Horários
  64. 64. Baixa motivação com o trabalho
  65. 65. Ficou doente?
  66. 66. ScrumMaster
  67. 67. Responsável pela utilização corretado Scrum e disseminação da cultura ágil dentro do projeto
  68. 68. Facilita as cerimônias do Scrum
  69. 69. Auxilia o Product Owner a realizar seu trabalho corretamente
  70. 70. Remoção de impedimentos
  71. 71. Proteje o time contra interrupções externas
  72. 72. Cuidado: Problemas famosos com opapel de ScrumMaster nos projetos
  73. 73. Good: ScrumMaster totalmentededicado a gestão e liderança de um único projeto.
  74. 74. Bad: ScrumMaster acumulando opapel de desenvolvedor na equipee dividindo as responsabilidadesde gestão e liderança.
  75. 75. Ugly: ScrumMaster acumulando o papel de Product Owner, definindo o direcionamento do produto etendo responsabilidade na gestão e liderança do projeto.
  76. 76. Fluxo do Scrum: Product Backlog
  77. 77. Product Backlog
  78. 78. Lista de requisitos de alto nívelpriorizada por valor de negócio
  79. 79. Quando o Product Backlog deve ser criado e modificado?
  80. 80. Story Writing Workshop
  81. 81. Foco na quantidade
  82. 82. Pensando alto nível
  83. 83. Não julgar as ideias
  84. 84. Cuidado: Uma lista de requisitossem qualquer priorização não é um Product Backlog!
  85. 85. Como priorizar sem ter idéia do tempo de desenvolvimento?
  86. 86. Story Points
  87. 87. Medida relativa de esforço
  88. 88. Variação grande de produtividade entre desenvolvedores
  89. 89. Por que não utilizar uma medida absoluta como o tempo?
  90. 90. Construindo uma parede de tijolos
  91. 91. Os Números de Fibonacci0, 1, 2, 3, 5, 8, 13, 21, 34, 55 ...
  92. 92. Trabalhando com a incerteza
  93. 93. Utilizando a triangulação
  94. 94. Estimando em equipe com o Planning Poker
  95. 95. Baixo nível de influência!
  96. 96. Processos de priorização
  97. 97. Maximização do Retorno do Investimento
  98. 98. Técnicas de priorização
  99. 99. Análise de MoSCoW
  100. 100. Análise MoSCoWOs requisitos são divididos em apenas quatro categorias:Must, Should, Could, Won’t
  101. 101. Must (Deve)Descreve um requisito que deve seratendido na solução final para que amesma seja considerada um sucesso. (Babok, pag. 108)
  102. 102. Should (Deveria) Representa um item de altaprioridade que deveria ser incluído na solução caso possível. (Babok, pag. 108)
  103. 103. Could (Poderia) Descreve um requisito que é considerado desejável, mas nãonecessário, e que será incluído caso o tempo e os recursos permitam. (Babok, pag. 108)
  104. 104. Won’t (Não irá) Representa um requisito que aspartes interessadas concordam em não implementar em uma determinada entrega. (Babok, pag. 108)
  105. 105. Análise de Kano
  106. 106. Recomendado para avaliargrandes grupos de usuários
  107. 107. Baseado na satisfação dos usuários
  108. 108. Como você se sentiria se o requisito estivesse presente?
  109. 109. Como você se sentiria de o requisito não estivesse presente?
  110. 110. Respostas possíveis:Desejo, Espero, Tanto faz, Não gostaria Observação importante Desejo = gosto, me agrado, aprecio Espero = quero, imagino.
  111. 111. Devem ser feitos (D), São atrativos (A), Quanto maismelhor (Q), Indiferente (I), Não devem ser feitos (N)
  112. 112. Fluxo do Scrum: Release Backlog
  113. 113. O que é uma release?
  114. 114. Cuidado: Falta de definição de release.
  115. 115. Cuidado: Release longa demais.
  116. 116. Fluxo do Scrum: Sprint
  117. 117. Qual é o conceito de Sprint?
  118. 118. Período de tempo, de tamanho fixo (conhecidos como timebox), em que o time secompromete com a realização de uma determinada meta.
  119. 119. Qual é o tamanho ideal do timebox?
  120. 120. Preferencialmente entre 2 e 4 semanas!
  121. 121. Por que não uma Sprint menor que 2 ou maior que 4 semanas?
  122. 122. As sprints devem ter um tamanho fixo ao longo do projeto.
  123. 123. Manter o ritmo
  124. 124. Velocidade da equipe
  125. 125. Está quase pronto, extender ou não o tamanho da Sprint?
  126. 126. Stop-the-line: Cancelando a Sprint
  127. 127. Fluxo do Scrum: Planning 1
  128. 128. Objetivo: Ter um entendimentomuito claro em relação a “o que” fazer para alcançar a meta da sprint.
  129. 129. As User Stories de maior prioridade são selecionadas deacordo com a velocidade do time
  130. 130. Cuidado: Se comprometer com User Stories demais, sem margem de manobra.
  131. 131. XP Practice: Slack
  132. 132. Problemas com o overcommitment
  133. 133. Frustração por não atingir a meta!
  134. 134. É necessário finalizar todas asuser stories para atingir uma meta?
  135. 135. Decompor as user stories deixando os detalhes menos importantes para o final
  136. 136. Incluir tarefas técnicas importantes mas que possam ser canceladas
  137. 137. Reservar um tempo livre caso seja necessário utilizá-lo
  138. 138. O time busca um entendimento detalhado de cada User Story
  139. 139. Os testes de aceitação são criados para cada User Story
  140. 140. Definição da Meta da SprintO time deve se comprometer com a meta. É onde o time deseja chegar ao final da sprint.
  141. 141. Metas S.M.A.R.T.
  142. 142. Specific
  143. 143. “Eu quero viajar no carnaval” Essa meta é específica?
  144. 144. Measurable
  145. 145. “Eu quero ser rico!”Essa meta é mensurável?
  146. 146. Achievable
  147. 147. “Eu quero ser campeão da Copa Libertadores da América” (Torcendo para o Corinthians) Essa meta é atingível?
  148. 148. Relevant
  149. 149. “Eu quero passar o carnaval em Curitiba!”Essa meta é relevante? Faz sentido dentro do contexto do carnaval?
  150. 150. Timebox
  151. 151. “Eu quero tirar férias” Quando?
  152. 152. Fluxo do Scrum: Planning 2
  153. 153. Objetivo: Ter um entendimentomuito claro em relação a “como” fazer para alcançar a meta da sprint.
  154. 154. Criação do Sprint Backlog
  155. 155. Formado apenas por atividades
  156. 156. Criado a partir da decomposição de cada User Story selecionada em atividades técnicas.
  157. 157. Estimar as atividades em unidades de tempo
  158. 158. Fluxo do Scrum: Execução da Sprint
  159. 159. Quadro Kanban
  160. 160. Fornece uma visão da situação das atividades durante a Sprint
  161. 161. Cuidado: Utilização das ferramentas eletrônicas.
  162. 162. Artefato responsável por forneceruma visualização do progresso da Sprint ou Release
  163. 163. Cuidado: Falta de atualização pode ser uma fonte de problemas
  164. 164. Hora de trabalhar!
  165. 165. Fluxo do Scrum: Daily Scrum
  166. 166. Feita sempre em pé
  167. 167. Planejamento tático diário
  168. 168. Estrutura da Daily Scrum• O que eu fiz desde a últimareunião diária?• O que eu farei até a próximareunião?• Existe alguma coisa meimpedindo?
  169. 169. Cuidado: Mantenha sempre o foco nos objetivos da reunião diária
  170. 170. Fluxo do Scrum: Sprint Review
  171. 171. Obter o aceite do Product Owner para os resultados da Sprint
  172. 172. Fluxo do Scrum: Retrospective
  173. 173. Momento de reflexão
  174. 174. Oportunidade para inspecionar e adaptar o processo
  175. 175. Estrutura da Retrospectiva• O que foi bom?• O que foi ruim?• O que podemos fazer paramelhorar?
  176. 176. Cuidado: Busque a imparcialidadede todos durante a retrospectiva

×