Gestão ágil de projetos 2015

467 visualizações

Publicada em

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
467
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
16
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Fim da aula 1
  • Fim da primeira aula
  • Para refletir depois de ações efetivas. Da reflexão vêm ações mais efetivas ainda. Drucker
  • Fim da aula 2
  • Fim da aula 3
  • Fim da segunda aula
  • Gestão ágil de projetos 2015

    1. 1. Gerenciamento de projetos Complexos Sob a Perspectiva da Gestão Ágil Um olhar sobre o SCRUM
    2. 2. powered by inaniaverba@bol.com.br
    3. 3. Quem é você?
    4. 4. Veja Ouça Fale
    5. 5. Participação, Pontualidade e Presença O aluno deverá ter no mínimo 75% de frequência na disciplina. 40% - avaliação integrada (Banco de Questões) 40% - Aferição e participação em debate de estudos de caso e artigos 20% - avaliação docente
    6. 6. Roteiro • Definir projetos complexos • Caracterizar projetos complexos • Contextualizar a gerência de projetos com foco em complexidade – justificar a procura por novas abordagens • Apresentar o paradigma de gerenciamento de projetos ágeis como uma alternativa viável para projetos complexos • Apresentar o SCRUM e desenvolver uma discussão em torno do framework • Promover uma experimentação com o SCRUM • Discussão final “Pois qual de vós, querendo edificar uma torre, não se assenta primeiro a fazer as contas dos gastos, para ver se tem com que a acabar?” Lc 14:28
    7. 7. Definindo Projetos Complexos • Complexo x Complicado: – Um projeto complicado sempre tem como reduzir para uma situação mais administrável, conforme competência, esforço e perícia aplicados; – Um projeto complexo não pode ser reduzido; • Definição de Complexidade para Projetos: – Elevado número de variáveis – Alto grau de multidisciplinaridade – Duração e diversidade de informações MAXIMIANO, A. C. A. Novos modelos de organização de projetos. Simpósio da gestão da inovação tecnológica. São Paulo, 1996.
    8. 8. Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013
    9. 9. Fatores que levam à complexidade • Diversidade cultural • Alterações de Escopo • Prazo longo • Riscos envolvidos • Elevado grau de incerteza OLIVEIRA, R. C. F. Gerenciamento de Projetos e a Aplicação da Análise de Earned Value em Grandes projetos. Dissertação (Mestrado) - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia Naval e Oceânica, 2003.
    10. 10. Categorias, conforme PMI • De acordo com o guia: NAVIGATING COMPLEXITY:A PRACTICE GUIDE, PMI, 2014 – Comportamento Humano: políticas, comunicações e desenho das organizações – Comportamento do Sistema: conectividade e inter-dependências – Ambiguidade: incerteza, mudanças imprevisíveis
    11. 11. Dificuldades Pesquisa PMI Brasil: maiores dificuldades enfrentadas pelos projetos
    12. 12. A Complexidade e a Incerteza Fonte: Shenhar; Wideman, 2000.
    13. 13. Fonte: DZone Refcardz
    14. 14. Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013
    15. 15. Porque tudo isso agora?
    16. 16. “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) "Melhor é o mancebo pobre e sábio do que o rei velho e insensato, que não se deixa mais admoestar" Ec 4:13
    17. 17. Estatísticas do The Standish Group
    18. 18. Estudo do PMI sobre Complexidade • Estudo patrocinado pelo PMI (CICMIL et al, 2009): – Discrepância entre “a melhor prática de GP” e o que realmente tem funcionado na prática; – Observações das reais consequências em seguir as prescrições by the book em GP; – Necessidade de uma nova conceituação e concepção sobre projetos e complexidade de projetos na prática.
    19. 19. Teoria de Gestão de Projetos • “A teoria implícita de gerenciamento de projetos está obsoleta.”, Gregory A. Howell e Lauri Koskela, 2002.
    20. 20. Teoria de Gestão de Projetos – cont. • Teoria de Projetos – Visão de transformação: entrada+processo+saída – Gerenciado por Princípios, como a decomposição total • Teoria de Administração – Gestão baseada no planejamento: criação, revisão e implementação de planos – Modelo de execução: tarefas planejadas executadas por notificação de permissão para iniciar – Modelo de termostato (mensuração): padronizar, medir e corrigir
    21. 21. Nova proposta (Howell e Koskela)
    22. 22. Last Planner System (1992) • Motivação: 54% de PPC semanal; • Criado por Glen Ballard, fruto de pesquisa construtiva em obras, traz novas teorias: – Gestão como organização, ao invés de gestão como planejamento; – Solicitações e compromissos em vez de ordens e autorizações; – Controle direcionado versus o modelo de termostato.
    23. 23. LPS – cont. • Cada trabalhador tem o dever e o direito de parar o fluxo para evitar defeitos: – Problemas emergiram, exigiu aprendizado; • Plano meticuloso do mestre de obras: eram suas promessas para a próxima equipe; • Redução de desperdícios e foco na entrega de valor, segundo a visão do cliente; • O realizador do plano tem a opção de dizer “não”: – Parar a linha de trabalho, aprender e melhorar; • Phase Pull Planning: – Todos responsáveis pelo marco trabalham juntos; • Integrated Project Delivery: – Possibilidade de mover dinheiro entre contratos;
    24. 24. Lean Construction • Cinco mudanças de paradigma (Koskela, 2002): 1. Da otimização (CPM) à eliminação de desperdício; 2. Da dedução à indução; 3. Da análise (reducionismo) à síntese (sinergia); 4. Da pesquisa descritiva, explanatória e normativa para “design science research”; • Partindo de um problema de ordem prática, desenvolve- se uma solução prática e avança a teoria em paralelo; 5. Da visão puramente centrada na produção para uma consideração dos aspectos sociais e econômicos. Fonte: Revista MundoPM, Dez/2014 & Jan/2015, p.36
    25. 25. Exercício Jogos Estatísticos: Lotes de Produção x Produtividade
    26. 26. Porque usar metodologia ágil para projetos complexos? • “É 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) • Exemplo: Desenvolvimento de software não éum processo que gera as mesmas saídas para as mesmas entradas
    27. 27. VIDEO
    28. 28. Manifesto Ágil • Indivíduos e interação entre eles mais que processos e ferramentas • Software em funcionamento mais que documentação abrangente • Colaboração com o cliente mais que negociação de contratos • Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. © 2001 Agile Alliance. http://www.agilemanifesto.org
    29. 29. 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 diariamente, durante todo o curso do projeto. © 2001 Agile Alliance. http://www.agilemanifesto.org
    30. 30. 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 Agile Alliance. http://www.agilemanifesto.org
    31. 31. 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 Agile Alliance. http://www.agilemanifesto.org
    32. 32. Teoria por trás do pensamento ágil • Theory of Constraints: perspectiva logística • Lean Thinking (Toyota-1940): eliminando disperdícios • Complex adaptive systems: a ciência da incerteza • Cognitive science: a natureza humana do processo de tomada de decisão • Evolutionary psychology & anthropology: as origens da iteração social e a sua natureza
    33. 33. Metodologias e Processos Ágeis • XP | Extreme Programming (Kent Beck) • FDD | Feature Driven Development (Jeff DeLuca) • DSDM | Dynamic System Development Method (Dane Faulkner, 1995) • SCRUM (Ken Schwaber) • Adaptive Software Development (Jim Highsmith) • Crystal (Alistair Cockburn) • Lean Software Development (Mary Poppendieck) • …
    34. 34. Tempo x ROI x Qualidade Fonte: Revista MundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima
    35. 35. Eventos sobre Agile DoDAgileDevelopment
    36. 36. PDCA Plan DoCheck Act Deming, 1939
    37. 37. Exercício Scrum Game
    38. 38. SCRUM
    39. 39. SCRUM • Palavra usada no Rugby para descrever uma formação: “O scrum é o meio de reiniciar o jogo após uma interrupção que tenha sido causada por uma infração leve às Leis (um passe para frente ou uma bola derrubada) ou por que a bola não pode continuar a ser jogada em um ruck ou maul. O scrum serve para concentrar todos os forwards e os médios scrum em um local do campo, proporcionando a oportunidade para os três-quartos prepararem um ataque usando o espaço criado em outro lugar” Fonte: Guia de Principiantes do Rugby Union. Disponivel em : http://www.sharklion.com/proyectos/cbru/main/Download/IRB_PTBR.pdf
    40. 40. VIDEO
    41. 41. SCRUM Framework !!! Metodologia.
    42. 42. Fundamentação Teórica Subjacente Fonte: Revista MundoPM, Ago & Set /2014, p. 70
    43. 43. Custo da mudança no Scrum Development Life Cycle Costofchange Scrum é flexível o bastante para acomodar as mudanças de requisitos facilmente, sem causar grandes custos adicionais. • Scrum permite mudanças a qualquer tempo • Desde que fora do ciclo do release • Scrum espera preparado pelas mudanças Scrum Development Life Cycle Costofchange Waterfall Fonte: Agile Project Management with Scrum, Aditya Raj
    44. 44. Estatísticas Fonte: Version One Agile Survey 2009
    45. 45. Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation
    46. 46. Visão do Produto Product Backlog Estimativa SP1 SP2Sprint Backlog Desenvolvimento Testes Sprint 2 a 4 semanas Reunião Diária 24hs Review Produto Retrospectiva powered by Fábio Menezes (Peggasus)
    47. 47. Sprint Planejamento Tático é feito a cada 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
    48. 48. Papéis Fonte: http://www.implementingscrum.com
    49. 49. Product Owner • Cria e compartilha a visão do projeto • Gerencia o product backlog • Representa stakeholders • Aceita/rejeita resultados • Define/prioriza funcionalidades • Estabelece e mantém o plano de entregas • Toma decisões pensando no ROI do projeto
    50. 50. Scrum Master • Trabalha com o product owner • Remove obstáculos • Evita interferências • Mantém foco na meta da sprint • Garante colaboração e comunicação • Guardião das práticas do scrum • O scrum master também é time • Pode ser: • Part-time ou total • Técnico ou administrativo • Gerente ou coordenador
    51. 51. VIDEO
    52. 52. Time
    53. 53. 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
    54. 54. O processo não é avaliado enquanto está rodando
    55. 55. Cerimônias Sprint Planning 1 Sprint Planning 2 Review Retrospective Estimativa Daily Meetings
    56. 56. 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
    57. 57. Exercício . Planning Poker
    58. 58. Exercício . Planning Poker
    59. 59. Sprint Planning 1 • Nível estratégico • PO apresenta o Product Backlog 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 Sprint Backlog é criado • Duração média de 3 horas
    60. 60. 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
    61. 61. Sprint Planning 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
    62. 62. foto: http://www.tecmedia.com.br/blog/wp-content/uploads/2008/12/dsc00091.jpg O que fez ontem? O que fará hoje? Tem algum obstáculo? As respostas são compromissos! Daily Meeting
    63. 63. VIDEO
    64. 64. Review • 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)
    65. 65. Retrospective "Loucura é fazer a mesma coisa e esperar um resultado diferente." Albert Einstein O que devemos começar a fazer? O que precisamos parar de fazer? O que devemos continuar a fazer?
    66. 66. Retrospective
    67. 67. Exercício . Negociação
    68. 68. Artefatos Product Backlog Sprint Backlog Burn-down chart Burn-up chart Taskboard Impediment List
    69. 69. 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: (benefício + penalidade) / tamanho
    70. 70. Sprint Backlog 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
    71. 71. Taskboard
    72. 72. Burn-down e Burn-up
    73. 73. Scrum of scrums
    74. 74. Scrum + XP • Padronização de código • Testes automatizados • Controle de versão • TDD • User stories • Refatoração • Integração contínua • Codificação em pares • Código compartilhado
    75. 75. Scrum + Kanbam
    76. 76. O fator H (1/3) • 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
    77. 77. O fator H (2/3) • Cinco estágios para o desenvolvimento de times (PMBOK) – Formação – Tempestade – Norma – Desempenho – Nova jornada
    78. 78. O fator H (3/3) Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013 • Competências do GP em projetos complexos:
    79. 79. 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
    80. 80. Déficit técnico Fonte: DZone Refcardz
    81. 81. 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 Scrum Master/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: Dairton Bassi – Agile Brazil 2010
    82. 82. Erros comuns no burn down chart • Ausência ou abandono • Burn down para o Product Owner • Não ajustar os planos Fonte: Dairton Bassi – Agile Brazil 2010
    83. 83. Erros comuns no papel do cliente/PO • Sobreposição do papel com o Scrum Master • Cliente com várias vozes • Envolvimento pontual Fonte: Dairton Bassi – Agile Brazil 2010
    84. 84. Exercício Projeto do avião
    85. 85. Problemas comuns na adoção de Scrum
    86. 86. Product Owner pouco presente Sem Visão Sem release plan Sem product backlog
    87. 87. Product Backlog não é mantido Falta estimativa Falta priorização Falta acompanhamento Fonte: http://www.slideshare.net/macaubas/seminario-scrum-pr
    88. 88. Se as cerimônias não acontecem Falta planejamento Falta comprometimento para entregas PO pode aceitar itens que não estão prontos Fonte: http://www.slideshare.net/macaubas/seminario-scrum-pr
    89. 89. 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-pr
    90. 90. O que é difícil em 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-pr
    91. 91. Não é uma metodologia completa e com o carimbo de um fornecedor Fonte: http://www.slideshare.net/macaubas/seminario-scrum-pr
    92. 92. Livros
    93. 93. Obrigado! Duas certezas sobre seu próximo projeto: 1. O escopo vai mudar 2. Alguma coisa vai dar errado
    94. 94. 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

    ×