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. 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. 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. Fonte: PMI´s Pulse of the Profession In-Depth Report: Navigating Complexity, September 2013
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. 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
17. “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
20. 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.
21. Teoria de Gestão de Projetos
• “A teoria implícita de gerenciamento de
projetos está obsoleta.”, Gregory A. Howell e
Lauri Koskela, 2002.
22. 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
24. 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.
25. 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;
26. 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
28. 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
34. 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
35. 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)
• …
41. 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
45. 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
48. 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)
49. 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
51. 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
52. 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
55. 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
58. 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
61. 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
63. 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
66. 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)
67.
68. 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?
72. 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
73. 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
79. 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
80. O fator H (2/3)
• Cinco estágios para o desenvolvimento de
times (PMBOK)
– Formação
– Tempestade
– Norma
– Desempenho
– Nova jornada
81. 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:
82. 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
84. 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
85. 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
86. 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
92. Product Backlog não
é mantido
Falta estimativa
Falta priorização
Falta acompanhamento
Fonte: http://www.slideshare.net/macaubas/seminario-scrum-pr
93. 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
94. 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
95. 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
96. Não é uma metodologia completa
e com o carimbo de um fornecedor
Fonte: http://www.slideshare.net/macaubas/seminario-scrum-pr
99. 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
Notas do Editor
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