O documento discute a metodologia ágil SCRUM para gestão de projetos de software. Ele apresenta os princípios e práticas do SCRUM, incluindo papéis como Product Owner e Scrum Master, cerimônias como planning, daily meetings e retrospectivas, e artefatos como product backlog e sprint backlog. O documento também discute como SCRUM pode ser combinado com outras metodologias como XP, Kanban e MPS.Br.

1. Gestão Ágil de ProjetosSCRUM

2. Quem é você?

3. poweredbySCRUM

4. VejaOuçaFale

5. Pontualidade e Presença

6. RoteiroDiscussão inicialMetodologias e processos ágeisSCRUMSCRUM + MPS.BrDiscussão final

7. “A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelomenos 50 anos. Elas tem sobrevivido ao seu tempo. Como resultado, estamos pregando, ensinando, e praticando políticas que estão cada vez mais desalinhadascom a realidade, e são contraprodutivas.”Peter Drucker (1909-2005)"Melhor é o mancebo pobre e sábio do que o rei velho e insensato, que não se deixa mais admoestar" Ec 4:13

8. Porque tudo isso agora?

10. Estatísticas do CHAOS Report

11. ExercícioJogos Estatísticos: Lotes de Produção x Produtividade

12. Metodologias e Processos ÁgeisXP | Extreme Programming (Kent Beck)FDD | FeatureDrivenDevelopment (Jeff DeLuca) DSDM | Dynamic System DevelopmentMethod (Dane Faulkner)SCRUM (Ken Schwaber) Adaptive Software Development (Jim Highsmith)Crystal (Alistair Cockburn)Lean Software Development (Mary Poppendieck)…

13. Manifesto ÁgilIndivíduos e interação entre elesmais que processos e ferramentasSoftware em funcionamentomais que documentação abrangenteColaboração com o clientemais que negociação de contratosResponder a mudançasmais que seguir um planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.© 2001 AgileAlliance. http://www.agilemanifesto.org

14. Princípios do Manifesto Ágil (1/3)Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.© 2001 AgileAlliance. http://www.agilemanifesto.org

15. Princípios do Manifesto Ágil (2/3)Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.Software funcional é a medida primária de progresso.Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.© 2001 AgileAlliance. http://www.agilemanifesto.org

16. Princípios do Manifesto Ágil (3/3)Contínua atenção à excelência técnica e bom design, aumenta a agilidade.Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.© 2001 AgileAlliance. http://www.agilemanifesto.org

17. Teoria por trás do pensamento ágilTheory of Constraints and Lean ThinkingComplex adaptive systems: a ciênciadaincertezaCognitive science: a naturezahumana do processo de tomada de decisãoEvolutionary psychology & anthropology: as origens da iteração social e a sua natureza

18. Porque usar metodologia ágil para projetos de software?“É 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.” (Ogunnaikeand Ray, Oxford UniversityPress)Desenvolvimento de software não é um processo que gera as mesmas saídas para as mesmas entradas

19. Fonte: DZoneRefcardz

20. TempoxROIxQualidadeFonte: RevistaMundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima

21. Eventos sobre AgileAgileNCR 2011 DoDAgileDevelopment

22. PDCA

23. SCRUM

24. SCRUMFramework !!!Metodologia.

25. Custodamudança no ScrumCost of changeDevelopment Life CycleScrum é flexível o bastanteparaacomodar as mudanças de requisitosfacilmente, semcausargrandescustosadicionais.WaterfallScrum permitemudanças a qualquer tempo

26. Desdequefora do ciclo do release

27. Scrum esperapreparadopelasmudançasCost of changeScrum Development Life CycleFonte: Agile Project Management with Scrum, Aditya Raj

28. EstatísticasFonte: Version One Agile Survey 2009

29. Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation

30. SP1SprintBacklogSP2Reunião DiáriaEstimativa24hsProdutoProductBacklogDesenvolvimentoSprint2 a 4 semanasReviewTestesVisão do ProdutoRetrospectivapowered by FábioMenezes (Peggasus)

31. SprintEm cada Sprint: planejamento, execução, acompanhamento, validação e análise de melhoriasAs reuniões diárias servem para o acompanhamento de metas e verificação de impedimentosPlanejamentoTático é feitoa cadaSprint

32. PapéisFonte: http://www.implementingscrum.com

33. ProductOwnerCria e compartilha a visão do projeto

34. Gerencia o product backlog

35. Representa stakeholders

36. Aceita/rejeitaresultados

37. Define/priorizafuncionalidades

38. Estabelece e mantém o plano de entregas

39. Tomadecisõespensando no ROI do projetoScrumMasterTrabalha com o productowner

40. Remove obstáculos

41. Evitainterferências

42. Mantémfocona meta da sprint

43. Garantecolaboração e comunicação

44. Guardião das práticas do scrum

45. O scrum master também é time

46. Pode ser:

47. Part-time ou total

48. Técnicoouadministrativo

49. GerenteoucoordenadorTime

50. TimeAuto-gerenciávelGerencia o próprio progressoMantém o foco no que o PO querGarante a qualidadeDesenvolve o processoDefine a distribuição interna das tarefasMultifuncional5 a 9 pessoasFulltimeEstima itens do backlogSe compromete na entrega de um incremento funcionalFoco na lista priorizada pelo PO e acordada com o timeDefine as tarefas que determinam o “COMO”Desenvolve o produto

51. O processo não é avaliado enquantoestá rodando

52. CerimôniasSprintPlanning 1SprintPlanning 2ReviewDaily MeetingsRetrospectiveEstimativa

53. Estimativa Preparação para o SprintPlanning

54. Estimar baseado no tamanho, nunca em tempo

55. Atualizar ProductBacklog com as estimativas

56. Importante para o PO criar o release planExercício.PlanningPoker

57. SprintPlanning 1Nível estratégicoPO apresenta o ProductBacklog priorizado já estimado pelo TimeO Time obtém o entendimento das históriasDiscussão sobre os critérios de aceitaçãoA equipe aprova as histórias com as quais se comprometerá a concluirO SprintBacklog é criadoDuração média de 3 horas

58. SprintPlanning 1ProductBacklogCapacidade da equipe Condições do NegócioObjetivos da SprintItens selecionados do backlogAceite do timeRevisaConsideraOrganiza

59. SprintPlanning 2Nível táticoPO não precisa participarO Time planeja como vai implementar cada históriaAs histórias são quebradas em tarefas

60. Daily Meeting O que fez ontem? O que fará hoje? Tem algum obstáculo?As respostas são compromissos!foto: http://www.tecmedia.com.br/blog/wp-content/uploads/2008/12/dsc00091.jpg

61. ReviewSoftware funcionando para o PO e interessados

62. Os resultados são aceitos ou rejeitados pelo PO

63. Toda equipe

64. Definição de “pronto”

65. Informal (no slides)

66. Retrospective O que devemos começar a fazer? O que precisamos parar de fazer?O que devemos continuar a fazer?"Loucura é fazer a mesma coisa e esperar um resultado diferente." Albert Einstein

67. Retrospective

68. Exercício.Negociação

69. ArtefatosProductBacklogSprintBacklogTaskboardBurn-downchartBurn-upchartImpedimentList

70. ProductBacklogEmergentePriorizado e estimadoMaior prioridade, mais detalhesQualquer um pode contribuirPriorização é tarefa do POSempre visívelAlinhado ao plano de negócios: (benefício + penalidade) / tamanho

71. SprintBacklogProduto da SP1Mantido pelo TimeO Time aloca o trabalhoExecutado na ordem definida pelo PONão deve mudarTudo deve ser entregue, e sem bugs

72. Taskboard

73. Burn-down e Burn-up

74. Exercício

75. Scrumofscrums

76. Scrum+XPPadronização de código

77. Testes automatizados

78. Controle de versão

79. TDD

80. Userstories

81. Refatoração

82. Integração contínua

83. Codificação em pares

84. Código compartilhadoScrum+Kanbam

85. O fator H (1/2)Características de um time ágil:Orientação ao valor proporcionado ao clienteDesenvolvimento das competências individuaisTimes pequenosAutodisciplina sustentávelIntensa colaboraçãoReduzido custo de transferência da informaçãoTempo reduzido para feedbackAprendizado e adaptação constantes

86. O fator H (2/2)Cinco estágios para o desenvolvimento de times (PMBOK)FormaçãoTempestadeNormaDesempenhoNova jornada

87. BenchmarkingBenchmarking simples (identificação)Benchmarking de líderes (Ex: Toyota e 5 meses de treinamento para todos os novos funcionários)Benchmarking da concorrência total (extrapole)POR OUTRO LADO, TODO CONCORRENTE É UM PARCEIRO EM POTENCIAL ... BASTA ENCONTRAR UM INTERESSE EM COMUM...Fonte: Aísa Pereira - www.engenhariadevendas.com.br

88. Déficit técnicoFonte: DZoneRefcardz

89. Erros comums em reuniões diáriasReuniões diárias a cada três diasReuniões com longa duração (+15 minutos)Reuniões diárias realizadas fora do ambiente de trabalho (ex.: sala de reuniões)Reunião diária como report ao ScrumMaster/Coach/LíderReuniões de 2 minutos (curtas demais)Detalhamento e explicações de soluções na reuniãoHorário flutuanteParticipação parcial na reuniãoFonte: DairtonBassi – Agile Brazil 2010

90. Erros comuns no burndownchartAusência ou abandonoBurndown para o ProductOwnerNão ajustar os planosFonte: DairtonBassi – Agile Brazil 2010

91. Erros comuns no papel do cliente/POSobreposição do papel com o ScrumMasterCliente com várias vozesEnvolvimento pontualFonte: DairtonBassi – Agile Brazil 2010

94. SCRUM + MPS.Br

95. SCRUM + MPS.Br

96. SCRUM + MPS.Br

97. SCRUM + MPS.Br

98. SCRUM + MPS.Br

99. SCRUM + MPS.Br

100. SCRUM + MPS.Br

101. SCRUM + MPS.Br

102. SCRUM + MPS.Br

103. SCRUM + MPS.Br

104. SCRUM + MPS.Br

105. SCRUM + MPS.Br

106. SCRUM + MPS.Br

107. SCRUM + MPS.Br

108. SCRUM + MPS.Br

109. SCRUM + MPS.Br

110. SCRUM + MPS.Br

111. ExercícioProjeto do avião

112. Problemas comuns na adoção de Scrum

113. Product Owner pouco presenteSem VisãoSem release planSem product backlogFonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

114. Product Backlog não é mantidoFalta estimativaFalta priorizaçãoFalta acompanhamentoFonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

115. Se as cerimônias nãoacontecem Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontosFonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

116. Sem retrospectivas Falta de uma maneira de melhorar o trabalho do timeMesmos erros acontecem sempre Impedimentos não são removidosFonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

117. O que é difícilem Scrum?Detalhes podem escapar se não for gerenciado corretamenteCriar e manter um ProductBacklog requer trabalhoFonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

118. Não é uma metodologia completa e com o carimbo de um fornecedorFonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation

119. Livros

120. Obrigado!Duas certezas sobre seu próximo projeto:O escopo vai mudarAlguma coisa vai dar errado

121. Este trabalhoestálicenciadoatravésda “Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 3.0 Unported”Vocêpode:Copiar, distribuir, exibir e executar a obraCriarobrasderivadasSob as seguintescondiçõ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 estaPara 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 thislicenseimpairsorrestrictstheauthor's moral rights.http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt