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

contato@leandrofaria.com.br

twitter.com/lhfaria