Gerenciamento de projetos
Complexos
Sob a Perspectiva da Gestão Ágil
Um olhar sobre o SCRUM
powered by inaniaverba@bol.com.br
Quem é
você?
Veja Ouça Fale
Participação, Pontualidade e Presença
O aluno deverá ter no mínimo 75% de
frequência na disciplina.
40% - avaliação integr...
Roteiro
• Definir projetos complexos
• Caracterizar projetos complexos
• Contextualizar a gerência de projetos com foco em...
Definindo Projetos Complexos
• Complexo x Complicado:
– Um projeto complicado sempre tem como reduzir
para uma situação ma...
Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013
Fatores que levam à complexidade
• Diversidade cultural
• Alterações de Escopo
• Prazo longo
• Riscos envolvidos
• Elevado...
Categorias, conforme PMI
• De acordo com o guia: NAVIGATING
COMPLEXITY:A PRACTICE GUIDE, PMI, 2014
– Comportamento Humano:...
Dificuldades
Pesquisa PMI Brasil: maiores dificuldades enfrentadas pelos projetos
A Complexidade e a Incerteza
Fonte: Shenhar; Wideman, 2000.
Fonte: DZone Refcardz
Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013
Porque
tudo isso
agora?
“A maioria das nossas suposições sobre negócios,
tecnologia e organizações têm pelo menos 50
anos. Elas tem sobrevivido ao...
Estatísticas do The Standish Group
Estudo do PMI sobre Complexidade
• Estudo patrocinado pelo PMI (CICMIL et al,
2009):
– Discrepância entre “a melhor prátic...
Teoria de Gestão de Projetos
• “A teoria implícita de gerenciamento de
projetos está obsoleta.”, Gregory A. Howell e
Lauri...
Teoria de Gestão de Projetos – cont.
• Teoria de Projetos
– Visão de transformação: entrada+processo+saída
– Gerenciado po...
Nova proposta (Howell e Koskela)
Last Planner System (1992)
• Motivação: 54% de PPC semanal;
• Criado por Glen Ballard, fruto de pesquisa
construtiva em ob...
LPS – cont.
• Cada trabalhador tem o dever e o direito de parar
o fluxo para evitar defeitos:
– Problemas emergiram, exigi...
Lean Construction
• Cinco mudanças de paradigma (Koskela, 2002):
1. Da otimização (CPM) à eliminação de desperdício;
2. Da...
Exercício
Jogos
Estatísticos:
Lotes de
Produção x
Produtividade
Porque usar metodologia ágil para
projetos complexos?
• “É típico adotar a abordagem de modelagem definida quando
os mecan...
VIDEO
Manifesto
Ágil
• Indivíduos e interação entre eles
mais que processos e ferramentas
• Software em funcionamento mais
que d...
Princípios do Manifesto Ágil (1/3)
• Nossa maior prioridade é satisfazer o cliente, através
da entrega adiantada e contínu...
Princípios do Manifesto Ágil (2/3)
• Construir projetos ao redor de indivíduos motivados.
Dando a eles o ambiente e suport...
Princípios do Manifesto Ágil (3/3)
• Contínua atenção à excelência técnica e bom
design, aumenta a agilidade.
• Simplicida...
Teoria por trás do pensamento ágil
• Theory of Constraints: perspectiva logística
• Lean Thinking (Toyota-1940): eliminand...
Metodologias e Processos Ágeis
• XP | Extreme Programming (Kent Beck)
• FDD | Feature Driven Development (Jeff DeLuca)
• D...
Tempo
x
ROI
x
Qualidade
Fonte: Revista MundoJ, número 42, ano VIII, 2010, p.6 – Rodrigo Yoshima
Eventos sobre Agile
DoDAgileDevelopment
PDCA
Plan
DoCheck
Act
Deming, 1939
Exercício
Scrum Game
SCRUM
SCRUM
• Palavra usada no Rugby para descrever uma
formação:
“O scrum é o meio de reiniciar o jogo após uma
interrupção que...
VIDEO
SCRUM
Framework !!!
Metodologia.
Fundamentação Teórica Subjacente
Fonte: Revista MundoPM, Ago & Set /2014, p. 70
Custo da mudança no Scrum
Development Life Cycle
Costofchange
Scrum é flexível o bastante para acomodar as mudanças de req...
Estatísticas
Fonte: Version One Agile Survey 2009
Fonte: http://www.slideshare.net/acarlos1000/scrum-agile-development-intro-campus-party-2009-presentation
Visão do Produto
Product Backlog
Estimativa
SP1 SP2Sprint Backlog
Desenvolvimento
Testes
Sprint
2 a 4 semanas
Reunião Diár...
Sprint
Planejamento Tático é feito a
cada Sprint
Em cada Sprint: planejamento, execução,
acompanhamento, validação e análi...
Papéis
Fonte: http://www.implementingscrum.com
Product
Owner • Cria e compartilha a visão do
projeto
• Gerencia o product backlog
• Representa stakeholders
• Aceita/reje...
Scrum
Master • Trabalha com o product owner
• Remove obstáculos
• Evita interferências
• Mantém foco na meta da sprint
• G...
VIDEO
Time
Time
• Auto-gerenciável
– Gerencia o próprio progresso
– Mantém o foco no que o PO quer
– Garante a qualidade
– Desenvolve...
O processo não é avaliado
enquanto está rodando
Cerimônias
Sprint Planning 1
Sprint Planning 2
Review
Retrospective
Estimativa
Daily Meetings
Estimativa
• Preparação para o Sprint
Planning
• Estimar baseado no tamanho,
nunca em tempo
• Atualizar Product Backlog
co...
Exercício
.
Planning
Poker
Exercício
.
Planning
Poker
Sprint Planning 1
• Nível estratégico
• PO apresenta o Product Backlog priorizado já
estimado pelo Time
• O Time obtém o e...
Sprint Planning 1
Product
Backlog
Capacidade da
equipe
Condições do
Negócio
Revisa
Considera
Organiza
Objetivos da
Sprint
...
Sprint Planning 2
• Nível tático
• PO não precisa participar
• O Time planeja como vai implementar cada
história
• As hist...
foto: http://www.tecmedia.com.br/blog/wp-content/uploads/2008/12/dsc00091.jpg
O que fez ontem?
O que fará hoje?
Tem algum ...
VIDEO
Review
• Software funcionando para o PO
e interessados
• Os resultados são aceitos ou
rejeitados pelo PO
• Toda equipe
• D...
Retrospective
"Loucura é fazer a mesma coisa e
esperar um resultado diferente."
Albert Einstein
O que devemos começar a fa...
Retrospective
Exercício
.
Negociação
Artefatos
Product Backlog
Sprint Backlog
Burn-down chart
Burn-up chart
Taskboard
Impediment List
Product
Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Qualquer um pode contribuir
Priorização é ...
Sprint
Backlog
Produto da SP1
Mantido pelo Time
O Time aloca o trabalho
Executado na ordem definida pelo PO
Não deve mudar...
Taskboard
Burn-down e Burn-up
Scrum of scrums
Scrum
+
XP
• Padronização de código
• Testes automatizados
• Controle de versão
• TDD
• User stories
• Refatoração
• Integ...
Scrum
+
Kanbam
O fator H (1/3)
• Características de um time ágil:
– Orientação ao valor proporcionado ao cliente
– Desenvolvimento das co...
O fator H (2/3)
• Cinco estágios para o desenvolvimento de
times (PMBOK)
– Formação
– Tempestade
– Norma
– Desempenho
– No...
O fator H (3/3)
Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013
• Competências...
Benchmarking
Benchmarking simples (identificação)
Benchmarking de líderes (Ex: Toyota e 5
meses de treinamento para todos ...
Déficit técnico
Fonte: DZone Refcardz
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...
Erros comuns no burn down chart
• Ausência ou abandono
• Burn down para o Product Owner
• Não ajustar os planos
Fonte: Dai...
Erros comuns no papel do cliente/PO
• Sobreposição do papel com o Scrum Master
• Cliente com várias vozes
• Envolvimento p...
Exercício
Projeto do
avião
Problemas comuns na adoção
de Scrum
Product Owner pouco presente
Sem Visão
Sem release plan
Sem product backlog
Product Backlog não
é mantido
Falta estimativa
Falta priorização
Falta acompanhamento
Fonte: http://www.slideshare.net/mac...
Se as cerimônias não acontecem
Falta planejamento
Falta comprometimento para entregas
PO pode aceitar itens que não estão
...
Sem retrospectivas
Falta de uma maneira de melhorar o
trabalho do time
Mesmos erros acontecem sempre
Impedimentos não são ...
O que é difícil em Scrum?
Detalhes podem escapar se não
for gerenciado corretamente
Criar e manter um Product
Backlog requ...
Não é uma metodologia completa
e com o carimbo de um fornecedor
Fonte: http://www.slideshare.net/macaubas/seminario-scrum-...
Livros
Obrigado!
Duas certezas sobre seu próximo projeto:
1. O escopo vai mudar
2. Alguma coisa vai dar errado
Este trabalho está licenciado através da “Atribuição-Uso Não-Comercial-Compartilhamento
pela mesma Licença 3.0 Unported”
V...
Gestão ágil de projetos 2015
Gestão ágil de projetos 2015
Gestão ágil de projetos 2015
Gestão ágil de projetos 2015
Gestão ágil de projetos 2015
Próximos SlideShares
Carregando em…5
×

Gestão ágil de projetos 2015

432 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
432
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
15
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

    ×