GERENCIAMENTO GIL

DE PROJETOS
UMA NOVA ABORDAGEM PARA
OS DESAFIOS DE SEMPRE

LEANDRO FARIA
PMP, PMI-ACP, CSM, ITIL, FCE, MCPD, MCITP, MCT
WWW.LEANDROFARIA.COM.BR
WWW.STEFANINI.COM

1
SOBRE
LEANDRO FARIA
PMP, PMI-ACP, CSM, ITIL, FCE, MCPD, MCITP, MCT

Expert em agilidade;
Foi um dos primeiros profissionais do mundo a obter a certificao PMI-
ACP, ainda durante o perodo beta.
Contribuiu a ltima verso do PMBOK com as definies de agilidade e o
ciclo de vida iterativo e incremental de projetos.
Atualmente Executivo de Pr-vendas para a Europa na Stefanini, maior
provedora de servios de TI da Amrica Latina com faturamento anual
superior a 2 bilhes de reais.
Fundador do Scrum Minas - user group oficial da Scrum Alliance em Minas
Gerais do Limited WIP Society Brazil, e do PMI Credentialed ACPs, maior
grupo de profissionais certificados PMI-ACP da internet.

2
GERENCIAMENTO GIL DE PROJETOS

QUAIS SO OS
PRINCIPAIS
PROBLEMAS EM
PROJETOS?
3
QUAIS SO OS PRINCIPAIS
PROBLEMAS EM PROJETOS?

Falta de planejamento

Mudana constante de requisitos

Escopo mal definido

Falta de participao do cliente

Comunicao falha

4
GERENCIAMENTO GIL DE PROJETOS

VALORES E
PRINCPIOS DO
MANIFESTO GIL
5
TRADICIONAL X GIL
O Gerenciamento gil de Projetos uma nova abordagem de
Gerenciamento de Projetos;
Porque preciso de uma nova abordagem alm do extenso e
completo PMBOK? Projetos diferentes precisam de mtodos
diferentes;
Prticas geis no so apropriadas para todos os cenrios. Em
especial, a agilidade melhor aproveitada nas seguintes situaes:
Projetos cujo esforo intelectual;
Escopo altamente sujeito a mudanas;
Restries agressivas de tempo.
Uma abordagem no restritiva a outra. Utilize o que faz sentido
para o cenrio da organizao e do projeto.

6
INDUSTRIAL X
INTELECTUAL
O trabalho intelectual tem caractersticas diferentes do trabalho intelectual:

Caractersticas do Trabalho Industrial Caractersticas do Trabalho Intelectual

O trabalho visvel O trabalho invisvel

O trabalho estvel O Trabalho muda constantemente

Foco em operao e manuteno Foco em mudana e inovao

Mais estrutura e menos decises Menos estrutura e mais decises

Foco nas respostas corretas Foco nas perguntas corretas

Definio de tarefas Entendimento de tarefas

Comando e controle Autonomia

Normas rgidas Inovao contnua

Foco na quantidade Foco na qualidade

Medio de performance com normas rgidas Ensino e aprendizado contnuo

Minimizar o custo de trabalhadores em tarefas Trata os trabalhadores como ativos, no custos

7
O MANIFESTO GIL
o termo de rege a filosofia da agilidade;
Surgiu de um encontro realizado por especialistas de software e
metodologias de projeto em fevereiro de 2001, definindo os
conceitos e princpios que norteiam a agilidade.
Assinado pelas seguintes pessoas:

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeries Je Shuterland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

8
MANIFESTO PARA O DESENVOLVIMENTO GIL DE SOFTWARE

Estamos descobrindo maneiras melhores de desenvolver software,

fazendo-o ns mesmos e ajudando outros a fazerem o mesmo.
Atravs deste trabalho, passamos a valorizar:

Indivduos e interaes mais que processos e ferramentas

Software em funcionamento mais que documentao abrangente
Colaborao com o cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano

Ou seja, mesmo havendo valor nos itens direita, valorizamos mais

os itens esquerda.

http://agilemanifesto.org/iso/ptbr/
9
INDIVDUOS E ITERAES MAIS
QUE PROCESSOS E
FERRAMENTAS
Projetos so realizados por pessoas, no por ferramentas;
Problemas so resolvidos por pessoas, no por processos;
Projetos so aceitos por pessoas;
O sucesso determinado por pessoas;
O escopo detalhado por pessoas;
Envolva as pessoas sempre, e o quanto antes;
Isso quer dizer que no precisamos de processos e ferramentas?
No!
Isso quer dizer que processos e ferramentas no ajudam ou
atrapalham a execuo de um projeto? No!

10
SOFTWARE EM
FUNCIONAMENTO MAIS QUE
DOCUMENTAO ABRANGENTE
Software (ou projeto) sem documentao com certeza um
problema, principalmente do ponto de vista de evoluo,
manuteno e operao;
Mas documentao sem software ainda pior. Neste cenrio o
benefcio para a organizao muito prximo de zero;
Documentao extensa e processos burocrticos podem acabar
como um tiro no p;
Foco no projeto ou foco no processo?
Documente e formalize o necessrio, nem mais, nem menos. Foco
no valor/benefcio para o negco.
Isso quer dizer que eu no preciso de documentao? No!

11
COLABORAO COM O CLIENTE
MAIS DO QUE A NEGOCIAO DE
UM CONTRATO
Seja flexvel e adaptativo, ao invs de rgido e no cooperativo;
a diferena entre estar certo e fazer a coisa certa;
No adianta fazer o que est especificado, se o que est
especificado no resolve o problema do cliente;
Crie relaes ganha-ganha;
A premissa bsica na definio de um contrato a confiana;
Crie um cenrio contratual favorvel a agilidade. Quanto mais flexvel
ele for, melhor. Prefira contratos de registro de preo;
Isso quer dizer que eu no preciso de um contrato? No!

12
RESPONDER A MUDANAS MAIS
DO QUE SEGUIR UM PLANO
No implemente processos para gerir mudanas se o foco ser um
processo para evitar mudanas;
No gaste mais tempo realizando anlises de impacto e changes
requests do que implementando o projeto;
Durante o planejamento tenha certeza de que o plano ir mudar, e
prepare-se para isso;
Isso quer dizer que eu no preciso planejar? No!

13
GERENCIAMENTO GIL DE PROJETOS

VALUE-DRIVEN
DELIVERY

14
O QUE VALUE-DRIVEN
DELIVERY?
O Value Driven Delivery est na base da agilidade e uma das
assim definidas reas de conhecimento;
Value Driven Delivery muito mais um conceito do que uma prtica
ou ferramenta. A traduo livre do termo seria Entrega Orientada
por Valor, ou seja, neste modelo o que rege todo o trabalho do
projeto do ponto de vista de planejamento e priorizao, o valor de
uma determinada parte do escopo para o negcio;
O que chamamos de valor nada mais do que a razo pela qual o
projeto existe, e o nosso principal objetivo fazer com que este
valor seja entregue o mais rpido possvel;
Est intimamente ligado com o valor do manifesto gil Software em
funcionamento mais do que documentao abrangente;

15
WASTE
So considerados waste (perdas), qualquer tipo de esforo
desnecessrio e/ou que no agregue valor ao negcio da
organizao;
Os tipos de perda foram adaptados dos processos de Lean
Manufacturing para os projetos de desenvolvimento de software, e
so distribudos basicamente em sete tipos:
Partially done work;
Extra processes;
Extra features;
Task switching;
Waiting;
Motion;
Defects.
16
WASTE
Waste Description
Partially done work Work started, but not complete;
partially done work can entropy
Extra process Extra work that does not add value
Extra features Features that are not required, or
are thought of as nice-to-haves
Task switching Multitasking between several
dierent projects when there are
context-switching penalties
Waiting Delays waiting for reviews and
approvals
Motion The eor required to communicate
or move information or deliverables
from one group to another, if teams
are not co-located, this eort may
need to be greater
Defects Defective documents or software
that need correction
Example
Code waiting for testing;
Specs waiting for development;
Unused documentation;
Unnecessarry approvals
Gold-plating
Technology features
People on multiple projects
Waiting for prototype reviews
Waiting for document approvals
Distributed defects
Handos
Requirements defects
17
CURSO PREPARATRIO PARA A CERTIFICAO PMI-ACP

ADAPTATIVE
PLANNING

18
ADAPTATIVE PLANNING
Como o prprio nome j diz, o planejamento adaptativo alm de
realizado constantemente durante o projeto moldado para o
cenrio e atual status dos projetos;
aceitar que o plano inicial ir mudar, e se prepara para isso;
a aplicao de lies aprendias do projeto, no prprio projeto em
andamento;
a mitigao da incerteza e falta de previsibilidade de projetos que
so sujeitos a mudanas;
a garantia de que o projeto continua resolvendo o problema
proposto no incio, ou seja, que valores continuam sendo entregues
e o planejamento no se torna ultrapassado ou obsoleto.

19
GERENCIAMENTO GIL DE PROJETOS

O CICLO
ITERATIVO E
INCREMENTAL

20
O CICLO DE VIDA
WATERFALL

Requisitos
Processo sequencioal, tem
etapas e objetivos muito bem
Arquitetura definidos em um fluxo no
modelo cascata, onde uma
Implementao etapa executada aps a outra
at o fim do projeto.
Verificao

O Modelo original criado em

Manuteno
1970 por Winston Royce,
definia etapas com
dependncia trmino-incio.
WATERFALL. CASCATA.
21
Qual o custo da mudana?

22
O CICLO DE VIDA ITERATIVO
E INCREMENTAL

Processo baseado em iteraes que incrementam a construo

de um produto, com entregar parciais, baseado no feedback do
cliente.

Iterao

Requisitos Arquitetura Implementao Verificao

23
O CICLO DE VIDA ITERATIVO
E INCREMENTAL

24
O CICLO DE VIDA ITERATIVO
E INCREMENTAL

25
TIMEBOXING
So espaos de tempo com durao fixa que limitam a quantidade
de atividades ou trabalho executados;
Se um trabalho planejado fica de fora por falta de tempo, ele
includo no prximo timebox.

User
Story B

Should have

User
Story A User
Story C

Must have
Could have
26
PROGRESSIVE
ELABORATION
Elaborao progressiva o nome dado ao processo de inserir mais
detalhes a medida que informaes so obtidas;
A elaborao progressiva usada para detalhar:
Planejamentos;
Estimativas;
Riscos;
Definies de requisitos;
Modelos de arquitetura;
Critrios de aceitao;
Cenrios de teste.
No planejamento com elaborao progressiva, a tcnica de
planejamento em ondas sucessivas levada ao limite.

27
PROGRESSIVE
ELABORATION

The Level of Planning Early in a Project When Using Progressive Elaboration

Release Plan
Upfront 80% - 85% Close
Planning Schedule Out

10% - 15% 5%
Schedule Schedule

28
PROGRESSIVE
ELABORATION

The Level of Planning as the Project Is Being Completed

Release Plan
Upfront 80% - 85% Close
Planning Schedule Out

10% - 15% 5%
Schedule Schedule

29
PROGRESSIVE
ELABORATION

The Level of Planning as the Project Is Being Completed

Release Plan
Upfront 80% - 85% Close
Planning Schedule Out

10% - 15% 5%
Schedule Schedule

30
PROGRESSIVE
ELABORATION

The Level of Planning as the Project Is Being Completed

Release Plan
Upfront 80% - 85% Close
Planning Schedule Out

10% - 15% 5%
Schedule Schedule

31
VALUE-BASED ANALYSIS
A anlise baseada em valor considera as features ou partes do
escopo de um projeto em valores monetrios, baseando a
priorizao do backlog do projeto;
Naturalmente, priorizado o item que traz maior benefcio ao
negcio, ou seja, o que tem maior valor.

$5,000
Business $3,000
Benefit Business
Benefit

32
VALUE-BASED ANALYSIS
To importante quando analisar o retorno, analisar o custo de
implementao. a anlise prtica de custo benefcio.

$5,000
Business $3,000
Benefit Business
Benefit
$1,000 Cost to Build
$4,000
Cost to Build

33
AGILE PLANS
Em uma abordagem tradicional o planejamento realizado em uma
etapa inicial do projeto, e monitorado ao longo da exeuo;
Em uma abordagem gil no h um planejamento inicial completo,
entretanto o planejamento realizado e revisto durante todo o
projeto;
Faz-se um planejamento em alto nvel no incio;
Iteraes so planejadas e detalhadas no comeo;
Com o passar das iteraes, refina-se o plano em alto nvel;
No h necessariamente mais ou menos planejamento na
abordagem tradicional ou gil, mas somente so realizados de
maneira diferente.

34
AGILE PLANS

35
AGILE PLANS

36
AGILE PLANS

37
GERENCIAMENTO GIL DE PROJETOS

PROCESS
TAILORING

38
O QUE PROCESS
TAILORING?
Process Tailoring , tem termos gerais, o ato de adaptar um
processo realidade de um projeto ou organizao;
Exemplos:
O DSDM oferece diferentes abordagens de um mesmo
processo para melhor se adaptar realidade do projeto;
O Crystal oferece uma famlia de mtodos que divididos em
mtodos, so indicados para projetos de acordo com as
necessidades.
Estas adaptaes consideram basicamente: o tamanho do
escopo do projeto, a complexidade, os riscos, a quantidade de
pessoas envolvidas, e fatores externos organizao.

39
TOME CUIDADO AO
ADAPTAR UM MTODO
Adaptar um processo complexo e perigoso;
Times de primeira viagem devem usar os processos by the book
durante algum tempo, at que entendam exatamente as
caractersticas da organizao e possam assim, saber o que pode
ser adaptado;
Adaptar um processo pode ser por exemplo, retirar um determinado
evento ou artefato, e caso isso seja feito de maneira inapropriada,
pode-se gerar um grande problema, que neste caso, estar
disfaado de tailoring.

40
O MODELO SHU-HA-RI
O modelo Shu-Ha-Ri definido por Alistair Cockburns, detalha o
processo de evoluo do conhecimento e aplicao de um
processo;
Shu
Shu em japons significa manter, protejer ou manter.
Basicamente, o nvel onde obedecemos as regras exatamente
como elas so definidas;
Ha
Ha em japons significa separa ou se livrar de algo. em
resumo quando se entende a razo de seguir uma regra, e pode
optar por no segu-la para melhorar ainda mais;
Ri
Ri em japons significa ir alm, ou transcender. quando de
maneira inconscientemente, voc cria seu prprio caminho.

41
GERENCIAMENTO GIL DE PROJETOS

AGILE
CONTRACTING

42
AGILE CONTRACTING
A agilidade trs muitos benefcios na execuo de um projeto, mas
pode trazer algumas dificuldades na contratao;
A flexibilidade de escopo deve ser compreendida de maneira
profunda, e as necessidades devem ser avaliadas de maneira a criar
o menor cenrio contratual possvel para a execuo de um projeto
gil;
A principal dificuldade fica em torno dos critrios de aceitao.
Quando o contrato ser considerado cumprido?
Estes problemas so conhecidos desde o incio da agilidade, e j
tem 1994 a primeira edio do DSDM apresentou o modelo do
tringulo invertido.

43
AGILE CONTRACTING
THE INVERTED TRIANGLE MODEL
Abordagens tradicionais fixam um escopo, e tempo e custo so
calculados em razo do esforo de implementao deste escopo;
Projetos geis fixam recursos e tempo (componentes chave para o
custo) e variam o escopo - de maneira a entregar o produto mais
prioritrio, com maior qualidade, respeitando estas restries.

Escopo Recursos Tempo

Fixo

Agile

Traditional

Varivel
Tempo Custo Escopo
44
AGILE CONTRACTING
A ideia de eventualmente no entregar todo o escopo do projeto
normalmente no cai bem s pessoas;
uma mudana cultural muitas vezes mal interpretada;
Contratantes querem a segurana de que 100% do escopo ser
entregue, alm de estimativas e comprometimento contratual;
Um projeto de escopo fechado funciona? Sim, deste que o escopo
esteja de fato muito bem definido e assim assim custa caro
normalmente as estimativas de um projeto de escopo fechado
chegam cercadas por buers (gorduras) a fim de mitigar eventuais
riscos ou desvios de esforo;
Em resumo, em um projeto de escopo fechado o cliente paga por
muitas atividades que no agregam valor ao negcio.

45
AGILE CONTRACTING
O objetivo principal da agilidade eliminar este esforo
desnecessrio e focar no que de fato tem valor para o negcio;
Vem deste conceito o que chamamos de Value-Driven Delivery (ou
entrega orientada por valor);
Um contrato gil demanda muito mais confiana e colaborao entre
as partes;
representada pelo terceiro valor do Manifesto gil: Customer
collaboration over contract negotiation;
Existem algumas abordagens possveis para um contrato, mas a
agilidade aborda cinco principais.

46
DSDM CONTRACT
Criado pela DSDM Consortium e ainda em evoluo at hoje;
Tem como foco:
O trabalho sendo fit for business purpose;
Validao e aceitao baseada em testes;
E no:
Implementar o que est especificado;
Muito utilizado no Reino Unido e em outras partes da Europa.

47
MONEY FOR NOTHING
AND CHANGE FOR FREE
Abordagem contratual definida por Je Sutherland;
No incio, define um contrato padro de tempo e custo definido;
Adiciona uma clusula chamada change for free;
Esta clusula pode ser utilizada desde que o cliente coopere e
participe do projeto junto com o time em todas as iteraes;
Novas funcionalidades podem ser includas a qualquer momento no
backlog do produto, desde que uma outra funcionalidade com o
mesmo esforo/tamanho seja removida;
Define algumas clusulas que possibilitam que o projeto seja
encerrado antecipadamente.

48
MONEY FOR NOTHING
AND CHANGE FOR FREE

B Nova funcionalidade
Business value

C O projeto
termina aqui

D
ROI cut-o

Time
49
GRADUATE FIXED PRICE
CONTRACT
Neste modelo, o contratante e o contratado dividem os riscos de
variaes no cronograma

Project Completion Graduate Rate Total Fee

Finish early $110 / hour $92,000

Finish on time $100 / hour $100,000

Finish late $90 / hour $112,000

Caso o projeto seja entregue com atraso, o fornecedor receber

mais horas, entretanto a um rate menor;
No to flexvel quanto outros modelos, mas permite alguma
adaptao do escopo e prazo do projeto.

50
FIXED PRICE WORK
PACKAGES
uma abordagem que define preos fixos por pacote de trabalho;
Mitiga o risco de uma estimativa no assertiva dividindo o escopo do
projeto em pequenos pacotes, de maneira a facilitar a anlise do
tamanho e esforo de implementao de cada pacote.
prevista uma re-estimativa ao longo do projeto.
Traditional SOW: Fiexd price work packages:

$15k "

$30k $5k "

Re-estimativa
"
$10k $12k

51
CUSTOMIZED
CONTRACTS
Estas diferentes abordagens podem ser combinadas para a criao
de um contrato personalizado;
O objetivo sempre manter a flexibilidade de escopo para o
contratante, e a no penalidade de variao de prazo/custo para o
contratado;
Como benefcio, reduz a necessidade do contratado em inserir
grandes reservas em suas estimativas para a mitigao de riscos;
Como em todo contrato os benefcios devem ser mtuos;
Crie relaes ganha-ganha;
Ambos devem ter o pensamento de criar relaes de confiana e
longo prazo, e no somente para um projeto.

52
OBRIGADO!
WWW.LEANDROFARIA.COM.BR

53