Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre

2,792 views
2,656 views

Published on

Published in: Business
1 Comment
3 Likes
Statistics
Notes
  • Excelente material Leandro! Objetivo e conciso. Parabéns!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,792
On SlideShare
0
From Embeds
0
Number of Embeds
828
Actions
Shares
0
Downloads
112
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Gerenciamento Ágil de Projetos, Uma nova abordagem para os desafio de sempre

  1. 1. GERENCIAMENTO ÁGIL DE PROJETOSUma nova abordagem para os desafios de sempre
  2. 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. 3. • A Origem da Agilidade• Números da Agilidade• Scrum• Kanban• A Certificação PMI-ACP• ConcluõesAGENDA
  4. 4. A ORIGEM DAAGILIDADE
  5. 5. PERGUNTA:QUAIS SÃO ASPRINCIPAISDIFICULDADES EMPROJETOS?
  6. 6. Falta de planejamentoMudança constante de requisitos Escopo mal definidoFalta de participação do cliente Comunicação falha
  7. 7. Em 1995 o Departamento de Defesa dos EstadosUnidos gastou $35.7 bilhões de dólares em software e somente 2% foi plenamente utilizado.Fonte: CHAOS, Standish GroupA ORIGEM DAAGILIDADE
  8. 8. O artigo acadêmico elaborado em 1998 naHarvard Business School pelos pesquisadoresRobert D. Austin e Richard L. Nolan expôs asdificuldades da gestão tradicional de projetos emgrandes projetos de software e questionoualgumas das premissas fundamentais dogerenciamento de projetos.A ORIGEM DAAGILIDADE
  9. 9. “Em um novo projeto de software, os requisitos nuncaserão completamente conhecidos até que o usuário os tenha utilizado.” Watts Humphrey, IBM ResearchA ORIGEM DAAGILIDADE
  10. 10. “A incerteza é inerente e inevitável nos processos de desenvolvimento de software e produtos.” Hadar Ziv, University of CaliforniaA ORIGEM DAAGILIDADE
  11. 11. Abrangendo todos estes novos conceitos, oartigo Why Evolutionary SoftwareDevelopment Works escrito em 2001 peloprofessor assistente na Hardvard BusinessSchool, Alan MacCormack, estudou asabordagens existentes da época e suasimplicações.A ORIGEM DAAGILIDADE
  12. 12. O artigo não só expunha os problemas dos métodos, mastambém sugeria novas abordagens e práticas que poderiamcomeçar a substituir o ciclo de vida natural de desenvolvimento.Estas três simples ideias, ficaram marcadas como o início dasprá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 DAAGILIDADE
  13. 13. O Manifesto Ágil foi a culminação de todasestas teorias e abordagens. Escrito em 2001por um grupo de praticantes da teoria iterativaincremental, é o documento de fundação domovimento ágil e estabelece a filosofia doconceitos por trás da gestão ágil de projetos.O MANIFESTO ÁGIL
  14. 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 planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.” http://agilemanifesto.org/iso/ptbr/
  15. 15. Entre os assinantes estão muitos dos criadores dosframeworks, práticas e manuais mais utilizados pelacomunidade á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. 16. NÚMEROS DAAGILIDADE
  17. 17. NÚMEROS DAAGILIDADE
  18. 18. NÚMEROS DAAGILIDADE
  19. 19. NÚMEROS DAAGILIDADE
  20. 20. NÚMEROS DAAGILIDADE
  21. 21. SCRUM
  22. 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. 23. Transparência Inspeção AdaptaçãoPILARES
  24. 24. TransparênciaTodo e qualquer fator ou acontecimento relacionado aoprocesso de entrega, que possa impactar o resultado final doprojeto (produto), deve ser visível e do conhecimento detodos envolvidos, inclusive o cliente. Inspeção AdaptaçãoPILARES
  25. 25. Transparência InspeçãoTodos os aspectos do processo de entrega que possamimpactar o resultado final do projeto devem serinspecionados freqüentemente, para que qualquer variaçãoprejudicial possa ser identificada e corrigida o mais rápidopossível. AdaptaçãoPILARES
  26. 26. Transparência Inspeção AdaptaçãoToda vez que uma variação prejudicial é identificada, oprocesso deve ser ajustado imediatamente, como forma deevitar outros desvios.PILARES
  27. 27. Derivado da engenharia, tem etapas e objetivos muitobem definidos em um fluxo no modelo cascata, onde uma etapa é executada após a outra até o fim do projeto.FLUXO “TRADICIONAL”
  28. 28. Qual é o custo da mudança?
  29. 29. Processo baseado em iterações que incrementam a construção de um produto, com entregar parciais, baseado no feedback do cliente.FLUXO ITERATIVO EINCREMENTAL
  30. 30. Maximza o valor do produto e o trabalho daProduct 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 oScrum Master Scrum seja entendido e aplicado. É um líder facilitador e servidor para a equipe Scrum.TIME SCRUM
  31. 31. Lista ordenada de tudo que pode ser necessárioProduct Backlog no produto. Fonte única de requisitos do projeto, é mantida pelo Product Owner. Conjunto de itens selecionados do ProductSprint 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
  32. 32. 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
  33. 33. O Release BurndownChart acompanha oprogresso de umtime comparado aoseu planejamento.BURNDOWN CHART
  34. 34. KANBAN
  35. 35. Em Tóquio no mês deAbril, os Jardins doOriente ficam repletos devisitantes e turistas quevão lá para desfrutar datranquilidade do parque ebeleza da sakura (flor dacerejeira).OS JARDINS DO PALÁCIOIMPERIAL DO JAPÃO
  36. 36. Ao entrar no parque, cadavisitante recebe um“Admission Ticket”, um Fim Início Saída Entradapequeno cartão de (+1 Ticket) (-1 Ticket)plástico sem identificaçãoou cobrança que édevolvido na saída doparque. VisitanteOS JARDINS DO PALÁCIOIMPERIAL DO JAPÃO
  37. 37. PERGUNTA:SE O TICKET NÃO TEMNENHUMAIDENTIFICAÇÃO, NÃO ÉREGISTRADO NA ENTRADA,E NÃO É COBRADO, PRAQUE ELE EXISTE?
  38. 38. 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 pessoasformam 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ÁCIOIMPERIAL DO JAPÃO
  39. 39. • 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ÁCIOIMPERIAL DO JAPÃO
  40. 40. • 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
  41. 41. • 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
  42. 42. O Kanban implementa conceitos daTeoria das Restrições em um modelo de sistema puxado.A TEORIA DAS RESTRIÇÕES
  43. 43. O conceito de sistema puxado foiamplamente utilizado em aplicações desupply chain management, em especialpelo pioneiro Sistema Toyota de Produção,base para diversos frameworks emetodologias inspiradas em LeanManufacturing, criando por exemplo,sistemas com o Just in Time.PORQUE KANBAN?
  44. 44. • 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?
  45. 45. “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 eaprimorado pela comunidade lean software development.PORQUE KANBAN?
  46. 46. Quadros de cartões e post-its se tornaram ummecanismo de controle visual popular nodesenvolvimento de software ágil, paracontrole do WIP. Vale observar que os Kanban boards não são inerentemente sistemas Kanban, são apenas ferramenas de controle visual.KANBAN BOARDS
  47. 47. KANBAN BOARDS
  48. 48. KANBAN BOARDS
  49. 49. KANBAN BOARDS
  50. 50. • 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
  51. 51. • 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
  52. 52. A CERTIFICAÇÃOPMI-ACP
  53. 53. • 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ÇÃOPMI-ACP
  54. 54. • 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
  55. 55. 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
  56. 56. CONCLUSÕES
  57. 57. TRADICIONAL + ÁGILNão opte por um ou outro. Utilizeambos, na medida certa para o cenáriodo projeto.CONCLUSÕES
  58. 58. • Limited WIP Society: www.limitedwipsocity.org• PMI Agile Virtual Community: agile.vc.pmi.org• Blog: www.leandrofaria.com.br• Scrum Minas: www.scrumminas.com.brREFERÊNCIAS
  59. 59. LEANDRO FARIAPMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCTwww.leandrofaria.com.brcontato@leandrofaria.com.brtwitter.com/lhfariaPERGUNTAS?

×