Embed Size (px)
Citation preview
GERENCIAMENTO ÁGIL DE PROJETOSUma nova abordagem para os desafios de sempre
SOBRE
• 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.
Leandro FariaPMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
AGENDA
• A Origem da Agilidade
• Números da Agilidade
• Scrum
• Kanban
• A Certificação PMI-ACP
• Concluões
A ORIGEM DA
AGILIDADE
PERGUNTA:
QUAIS SÃO AS
PRINCIPAIS
DIFICULDADES EM
PROJETOS?
Falta de planejamento
Mudança constante de requisitos
Escopo mal definido
Falta de participação do cliente
Comunicação falha
A ORIGEM DA
AGILIDADE
Fonte: CHAOS, Standish Group
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.
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.
A ORIGEM DA
AGILIDADE
Watts Humphrey, IBM Research
“Em um novo projeto de software, os requisitos nunca
serão completamente conhecidos até que o usuário os
tenha utilizado.”
A ORIGEM DA
AGILIDADE
Hadar Ziv, University of California
“A incerteza é inerente e inevitável nos processos de
desenvolvimento de software e produtos.”
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.
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;
• 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.
“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.”
Manifesto para Desenvolvimento Ágil de Software
http://agilemanifesto.org/iso/ptbr/
O MANIFESTO ÁGIL
Entre os assinantes estão muitos dos criadores dos
frameworks, práticas e manuais mais utilizados pela
comunidade á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.
NÚMEROS DA
AGILIDADE
NÚMEROS DA
AGILIDADE
NÚMEROS DA
AGILIDADE
NÚMEROS DA
AGILIDADE
NÚMEROS DA
AGILIDADE
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.
SCRUM
PILARES
Transparência
Inspeção
Adaptação
PILARES
Transparência
Inspeção
Adaptação
Todo e qualquer fator ou acontecimento relacionado ao
processo de entrega, que possa impactar o resultado final do
projeto (produto), deve ser visível e do conhecimento de
todos envolvidos, inclusive o cliente.
PILARES
Transparência
Inspeção
Adaptação
Todos os aspectos do processo de entrega que possam
impactar o resultado final do projeto devem ser
inspecionados freqüentemente, para que qualquer variação
prejudicial possa ser identificada e corrigida o mais rápido
possível.
PILARES
Transparência
Inspeção
Adaptação
Toda vez que uma variação prejudicial é identificada, o
processo deve ser ajustado imediatamente, como forma de
evitar outros desvios.
FLUXO “TRADICIONAL”
Derivado da engenharia, tem etapas e objetivos muito
bem definidos em um fluxo no modelo cascata, onde
uma etapa é executada após a outra até o fim do
projeto.
Qual é o custo da mudança?
FLUXO ITERATIVO E
INCREMENTAL
Processo baseado em iterações que incrementam a
construção de um produto, com entregar parciais,
baseado no feedback do cliente.
TIME SCRUM
Product Owner
Maximza o 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 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 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 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 PO.
EVENTOS 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 planning.
Retrospectiva da Sprint (~3 horas)
• 3 horas para cada 1 mês de sprints;
• Lições aprendidas;
• Proposta de melhorias no processo.
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).
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.
Início
Entrada
(-1 Ticket)
Visitante
Fim
Saída
(+1 Ticket)
PERGUNTA:
SE O TICKET NÃO TEM
NENHUMA
IDENTIFICAÇÃO, NÃO É
REGISTRADO NA ENTRADA,
E NÃO É COBRADO, PRA
QUE ELE EXISTE?
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, quando 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!
OS JARDINS DO PALÁCIO
IMPERIAL DO JAPÃO
• 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
• 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
A TEORIA DAS RESTRIÇÕES
O Kanban implementa conceitos da
Teoria das Restrições em um modelo de
sistema puxado.
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?
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 BOARDS
Vale observar que os Kanban boards não são
inerentemente sistemas Kanban, são apenas
ferramenas de controle visual.
Quadros de cartões e post-its se tornaram um
mecanismo de controle visual popular no
desenvolvimento de software ágil, para
controle do WIP.
KANBAN BOARDS
KANBAN BOARDS
KANBAN BOARDS
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.
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;
• Por enquanto disponível somente em inglês.
A CERTIFICAÇÃO
PMI-ACP
• O Manifesto Ágil;
• Scrum;
• Kanban;
• Extreme Programming;
• Feature Driven Development;
• Value Stream Mapping;
• Lean Portfólio Management;
CONTEÚDO
• Test Driven Development;
• Business Value Focus;
• Continous Integration;
• Continous Deployment;
• Ideal Time;
• Velicity, Users 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.
CONCLUSÕES
CONCLUSÕES
TRADICIONAL + ÁGIL
Não opte por um ou outro. Utilize ambos, na medida certa para o cenário do projeto.
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
PERGUNTAS?
LEANDRO FARIA
PMP, PMI-ACP, CSM, ITIL, FCE, MCTS, MCPD, MCITP, MCT
www.leandrofaria.com.br
twitter.com/lhfaria
