Gestão Ágil de Projetos
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Gestão Ágil de Projetos

on

  • 1,466 views

 

Statistics

Views

Total Views
1,466
Views on SlideShare
1,466
Embed Views
0

Actions

Likes
3
Downloads
75
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gestão Ágil de Projetos Presentation Transcript

  • 1. Gestão Ágil de Projetos
    SCRUM
  • 2. Quem é você?
  • 3. poweredby
    SCRUM
  • 4. Veja
    Ouça
    Fale
  • 5. Pontualidade e Presença
  • 6. Roteiro
    Discussão inicial
    Metodologias e processos ágeis
    SCRUM
    SCRUM + MPS.Br
    Discussã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?
  • 9.
  • 10. Estatísticas do CHAOS Report
  • 11. ExercícioJogos Estatísticos: Lotes de Produção x Produtividade
  • 12. Metodologias e Processos Ágeis
    XP | 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 Ágil
    Indivíduos e interação entre elesmais que processos e ferramentas
    Software em funcionamentomais que documentação abrangente
    Colaboração com o clientemais que negociação de contratos
    Responder a mudançasmais que seguir um plano
    Ou 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 ágil
    Theory of Constraints and Lean Thinking
    Complex adaptive systems: a ciênciadaincerteza
    Cognitive science: a naturezahumana do processo de tomada de decisão
    Evolutionary 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. TempoxROIxQualidade
    Fonte: RevistaMundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima
  • 21. Eventos sobre Agile
    AgileNCR 2011
    DoDAgileDevelopment
  • 22. PDCA
  • 23. SCRUM
  • 24. SCRUM
    Framework !!!
    Metodologia.
  • 25. Custodamudança no Scrum
    Cost of change
    Development Life Cycle
    Scrum é flexível o bastanteparaacomodar as mudanças de requisitosfacilmente, semcausargrandescustosadicionais.
    Waterfall
    • Scrum permitemudanças a qualquer tempo
    • 26. Desdequefora do ciclo do release
    • 27. Scrum esperapreparadopelasmudanças
    Cost of change
    Scrum Development Life Cycle
    Fonte: Agile Project Management with Scrum, Aditya Raj
  • 28. Estatísticas
    Fonte: Version One Agile Survey 2009
  • 29. Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation
  • 30. SP1
    SprintBacklog
    SP2
    Reunião Diária
    Estimativa
    24hs
    Produto
    ProductBacklog
    Desenvolvimento
    Sprint
    2 a 4 semanas
    Review
    Testes
    Visão do Produto
    Retrospectiva
    powered by FábioMenezes (Peggasus)
  • 31. Sprint
    Em cada Sprint: planejamento, execução, acompanhamento, validação e análise de melhorias
    As reuniões diárias servem para o acompanhamento de metas e verificação de impedimentos
    PlanejamentoTático é feitoa cadaSprint
  • 32. Papéis
    Fonte: http://www.implementingscrum.com
  • 33. ProductOwner
    • Cria 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 projeto
  • ScrumMaster
    • Trabalha 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. Gerenteoucoordenador
  • Time
  • 50. Time
    Auto-gerenciável
    Gerencia o próprio progresso
    Mantém o foco no que o PO quer
    Garante a qualidade
    Desenvolve o processo
    Define a distribuição interna das tarefas
    Multifuncional
    5 a 9 pessoas
    Fulltime
    Estima itens do backlog
    Se compromete na entrega de um incremento funcional
    Foco na lista priorizada pelo PO e acordada com o time
    Define as tarefas que determinam o “COMO”
    Desenvolve o produto
  • 51. O processo não é avaliado enquantoestá rodando
  • 52. Cerimônias
    SprintPlanning 1
    SprintPlanning 2
    Review
    Daily Meetings
    Retrospective
    Estimativa
  • 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 plan
  • Exercício.PlanningPoker
  • 57. SprintPlanning 1
    Nível estratégico
    PO apresenta o ProductBacklog priorizado já estimado pelo Time
    O Time obtém o entendimento das histórias
    Discussão sobre os critérios de aceitação
    A equipe aprova as histórias com as quais se comprometerá a concluir
    O SprintBacklog é criado
    Duração média de 3 horas
  • 58. SprintPlanning 1
    ProductBacklog
    Capacidade da equipe
    Condições do Negócio
    Objetivos da Sprint
    Itens selecionados do backlog
    Aceite do time
    Revisa
    Considera
    Organiza
  • 59. SprintPlanning 2
    Nível tático
    PO não precisa participar
    O Time planeja como vai implementar cada história
    As 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. Review
    • Software 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. Artefatos
    ProductBacklog
    SprintBacklog
    Taskboard
    Burn-downchart
    Burn-upchart
    ImpedimentList
  • 70. ProductBacklog
    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:
    (benefício + penalidade) / tamanho
  • 71. SprintBacklog
    Produto da SP1
    Mantido pelo Time
    O Time aloca o trabalho
    Executado na ordem definida pelo PO
    Não deve mudar
    Tudo deve ser entregue, e sem bugs
  • 72. Taskboard
  • 73. Burn-down e Burn-up
  • 74. Exercício
  • 75. Scrumofscrums
  • 76. Scrum+XP
    • Padronizaçã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 compartilhado
  • Scrum+Kanbam
  • 85. O fator H (1/2)
    Características de um time ágil:
    Orientação ao valor proporcionado ao cliente
    Desenvolvimento das competências individuais
    Times pequenos
    Autodisciplina sustentável
    Intensa colaboração
    Reduzido custo de transferência da informação
    Tempo reduzido para feedback
    Aprendizado e adaptação constantes
  • 86. O fator H (2/2)
    Cinco estágios para o desenvolvimento de times (PMBOK)
    Formação
    Tempestade
    Norma
    Desempenho
    Nova jornada
  • 87. Benchmarking
    Benchmarking 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écnico
    Fonte: DZoneRefcardz
  • 89. Erros comums em reuniões diárias
    Reuniões diárias a cada três dias
    Reuniõ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íder
    Reuniões de 2 minutos (curtas demais)
    Detalhamento e explicações de soluções na reunião
    Horário flutuante
    Participação parcial na reunião
    Fonte: DairtonBassi – Agile Brazil 2010
  • 90. Erros comuns no burndownchart
    Ausência ou abandono
    Burndown para o ProductOwner
    Não ajustar os planos
    Fonte: DairtonBassi – Agile Brazil 2010
  • 91. Erros comuns no papel do cliente/PO
    Sobreposição do papel com o ScrumMaster
    Cliente com várias vozes
    Envolvimento pontual
    Fonte: DairtonBassi – Agile Brazil 2010
  • 92.
  • 93.
  • 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 presente
    Sem Visão
    Sem release plan
    Sem product backlog
    Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation
  • 114. Product Backlog não é mantido
    Falta estimativa
    Falta priorização
    Falta acompanhamento
    Fonte: 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
    prontos
    Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation
  • 116. Sem retrospectivas
    Falta de uma maneira de melhorar o
    trabalho do time
    Mesmos erros acontecem sempre
    Impedimentos não são removidos
    Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation
  • 117. O que é difícilem Scrum?
    Detalhes podem escapar se não
    for gerenciado corretamente
    Criar e manter um Product
    Backlog requer trabalho
    Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation
  • 118. Não é uma metodologia completa
    e com o carimbo de um fornecedor
    Fonte: http://www.slideshare.net/macaubas/seminario-scrum-presentation
  • 119. Livros
  • 120. Obrigado!
    Duas certezas sobre seu próximo projeto:
    O escopo vai mudar
    Alguma 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 obra
    Criarobrasderivadas
    Sob 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 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 thislicenseimpairsorrestrictstheauthor's moral rights.
    http://creativecommons.org/licenses/by-nc-sa/3.0/deed.pt