O documento apresenta um treinamento sobre Scrum, um framework ágil para gestão de projetos. Explica o que é Scrum, por que é usado e que não é uma solução mágica. Apresenta os papéis, cerimônias e práticas de Scrum como planejamento, daily meetings, retrospectivas e a importância de um product backlog bem gerenciado. Também discute desafios comuns e como Scrum ajuda a lidar com mudanças frequentes de requisitos.

1. Scrum Gestão ágil de projetos

2. Igor Macaúbas e Marcos Pereira

3. Metas para o treinamento Explicar o que é Scrum Por que Scrum Mostrar que Scrum não é uma bala de prata Novo olhar sobre gestão de projetos Metas para o seminário

4. Veja Ouça Fale

5. “ A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelo menos 50 anos . Elas tem sobrevivido ao seu tempo. Como resultado, estamos pregando, ensinando, e praticando políticas que estão cada vez mais desalinhadas com a realidade, e são contra produtivas .” Peter Drucker (1909-2005)

6. 31% são cancelados 53% custam o dobro do estimado Apenas 16% são completados no prazo e custo estimados * dados do CHAOS report

7. Mas por que ?

8. Falta de envolvimento do usuário Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos

14. Falhar é uma maneira muito forte de aprendizado, mas é preciso parar de apontar culpados

15. “ Jogar a culpa dos problemas nas pessoas envolvidas é mais do que contra produtivo, é deixar uma situação ruim pior ainda.” Mary Poppendieck

16. Manifesto Ágil

17. Indivíduos e interação entre eles mais que processos e ferramentas

18. Software Funcionando mais que documentação abrangente

19. Colaboração mais que negociação de contratos

20. Responder às mudanças mais que seguir um plano http:// www.agilemanifesto.org

21. Olá , Scrum!

23. Scrum é um processo iterativo e incremental para desenvolvimento de produtos .

24. O objetivo é entregar o máximo de valor de negócio* possível no menor tempo * Foco no ROI – Retorno de investimento

25. Scrum é também um meio de evidenciar os problemas

26. Mas Scrum não é bala de prata* * Não mata vampiros & afins * Exige trabalho duro e comprometimento

27. P D C A Plan, Do, Check, Act

28. Planejamento

29. Execução

30. Checagem

31. Retrospectiva e melhoria contínua

32. O processo não é avaliado enquanto está rodando

33. Ciclo Scrum

34. Tipos de Processos

35. “ É típico adotar a abordagem de modelagem definida quando os mecanismos subjacentes pelos quais um processo opera são razoavelmente bem entendidos. Quando o processo é muito complexo para ser definido, a abordagem empírica é a escolha apropriada .” (Ogunnaike and Ray, Oxford University Press)

36. Processo definido vs Processo empírico

37. Desenvolvimento de software não é um processo que gera as mesmas saídas para as mesmas entradas

38. Processos empíricos

39. Complexos, caóticos ou seus detalhes ainda não são conhecidos

40. Atividades podem ser cíclicas e tem duração com muitas variações

41. É difícil estimar tempos de execução

43. Fixar a maior quantidade possível de parâmetros

44. Parâmetros de contexto Tempo, Esforço, Time Parâmetros de entrada Backlog, Prioridades, Estimativas Parâmetros de saída Objetivos, Critérios de avaliação

45. Exatamente o que Scrum faz!

46. Timeboxing!

47. Ciclo Scrum Fonte: http://www.mountaingoatsoftware.com/scrum

48. Papéis e Responsabilidades

49. Fonte: http://www.implementingscrum.com

50. Scrum tem poucos papéis ( não são cargos!): Product Owner, Team, Scrum Master

51. Scrum Master * *Mãe, quando eu crescer, quero ser Scrum Master.

52. Trabalhar com o Product Owner Cuidar do time Manter o processo funcionando Disseminar o Scrum Garantir comunicação

53. Product Owner * *Me dá, me dá, me dá, me dá!

54. Criar e compartilhar uma visão do projeto

55. Tomar decisões continuamente sobre os itens do product backlog

56. Escrever e priorizar itens de backlog

57. Validar software no final de cada Sprint

58. Estabelecer e manter o plano de entregas

59. Tomar decisões pensando no ROI do projeto responsável pelo lucro

60. Time * *Tudo eu! Tudo eu!

61. Responsabilidades: Estimar itens do backlog Se comprometer a entregar um incremento funcional de software Gerenciar o próprio progresso Auto organizados para entregar o que o PO quer

62. Times Scrum

63. Como são compostos: Cross functional, sem papéis Multidisciplinares Auto sustentáveis Todos os skills e habilidades necessárias para desenvolver o produto 7 pessoas (mais ou menos 2)

64. Cerimônias de Scrum: Sprint Planning 1 Sprint Planning 2 Daily Scrum Sprint Review Sprint Retrospective

65. Todas com timebox

66. Reunião de Estimativa : Preparação para o Sprint Planning Estimar baseado no tamanho, nunca em tempo Atualizar Product Backlog com as estimativas Importante para o PO criar o release plan

67. Sprint Planning 1 : Product Backlog Capacidade da equipe Condições do Negócio Revisa Considera Organiza Objetivos da Sprint Itens selecionados do backlog Aceite do time

68. Sprint Planning 2 : PO não precisa participar É um planejamento tático da equipe Os itens selecionados do Product Backlog são destrinchados em tarefas Sprint Backlog

69. Daily Scrum : Deve responder as três perguntas: O que fiz desde a ultima Daily Scrum? O que espero fazer até a próxima Daily Scrum? O que está impedindo o progresso? Impedimentos reportados aqui

70. Sprint Review : O que significa “ pronto ”? Team deve ter um critério técnico para indicar o que significa pronto! Incrementos funcionais são apresentados ao Product Owner e interessados

71. Consequências do Review : Estórias não concluídas voltam para o product backlog Atualizar Product Backlog para remover itens que a equipe implementou inadvertidamente Scrum Master trabalha para reformular a equipe

72. Consequências do Review : Product Backlog é repriorizado para tomar vantagem dos incrementos apresentados Decidir se haverá ou não outra Sprint

73. Sprint Retrospectives

74. O que aprendizado é

75. O que aprendizado não é

76. Cometer os mesmos erros e esperar resultados diferentes

77. Aprender é desapontar expectativas, mas não procure culpados

78. Diretiva Primária

79. “ Não importa o que descobrimos, nós entendemos e realmente acreditamos que cada um fez o melhor trabalho que pode considerando: O que era conhecido, suas habilidades, os recursos disponíveis e a situação no momento. ” (Kerth, Project Retrospectives, 2001)

80. Passos para a Retrospectiva

81. Saídas da Retrospectiva : Team Backlog (para ajustar o processo) Backlog de impedimentos (mudanças na empresa) Os backlogs devem ser ordenados por importância

82. Onde, Quando, Quem?

83. Quando as retrospectivas não funcionam

84. O facilitador controla demais a reunião

85. Little less conversation , more action, please

86. Conflito de interesses O formato é muito repetitivo O facilitador não se prepara Itens de ação mal formulados

87. A Visão do Produto + Product Backlog Planejamento Estratégico

88. O que é estratégia ? “ O conceito de estratégia, em grego strateegia , em latim strategi , em francês stratégie...”

89. Plano de ação a longo prazo criado pra atingir um objetivo

90. Planejamento Tático Selected Backlog + Sprint Backlog

91. Planejamento Tático é feito por Sprint

92. Em Scrum, as táticas são voláteis e de responsabilidade do time

93. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

94. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

95. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

96. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

97. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

98. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

99. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

100. Escrevendo Estórias

101. Testáveis Independentes NegociáveisValor para o clienteEstimáveisSmallTestáveis

102. TestáveisIndependentes Negociáveis Valor para o clienteEstimáveisSmallTestáveis

103. TestáveisIndependentesNegociáveis Valor para o cliente EstimáveisSmallTestáveis

104. TestáveisIndependentesNegociáveisValor para o cliente Estimáveis SmallTestáveisIndependentes

105. TestáveisIndependentesNegociáveisValor para o clienteEstimáveis Small TestáveisIndependentesNegociáveis

106. TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmall Testáveis IndependentesNegociáveis

107. Estórias com critérios de aceitação criam entendimento sobre quando a tarefa está pronta e ajudam o time a estimar e dividir a estória em tarefas

109. Scrum foca em tamanho e não em duração

110. Estimar em tamanho relativo é mais simples

111. Monitorando a Sprint

112. Sprint Burndown

113. Sprint Burn Up

114. Capacidade

115. Problemas comuns na adoção de Scrum

116. Product Owner pouco presente Sem Visão Sem release plan Sem product backlog

117. Product Backlog não é mantido Falta estimativa Falta priorização Falta acompanhamento

118. Se as cerimônias não acontecem Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontos

119. Sem retrospectivas Falta de uma maneira de melhorar o trabalho do time Mesmos erros acontecem sempre Impedimentos não são removidos

120. Decomposição do trabalho Planejamento a longo prazo Tempo para pesquisa e folga

121. O que é difícil em Scrum? Detalhes podem escapar se não for gerenciado corretamente Criar e manter um Product Backlog requer trabalho

122. Resumo da ópera

123. É um processo ágil para gerenciar e controlar trabalho. É um embrulho para as práticas existentes de engenharia. É uma aproximação coletiva , iterativa e incremental , onde requisitos mudam rapidamente.

124. Controla o caos de interesses e necessidades conflitantes .

125. É uma forma de detectar e remover obstáculos que entrem no desenvolvimento e entregas

126. É melhorar a comunicação e maximizar cooperação .

127. Não é uma metodologia completa e com o carimbo de um fornecedor

128. Não é um ataque à documentação ou às ferramentas case

129. Não confundir Scrum com XP: são diferentes, mas se complementam!

130. ?

131. Scrum Igor Macaúbas Marcos Pereira

132. [email_address]

133. http://delicious.com/macaubas http://delicious.com/marcospereira http://scrumalliance.org http://br.groups.yahoo.com/group/scrum-brasil/ http://macaubas.com http://marcospereira.wordpress.com/

134. Este trabalho está licenciado através da “ Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 3.0 Unported” Você pode: Copiar, distribuir, exibir e executar a obra Criar obras derivadas Sob as seguintes condições: Atribuição . Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante. Uso Não-Comercial . Você não pode utilizar esta obra com finalidades comerciais. Compartilhamento pela mesma Licença . Se você alterar, transformar, ou criar outra obra com base nesta, você somente poderá distribuir a obra resultante sob uma licença idêntica a esta Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha permissão do autor. Nothing in this license impairs or restricts the author's moral rights. http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt