Metodologias Agile de Gestão de Projetos

Transcrição

1

2 Metodologias Agile de Gestão de Projetos Leandro Faria PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT

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 ScrumMinas, primeiro e único usergroupoficial da ScrumAlliance 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 StandishGroupdemonstra 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.7bilhões de dólares em software e somente 2% foi plenamente utilizado.

7 A Origem da Agilidade O artigo acadêmico elaborado em 1998na Harvard Business Schoolpelos pesquisadores Robert D. Austin e Richard L. Nolanexpôs as dificuldadesda gestão tradicional de projetos em grandes projetos de software e questionoualgumas 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 Abrangendotodosestesnovosconceitos, o artigowhy Evolutionary Software Development Works escrito em 2001 peloprofessor assistentenahardvardbusiness School, Alan MacCormack, estudouas abordagensexistentesda épocae suasimplicaçõ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 2001por um grupo de praticantes da teoria iterativa incremental, é o documento de fundação do movimento ágil e estabelece a filosofiado 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); AlistairCockburn foi o criador do método Crystal e autor de obras influentes sobre desenvolvimento ágil; Jim Highsmithtraduziu 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; Scrumnã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 Product Owner Maximzao valor do produto e o trabalho da equipe. É responsável pela definição, priorização e manutenção do backlog do projeto. Time Profissionais de desenvolvimento que criam o incremento do produto. Auto organizáveis e multi funcionais. Mais que três e menos que nove. Scrum Master O ScrumMaster é responsável para garantir que o Scrumseja entendido e aplicado. É um líder facilitador e servidor para a equipe Scrum.

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

26 Eventos do Scrum Planejamento da Sprint (~4 horas) Planejamento da Sprint; Definição do objetivo da Sprint; O que será incluso na Sprint. Reunião Diária (15 minutos) O que foi realizado desde ontem? O que será realizado hoje? Existe algum impedimento? Revisão da Sprint (~4 horas) Validação do produto entregue; Discussão dos itens do backlog; Input valioso para o próximo planning. Retrospectiva da Sprint (~3 horas) 3 horas para cada 1 mês de sprints; Lições aprendidas; 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 Ticket, um pequeno cartão de plástico sem identificação ou cobrança que é devolvido na saída do parque. Fim Saída (+1 Ticket) Visitante Início Entrada (-1 Ticket)

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= Workin 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 WIPem uma organização, em um time, ou uma célula, deve ser configuradolevando em consideração a capacidadede execução de trabalho, ou como conhecemos, pelos seus limites. O objetivoprincipal é 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 TheoryofConstraints) é uma filosofia de negócios introduzida por EliyahuM. Goldrattno 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 momentono 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 Kanbanimplementa 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 supplychainmanagement, 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, kanbansignifica 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 kanbansã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 Kanbanboardsnão sãoinerentemente 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ânciaentre a primeirae últimalinha horizontalmente representa o WIP; A distânciaentre a primeirae a últimalinha verticalmenterepresenta uma média de lead time.

43 Métricas A diminuiçãodo WIPcomprovadamente diminui o lead time médio; Isto significa menos trabalho em progresso, mais entregas, menorchance de errose 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; Scrum; Kanban; Extreme Programming; Feature Driven Development; Value Stream Mapping; Lean Portfólio Management; Test Driven Development; Business Balue Focus; Continous Integration; Continoues Deployment; Ideal Time; Velocity, User Stories, Points; Planning Poker;

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

49 Takeaways

50 Takeaways Agilejá 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: PMI Agile Virtual Community: agile.vc.pmi.org Blog: Scrum Minas:

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