O documento discute a abordagem ágil para gerenciamento de projetos. Resume os principais pontos da origem da agilidade, os frameworks Scrum e Kanban, e a certificação PMI-ACP. Apresenta números sobre a adoção da agilidade e conclui que as abordagens tradicional e ágil devem ser usadas de forma complementar.

1. GERENCIAMENTO ÁGIL DE PROJETOS
Uma nova abordagem para os desafios de sempre

2. Leandro Faria
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
• Especialista em Gerenciamento Ágil de Projetos;
• Graduado em Sistemas de Informação e Pós-graduado em Gestão
Estratégica de Projetos pela Universidade Fumec;
• Responsável pelo PMO da Stefanini em Belo Horizonte, maior fornecedora
de serviços de TI da América Latina, com faturamento superior a U$1bi;
• Executivo Nomeado da Diretoria de Administração e Finanças do PMI-MG;
• Presidente e fundador do Scrum Minas, primeiro e único user group oficial
da Scrum Alliance em Minas Gerais e um dos primeiros do Brasil;
• Empreendedor e entusiasta de startups.
SOBRE

3. • A Origem da Agilidade
• Números da Agilidade
• Scrum
• Kanban
• A Certificação PMI-ACP
• Concluões
AGENDA

4. A ORIGEM DA
AGILIDADE

5. PERGUNTA:
QUAIS SÃO AS
PRINCIPAIS
DIFICULDADES EM
PROJETOS?

6. Falta de planejamento
Mudança constante de requisitos
Escopo mal definido
Falta de participação do cliente
Comunicação falha

7. Em 1995 o Departamento de Defesa dos Estados
Unidos gastou $35.7 bilhões de dólares em software e
somente 2% foi plenamente utilizado.
Fonte: CHAOS, Standish Group
A ORIGEM DA
AGILIDADE

8. O artigo acadêmico elaborado em 1998 na
Harvard Business School pelos pesquisadores
Robert D. Austin e Richard L. Nolan expôs as
dificuldades da gestão tradicional de projetos em
grandes projetos de software e questionou
algumas das premissas fundamentais do
gerenciamento de projetos.
A ORIGEM DA
AGILIDADE

9. “Em um novo projeto de software, os requisitos nunca
serão completamente conhecidos até que o usuário os
tenha utilizado.”
Watts Humphrey, IBM Research
A ORIGEM DA
AGILIDADE

10. “A incerteza é inerente e inevitável nos processos de
desenvolvimento de software e produtos.”
Hadar Ziv, University of California
A ORIGEM DA
AGILIDADE

11. Abrangendo todos estes novos conceitos, o
artigo Why Evolutionary Software
Development Works escrito em 2001 pelo
professor assistente na Hardvard Business
School, Alan MacCormack, estudou as
abordagens existentes da época e suas
implicações.
A ORIGEM DA
AGILIDADE

12. O artigo não só expunha os problemas dos métodos, mas
também sugeria novas abordagens e práticas que poderiam
começar a substituir o ciclo de vida natural de desenvolvimento.
Estas três simples ideias, ficaram marcadas como o início das
práticas ágeis:
• Entrega antecipada de arquitetura de codificação;
• Compilação diária de código e retorno rápido;
• Equipes profundamente capacitadas.
A ORIGEM DA
AGILIDADE

13. O Manifesto Ágil foi a culminação de todas
estas teorias e abordagens. Escrito em 2001
por um grupo de praticantes da teoria iterativa
incremental, é o documento de fundação do
movimento ágil e estabelece a filosofia do
conceitos por trás da gestão ágil de projetos.
O MANIFESTO ÁGIL

14. Manifesto para Desenvolvimento Ágil de Software
“Estamos descobrindo maneiras melhores de desenvolver software,
fazendo-o nós mesmos e ajudando outros a fazerem o mesmo.
Através deste trabalho, passamos a valorizar:
Indivíduos e interações 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.”
http://agilemanifesto.org/iso/ptbr/

15. Entre os assinantes estão muitos dos criadores dos
frameworks, práticas e manuais mais utilizados pela
comunidade ágil, entre eles:
• Signer Kent Beck, criador do XP (Extreme Programming);
• Alistair Cockburn, criador do método Crystal e autor de
obras influentes sobre desenvolvimento ágil;
• Jim Highsmith, que traduziu conceitos ágeis de software
em uma metodologia de Gerenciamento Ágil de
Projetos.
O MANIFESTO ÁGIL

16. NÚMEROS DA
AGILIDADE

17. NÚMEROS DA
AGILIDADE

18. NÚMEROS DA
AGILIDADE

19. NÚMEROS DA
AGILIDADE

20. NÚMEROS DA
AGILIDADE

21. SCRUM

22. • Framework de gestão de produtos
complexos baseado no modelo iterativo
e incremental;
• Scrum não é um processo ou técnica
para construir produtos, é um
framework dentro do qual se pode
empregar processos e técnicas variadas.
SCRUM

23. Transparência
Inspeção
Adaptação
PILARES

24. Transparência
Todo e qualquer fator ou acontecimento relacionado ao
processo de entrega, que possa impactar o resultado final do
projeto (produto), deve ser visível e do conhecimento de
todos envolvidos, inclusive o cliente.
Inspeção
Adaptação
PILARES

25. Transparência
Inspeção
Todos os aspectos do processo de entrega que possam
impactar o resultado final do projeto devem ser
inspecionados freqüentemente, para que qualquer variação
prejudicial possa ser identificada e corrigida o mais rápido
possível.
Adaptação
PILARES

26. Transparência
Inspeção
Adaptação
Toda vez que uma variação prejudicial é identificada, o
processo deve ser ajustado imediatamente, como forma de
evitar outros desvios.
PILARES

27. Derivado da engenharia, tem etapas e objetivos muito
bem definidos em um fluxo no modelo cascata, onde
uma etapa é executada após a outra até o fim do
projeto.
FLUXO “TRADICIONAL”

28. Qual é o custo da mudança?

29. Processo baseado em iterações que incrementam a
construção de um produto, com entregar parciais,
baseado no feedback do cliente.
FLUXO ITERATIVO E
INCREMENTAL

31. Maximza o valor do produto e o trabalho da
Product Owner equipe. É responsável pela definição, priorização e
manutenção do backlog do projeto.
Profissionais de desenvolvimento que criam o
Time incremento do produto. Auto organizáveis e multi
funcionais. Mais que três e menos que nove.
O Scrum Master é responsável para garantir que o
Scrum Master Scrum seja entendido e aplicado. É um líder
facilitador e servidor para a equipe Scrum.
TIME SCRUM

32. Lista ordenada de tudo que pode ser necessário
Product Backlog no produto. Fonte única de requisitos do projeto,
é mantida pelo Product Owner.
Conjunto de itens selecionados do Product
Sprint Backlog Backlog para execução na Sprint corrente. Prevista
e estimada pelo time de desenvolvimento.
Soma de todos os itens do Product Backlog
Incremento completados por um Sprint. A “definição de
pronto” é previamente acordada com o PO.
ARTEFATOS SCRUM

33. Planejamento da Sprint (~4 horas) Reunião Diária (15 minutos)
• Planejamento da Sprint; • O que foi realizado desde ontem?
• Definição do objetivo da Sprint; • O que será realizado hoje?
• O que será incluso na Sprint. • Existe algum impedimento?
Revisão da Sprint (~4 horas) Retrospectiva da Sprint (~3 horas)
• Validação do produto entregue; • 3 horas para cada 1 mês de sprints;
• Discussão dos itens do backlog; • Lições aprendidas;
• Input valioso para o planning. • Proposta de melhorias no processo.
EVENTOS SCRUM

34. O Release Burndown
Chart acompanha o
progresso de um
time comparado ao
seu planejamento.
BURNDOWN CHART

35. KANBAN

36. Em Tóquio no mês de
Abril, os Jardins do
Oriente ficam repletos de
visitantes e turistas que
vão lá para desfrutar da
tranquilidade do parque e
beleza da sakura (flor da
cerejeira).
OS JARDINS DO PALÁCIO
IMPERIAL DO JAPÃO

37. Ao entrar no parque, cada
visitante recebe um
“Admission Ticket”, um Fim Início
Saída Entrada
pequeno cartão de (+1 Ticket) (-1 Ticket)
plástico sem identificação
ou cobrança que é
devolvido na saída do
parque. Visitante
OS JARDINS DO PALÁCIO
IMPERIAL DO JAPÃO

38. PERGUNTA:
SE O TICKET NÃO TEM
NENHUMA
IDENTIFICAÇÃO, NÃO É
REGISTRADO NA ENTRADA,
E NÃO É COBRADO, PRA
QUE ELE EXISTE?

39. Para controlar o WIP.
WIP = Work in Progress
Cada visitante que recebe um ticket é considerado um WIP. Como existe um
limite de pessoas dentro dos jardins, quando os cartões acabam, as pessoas
formam uma fila do lado de fora dos portões aguardando que novos cartões
estejam disponíveis, devolvidos pelos visitantes que saíram.
OS JARDINS DO PALÁCIO
IMPERIAL DO JAPÃO

40. • O WIP associado a um limite, põe em prática
conceitos conhecidos como sistemas
“puxados” (pull systems).
• Em resumo, o Palácio Imperial de Tóquio
utiliza um sistema Kanban!
OS JARDINS DO PALÁCIO
IMPERIAL DO JAPÃO

41. • Um sistema puxado, determina que o WIP em
uma organização, em um time, ou uma célula,
deve ser configurado levando em consideração
a capacidade de execução de trabalho, ou como
conhecemos, pelos seus limites;
• O objetivo principal é atingir um ritmo
sustentável de produção, e evitar sintomas
como: overstocking, bottlenecks e delays.
SISTEMAS PUXADOS

42. • A Teoria das Restrições (TOC – Theory of Constraints) é uma filosofia
de negócios introduzida por Eliyahu M. Goldratt no seu livro “A Meta”,
de 1984;
• Ela é baseada na aplicação de princípios científicos e do raciocínio
lógico para guiar organizações humanas;
• De acordo com a TOC, toda organização tem – em um dado momento
no tempo – pelo menos uma restrição que limita a performance do
sistema (a organização em questão) em relação à sua meta;
• Para gerir a performance do sistema, a restrição deve ser identificada
e administrada.
A TEORIA DAS RESTRIÇÕES

43. O Kanban implementa conceitos da
Teoria das Restrições em um modelo de
sistema puxado.
A TEORIA DAS RESTRIÇÕES

44. O conceito de sistema puxado foi
amplamente utilizado em aplicações de
supply chain management, em especial
pelo pioneiro Sistema Toyota de Produção,
base para diversos frameworks e
metodologias inspiradas em Lean
Manufacturing, criando por exemplo,
sistemas com o Just in Time.
PORQUE KANBAN?

45. • Kanban é uma palavra japonesa que significa “etiqueta” ou
“cartão sinalizador”;
• Em administração da produção, kanban significa um cartão
de sinalização que controla os fluxos de produção ou
transportes em uma indústria. O cartão pode ser substituído
por outro sistema de sinalização, como luzes, caixa ou locais
vazios demarcados;
• No caso da Toyota, cartões kanban são utilizados para
sinalizar a necessidade de repor estoques.
PORQUE KANBAN?

46. “kanban” com “k” minúsculo, refere-se aos cartões
sinalizadores há muito tempo utilizados na indústria.
“Kanban”, com “K” maiúsculo, é utilizado para se referir ao
método de melhoria de processo incremental que surgiu
entre 2006 e 2008 e é hoje amplamente utilizado e
aprimorado pela comunidade lean software development.
PORQUE KANBAN?

47. Quadros de cartões e post-its se tornaram um
mecanismo de controle visual popular no
desenvolvimento de software ágil, para
controle do WIP.
Vale observar que os Kanban boards não são
inerentemente sistemas Kanban, são apenas
ferramenas de controle visual.
KANBAN BOARDS

48. KANBAN BOARDS

49. KANBAN BOARDS

50. KANBAN BOARDS

51. • Um diagrama de fluxo cumulativo é
um gráfico de área que representa a
quantidade de trabalho em um
determinado estado;
• A distância entre a primeira e última
linha horizontalmente representa o
WIP;
• A distância entre a primeira e a
última linha verticalmente representa
uma média de lead time.
MÉTRICAS

52. • A diminuição do WIP
comprovadamente diminui o
lead time médio;
• Isto significa menos trabalho
em progresso, mais entregas,
menor chance de erros e
consequentemente melhoria na
qualidade.
MÉTRICAS

53. A CERTIFICAÇÃO
PMI-ACP

54. • Foco em métodos e práticas de gestão ágil de projetos;
• Lançada em período beta durante setembro e novembro/2012;
• 120 questões;
• 3 horas de duração;
• Por enquanto disponível somente em inglês.
A CERTIFICAÇÃO
PMI-ACP

55. • O Manifesto Ágil; • Test Driven Development;
• Scrum; • Business Value Focus;
• Kanban; • Continous Integration;
• Extreme Programming; • Continous Deployment;
• Feature Driven Development; • Ideal Time;
• Value Stream Mapping; • Velicity, Users Stories, Points;
• Lean Portfólio Management; • Planning Poker.
CONTEÚDO

56. Durante o Período Beta:
Atualmente:
• 7654 aplicações abertas;
• 1404 submetidas; 758 PMI-ACPs
• 827 exames pagos;
• 557 exames prestados; Em todo o mundo.
• 515 candidatos aprovados;
NÚMEROS

57. CONCLUSÕES

58. TRADICIONAL + ÁGIL
Não opte por um ou outro. Utilize
ambos, na medida certa para o cenário
do projeto.
CONCLUSÕES

59. • Limited WIP Society: www.limitedwipsocity.org
• PMI Agile Virtual Community: agile.vc.pmi.org
• Blog: www.leandrofaria.com.br
• Scrum Minas: www.scrumminas.com.br
REFERÊNCIAS

60. LEANDRO FARIA
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
www.leandrofaria.com.br
contato@leandrofaria.com.br
twitter.com/lhfaria
PERGUNTAS?