Métodos Ágeis para

Gerenciamento de Projetos
Bruno Maia
bruno@nitin.com.br
@brunoluismaia
 Apresentação
Mais de 20 anos de experiência em
projetos.
Mestrando em Engenharia Ambiental
Engenheiro de Produção (FeMASS)
MBA em Gestão Empresarial (FGV)
Esp. em Engenharia de Equipamentos On-
Shore e Off-Shore (UCP/UNIG)
PMP - Project Management Professional
(PMI)
Professor do Curso de Engenharia de
Produção da Universidade Estácio de Sá
Mais um monte de coisas.....
 O que é projeto?

Projeto: Gerenciamento de Projetos

“Esforço temporário realizado por pessoas com o
objetivo de criar um produto, serviço e/ou
resultado único.”
“É a aplicação de conhecimentos, habilidades,
ferramentas e técnicas para fazer com que as
atividades de projeto atendam os requisitos do
projeto, normalmente ligados a escopo, prazo,
custos e qualidade.”
 Porque gerenciar projetos?
Segundo a Pesquisa de Benchmark em Gerenciamento de Projetos:

No Brasil, 25% dos projetos estouram seu orçamento em mais de

10%, se levarmos em consideração apenas o setor de Óleo e Gás
esse número aumenta para 70%!

60% das organizações de Óleo e Gás que responderam a

pesquisa disseram que a frequência que seus projetos alcançam
suas metas de prazo, custo, qualidade e satisfação do cliente é
bem pequena.

Desse mesmo público, 90% delas dizem enfrentar problemas

com prazos frequentemente. De acordo com essas empresas,
80% delas também dizem enfrentar problemas com custos
frequentemente.
 Porque gerenciar projetos?
Ainda segundo a Pesquisa de Benchmark em Gerenciamento de Projetos,
as organizações respondentes depois de implantarem metodologias de
gerenciamento de projetos:

60% delas perceberam um aumento no comprometimento com

resultados

70% delas descreveram uma maior integração entre as áreas e

maior disponibilidade de informações para tomada de decisões.

50% perceberam uma minimização dos riscos e problemas em

projetos
 Gerenciamento de Projetos

E depois?
Henry Gantt U.S. Navy
(1861-1919) (50’s/60’s)

????????

Gráfico de Gantt PERT / CPM

Mundo VUCA

Volatilidade Incerteza Complexidade Ambiguidade

Tarefas
Mudanças Rápidas Ideal x Real
Resultados Incertos, correlacionadas com
na dinâmicas e na Problemas de
Potenciais Surpresas efeitos
natureza das coisas Interpretação
multifacetados

Acaba por induzir

Gera instabilidade, dúvida e
Excesso de dados Baixa Produção
riscos, mudanças de desconfiança, além
causando paralisia Dualidades
fluxos de falhas no
processo de decisão

Necessita que se Necessita um

Necessita de Foco Necessita de
tenha uma Visão, entendimento
claro, com Agilidade na tomada
tome ações rápidas amplo a partir de
flexibilidade e de decisão e
e testar as diferentes
criatividade inovação
mudanças perspectivas
 Manifesto para o desenvolvimento ágil
de software
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o
nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a
valorizar:

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.
Manifesto Ágil, © 2001
 Metodologias Ágeis
1950 - Toyota Production System -Taiichi Ohno

1986 - The New New Product Development Game – Takeuchi e Nonaka

1992 - Crystal Clear Method – Alistair Cockburn

1993 - Scrum - Jeff Shuterland, Ken Schwaber e Mike Beedle

1994 - Analysis Patterns, UML Distilled, Planning XP – Martin Fowler

1996 - XP - Kent Beck, Ward Cunningham e Ron Jeffries

1997 - DSDM (Dynamic Syst. Dev. Method) – Arie van Bennekum e outros

1997 - FDD - Feature-Driven Development – Jeff De Luca e Peter Coad

1997 - ASD - Adaptive SW Develop. – Jim Highsmith e Alistair Cockburn

1999 - The Pragmatic Programmer – Andrew Hunt e Dave Thomas

2003 - Lean Software Development - Mary e Tom Poppendieck

 Premissas para Métodos Ágeis
Times pequenos, auto-organizados, menos hierarquia e mais autonomia;

Foco em valor, saber o que realmente faz a diferença para o negócio e pessoas;

Ciclos curtos, iterativos-incrementais, na escala de horas, dias e semanas;

Busca pela qualidade consciente, ter orgulho do que se faz, sem desperdícios;

Liberdade com responsabilidade coletiva, devemos ter orgulho de toda a equipe;

Gestão visual, realismo e transparência, tomando decisões diariamente;

Usar uma linguagem comum junto a todos os envolvidos no projeto ou sistema.

SAFe
LeSS
Design Thinking
Cynefyn
FLOW
XP
Human Centered Design
DSDM
Prince2
RUP
Mikado Method
DAD
Lean
FDD
SCRUM
TDD
Kaizen
Kanban
Crystal
DevOps
RightShifting
Management 3.0
Beyond Budgeting
 Métodos Ágeis Mais Utilizados
SCRUM

XP (eXtreme Programming)

Kanban

Lean
SCRUM
 Scrum

Um framework dentro do qual pessoas podem

tratar e resolver problemas complexos e
adaptativos, enquanto produtiva e criativamente
entregam produtos com o mais alto valor possível.

O framework Scrum consiste nas pessoas do time Scrum associadas a

papéis, eventos, artefatos e regras. Cada componente dentro do
framework serve a um propósito específico e é essencial para o uso e
sucesso do Scrum
 Papéis no SCRUM

Product Owner (P.O.) Time Scrum ScrumMaster

Tem a visão do produto junto Deve ser: É o responsável por garantir

ao cliente. Prioriza o Auto-Organizável que o Scrum seja entendido
trabalho do time de forma a Multifuncional e aplicado.
agregar mais valor ao cliente Responsabilidade é do Time É um líder-servidor para o
Não contém sub-times Time Scrum.
 Eventos e Artefatos SCRUM

Artefatos
Eventos
Sprint
Sprint Planning Product Backlog
Daily Scrum
Sprint Review Todos as eventos são “time- Sprint BackLog
Sprint Retrospective boxed”, ou seja possuem
tempo determinado.
 Sprint
O coração do Scrum é a Sprint.

É um período de um mês ou menos, durante o

qual um produto “Pronto” ou versão incremental
potencialmente utilizável, é criado.

Uma vez que a Sprint começa, sua duração é

fixada e não pode ser reduzida ou aumentada.

Limita o risco ao custo da duração da Sprint

 Sprint Planning (Planejamento da Sprint)
O trabalho a ser realizado na Sprint é
planejado na reunião de planejamento O que pode ser pronto nesta Sprint?
da Sprint.
Como o trabalho escolhido será pronto?

Este plano é criado com o trabalho

colaborativo de todo o Time Scrum. Backlog do Produto

Último Incremento
Sprint
Sprint Backlog
Reunião de planejamento da Sprint Capacidade do Time
Scrum Planning
possui um time-box com no máximo Desempenho
Meta da
Sprint
oito horas para uma Sprint de um mês Passado

de duração (5%) Necessidades de

Negócio
 Sprint Planning (Planejamento da Sprint)

Estórias de Usuário

Planning Poker

Time deve saber sua Capacidade em cada

Sprint por meio de Story Points
 Daily Scrum (Reunião Diária)
A Reunião Diária do Scrum é um evento
time-boxed de 15 minutos(3% do dia), para O que eu fiz ontem que ajudou o Time a atender a meta
da Sprint?
que o Time de Desenvolvimento possa
sincronizar as atividades e criar um plano
para as próximas 24 horas. O que eu farei hoje para ajudar o Time a atender a meta
da Sprint?

O time deve utilizar a reunião diária para Eu vejo algum obstáculo que impeça a mim ou o Time
inspecionar o progresso e o objetivo da no atendimento da meta da Sprint?
Sprint

Serve também para o time entender como

pode trabalhar em conjunto, se auto-
organizando para completar o objetivo da
Sprint.
 Revisão da Sprint (Sprint Review)
No final de cada Sprint, a equipe mostra
o incremento real do produto que eles Informal
construíram para o Product Owner e outros
stakeholders.
NÃO é
Backlog
Apresentação
O Product Owner declara que itens serão Revisado
de Slides
considerados como “Prontos" de acordo com o
previamente negociado.

Itens incompletos são devolvidos ao Product Decisão de

Backlog como candidatos para futuro Sprints. “Pronto” ou
Inclui P.O. e
Stakeholders
não

O feedback dos interessados é convertido em

novos Itens do Product Backlog. Sugere-se um time-box de 4h
para uma sprint de 30 dias
 Sprint Retrospective (Retrospectiva da Sprint)
Ocorre depois da Sprint Review antes do planejamento
da próxima Sprint.
Recomenda-se não mais do que 2% do tempo da Sprint
para a Retrospectiva

Os propósitos da Retrospectiva são:

Identificar melhorias no Sprint, seja da natureza
tecnológica, processo, pessoas, relações entre elas e
ferramentas;
1. Anotar os pontos a melhorar
Listar os itens que foram bons durante o Sprint com o 2. Ler os pontos a melhorar e definir plano de
objetivo de repetí-los; ação
3. Anotar os pontos bons
Listar os itens a melhorar e definir plano de ação visando
evitar que os mesmos tornem-se recorrentes 4. Ler os pontos bons
5. Ler os planos de ação do Sprint passado
 Resumindo...
Product Owner Time Scrum ScrumMaster

Visão do Sprint
Produto Planning 2

Sprint
Identificar Tarefas Daily
Planning 1
das Estórias Scrum

Análise de Estórias
O que foi feito desde ontem?
Estimativas
Product Execução da O que será feito até amanhã?
Criação do Sprint Backlog
Backlog Sprint O que impede de evoluir?

Criação de Estórias Execução das Tarefas

Priorização
Sprint
Retrospective

O que devemos continuar? Sprint

O que devemos melhorar? Review
O que devemos parar de fazer?

Apresentação do Produto

Sprint
 DÚVIDAS?
bruno@nitin.com.br
@brunoluismaia
 Calendário de Cursos
Outubro
19 e 26 – Gestão de Pessoas e Equipes para www.nitin.com.br
Engenheiros (Macaé/RJ)

Novembro /nitindesenvolvimento

09 – Workshop de Gestão Ágil com SCRUM

(Macaé/RJ)
/nitin_desenv
23 e 30 – Qualidade na Prática: Métodos de Solução
de Problemas (Macaé/RJ)
/nitindesenvolvimento
Dezembro
14 – Facilitação e Gamification para Negócios e
Treinamentos (Macaé/RJ)
 OBRIGADO!

contato@nitin.com.br
https://bit.ly/2k64NE6