Metodologias Ágeis de Gestão de Projetos

10,376 views
10,135 views

Published on

Apresentação utilizada na palestra "Metodologias Ágeis de Gestão de Projetos" ministrada no dia 18/julho de 2012 no 15o Seminário Nacional de Gestão de Projetos do Ietec, em Belo Horizonte, Minas Gerais.

Published in: Business
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,376
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
331
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Metodologias Ágeis de Gestão de Projetos

  1. 1. Metodologias Agile de Gestão de Projetos Leandro FariaPMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT www.leandrofaria.com.br @lhfaria
  2. 2. Agenda A Origem da Agilidade Agilidade Hoje Scrum Kanban A Certificação PMI-ACP Takeaways
  3. 3. 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.
  4. 4. A Origem da Agilidade
  5. 5. A Origem da AgilidadeO estudo CHAOS do Standish Group demonstra que muitos dos projetos de TI não temsucesso em relação ao planejamento de prazo e custo, e muitas vezes não atendem nemaos 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.
  6. 6. A Origem da AgilidadeO artigo acadêmico elaborado em 1998 na Harvard BusinessSchool pelos pesquisadores Robert D. Austin e Richard L.Nolan expôs as dificuldades da gestão tradicional de projetosem grandes projetos de software e questionou algumas daspremissas fundamentais do gerenciamento de projetos.
  7. 7. 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
  8. 8. A Origem da Agilidade “A incerteza é inerente e inevitável nos processos de desenvolvimento de software e produtos.” Hadar Ziv, University of California
  9. 9. A Origem da AgilidadeAbrangendo todos estes novos conceitos, o artigo WhyEvolutionary Software Development Works escrito em 2001pelo professor assistente na Hardvard Business School, AlanMacCormack, estudou as abordagens existentes da época esuas implicações.
  10. 10. A Origem da AgilidadeO artigo não só expunha os problemas dos métodos, mas também sugeria novasabordagens e práticas que poderiam começar a substituir o ciclo de vida naturalde desenvolvimento. Estas três simples ideias, ficaram marcadas como o iníciodas 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.
  11. 11. O Manifesto ÁgilO Manifesto Ágil foi a culminação de todas estas teorias eabordagens. Escrito em 2001 por um grupo de praticantes dateoria iterativa incremental, é o documento de fundação domovimento ágil e estabelece a filosofia do conceitos por trásda gestão ágil de projetos.
  12. 12. 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.”
  13. 13. O Manifesto ÁgilEntre os assinantes estão muitos dos criadores dos frameworks mais utilizadospela 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.
  14. 14. Agilidade Hoje (Fonte: State of Agile 2011)
  15. 15. Agilidade Hoje
  16. 16. Agilidade Hoje
  17. 17. Agilidade Hoje
  18. 18. Agilidade Hoje
  19. 19. Scrum
  20. 20. 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.
  21. 21. Fluxo “Tradicional”Derivado da engenhariacivil, tem etapas eobjetivos muito bemdefinidos em um fluxono modelo cascata. Qual é o custo da mudança?
  22. 22. Fluxo ScrumFluxo iterativoincremental baseadoem time-boxes ebacklogs de estórias.
  23. 23. 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.
  24. 24. Artefatos Scrum Lista ordenada de tudo que pode ser necessário no produto. Fonte únicaProduct 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.
  25. 25. Eventos do ScrumPlanejamento 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.
  26. 26. Scrum Burndown ChartO Release BurndownChart acompanha oprogresso de um timecomparado ao seuplanejamento.
  27. 27. Kanban
  28. 28. Os Jardins do Palácio Imperial doJapãoEm Tóquio no mês de Abril, osJardins do Oriente ficamrepletos de visitantes e turistasque vão lá para desfrutar datranquilidade do parque ebeleza da sakura (flor dacerejeira).
  29. 29. Os Jardins do Palácio Imperial doJapãoAo entrar no parque, cadavisitante recebe um “Admission Fim InícioTicket”, um pequeno cartão de Saída Entrada (+1 Ticket) (-1 Ticket)plástico sem identificação oucobrança que é devolvido nasaída do parque. Visitante
  30. 30. Os Jardins do Palácio Imperial doJapão Se o ticket não tem nenhuma identificação, não é registrado, e não é utilizado para cobrança, pra que ele existe?
  31. 31. Os Jardins do Palácio Imperial doJapã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.
  32. 32. Os Jardins do Palácio Imperial doJapãoO 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!
  33. 33. O Conceito de SistemaPuxado 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.
  34. 34. 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.
  35. 35. A Teoria das Restrições O Kanban implementa conceitos da Teoria das Restrições em um modelo de sistema puxado.
  36. 36. Porque Kanban?O conceito de sistema puxado foi amplamente utilizado emaplicações de supply chain management, em especial pelopioneiro Sistema Toyota de Produção, base para diversosframeworks e metodologias inspiradas em LeanManufacturing, criando por exemplo, sistemas com o Just inTime.
  37. 37. 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.
  38. 38. 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.
  39. 39. Kanban BoardsQuadros de cartões e post-its se tornaram um mecanismo de controle visualpopular 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.
  40. 40. Kanban Boards Live Demo
  41. 41. 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.
  42. 42. 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.
  43. 43. MétricasUm sistema puxado expõe os gargalos e cria folgas onde não há gargalos.
  44. 44. A Certificação PMI-ACP
  45. 45. 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.
  46. 46. 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;
  47. 47. 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
  48. 48. Takeaways
  49. 49. 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.
  50. 50. Referências
  51. 51. 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
  52. 52. 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
  53. 53. Obrigado Leandro FariaPMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT www.leandrofaria.com.brcontato@leandrofaria.com.br @lhfaria

×