Gestão ágil de projetos 2015

Gerenciamento de projetos
Complexos
Sob a Perspectiva da Gestão Ágil
Um olhar sobre o SCRUM

powered by inaniaverba@bol.com.br

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

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

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.

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 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.

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

Dificuldades
Pesquisa PMI Brasil: maiores dificuldades enfrentadas pelos projetos

A Complexidade e a Incerteza
Fonte: Shenhar; Wideman, 2000.

“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

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á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.

Teoria de Gestão de Projetos
• “A teoria implícita de gerenciamento de
projetos está obsoleta.”, Gregory A. Howell e
Lauri Koskela, 2002.

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

Nova proposta (Howell e Koskela)

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.

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;

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

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 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

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

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.

• 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.

• 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.

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

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)
• …

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

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

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 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

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ária
24hs
Review
Produto
Retrospectiva powered by Fábio Menezes (Peggasus)

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

Papéis
Fonte: http://www.implementingscrum.com

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

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

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

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
com as estimativas
• Importante para o PO criar o
release plan

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

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

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

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

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)

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?

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 é tarefa do PO
Sempre visível
Alinhado ao plano de negócios:
(benefício + penalidade) / tamanho

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

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

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

O fator H (2/3)
• Cinco estágios para o desenvolvimento de
times (PMBOK)
– Formação
– Tempestade
– Norma
– Desempenho
– Nova jornada

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:

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

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 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

Erros comuns no burn down chart
• Ausência ou abandono
• Burn down para o Product Owner
• Não ajustar os planos

Erros comuns no papel do cliente/PO
• Sobreposição do papel com o Scrum Master
• Cliente com várias vozes
• Envolvimento pontual

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/macaubas/seminario-scrum-pr

Se as cerimônias não acontecem
Falta planejamento
Falta comprometimento para entregas
PO pode aceitar itens que não estão
prontos

Sem retrospectivas
Falta de uma maneira de melhorar o
trabalho do time
Mesmos erros acontecem sempre
Impedimentos não são removidos

O que é difícil em Scrum?
Detalhes podem escapar se não
for gerenciado corretamente
Criar e manter um Product
Backlog requer trabalho

Não é uma metodologia completa
e com o carimbo de um fornecedor

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”
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

Gestão ágil de projetos 2015

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à Gestão ágil de projetos 2015

Similaire à Gestão ágil de projetos 2015 (20)

Dernier

Dernier (20)

Gestão ágil de projetos 2015

Notes de l'éditeur