Metodologias Ágeis de Gestão de Projetos

Leandro FariaPMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT

www.leandrofaria.com.br@lhfaria

Metodologias Agile deGestão de Projetos

Agenda A Origem da Agilidade

Agilidade Hoje

Scrum

Kanban

A Certificação PMI-ACP

Takeaways


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.

A Origem da Agilidade

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


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.


“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 incerteza é inerente e inevitável nos processos de desenvolvimento de software e produtos.”

Hadar Ziv, University of California


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 AgilidadeO 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.

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.

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.”

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

Agilidade Hoje(Fonte: State of Agile 2011)

Agilidade Hoje

Agilidade Hoje

Agilidade Hoje

Agilidade Hoje

Scrum

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.

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?

Fluxo Scrum

Fluxo iterativo

incremental baseado

em time-boxes e

backlogs de estórias.

Equipe Scrum

Product OwnerMaximza o valor do produto e o trabalho da equipe. É responsável pela

definição, priorização e manutenção do backlog do projeto.

TimeProfissionais de desenvolvimento que criam o incremento do produto.

Auto organizáveis e multi funcionais. Mais que três e menos que nove.

Scrum MasterO Scrum Master é responsável para garantir que o Scrum seja entendido e

aplicado. É um líder facilitador e servidor para a equipe Scrum.

Artefatos Scrum

Product BacklogLista ordenada de tudo que pode ser necessário no produto. Fonte única

de requisitos do projeto, é mantida pelo Product Owner.

Sprint BacklogConjunto de itens selecionados do Product Backlog para execução na

Sprint corrente. Prevista e estimada pelo time de desenvolvimento.

IncrementoSoma de todos os itens do Product Backlog completados por um Sprint. A

“definição de pronto” é previamente acordada com o Product Owner.

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.

Scrum Burndown Chart

O Release Burndown

Chart acompanha o

progresso de um time

comparado ao seu

planejamento.

Kanban

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).


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.

InícioEntrada

(-1 Ticket)

Visitante

FimSaída

(+1 Ticket)


Se o ticket não tem nenhuma identificação,

não é registrado, e não é utilizado para

cobrança, pra que ele existe?


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.


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!

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.

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.

A Teoria das Restrições

O Kanban implementa conceitos da Teoria das

Restrições em um modelo de sistema puxado.

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.

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.

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.

Kanban BoardsQuadros 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

Live Demo

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.

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.

Métricas

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

A Certificação PMI-ACP

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.

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;

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

Takeaways

Takeaways

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.

Agile já tem uma presença sólida no mercado, e isso é um fato.

Referências

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

http://www.limitedwipsocity.org/

http://agile.vc.pmi.org/

http://www.leandrofaria.com.br/

http://www.scrumminas.com.br/

?

ReferênciasKanban: 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

Obrigado


[email protected]

@lhfaria