Gestão Ágil de Projetos<br />SCRUM<br />
Quem é você?<br />
poweredby<br />SCRUM<br />
Veja<br />Ouça<br />Fale<br />
Pontualidade e Presença<br />
Roteiro<br />Discussão inicial<br />Metodologias e processos ágeis<br />SCRUM<br />SCRUM + MPS.Br<br />Discussão final<br />
	“A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelomenos 50 anos. Elas tem sobrevivido ao...
Porque tudo isso agora?<br />
Estatísticas do CHAOS Report<br />
ExercícioJogos Estatísticos: Lotes de Produção x Produtividade<br />
Metodologias e Processos Ágeis<br />XP | Extreme Programming (Kent Beck)<br />FDD | FeatureDrivenDevelopment (Jeff DeLuca)...
Manifesto Ágil<br />Indivíduos e interação entre elesmais que processos e ferramentas<br />Software em funcionamentomais q...
Princípios do Manifesto Ágil (1/3)<br />Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e cont...
Princípios do Manifesto Ágil (2/3)<br />Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e sup...
Princípios do Manifesto Ágil (3/3)<br />Contínua atenção à excelência técnica e bom design, aumenta a agilidade.<br />Simp...
Teoria por trás do pensamento ágil<br />Theory of Constraints and Lean Thinking<br />Complex adaptive systems: a ciênciada...
Porque usar metodologia ágil para projetos de software?<br />“É típico adotar a abordagem de modelagem definida quando os ...
Fonte: DZoneRefcardz<br />
TempoxROIxQualidade<br />Fonte: RevistaMundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima<br />
Eventos sobre Agile<br />AgileNCR 2011 <br />DoDAgileDevelopment<br />
PDCA<br />
SCRUM<br />
SCRUM<br />Framework !!!<br />Metodologia.<br />
Custodamudança no Scrum<br />Cost of change<br />Development Life Cycle<br />Scrum é flexível o bastanteparaacomodar as mu...
Desdequefora do ciclo do release
Scrum esperapreparadopelasmudanças</li></ul>Cost of change<br />Scrum Development Life Cycle<br />Fonte: Agile Project Man...
Estatísticas<br />Fonte: Version One Agile Survey 2009<br />
Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation<br />
SP1<br />SprintBacklog<br />SP2<br />Reunião Diária<br />Estimativa<br />24hs<br />Produto<br />ProductBacklog<br />Desenv...
Sprint<br />Em cada Sprint: planejamento, execução, acompanhamento, validação e análise de melhorias<br />As reuniões diár...
Papéis<br />Fonte: http://www.implementingscrum.com<br />
ProductOwner<br /><ul><li>Cria e compartilha a visão do projeto
Gerencia o product backlog
Representa stakeholders
Aceita/rejeitaresultados
Define/priorizafuncionalidades
Estabelece e mantém o plano de entregas
Tomadecisõespensando no ROI do projeto</li></li></ul><li>ScrumMaster<br /><ul><li>Trabalha com o productowner
Remove obstáculos
Evitainterferências
Mantémfocona meta da sprint
Garantecolaboração e comunicação
Guardião das práticas do scrum
O scrum master também é time
Pode ser:
Part-time ou total
Técnicoouadministrativo
Gerenteoucoordenador</li></li></ul><li>Time<br />
Time<br />Auto-gerenciável<br />Gerencia o próprio progresso<br />Mantém o foco no que o PO quer<br />Garante a qualidade<...
O processo não é avaliado enquantoestá rodando<br />
Cerimônias<br />SprintPlanning 1<br />SprintPlanning 2<br />Review<br />Daily Meetings<br />Retrospective<br />Estimativa<...
Estimativa<br /><ul><li> Preparação para o SprintPlanning
Estimar baseado no tamanho, nunca em tempo
Atualizar ProductBacklog com as estimativas
Importante para o PO criar o release plan</li></li></ul><li>Exercício.PlanningPoker<br />
SprintPlanning 1<br />Nível estratégico<br />PO apresenta o ProductBacklog priorizado já estimado pelo Time<br />O Time ob...
SprintPlanning 1<br />ProductBacklog<br />Capacidade da equipe  <br />Condições do Negócio<br />Objetivos da Sprint<br />I...
SprintPlanning 2<br />Nível tático<br />PO não precisa participar<br />O Time planeja como vai implementar cada história<b...
Daily Meeting<br />  O que fez ontem?<br />  O que fará hoje?<br />  Tem algum obstáculo?<br />As respostas são compromiss...
Review<br /><ul><li>Software funcionando para o PO e interessados
Os resultados são aceitos ou rejeitados pelo PO
Toda equipe
Definição de “pronto”
Informal (no slides)</li></li></ul><li>
Retrospective<br />  O que devemos começar a fazer?<br />  O que precisamos parar de fazer?<br />O que devemos continuar a...
Retrospective<br />
Exercício.Negociação<br />
Artefatos<br />ProductBacklog<br />SprintBacklog<br />Taskboard<br />Burn-downchart<br />Burn-upchart<br />ImpedimentList<...
ProductBacklog<br />Emergente<br />Priorizado e estimado<br />Maior prioridade, mais detalhes<br />Qualquer um pode contri...
SprintBacklog<br />Produto da SP1<br />Mantido pelo Time<br />O Time aloca o trabalho<br />Executado na ordem definida pel...
Taskboard<br />
Burn-down e Burn-up<br />
Exercício<br />
Scrumofscrums<br />
Scrum+XP<br /><ul><li>Padronização de código
Testes automatizados
Controle de versão
TDD
Userstories
Refatoração
Integração contínua
Codificação em pares
Código compartilhado</li></li></ul><li>Scrum+Kanbam<br />
O fator H (1/2)<br />Características de um time ágil:<br />Orientação ao valor proporcionado ao cliente<br />Desenvolvimen...
O fator H (2/2)<br />Cinco estágios para o desenvolvimento de times (PMBOK)<br />Formação<br />Tempestade<br />Norma<br />...
Benchmarking<br />Benchmarking simples (identificação)<br />Benchmarking de líderes (Ex: Toyota e 5 meses de treinamento p...
Déficit técnico<br />Fonte: DZoneRefcardz<br />
Erros comums em reuniões diárias<br />Reuniões diárias a cada três dias<br />Reuniões com longa duração (+15 minutos)<br /...
Erros comuns no burndownchart<br />Ausência ou abandono<br />Burndown para o ProductOwner<br />Não ajustar os planos<br />...
Erros comuns no papel do cliente/PO<br />Sobreposição do papel com o ScrumMaster<br />Cliente com várias vozes<br />Envolv...
Upcoming SlideShare
Loading in...5
×

Gestão Ágil de Projetos

1,086

Published on

Published in: Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,086
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
82
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Gestão Ágil de Projetos

  1. 1. Gestão Ágil de Projetos<br />SCRUM<br />
  2. 2. Quem é você?<br />
  3. 3. poweredby<br />SCRUM<br />
  4. 4. Veja<br />Ouça<br />Fale<br />
  5. 5. Pontualidade e Presença<br />
  6. 6. Roteiro<br />Discussão inicial<br />Metodologias e processos ágeis<br />SCRUM<br />SCRUM + MPS.Br<br />Discussão final<br />
  7. 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.”<br />Peter Drucker (1909-2005)<br />"Melhor é o mancebo pobre e sábio do que o rei velho e insensato, que não se deixa mais admoestar" Ec 4:13<br />
  8. 8. Porque tudo isso agora?<br />
  9. 9.
  10. 10. Estatísticas do CHAOS Report<br />
  11. 11. ExercícioJogos Estatísticos: Lotes de Produção x Produtividade<br />
  12. 12. Metodologias e Processos Ágeis<br />XP | Extreme Programming (Kent Beck)<br />FDD | FeatureDrivenDevelopment (Jeff DeLuca) <br />DSDM | Dynamic System DevelopmentMethod (Dane Faulkner)<br />SCRUM (Ken Schwaber) <br />Adaptive Software Development (Jim Highsmith)<br />Crystal (Alistair Cockburn)<br />Lean Software Development (Mary Poppendieck)<br />…<br />
  13. 13. Manifesto Ágil<br />Indivíduos e interação entre elesmais que processos e ferramentas<br />Software em funcionamentomais que documentação abrangente<br />Colaboração com o clientemais que negociação de contratos<br />Responder a mudançasmais que seguir um plano<br />Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.<br />© 2001 AgileAlliance. http://www.agilemanifesto.org<br />
  14. 14. Princípios do Manifesto Ágil (1/3)<br />Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.<br />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.<br />Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.<br />Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.<br />© 2001 AgileAlliance. http://www.agilemanifesto.org<br />
  15. 15. Princípios do Manifesto Ágil (2/3)<br />Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.<br />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.<br />Software funcional é a medida primária de progresso.<br />Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.<br />© 2001 AgileAlliance. http://www.agilemanifesto.org<br />
  16. 16. Princípios do Manifesto Ágil (3/3)<br />Contínua atenção à excelência técnica e bom design, aumenta a agilidade.<br />Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.<br />As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.<br />Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.<br />© 2001 AgileAlliance. http://www.agilemanifesto.org<br />
  17. 17. Teoria por trás do pensamento ágil<br />Theory of Constraints and Lean Thinking<br />Complex adaptive systems: a ciênciadaincerteza<br />Cognitive science: a naturezahumana do processo de tomada de decisão<br />Evolutionary psychology & anthropology: as origens da iteração social e a sua natureza <br />
  18. 18. Porque usar metodologia ágil para projetos de software?<br />“É 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)<br />Desenvolvimento de software não é um processo que gera as mesmas saídas para as mesmas entradas<br />
  19. 19. Fonte: DZoneRefcardz<br />
  20. 20. TempoxROIxQualidade<br />Fonte: RevistaMundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima<br />
  21. 21. Eventos sobre Agile<br />AgileNCR 2011 <br />DoDAgileDevelopment<br />
  22. 22. PDCA<br />
  23. 23. SCRUM<br />
  24. 24. SCRUM<br />Framework !!!<br />Metodologia.<br />
  25. 25. Custodamudança no Scrum<br />Cost of change<br />Development Life Cycle<br />Scrum é flexível o bastanteparaacomodar as mudanças de requisitosfacilmente, semcausargrandescustosadicionais.<br />Waterfall<br /><ul><li>Scrum permitemudanças a qualquer tempo
  26. 26. Desdequefora do ciclo do release
  27. 27. Scrum esperapreparadopelasmudanças</li></ul>Cost of change<br />Scrum Development Life Cycle<br />Fonte: Agile Project Management with Scrum, Aditya Raj<br />
  28. 28. Estatísticas<br />Fonte: Version One Agile Survey 2009<br />
  29. 29. Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation<br />
  30. 30. SP1<br />SprintBacklog<br />SP2<br />Reunião Diária<br />Estimativa<br />24hs<br />Produto<br />ProductBacklog<br />Desenvolvimento<br />Sprint<br />2 a 4 semanas<br />Review<br />Testes<br />Visão do Produto<br />Retrospectiva<br />powered by FábioMenezes (Peggasus) <br />
  31. 31. Sprint<br />Em cada Sprint: planejamento, execução, acompanhamento, validação e análise de melhorias<br />As reuniões diárias servem para o acompanhamento de metas e verificação de impedimentos<br />PlanejamentoTático é feitoa cadaSprint<br />
  32. 32. Papéis<br />Fonte: http://www.implementingscrum.com<br />
  33. 33. ProductOwner<br /><ul><li>Cria e compartilha a visão do projeto
  34. 34. Gerencia o product backlog
  35. 35. Representa stakeholders
  36. 36. Aceita/rejeitaresultados
  37. 37. Define/priorizafuncionalidades
  38. 38. Estabelece e mantém o plano de entregas
  39. 39. Tomadecisõespensando no ROI do projeto</li></li></ul><li>ScrumMaster<br /><ul><li>Trabalha com o productowner
  40. 40. Remove obstáculos
  41. 41. Evitainterferências
  42. 42. Mantémfocona meta da sprint
  43. 43. Garantecolaboração e comunicação
  44. 44. Guardião das práticas do scrum
  45. 45. O scrum master também é time
  46. 46. Pode ser:
  47. 47. Part-time ou total
  48. 48. Técnicoouadministrativo
  49. 49. Gerenteoucoordenador</li></li></ul><li>Time<br />
  50. 50. Time<br />Auto-gerenciável<br />Gerencia o próprio progresso<br />Mantém o foco no que o PO quer<br />Garante a qualidade<br />Desenvolve o processo<br />Define a distribuição interna das tarefas<br />Multifuncional<br />5 a 9 pessoas<br />Fulltime<br />Estima itens do backlog<br />Se compromete na entrega de um incremento funcional<br />Foco na lista priorizada pelo PO e acordada com o time<br />Define as tarefas que determinam o “COMO”<br />Desenvolve o produto<br />
  51. 51. O processo não é avaliado enquantoestá rodando<br />
  52. 52. Cerimônias<br />SprintPlanning 1<br />SprintPlanning 2<br />Review<br />Daily Meetings<br />Retrospective<br />Estimativa<br />
  53. 53. Estimativa<br /><ul><li> Preparação para o SprintPlanning
  54. 54. Estimar baseado no tamanho, nunca em tempo
  55. 55. Atualizar ProductBacklog com as estimativas
  56. 56. Importante para o PO criar o release plan</li></li></ul><li>Exercício.PlanningPoker<br />
  57. 57. SprintPlanning 1<br />Nível estratégico<br />PO apresenta o ProductBacklog priorizado já estimado pelo Time<br />O Time obtém o entendimento das histórias<br />Discussão sobre os critérios de aceitação<br />A equipe aprova as histórias com as quais se comprometerá a concluir<br />O SprintBacklog é criado<br />Duração média de 3 horas<br />
  58. 58. SprintPlanning 1<br />ProductBacklog<br />Capacidade da equipe <br />Condições do Negócio<br />Objetivos da Sprint<br />Itens selecionados do backlog<br />Aceite do time<br />Revisa<br />Considera<br />Organiza<br />
  59. 59. SprintPlanning 2<br />Nível tático<br />PO não precisa participar<br />O Time planeja como vai implementar cada história<br />As histórias são quebradas em tarefas<br />
  60. 60. Daily Meeting<br /> O que fez ontem?<br /> O que fará hoje?<br /> Tem algum obstáculo?<br />As respostas são compromissos!<br />foto: http://www.tecmedia.com.br/blog/wp-content/uploads/2008/12/dsc00091.jpg<br />
  61. 61. Review<br /><ul><li>Software funcionando para o PO e interessados
  62. 62. Os resultados são aceitos ou rejeitados pelo PO
  63. 63. Toda equipe
  64. 64. Definição de “pronto”
  65. 65. Informal (no slides)</li></li></ul><li>
  66. 66. Retrospective<br /> O que devemos começar a fazer?<br /> O que precisamos parar de fazer?<br />O que devemos continuar a fazer?<br />"Loucura é fazer a mesma coisa e esperar um resultado diferente." Albert Einstein<br />
  67. 67. Retrospective<br />
  68. 68. Exercício.Negociação<br />
  69. 69. Artefatos<br />ProductBacklog<br />SprintBacklog<br />Taskboard<br />Burn-downchart<br />Burn-upchart<br />ImpedimentList<br />
  70. 70. ProductBacklog<br />Emergente<br />Priorizado e estimado<br />Maior prioridade, mais detalhes<br />Qualquer um pode contribuir<br />Priorização é tarefa do PO<br />Sempre visível<br />Alinhado ao plano de negócios: <br />(benefício + penalidade) / tamanho<br />
  71. 71. SprintBacklog<br />Produto da SP1<br />Mantido pelo Time<br />O Time aloca o trabalho<br />Executado na ordem definida pelo PO<br />Não deve mudar<br />Tudo deve ser entregue, e sem bugs<br />
  72. 72. Taskboard<br />
  73. 73. Burn-down e Burn-up<br />
  74. 74. Exercício<br />
  75. 75. Scrumofscrums<br />
  76. 76. Scrum+XP<br /><ul><li>Padronização de código
  77. 77. Testes automatizados
  78. 78. Controle de versão
  79. 79. TDD
  80. 80. Userstories
  81. 81. Refatoração
  82. 82. Integração contínua
  83. 83. Codificação em pares
  84. 84. Código compartilhado</li></li></ul><li>Scrum+Kanbam<br />
  85. 85. O fator H (1/2)<br />Características de um time ágil:<br />Orientação ao valor proporcionado ao cliente<br />Desenvolvimento das competências individuais<br />Times pequenos<br />Autodisciplina sustentável<br />Intensa colaboração<br />Reduzido custo de transferência da informação<br />Tempo reduzido para feedback<br />Aprendizado e adaptação constantes<br />
  86. 86. O fator H (2/2)<br />Cinco estágios para o desenvolvimento de times (PMBOK)<br />Formação<br />Tempestade<br />Norma<br />Desempenho<br />Nova jornada<br />
  87. 87. Benchmarking<br />Benchmarking simples (identificação)<br />Benchmarking de líderes (Ex: Toyota e 5 meses de treinamento para todos os novos funcionários)<br />Benchmarking da concorrência total (extrapole)<br />POR OUTRO LADO, TODO CONCORRENTE É UM PARCEIRO EM POTENCIAL ... BASTA ENCONTRAR UM INTERESSE EM COMUM...<br />Fonte: Aísa Pereira - www.engenhariadevendas.com.br<br />
  88. 88. Déficit técnico<br />Fonte: DZoneRefcardz<br />
  89. 89. Erros comums em reuniões diárias<br />Reuniões diárias a cada três dias<br />Reuniões com longa duração (+15 minutos)<br />Reuniões diárias realizadas fora do ambiente de trabalho (ex.: sala de reuniões)<br />Reunião diária como report ao ScrumMaster/Coach/Líder<br />Reuniões de 2 minutos (curtas demais)<br />Detalhamento e explicações de soluções na reunião<br />Horário flutuante<br />Participação parcial na reunião<br />Fonte: DairtonBassi – Agile Brazil 2010<br />
  90. 90. Erros comuns no burndownchart<br />Ausência ou abandono<br />Burndown para o ProductOwner<br />Não ajustar os planos<br />Fonte: DairtonBassi – Agile Brazil 2010<br />
  91. 91. Erros comuns no papel do cliente/PO<br />Sobreposição do papel com o ScrumMaster<br />Cliente com várias vozes<br />Envolvimento pontual<br />Fonte: DairtonBassi – Agile Brazil 2010<br />
  92. 92.
  93. 93.
  94. 94. SCRUM + MPS.Br<br />
  95. 95. SCRUM + MPS.Br<br />
  96. 96. SCRUM + MPS.Br<br />
  97. 97. SCRUM + MPS.Br<br />
  98. 98. SCRUM + MPS.Br<br />
  99. 99. SCRUM + MPS.Br<br />
  100. 100. SCRUM + MPS.Br<br />
  101. 101. SCRUM + MPS.Br<br />
  102. 102. SCRUM + MPS.Br<br />
  103. 103. SCRUM + MPS.Br<br />
  104. 104. SCRUM + MPS.Br<br />
  105. 105. SCRUM + MPS.Br<br />
  106. 106. SCRUM + MPS.Br<br />
  107. 107. SCRUM + MPS.Br<br />
  108. 108. SCRUM + MPS.Br<br />
  109. 109. SCRUM + MPS.Br<br />
  110. 110. SCRUM + MPS.Br<br />
  111. 111. ExercícioProjeto do avião<br />
  112. 112. Problemas comuns na adoção de Scrum<br />
  113. 113. Product Owner pouco presente<br />Sem Visão<br />Sem release plan<br />Sem product backlog<br />Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation<br />
  114. 114. Product Backlog não é mantido<br />Falta estimativa<br />Falta priorização<br />Falta acompanhamento<br />Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation<br />
  115. 115. Se as cerimônias nãoacontecem<br /> Falta planejamento<br /> Falta comprometimento para entregas<br /> PO pode aceitar itens que não estão<br /> prontos<br />Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation<br />
  116. 116. Sem retrospectivas<br /> Falta de uma maneira de melhorar o <br /> trabalho do time<br />Mesmos erros acontecem sempre<br /> Impedimentos não são removidos<br />Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation<br />
  117. 117. O que é difícilem Scrum?<br />Detalhes podem escapar se não <br /> for gerenciado corretamente<br />Criar e manter um Product<br />Backlog requer trabalho<br />Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation<br />
  118. 118. Não é uma metodologia completa <br /> e com o carimbo de um fornecedor<br />Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation<br />
  119. 119. Livros<br />
  120. 120. Obrigado!<br />Duas certezas sobre seu próximo projeto:<br />O escopo vai mudar<br />Alguma coisa vai dar errado<br />
  121. 121. Este trabalhoestálicenciadoatravésda “Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 3.0 Unported”<br />Vocêpode:<br />Copiar, distribuir, exibir e executar a obra<br />Criarobrasderivadas<br />Sob as seguintescondições:<br />Atribuição. Você deve dar crédito ao autor original, da forma especificada pelo autor ou licenciante.<br />Uso Não-Comercial. Você não pode utilizar esta obra com finalidades comerciais. <br />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<br />Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. <br />Qualquer uma destas condições podem ser renunciadas, desde que Você obtenha permissão do autor.<br />Nothing in thislicenseimpairsorrestrictstheauthor's moral rights.<br />http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×