Este documento apresenta uma palestra sobre metodologias ágeis de gestão de projetos. Resume os principais pontos da origem da agilidade, Scrum, Kanban, a certificação PMI-ACP e conclusões.

2. Metodologias Agile de
Gestão de Projetos
Leandro Faria
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
www.leandrofaria.com.br
@lhfaria

3. Agenda
 A Origem da Agilidade
 Agilidade Hoje
 Scrum
 Kanban
 A Certificação PMI-ACP
 Takeaways

4. Leandro Faria
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
 Especialista em Gestão Ágil de Projetos e Application Lifecycle Management;
 Graduado em Sistemas de Informação e Pós-graduado em Gestão Estratégica de Projetos pela
Universidade Fumec;
 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.

5. A Origem da Agilidade

6. A Origem da Agilidade
O estudo CHAOS do Standish Group demonstra que muitos dos projetos de TI não tem
sucesso em relação ao planejamento de prazo e custo, e muitas vezes não atendem nem
aos requisitos de negócio previamente estabelecidos.
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.

7. A Origem da Agilidade
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.

8. A Origem da Agilidade
“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

9. A Origem da Agilidade
“A incerteza é inerente e inevitável nos processos de desenvolvimento de
software e produtos.”
Hadar Ziv, University of California

10. A Origem da Agilidade
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.

11. A Origem da Agilidade
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 quanto as alterações;
 Equipes profundamente capacitadas.

12. O Manifesto Ágil
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.

13. O Manifesto Ágil
“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.”

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

15. Agilidade Hoje
(Fonte: State of Agile 2011)

16. Agilidade Hoje

17. Agilidade Hoje

18. Agilidade Hoje

19. Agilidade Hoje

20. Scrum

21. Scrum
 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.

22. Fluxo “Tradicional”
Derivado da engenharia
civil, tem etapas e
objetivos muito bem
definidos em um fluxo
no modelo cascata. Qual é o custo da mudança?

23. Fluxo Scrum
Fluxo iterativo
incremental baseado
em time-boxes e
backlogs de estórias.

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

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

26. Eventos do Scrum
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 próximo planning. • Proposta de melhorias no processo.

27. Scrum Burndown Chart
O Release Burndown
Chart acompanha o
progresso de um time
comparado ao seu
planejamento.

28. Kanban

29. Os Jardins do Palácio Imperial do
Japão
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).

30. Os Jardins do Palácio Imperial do
Japão
Ao entrar no parque, cada
visitante recebe um “Admission Fim Início
Ticket”, um pequeno cartão de Saída Entrada
(+1 Ticket) (-1 Ticket)
plástico sem identificação ou
cobrança que é devolvido na
saída do parque.
Visitante

31. Os Jardins do Palácio Imperial do
Japão
Se o ticket não tem nenhuma
identificação, não é registrado, e não é
utilizado para cobrança, pra que ele existe?

32. Os Jardins do Palácio Imperial do
Japão
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, quanto 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.

33. Os Jardins do Palácio Imperial do
Japão
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!

34. O Conceito de Sistema
Puxado
 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.

35. A Teoria das Restrições
 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.

36. A Teoria das Restrições
O Kanban implementa conceitos da Teoria das
Restrições em um modelo de sistema puxado.

37. Porque Kanban?
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.

38. Porque Kanban?
 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.

39. Porque Kanban?
“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.

40. Kanban Boards
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.

41. Kanban Boards
Live Demo

42. Métricas
 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.

43. Métricas
 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.

44. Métricas
Um sistema puxado expõe os gargalos e cria folgas
onde não há gargalos.

45. A Certificação PMI-ACP

46. A Certificação PMI-ACP
 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;
 Ainda disponível somente em inglês.

47. Conteúdo
 O Manifesto Ágil;  Test Driven Development;
 Scrum;  Business Balue Focus;
 Kanban;  Continous Integration;
 Extreme Programming;  Continoues Deployment;
 Feature Driven Development;  Ideal Time;
 Value Stream Mapping;  Velocity, User Stories, Points;
 Lean Portfólio Management;  Planning Poker;

48. Números
 Durante o Período Beta:
 7654 aplicações abertas; Atualmente:
 1404 submetidas;
758 PMI-ACPs
 827 exames pagos;
 557 exames prestados;
Em todo o mundo.
 515 candidatos aprovados;
Números de Abril-2012

49. Takeaways

50. Takeaways
Agile já tem uma presença sólida no mercado, e isso é um fato.
Agile é apenas uma nova abordagem de Gerenciamento de Projetos.
Os frameworks e práticas não são cabíveis a todos os cenários.
Agile cria uma tensão positiva pois força a discussão e auto-gestão do time.
A mudança cultura é fator crucial para a implementação de práticas ágeis.

51. Referências

52. Referências
 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

53. Referências
Kanban: Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia
David Anderson
PMI-ACP Exam Prep
Mike Griffiths
Gerenciamento Ágil de Projetos: Preparatório para a Certificação PMI-ACP
? Leandro Faria
Editora Brasport, previsão de lançamento para o segundo semestre de 2012

54. Obrigado
Leandro Faria
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
www.leandrofaria.com.br
contato@leandrofaria.com.br
@lhfaria