Apresentacao feita por Igor Macaubas e Marcos Pereira sobre gestao ágil de Projetos com Scrum.

1. Scrum Gestão ágil de projetos

2. Igor Macaúbas e Marcos Pereira

4. Veja Ouça Fale

7. Mas por que ?

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!

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!

62. Times Scrum

65. Todas com timebox

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

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

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

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

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]