Livro Metodosageis

Rafael Dias Ribeiro,MSc,CSM,CSPO,ACP,PMP.
Horcio da Cunha e Sousa Ribeiro,MSc.
Mtodos geis
em Gerenciamento de Projetos
1 Edio
Rio de Janeiro
Horcio da Cunha e Sousa Ribeiro
2015
1
Gerenciamento de Projetos
com Mtodos geis
contato@cursospin.com.br
Av. Djalma Batista, n. 946, sala 08 (Centro Empresarial Santo Remdio) - Vieiralves
Nossa Sra. das Graas Manaus
Telefone (92) 3584-1966
Site: WWW.cursospin.com.br
Rafael Dias Ribeiro

Gerenciamento de Projetos com

Mtodos geis
1 Edio
Telefone (92) 3584-1966
Rio de Janeiro
2015
Todos os direitos reservados. Nenhuma parte deste livro pode ser fotocopiada, gravada, reproduzida ou
armazenada num sistema de recuperao ou transmitida sob qualquer forma ou por qualquer meio
eletrnico ou mecnico sem o prvio consentimento dos autores.
Direito Editorial
Catalogao na fonte por: Edirlane Carvalho de Souza Freitas CRB7-5463
R484g
Ribeiro, Rafael Dias; Ribeiro, Horcio da Cunha e Sousa Ribeiro.
Gerenciamento de projetos com mtodos geis / Rafael Dias Ribeiro, Horcio da

Cunha e Sousa Ribeiro. Rio de Janeiro: [s.n.], 2015.
115 p.; il.; 23 cm.
Contm Referncias
ISBN: 978-85-919102-1-2
1. Projetos. 2. Gerncia de projetos. 3. Mtodos geis. 4. SCRUM. 5. XP. 6.
Engenharia. 7. Metodologia. I. Ttulo.
CDD 658.404
Dedicatria:
Este livro dedicado a Emanuel Bodstein
Ribeiro o projeto mais complexo da minha
vida.
Rafael Dias Ribeiro
Dedico este livro a Vera Lcia Dias Ribeiro

que foi inspirao para todo o meu trabalho.
Horacio da Cunha e Sousa Ribeiro
Contedo
CAPTULO 1 ...................................................................................................................................10
1.1 - Introduo .........................................................................................................................10
1.2 - Anlises de Ambientes ...............................................................................................11
1.2.1 -Teoria de Cynefin ..................................................................................................12
1.3 - Tolerncia ao Erro ........................................................................................................15
1.4 - Projetos Direcionados Valor e Projetos Direcionados Planos ........17
1.4.1 - Projeto Direcionado Plano: ..........................................................................17
1.4.2 - Projeto Direcionado Valor: ...........................................................................18
CAPTULO 2 ...................................................................................................................................20
2.1 Introduo: ......................................................................................................................20
2.2 - Indivduos e interaes mais que processos e ferramentas...........21
2.3 - Software em funcionamento mais que documentao abrangente .....21
2.4 - Colaborao com o cliente mais que negociao de contratos .............22
2.5 - Responder a mudanas mais que seguir um plano .....................................22
2.6 - Os 12 Princpios por trs do Manifesto: .............................................................23
2.7 - Declarao de Interdependncia ......................................................................24
CAPTULO 3 ...................................................................................................................................25
3.1 Feature Driven Development(FDD) - Desenvolvimento Dirigido a
Funcionalidades .......................................................................................................................25
3.1.1 - Modelagem de Domnio do Objeto: ........................................................25
3.1.2 - Desenvolvimento por Funcionalidade:.................................................26
3.1.3 - Propriedade Individual(cdigo): ...............................................................26
3.1.4 - Times Dinmicos: ..............................................................................................26
3.1.5 - Inspees: ..............................................................................................................26
3.1.6 - Gerenciamento de Configurao:............................................................26
3.1.7 - Construes Regulares: ...............................................................................26
3.1.8 - Visibilidade: ...........................................................................................................26
3.2 - Dynamic Systems Development Method(DSDM) - Metodologia de
Desenvolvimento de Sistemas Dinmicos ..................................................................27
3.2.1 - - Ciclo de Vida DSDM ........................................................................................27
3.3 - Crystal ...............................................................................................................................29
3.4 - Lean Software Development Desenvolvimento de Software
Enxuto ..........................................................................................................................................30
3.5 - KanBan .............................................................................................................................33
CAPTULO 4 ...................................................................................................................................37
4.1 - eXtremingProgramming .........................................................................................37
7
4.2 - Como realizar o TDD ? .......................................................................................42

CAPTULO 5 ...................................................................................................................................47
5.1 - SCRUM ..............................................................................................................................47
5.1.1 - Histria ......................................................................................................................47
5.2 - Pilares SCRUM ..............................................................................................................48
5.3 - O Framework SCRUM ................................................................................................48
5.4 - Artefatos, Eventos e Papis ....................................................................................51
5.4.1 - Backlog de Produto( Product Backlog) ..................................................51
5.4.2 - Backlog da Sprint (Sprint Backlog) ..............................................................51
5.5 - Os papis e responsabilidades no Scrum: .......................................................52
5.6 - Eventos Scrum ...............................................................................................................59
5.6.1 - Sprint ..........................................................................................................................59
5.6.2 - Reunio de Planejamento - Planning Meeting .......................................59
5.6.4 - Scrum Dirio - Daily Scrum .............................................................................60
5.6.5 - Reunio de Reviso da Sprint - Review Meeting .................................61
5.6.6 - Reunio de Retrospectiva da Sprint - Retrospective Meeting ........61
5.6 - Dinmica Bons e Ruins ..............................................................................................63
5.7 - Consideraes: ..............................................................................................................65
5.8 - Dinmica Mercado de Habilidades (Market ofSkills) ...................................66
5.8 - Tcnica PrOpER............................................................................................................68
5.8.1 - Problema: .................................................................................................................68
5.8.2 - Opes: .....................................................................................................................69
5.8.3 - Experimente: ..........................................................................................................69
5.8.4 - Reviso: ....................................................................................................................69
5.8.5 - EXEMPLO: ..............................................................................................................69
CAPTULO 6 ...................................................................................................................................72
6.1 - Planejamento Orientado Valor ...........................................................................72
6.2 - Viso em um projeto gil ...........................................................................................73
6.3 - Planos Adaptativos ......................................................................................................76
6.4 - Planejamento de Release ....................................................................................77
6.5 - User Story .........................................................................................................................78
6.6 - Stories, Temas e EPICS............................................................................................81
6.7 - Priorizao de Backlog...............................................................................................82
6.8 - Priority markets ..............................................................................................................84
6.9 - Theme screening ..........................................................................................................90
6.10 - Kano model ...................................................................................................................92
6.11 - MMF Minimum Marketable Feature...............................................................95

CAPTULO 7 ...................................................................................................................................97
7.1 - Estimativas geis ..........................................................................................................97
7.2 - Um pouco mais sobre times geis..................................................................... 102
7.3 - Liderana Adaptativa ................................................................................................. 103
7.4 - Inteligncia Emocional............................................................................................. 107
7.5 - Comunicao e o ambiente de trabalho ......................................................... 108
7.6 - Equipes virtuais........................................................................................................... 112
7.7 - Acompanhamento de produtividade ................................................................. 112
7.8 Cumulative Flow Diagram(CFD) ........................................................................ 114
MENSAGEM FINAL ................................................................................................................. 116
SOBRE OS AUTORES:..................................................................................................... 117
Rafael Dias Ribeiro................................................................................................................ 117
Horcio da Cunha e Sousa Ribeiro .................................................................................. 118
CAPTULO 1
1.1 - Introduo
Pela necessidade de um aumento contnuo de competitividade, com
o dinamismo e a velocidade com que a informao e o conhecimento
circulam, o ambiente corporativo de vrias empresas necessita utilizar a
gerncia atravs de projetos para se tornar mais eficaz, gil e competitivo.
H uma crescente demanda de profissionais detentores de
habilidades para gerenciar projetos, que utilizem boas prticas e ferramentas
para alcanar os objetivos do projeto e no apenas intuio ou bom senso.
Para responder a esse desafio, colaboradores devem reunir atributos de
conhecimentos tcnicos sobre gerenciamento de projetos, usando de modo
eficiente esse conhecimento, aumentando as chances de sucesso do projeto.
Neste captulo, iremos compreender o que realmente um projeto e vamos
identificar as caractersticas de projetos orientados a planos e de projetos
orientados a valor.
muito comum no meio corporativo, ouvirmos:
Prximo ms, iniciamos o Projeto XYZ(...)
Esto todos dedicados ao Projeto XYZ(...)
Mas ser que o conceito de projeto usado corretamente? Vamos
entender o que um projeto e suas caractersticas.
A definio do PMBoK-Project Management Body of Knowledge,
sobre projeto, :
Um PROJETO um esforo temporrio empreendido
para criar um produto, servio ou resultado exclusivo.
Observe que os projetos possuem caractersticas bem significativas,
10
como:
Temporrios, possuem um incio e um fim definidos;
Planejados, executados e controlados;
Entregam produtos, servios ou resultados exclusivos;
Desenvolvidos em etapas, implementam uma elaborao
progressiva; realizados por pessoas; sofrem restries.
A empresa, assim como a execuo de determinados projetos,
algo vivo, que muda seu comportamento durante a execuo e, em
momentos diversos, poder exigir abordagens diferentes do gestor.
1.2 - Anlises de Ambientes

No livro Management 3.0, de Jurgen Appelo, o autor procura explicar
as diferenas entre os possveis ambientes organizacionais, nos quais
projetos ocorrem(neste trabalho, chamaremos de cenrios) utilizando duas
dimenses distintas.
A primeira dimenso diz respeito estrutura do sistema:
Simples: Fcil de entender.
Complicado: Muito difcil de entender.
A segunda dimenso diz respeito ao comportamento do sistema:
Ordenado: Totalmente previsvel.
Complexo: Parcialmente previsvel, mas com muitas surpresas.
Catico: Imprevisvel.
11
1.2.1 -Teoria de Cynefin

Outra abordagem sobre os ambientes organizacionais o Cynefin
Framework, de Dave Snowden, que descreve uma perspectiva sobre a
natureza evolutiva de sistemas complexos, inclui sua incerteza inerente.
O nome serve como um lembrete de que todas as interaes
humanas so fortemente influenciadas e, muitas vezes, determinadas por
nossas experincias, tanto atravs da interferncia direta da experincia
pessoal, bem como atravs da experincia coletiva, tais como histrias ou
msica.
O Cynefin Framework tem cinco domnios. Os quatro primeiros so:

Simples: voc faz X e voc sempre ter Y, e no importa quantas
vezes voc faz X, voc obter o mesmo resultado Y. Voc pode prever com
confiana o resultado final da atividade. Nesses casos, a coordenao pode
ser usada com grande efeito.
A relao entre causa e efeito bvia para todos. A abordagem :
Sentir - Categorizar - Responder e, assim, podemos aplicar as melhores
prticas(Best Practice).
12
Por exemplo, em uma loja do McDonalds, s existe uma melhor

forma de preparar um hambrguer(sempre a mesma temperatura e sempre a
mesma durao), o procedimento j predefinido e treinado.
Complicado: existe uma relao entre causa e efeito, porm voc
tem que investir tempo e energia em trabalhar fora dessa relao e, muitas
vezes, h uma srie de possveis respostas. Esse o reino de especialistas
que concentram tempo e energia em trabalhar tais relaes de causa e
efeito. Nesse caso, a cooperao eficaz nesse domnio, porque muitas
vezes h um objetivo final claro em mente, mas voc precisa das foras
combinadas de uma gama de pessoas para alcan-lo.
A relao entre causa e efeito requer uma anlise ou alguma outra
forma de investigao e / ou a aplicao de conhecimento especializado. A
abordagem Sentir - Analisar - Responder e, nesse caso, podemos aplicar
boas prticas (Good Practice).
Por exemplo, existem diversas formas de se criar a mistura do
concreto em uma obra. Dependendo da temperatura, umidade, ferramenta e
outros fatores, se pode utilizar uma tcnica em detrimento de outra. Por
exemplo, na obra da Usina de Itaipu, na mistura do concreto, foi utilizado
escamas de gelo, em vez de gua no estado lquido, para evitar micro
fissuras. Em uma construo, no comum se utilizar gelo no processo de
concretagem.
Complexo: esse domnio caracterizado por causas e efeitos que
so to entrelaados e intrincados que as coisas s fazem sentido em
retrospecto. Voc ouve as pessoas dizerem: "Ah, este resultado aconteceu
porque(...)", mas se voc voltar um pouco atrs e verificar o que aconteceu,
de fato, vai obter um resultado diferente.
Retroceder e voltar a jogar, e ainda ter outro resultado. Esse
fenmeno ocorre porque, em situaes complexas, tudo to interligado que
uma pequena mudana em uma parte do sistema pode ter um impacto
enorme em outro lugar e vice-versa.
13
O sistema imprevisvel em detalhes, mais ainda podemos discernir

padres. So nessas situaes complexas que a colaborao vem tona. A
colaborao funciona bem para cenrios complexos, pois o estilo de
trabalhar de forma colaborativa corresponde natureza das questes que
representam situaes complexas.
Complexidade
imprevisvel,
colaborativa,
adaptvel;
complexidade confuso difcil trabalhar a questo, e muito menos a

resposta colaborativa, pois envolve reunir uma diversidade de pessoas e
talentos para experimentar, criar e testar possveis abordagens para a
soluo de um determinado problema.
Complexidade imprevisvel, isto , dependendo dos fatores(ex:
clima organizacional, relacionamento interpessoal, autoconhecimento da
equipe, conhecimento prvio do trabalho que ser realizado e outros) no
temos a certeza do resultado produzido. Assim, no ambiente complexo,
temos um grande esforo para desenvolver o aspecto de confiana entre os
membros da equipe para que proporcione maior criatividade e, dessa forma,
inovaes. A relao entre causa e efeito s pode ser percebida em
retrospecto, mas no com antecedncia. A abordagem Probabilidade Sentir
Responder
e,
assim,
podemos
aplicar
prtica
emergente(emergente).
Por exemplo, ao entrar em um consultrio mdico e relatar que est
com dor no estmago(efeito), alm de tratar dos efeitos, o mdico ir iniciar
uma srie de testes at descobrir a causa.
Catico: este o lugar no qual impossvel discernir a relao entre
causa e efeito. A melhor abordagem nesse domnio simplesmente agir.
No h nenhuma relao entre causa e efeito no nvel de sistemas, a
abordagem Agir - Sentir - Responder e, assim, podemos descobrir novas
prticas.
14
Desordem: o quinto domnio. o estado de no saber que tipo de

causalidade existe. Em pleno uso, a estrutura do Cynefin tem subdomnios, e
o limite entre simples e catico visto como algo catastrfico.
Um exemplo bem interessante sobre a mudana do ambiente de
simples para catico ilustrado no filme, Um Dia de Fria(Falling Down,
1993), no qual o ator principal se irrita com uma regra(normal em sistemas
simples) e provoca algo catastrfico.
Observe que existe um grande esforo das empresas em
transformarem aes complexas em complicadas e, posteriormente, em
simples(o
que
no
possvel
para
todas
as
atividades),
pois
economicamente mais interessante e facilita a expanso do modelo.
1.3 - Tolerncia ao Erro

Atravs da atividade anterior, fomos capazes de identificar cenrios
simples, complexos e complicados. Iremos analisar agora a tolerncia ao
erro(ou melhor, possibilidade de aprender com o erro) e o tempo de
resposta do sistema.
Nos cenrios caticos e complexos, o erro melhor entendido do
que nos cenrios simples e complicados, j que a relao causa-efeito no
existe ou desconhecida. Essa aceitao conhecida com Fail Fast ou
Learning Fast.
Nos cenrios simples e caticos, o tempo de resposta precisa ser
mais rpido do que nos cenrios complexos e complicados, pois a demora
pode provocar perdas significativas. Por exemplo, caso voc entre em uma
lanchonete do tipo fast food(cenrio simples) e o atendimento demore por
volta de 20 minutos, voc provavelmente ir procurar outro estabelecimento
para fazer sua refeio ou, em um prdio incendiando(cenrio catico), voc
no poder demorar muito para agir, concorda?
15
Cenrios simples e complicados so mais comuns em projetos de

construo como avies, pontes, prdios, mquinas de caf, etc. Pois
seguem um fluxo de construo de pea por pea, montagem, testes e esto
prontos para uso, seu processo pode ser decomposto em um plano bem
detalhado por etapas(ou entregas parciais) at o todo estar pronto. Projetos
complexos como softwares, desenhos e redesenhos de processos,
campanhas publicitrias e outros so construdos dia a dia, etapa aps
etapa, assim muito arriscado definir um plano muito detalhado, j que
necessidades e prioridades mudam de acordo com o andamento do projeto(e
pela prpria dinmica das organizaes).
Diferentes tipos de projetos requerem diferentes mtodos. Alguns
projetos, especialmente projetos de profissionais do conhecimento, em
ambientes de rpida transformao, tm caractersticas complexas e
necessitam de tcnicas emergentes(tcnicas de agilidade).
Caractersticas
de
Projeto
de
Caractersticas de Profissionais
Construo(Trabalho Industrial)
do Conhecimento
O trabalho visvel.
O trabalho invisvel.
O trabalho estvel.
O trabalho instvel.
nfase na execuo das etapas.
nfase na mudana.
Mais estruturao e menos deciso.
Menos estruturao e mais deciso.
Foco nas respostas certas.
Foco nas perguntas certas.
Definio de tarefas.
Entendimento das tarefas.
Comando e controle.
Autonomia.
Padronizao.
Inovao contnua.
Foco na qualidade.
Foco na qualidade.
Medio
de
desempenho
padronizada.
Minimizao
Ensinamento
aprendizado
contnuo.
do
custo
trabalhador por tarefas.
pago
ao
Trabalhador visto como um ativo e

no como custo.
Quadro de comparao do trabalho industrial com profissionais do conhecimento, adaptado de PMIACP ExamPrep, MakiGiffiths, 2012.
16
1.4 - Projetos Direcionados Valor e Projetos Direcionados

Planos
Cenrios de projetos de construo, normalmente, seguem uma
abordagem orientada a plano, j projeto complexo deve ter uma abordagem
orientada a valor, visto que a entrega final tem grande probabilidade de no
ser a ideia inicial do projeto.
1.4.1 - Projeto Direcionado Plano:
Em projetos direcionados a plano, como o prprio nome sugere,

temos um grande esforo no planejamento, pois um bom plano aumenta as
chances de uma boa execuo. O guia de boas prticas PMBok define 47
processos, em 10 reas de conhecimento, apresentados na figura abaixo,
que aumentam as chances de sucesso de um projeto.
17
1.4.2 - Projeto Direcionado Valor:
Em projetos orientados a valor, quando se investe muito no

planejamento, gerado um risco muito grande ao projeto, j em cenrios de
grande incerteza, o planejamento precisar ser baseado em muitas
premissas(eventos incertos que definimos como verdade para fins de
planejamento) que sero falsas, o que pode gerar tantas mudanas no plano
original que o esforo de adaptao no compensaria a energia gasta no
desenvolvimento do plano original.
Observe que nenhum projeto totalmente simples,
complicado ou complexo. Pacotes de trabalho de um
mesmo projeto podem ter caractersticas diferentes, sendo
assim, importante observar o momento do projeto para
definir a abordagem adequada de gerenciamento e, nisso,
o planejamento em ondas sucessivas ajuda muito.
Outro ponto importante que tcnicas de gerenciamento de projetos

complicados, como as boas prticas do PMBoK
(ex: Plano de
comunicaes, estimativas de custo, declaraes de trabalho de aquisio,

etc.), podem ser aplicadas em projetos complexos, assim como tcnicas de
agilidade (ex: Reunio de Retrospectiva, Reunio de Planejamento da
Interao, Definio de Viso do Produto, planejamento de release, etc.), de
projetos complexos, podem ser aplicadas em cenrios complicados e
simples, tudo depende da anlise do gerente do projeto.
Perguntar qual a melhor forma de gerenciar um projeto sem
conhecer o projeto em si, ambiente organizacional e o produto do projeto
equivale a perguntar o que melhor, o martelo ou o alicate? A resposta
18
depende se voc deseja pendurar um quadro ou fazer uma instalao

eltrica. Podemos concluir que NO existe uma Bala de Prata em
Gerenciamento de Projetos. Assim, o entendimento dos possveis cenrios e
o conhecimento das diversas tcnicas e ferramentas de gerenciamento so
essenciais para o gestor de projetos.
19
CAPTULO 2
2.1 Introduo:
Diferentes tipos de projetos necessitam de diferentes mtodos de
gerenciamento. A abordagem gil muito utilizada em projetos orientados a
valor. Como vimos, projetos orientados a valor geralmente so realizados por
profissionais do conhecimento e possuem elevado grau de incerteza, por
grande indefinio do escopo e elevado nmero de mudanas.
A maior parte dos conceitos e princpios geis surgiu com foco em
projetos de desenvolvimento de software e atualmente so utilizados em
diversos tipos de projetos que possuem grandes incertezas, como
campanhas publicitrias, novos produtos, planejamento de oramento e
muitas outras reas. Neste livro iremos manter o foco em projetos de
software, porm estes conceitos NO so especficos para estes tipos de
projetos.
Existem diversos tipos de abordagens geis, como veremos neste
livro e estas abordagens geis buscam estar alinhadas com diversos
princpios
definidos
no
documento
Manifesto
for
Agile
Software
Development, criado em Fevereiro de 2001, por diversos especialistas em

projetos de software e disponvel na URL http://agilemanisfesto.org
Manifesto para 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.
20
2.2 - Indivduos e interaes mais que processos e ferramentas

Observe que o primeiro valor do manifesto deixa claro uma
importante mensagem, processo e as ferramentas provavelmente sero
necessrio no projeto, porm, devemos tentar concentrar a ateno da
equipe sobre os indivduos e interaes envolvidos no projeto. Lembre-se
que projetos so realizados por pessoas, e no por ferramentas, assim como
os problemas so resolvidos por pessoas, e no processos.
Focando
primariamente
no
desenvolvimento
dos
indivduos
envolvidos no projeto e enfatizando as interaes produtivas e eficazes,

melhoramos as chances de sucesso do projeto.
Lembre-se que isso no dizer que processos e ferramentas no
podem ajudar na concluso com xito de um projeto. Processos e
ferramentas bem desenhados e adequados so ativos de grande
importncia.
2.3 - Software em funcionamento mais que documentao

abrangente
O segundo valor do manifesto destaca a necessidade entregar o
software. Projetos de software so normalmente iniciados com os objetivos
de criao de valor para a empresa por meio de um produto de software de
alta
qualidade,
mas
muitas
vezes
entregas
em
partes
intermedirias(incrementos), raramente a documentao completamente

atualizada e reflete a realidade do software, porm essencial se
documentar o que precisa ser documentado em um software, mas sem
exagero. Lembre-se sempre que software sem documentao certamente
problemtico e dificulta o suporte e a manuteno. Mas uma documentao
completa sem software no agrega absolutamente nada a nenhuma
organizao.
21
2.4 - Colaborao com o cliente mais que negociao de

contratos
O terceiro valor refora a necessidade de ser flexvel e eficiente, ao
invs de rgidos e no cooperativos. semelhante a diferena entre "estar
certo" e fazer a coisa certa". Poderamos construir o produto exatamente
como originalmente especificado, mas se o cliente mudar de ideia ou de
prioridade, voc no concorda que devemos ser flexveis e trabalhar para a
nova meta ? claro que sim, as mudanas e ajustes devero ser refletidos
em aditivos contratuais ou ajustes, mas no deve ser um impeditivo para a
continuidade do desenvolvimento e entrega do software. Atualmente existem
diversas novas formas de contratos para acolher projetos com caractersticas
geis, como pagamento de preo fixo por interao(ou Sprint), pagamento
por pontos, estrias, ou outras que permitem a flexibilidade necessria para
projetos orientados valor.
2.5 - Responder a mudanas mais que seguir um plano

Em projetos com grande nmero de incertezas, quase certo que os
planos iniciais sero alterados. Em vez de investir esforos na tentativa de
trazer o projeto de volta aos planos originais, ns deveramos gastar esforo
e energia responder s inevitveis mudanas no projeto.
Observe
que
este
valor
no
est
sugerindo
abandonar
planejamento e apenas reagir s mudanas. Ns ainda precisamos planejar,

mas temos de reconhecer que os planos iniciais foram criados quando
conhecamos menos sobre o Projeto(no incio), e com o desenvolvimento do
trabalho, vamos precisar atualizar o plano. Muitos dos mtodos geis focam
em macro planos superficiais(criao de estrias, Product Release, casos de
uso, etc) , e um planejamento mais especfico para iteraes(ou Sprints).
22
2.6 - Os 12 Princpios por trs do Manifesto:

(Disponvel em http://agilemanifesto.org/iso/ptbr/principles.html)
1. Nossa maior prioridade satisfazer o cliente atravs da entrega

contnua e adiantada de software com valor agregado.
2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no
desenvolvimento. Processos geis tiram vantagem das mudanas
visando vantagem competitiva para o cliente.
3. Entregar
frequentemente
software
funcionando,
de
poucas
semanas a poucos meses, com preferncia menor escala de

tempo.
4. Pessoas
de
negcio
desenvolvedores
devem
trabalhar
diariamente em conjunto por todo o projeto.

5. Construa projetos em torno de indivduos motivados. D a eles o
ambiente e o suporte necessrio e confie neles para fazer o
trabalho.
6. O mtodo mais eficiente e eficaz de transmitir informaes para e
entre uma equipe de desenvolvimento atravs de conversa face
a face.
7. Software funcionando a medida primria de progresso. Os
processos geis promovem desenvolvimento sustentvel. Os
patrocinadores, desenvolvedores e usurios devem ser capazes
de manter um ritmo constante indefinidamente.
8. Contnua ateno excelncia tcnica e bom design aumenta a
agilidade.
9. Simplicidade - a arte de maximizar a quantidade de trabalho no
realizado essencial.
10.
As melhores arquiteturas, requisitos e designs emergem de
equipes auto-organizveis
11.
Em intervalos regulares, a equipe reflete sobre como se tornar
mais eficaz e ento refina e ajusta seu comportamento de acordo.
23
2.7 - Declarao de Interdependncia

Em 2005, The Agile Leader ship Network(ALN), criou a Declarao
de Interdependncia para Gerenciamento de Projetos geis e est disponvel
em http://pmdoi.org/
A Declarao de Interdependncia
promove abordagens geis e
adaptveis para unir as pessoas , projetos e valor. Para alcanar estes

resultados :
Ns aumentamos o retorno sobre o investimento, fazendo fluxo
contnuo de valor, o nosso foco.
Ns entregamos resultados confiveis por envolver os clientes em
interaes frequentes e compartilhamos a propriedade.
Esperamos a incerteza e a gerenciamos atravs de iteraes ,
antecipaes, e adaptaes.
Ns liberamos a criatividade e inovao, reconhecendo que os
indivduos so a melhor fonte de valor, e criando um ambiente
onde eles podem fazer a diferena.
Ns melhoramos o desempenho atravs de prestao de contas
do grupo para resultados e responsabilidade compartilhada para a
eficcia do time.
Ns melhoramos a eficcia e confiabilidade por meio de
estratgias especficas, processos e prticas.
Existem diversas metodologias e frameworks geis, os mais comuns
e utilizados so o Scrum, Extreme Programming(XP), Feature Driven
Development(FDD), Dynamic Systems Development Method(DSDM), Crystal,
Lean, KanBan, e outros.
O Scrum e o XP sero mais detalhados nos prximos captulos, pois
so os de maior aceitao e uso no Brasil, porm todos possuem
caractersticas muito valiosas para o gerenciamento de projetos orientados a
valor.
24
CAPTULO 3
3.1 Feature Driven Development(FDD) - Desenvolvimento
Dirigido a Funcionalidades
uma abordagem simples de entender e poderosa para o
desenvolvimento de produtos. Uma equipe de projeto seguindo o mtodo
FDD ir primeiro desenvolver um modelo global para o produto, construir lista
de recursos e planejar o trabalho. A equipe ento se move atravs da
concepo e construo de iteraes para desenvolver cada recurso. O FDD
busca apresentar resultados frequentes, tangveis e funcionais.
Desenvolver um
modelo global para o
produto
Crie uma lista de

funcionalidades
Planeje por
funcionalidade
Projete por
Projete
por
funcionalida
Projete
por
funcionalid
de
funcionalida
ade
de
Construa
Construa
por
Construa
por
funcionalida
por de
funcionalid
funcionalida
ade
de
O FDD recomenda uma srie de boas prticas oriundas da

Engenharia de Software, como:
3.1.1 - Modelagem de Domnio do Objeto:
As equipes de explorar e explicar o domnio (ou ambiente de
negcios ) do problema a ser resolvido.
25
3.1.2 - Desenvolvimento por Funcionalidade:

Esta prtica envolve decompor as necessidades em funcionalidades
e definir perodos de desenvolvimento de uma ou mais funcionalidades em
intervalos de duas semanas ou mais curtos.
3.1.3 - Propriedade Individual(cdigo):
As reas de cdigo devem ter um nico proprietrio para garantir
consistncia, desempenho e integridade conceitual.
(Nota: que um bem diferente da ideia de Propriedade Cdigo
Coletiva do XP que visa difundir o conhecimento para outros membros da
equipe ) .
3.1.4 - Times Dinmicos:
Estes so pequenas equipes, formadas dinamicamente de acordo
com caractersticas de cada projeto. Os times ajudam a mitigar o risco
associado propriedade individual.
3.1.5 - Inspees:
So revises que ajudam a garantir boa qualidade e design de
cdigo.
3.1.6 - Gerenciamento de Configurao:
Essa prtica envolve rotulagem de cdigo, controle de alteraes e
gerenciamento do cdigo fonte.
3.1.7 - Construes Regulares:
Atravs de entregas pequenas e constantes, o time incrementa o
produto de software com a nova funcionalidade desenvolvida. Esta prtica
tambm permite criar facilmente uma verso demo.
3.1.8 - Visibilidade:
Controle e acompanhamento do progresso e dos resultados baseado
em funcionalidades desenvolvidas.
Voc poder aprofundar seus conhecimentos sobre o FDD, acessando o web site
oficial da metodologia, na URL: http://www.featuredrivendevelopment.com/
26
3.2 - Dynamic Systems Development Method(DSDM) Metodologia de Desenvolvimento de Sistemas Dinmicos

DSDM foi um dos pioneiros dos mtodos geis. uma metodologia
de desenvolvimento bastante prescritiva, baseada em Rapid Application
Development (RAD)- Desenvolvimento Rpido de Aplicaes, o DSDM
enfatiza o envolvimento constante do usurio durante todo o projeto. Cria um
amplo ciclo de vida de projeto, abrangendo aspectos de um projeto gil
analisando sempre a viabilidade e necessidade do negcio para a
implementao.
3.2.1 - - Ciclo de Vida DSDM
O ciclo de vida do DSDM tanto iterativo e incremental. Portanto, a

soluo no pode ser entregue empresa de uma s vez, mas de uma srie
de incrementos que incrementam a soluo com cada entrega. Desta forma,
as necessidades de negcios urgentes podem ser priorizadas e abordadas
cedo, enquanto caractersticas menos importantes so implementadas e
entregues mais tarde.
A natureza iterativa permite que os representantes de negcios
vejam e se envolvam no trabalho em construo, analisando e j sugerindo
os ajustes e alteraes necessrias durante o desenvolvimento de um
incremento da soluo. Faz parte do ciclo de vida DSDM o ciclo de vida de
um projeto de gesto e um ciclo de vida de desenvolvimento de produtos em
um nico processo. O DSDM pode ser utilizado sozinho como metodologia
gil, porm o uso do DSDM com outros mtodos e boas prticas de
gerenciamento de projetos ou tcnicas de desenvolvimento detalhados
podem contribuir para a melhora nos processos e resultados.
27
CICLO DE VIDA DSDM

Fonte: http://www.dsdm.org/content/6-lifecycle
O DSDM centrado em 8 princpios(definidos antes da criao do

Manifesto gil, porm bem alinhados com os valores defendidos no
Manifesto gil). So eles:
Foco na necessidade de negcio
Entregas no prazo
Colaborao
NUNCA comprometa a qualidade
Desenvolvimento incremental com bases slidas
Desenvolva iterativamente
Comunicao contnua e clara
Demonstre Controle
Voc poder aprofundar seus conhecimentos sobre o DSDM, acessando o
web site oficial da metodologia, na URL http://www.dsdm.org/
28
3.3 - Crystal
Crystal uma famlia de metodologias desenvolvidas por Alistair
Cockburn, em meados da dcada de 1990, destinadas para projetos que vo
desde aqueles executados por pequenas equipes de desenvolvimento com
baixa criticidade e prove abordagens at com grandes equipes que
implementam sistemas de alta criticidade.
A famlia de metodologias Crystal utiliza cores diferentes para indicar
o "peso" do projeto e qual a metodologia aplicar.
Criticidade
(Defeitos causam
perda de ...)
Nmero de Pessoas Envolvidas
A Famlia Crystal promove uma srie de princpios geis, como:

Entregas Frequentes
Melhoria Reflexiva (Verificao constante e busca contnua de
promoo de melhoria e implementao de novos mtodos)
Comunicao Osmtica (Membros so alocados prximos uns
dos outros para melhorar a comunicao, este conceito tambm
conhecido como War Room - Sala de Guerra. Veremos mais
sobre comunicao mais adiante)
29
Segurana Pessoal (O Crystal defende um ambiente seguro

para
que
todos
possam
apresentar
suas
dvidas
questionamentos)
Foco (Cada membro do time deve saber o que precisa fazer e ter
liberdade suficiente para trabalhar no que necessrio)
Fcil acesso ao usurio (Fcil acesso aos usurios chaves e
rpido feedback)
Ambiente automatizado (Testes automatizados, controle de
configuraes, integrao contnua,...)
Voc poder aprofundar seus conhecimentos sobre o Crystal, acessando o

web site do criador destas metodologias, na URL: http://alistair.cockburn.us/
3.4 - Lean Software Development Desenvolvimento de Software
Enxuto
O Lean no especificamente uma metodologia gil, porm muitos
de seus valores esto presentes em valores geis e sua adoo pode
agregar muitos valores em diversas outras metodologias e boas prticas.
Baseado na metodologia desenvolvida pela Toyota conhecida como Lean
Manufacturing.
O Lean est diretamente ligado a reduo do desperdcio, para o
Lean, desperdcio tudo que no feito para o cliente, no caso dos
softwares podemos ter: Espera(tempo de desenvolvimento parado por falta
de informaes), documentao excessiva, funcionalidades e rotinas no
solicitadas pelo cliente.
30
O Lean Software Development identifica sete conceitos principais,

so eles:
Eliminar o Desperdcio: Para maximizar o valor, precisamos
minimizar o desperdcio.
O Lean classifica o desperdcio em 3 categorias:
MURA:
Desperdcio
gerado
por
antecipar
possveis
necessidades do cliente (desenvolver o que no foi solicitado pelo

cliente acreditando que um dia poder ser til. Este conceito est
muito prximo ao de Gold Plating, do gerenciamento de projetos).
Podemos diminuir a MURA evitando desenvolver o que no foi
solicitado e evitando paradas em trabalhos ainda no terminados.
MURI: Desperdcio gerado pela falta de planejamento (ou
planejamento mal feito). Na MURI tambm classificamos o desperdcio
causado pelo excesso de burocracia.
MUDA:
Desperdcio
gerado
pela
cultura
de
trabalho,
desperdcios do dia a dia, como: espera, super processamento,

defeitos, locomoo, inventrio, transporte desnecessrio e super
produo.
Empoderar o Time: Em vez de da abordagem de micro gesto,
devemos respeitar o conhecimento superior dos membros do time e deixar
que eles sejam responsveis pelas decises tcnicas(locais) necessrias,
para tornarem-se mais produtivos e bem sucedidos, aumentando as chances
de sucesso do projeto.
Entregar Rapidamente: Podemos aumentar o Retorno sobre
Investimento (return on investment) ROI com entregas de valor rpidas.
Com entregas rpidas e frequentes o cliente j pode iniciar o uso do software
(das funcionalidades j desenvolvidas) gerando valor mais rapidamente para
31
o investimento realizado no desenvolvimento. Como o cliente prioriza o que

deve ser feito primeiro, funcionalidades mais importantes (e as de maior
risco, assunto que ser tratado mais adiante) geralmente so produzidas
mais cedo, e consequentemente, entram em uso mais cedo, gerando maior
retorno.
Otimizar o todo: Para o Lean o sistema no apenas a soma de
suas partes, devemos observar como alm de cada parte e sim como todas
esto alinhadas aos interesses de negcio da empresa e como otimiz-las da
melhor forma possvel.
Construir com Qualidade: O Lean no testa a qualidade no final do
processo. A qualidade do produto final deve ser assegurada com a qualidade
de cada etapa/ parte do processo utilizando tcnicas como refatorao,
integrao contnua e muitas outras que veremos mais adiante.
Adiar Decises: Parece estranho este conceito mas a mensagem
aqui equilibramos o planejamento antecipado com a tomada de decises e
decidirmos o mais tarde possvel. Veja que no estamos defendendo a
procrastinao, mas sim esperarmos o mximo possvel antes de decidir.
Em muitos projetos na fase inicial estamos decidindo baseado em
vrias premissas (lembrando, Premissa - Eventos incertos que para fins de
planejamento consideramos como verdadeiros o que na execuo do projeto
no necessariamente ser verdadeira), o que sempre trs riscos ao projeto,
como estar restrito a uma soluo limitada por uma tecnologia disponvel at
o momento.
Amplificar
Aprendizagem:
Este
conceito
envolve
facilitar a
comunicao cedo e sempre, promovendo o feedback o mais rpido possvel,

e aprendizado contnuo com base no que aprendemos sobre projetos,
softwares e negcios.
Voc poder aprofundar seus conhecimentos sobre o Lean, acessando o
web site oficial do Lean, na URL http://www.thetoyotasystem.com/
32
3.5 - KanBan
Antes de iniciarmos nossa conversa sobre o KanBan, deixem contar
uma histria sobre os jardins do palcio imperial Japons. Em Abril, centenas
de visitantes vo aos jardins do palcio para apreciarem as flores de
Sakura(flor de cerejeira). Como os jardins, apesar de grandes, so limitados
fisicamente, existe um controle de cartes de entrada e sada.
Um visitante para entrar nos jardins precisa de um carto, este carto

retirado na entrada e devolvido na sada. Um novo visitante s entra se
tiver cartes disponveis. O que este carto controla? O nmero de
atividades(pessoas) que os Jardins so capazes de atender. Um controle
simples e eficiente garante o atendimento sem prejudicar a qualidade do
servio.
Fim
Sada
(+1 Ticket)
Incio
Entrada
(-1 Ticket)
Visitante
O KanBan possui a mesma filosofia dos cartes, uma ferramenta

visual que auxilia o acompanhamento do fluxo de trabalho e controle do WIP(
Work in Progress, Trabalho em Progresso ).
33
O Quadro Kanban permite visualizar o trabalho que est em

andamento e limitar o WIP. Tradicionalmente (mas NO uma REGRA), o
quadro Kanban dividido em quadros ou status como DO( Fazer)
DOING(Fazendo) DONE(Feito), as tarefas que preciso ser realizadas so
listadas(ou coladas) na parte Fazer, quando elas comeam a ser feitas,
elas mudam para o status Fazendo e quando esto(totalmente) prontas, vo
para o status Feito, bem os status podem ser completamente diferentes, por
exemplo, no caso de desenvolvimento de software poderamos ter
Modelado,
Em
Desenvolvimento,
Desenvolvido,
Em
implantao,
Pronto. Ou qualquer outro estado que faa sentido para o trabalho e para a
equipe.
Exemplo que quadro KanBan com tarefas no iniciadas
Limitador
Exemplo de quadro KanBan com tarefas em andamento. Observe

que cada inventrio pode determinar um limitador de tarefas que podem ser
feitas paralelamente, no exemplo o nmero mximo de tarefas que podem
34
estar no inventrio 1 , so duas paralelamente. Este limitador, geralmente

est associado a capacidade de atendimento da equipe.
Exemplo que quadro KanBan no desenvolvimento de Software.
Pois bem, como um sistema de controle visual pode ser to til ? O

Quadro Kanban permite:
Visualizar o Fluxo de Trabalho: O quadro KanBan uma excelente
ferramenta
Low-Tech,
High
Touch.Quando
inserimos
tarefa(ou
funcionalidade) no quadro, tornamos o trabalho tangvel, o que um desafio

para gerentes de projetos de softwares e servios. A visualizao nos permite
identificar onde esto ocorrendo os gargalos no fluxo de trabalho e assim
melhorar os processos redesenhando-os ou redimensionando a equipe em
cada tarefa.
Limitar o WIP (Trabalho em Progresso): O Trabalho at estar
pronto para o uso custo, por exemplo, uma funcionalidade em
desenvolvimento que ainda no utilizada agrega algum valor para a
empresa ? Um servio que est sendo desenhado, agrega ? NO ! S temos
valor quando a funcionalidade ou servio podem ser utilizados pela empresa.
Uma das regras mais importantes para qualquer metodologia ou framework
gil ENTREGAR MAIS QUE INICIAR.
No Quadro KanBan pode-se definir limites para no iniciar novas
atividades at que as que esto no status Fazendo migrem para Feito.
35
Tornar Regras e Processos Explcitos: Com o quadro mais fcil

discutirmos os trabalhos que esto em andamento, que precisaro ser feitos
e como um trabalho em andamento poder impactar em outro.
Colaborao: A percepo visual do trabalho facilita a o debate
aberto do time sobre como resolver atividades que esto engarrafando o
fluxo, alm de dar a percepo do todo(do conjunto de atividades feitas,
fazendo e fazer).
Voc poder aprofundar seus conhecimentos sobre o KanBan, acessando o
web site oficial do KanBan, na URL http://www.thetoyotasystem.com/
36
CAPTULO 4
4.1 - eXtremingProgramming
Os Valores em XP so conceitos no tangveis que se acredita fazer
uma grande diferena na qualidade final do produto e na motivao dos
times. Eles so:
Valores:
Comunicao
O valor da comunicao visto dentro do time, entre seus
membros, e entre o time e o cliente. Ambos tm igual importncia.
A comunicao deve ser:
DIRETA
EFICAZ
ESCLARECEDORA
Feedback
um valor que engloba as relaes interpessoais, mas tambm
se refere ao feedback que o prprio cdigo do projeto devolve aos
membros do time.
Para que o feedback do cdigo funcione bem, so necessrios
testes automatizados de unidade e um servidor de integrao contnua
para que os testes mais longos sejam rodados com freqncia e, se
quebrarem, sinalizem uma inconsistncia. Com o feedback o cliente pode:
Identificar erros rapidamente
Definir prioridades
37
Imagem de ciclos de Feedback do XP

Coragem
O XP prega que os desenvolvedores precisam ter coragem para
refatorar o cdigo em prol de melhorias em clareza e design e nada
melhor para dar coragem do que testes automatizados.
Coragem tambm apagar o cdigo, mesmo funcionalidades
inteiras, no importa o trabalho que tenha sido empregado para
desenvolv-la.
Coragem para no tentar prever o futuro, mas sim focar no que
realmente necessrio no momento. XP associa a essa ideia a sigla
YAGNI(you aint gonna need it- voc no vai precisar disso)
Simplicidade
Considere que, na mdia, o tempo de construo de um software
cerca de 30% do tempo investido nele. Os outros 70% so dedicados a
manuteno do sistema. Neste tipo de cenrio, a simplicidade essencial
para tornar esse perodo maior muito agradvel.
O desenvolvedor deve:
Implementar apenas o bsico
No antecipar funcionalidades (No gerar Gold Plating)
38
Propriedade Coletiva do Cdigo
comum
que
desenvolvedores
trabalhem
em
partes
independentes do cdigo. A consequncia desta abordagem que

cada desenvolvedor se sente responsvel apenas por sua parte.
O ideal o sentimento de time onde todos so responsveis
pelo cdigo. Assim, um desenvolvedor livre para interferir em
qualquer parte do cdigo sem irritar o dono do cdigo.
Programao Pareada(Pair Programming)
A programao em par uma forma eficaz de reduzir a
incidncia de bugs em um sistema. Quem trabalha continuamente com
programao em par se habitua a corrigir e ter seu trabalho corrigido
dezenas de vezes ao dia.
A incidncia de erros identificados pelo colega costuma ser to
elevada que surpreende quem no est acostumado ao uso da tcnica
e as equipes que trabalham em par conseguem reduzir drasticamente
a insero de defeitos em seus cdigos.
A programao em par ajuda os desenvolvedores a criarem
solues mais simples, mais rpidas de implementar e mais fceis de
manter. A programao em par tambm uma forma de fazer com
que o desenvolvedor tenha mais confiana no cdigo que produz.
Observe que todas estas caracterstica fazem com que a programao
em par acelere o desenvolvimento significativamente, embora
primeira vista parea o contrrio.
39
Programar em par exige que as pessoas envolvidas sejam

receptivas, compreensivas umas com as outras, engajadas e,
sobretudo, humildes. necessrio aceitar que somos falveis para
que possamos programar em par. Jerry Weinberg, no livro The
Psychologyof Computer Programming apresenta o termo ego less
programming, ou seja, programao sem ego.
Descubra
mais
sobre
ego
less
programming
no
site:http://blog.codinghorror.com/the-ten-commandments-ofegoless-programming/
Testes Automatizados eRefatorao

Um dos grandes desafios trabalhar em cdigos antigos.... O XP
prega a refatorao constante! Mas, quanto maior o projeto, maior a
quantidade de cdigo no escrita por ns ou antigo, o que aumenta a
insegurana de refatorar o cdigo impedindo a evoluo do projeto.
Com o aumento do projeto comum que pequenas partes de
cdigo mal escrito se acumulem e, quando menos se esperar,
compromete todo o projeto. Este conceito foi nomeado por Joe Yoder
como Big Ball of Mud.
A melhor forma de evitar este problema atravs de pequenas
refatoraes constantes.
O autor Martin Fowler define refatorao como:
uma tcnica controlada para reestruturar um trecho de
cdigo existente, alterando sua estrutura interna sem
modificar seu comportamento externo.
40
Exemplo de acmulo de dbito tcnico ao passar do tempo.

Representa-se na figura acima que quando refatoramos constantemente,
representado na figura com ondas com a legenda Minutos, nosso dbito
perceptivelmente menor do que quando refatoramos com intervalos de
dias ou semanas.
Este comportamento tambm refletido na economia gerada com
o hbito da refatorao constante. Na imagem abaixo, o eixo vertical
representa o dbito tcnico no cdigo, quanto mais cedo os ajustes
necessrios forem realizados, menor ser o custo da mudana para
ajustes tcnicos.
Imagem que representa o custo dos ajustes tcnicos no cdigo durante o tempo do projeto.
41
O XP prega o uso extensivo de testes automatizados que

descrevem o comportamento de uma funcionalidade, preferencialmente
escritos antes mesmo do cdigo que eles testam, prtica que recebe o
nome de desenvolvimento dirigido por testes (Test Driven Development TDD).
Os testes automatizados tem 2 funes importantes:
Permitir refatorao: Podemos refatorar o cdigo com mais

segurana. Isto , podemos alterar o cdigo e verificar
automaticamente se o software continua funcionando.
Documentar: Os testes devem ter nomes que explicam quais

funcionalidades eles testam, assim ao executar o cdigo, o
desenvolvedor
sabe
quais
funcionalidades
foram
implementadas e qual o comportamento esperado pelo cdigo.
4.2 - Como realizar o TDD ?

A filosofia do TDD que os testes guiem o prprio design das
classes do sistema.
O processo TDD funciona da seguinte maneira:
1 Faz-se o teste automatizado para o caso mais simples
2 Roda-se o teste (que no dever passar pois a funcionalidade
ainda no foi implementada)
3 Implementa-se atravs da mudana mais simples possvel que
faa o teste passar
4 Se o cdigo no estiver o melhor possvel:
- Refatora
- Certifique-se que os testes continuem passando
5 Se o cdigo estiver bom
- Volte para o primeiro item com o prximo teste mais
simples
42
Vejamos como os conceitos do TDD podem ser aplicados utilizando

um exemplo para desenvolvimento de um simulador do jogo de cartas Black
Jack
O Black Jack jogado com um ou mais baralhos de 52 cartas, para
cujos valores sero designados um total de pontos.
As cartas de 2 a 10 tero o valor dos nmeros. Reis, damas e valetes

valem 10 pontos cada e ases podero ser usados tanto como 1 ou 11.
O objetivo para o jogador ser comprar cartas at um total de 21
pontos(sem exceder), vencendo o total das cartas do distribuidor.
Passo 1: Desenho do deque de cartas( Design a deck of cards)
public class Deck
{
privatereadonlyIlist<Card> cards = new List<Card>( );
public Deck( )
{
cards.Add(Card.Dois_de_Copas);
cards.Add(Card.Tres_de_Copas);
//..restante de copas
cards.Add(Card.Dois_de_Ouros);
cards.Add(Card.Tres_de_Ouros);
//..restante de ouros
cards.Add(Card.Dois_de_Espadas);
cards.Add(Card.Tres_de_Espadas);
//..restante de Espadas
cards.Add(Card.Dois_de_Paus);
cards.Add(Card.Tres_de_Paus);
//..restante de paus
//Coringa
cards.Add(Card.Coringa);
}
43
Defeito identificado ! No existe Coringa no Black Jack. Como

testar automaticamente em cada novo incremento para que problemas assim
no ocorram ?
Devemos criar os Critrios de Teste, para o Black Jack vamos testar
se existem:
52 cartas no Baralho.
13 Cartas de Cada Naipe.
No pode existir carta Coringa.
Uma carta de Cada Tipo

public class DeckTest
{
public void Verify_Deck_contains_52_cards( )
{
var deck = new Deck( );
Assert.AreEqual(52,deck.Count( ) );
}
}
Classe que testa se existem 52 cartas no baralho.
Classes para Testes
52 cartas no Baralho. --- testado.

13 Cartas de Cada Naipe.
public class DeckTest2

{
public void Verify_Deck_contains_52_cards( )
{
Assert.AreEqual(52,deck.Count( ) );
}
public void Verify_Deck_contains_13_cards_for_each_suit( )
{
Assert.AreEqual(13,deck.NumberofCopas( ) );
Assert.AreEqual(13,deck.NumberofEspadas( ) );
Assert.AreEqual(13,deck.NumberofOuros( ) );
Assert.AreEqual(13,deck.NumberofPaus( ) );
}
}
44
Classe que testa se existem 52 cartas no baralho e se so 13 de

cada naipe.
Classes para Testes
52 cartas no Baralho --- testado.

13 Cartas de Cada Naipe --- testado.

{
//..Continuao
public void Verify_Deck_contains_no_joker( )
{
Assert.IsFalse(deck.Contains(Card.Coringa ) );
}
}
Classe que testa se coringa nas cartas geradas
Classes para Testes

No pode existir carta Coringa --- testado.

{
//..Continuao
public void Verify_Every_Card_in_the_Deck( )
{
Assert.IsTrue(deck.Contains(Card. Dois_de_Copas ) );
Assert.IsTrue(deck.Contains(Card. Tres_de_Copas ) );
}
}
//...Testar todas as cartas vlidas para cada naipe
Classe que testa se existe apenas uma carta de cada tipo

Classes para Testes

No pode existir carta Coringa --- testado.
Uma carta de Cada Tipo --- testado.
45
Este pequeno exemplo ilustra como gerar classes em funo dos

testes necessrios. Uma vez implementado qualquer novo incremento no
cdigo ir passar por estes testes, j que eles fazem parte do cdigo.
Voc poder aprofundar seus conhecimentos sobre o eXtreme Programming,
acessando o web site oficial, na URL: http://www.extremeprogramming.org/
46
CAPTULO 5
5.1 - SCRUM
O que SCRUM ?
Scrum um mtodo gil emprico, iterativo com entregas
incrementais.
Emprico porque se apoia no empirismo que afirma que o
conhecimento vem da experincia e de tomada de decises baseadas no que
conhecido. O Scrum emprega uma abordagem iterativa e incremental para
aperfeioar a previsibilidade e o controle de riscos.
5.1.1 - Histria
Scrum baseado em um artigo de 1986 escrito por HirotakaTakeuchi
e Ikujiro Nonaka para a Harvard Business Review, o "The Game
Development New Product". Neste trabalho, os autores utilizaram o esporte
do rugby como uma metfora para descrever os benefcios da auto
organizao de equipes de desenvolvimento de produtos inovadores e de
entrega. Jeff Sutherland, Ken Schwaber e Mike Beedle aderiram as ideias
deste artigo, incluindo a metfora, e as aplicou na rea de desenvolvimento
de software. Eles chamaram seu novo mtodo de Scrum*. Schwaber e
Beedle, escreveu sobre suas experincias em seu livro Desenvolvimento de
Software gil com Scrum em 2002.
O Scrum ou formao ordenada uma situao frequente no rugby,
geralmente usado aps uma jogada irregular ou em alguma

penalizao. Os 8 Avanados das duas equipes formam uns contra
os outros. O Scrum-half(Mdio-Formao) da equipe que no
cometeu a infrao insere a bola no meio do "tnel" formado pelas
duas primeiras linhas de cada equipe com a finalidade de que os
jogadores da sua equipe consigam ganhar(talonar) a bola.
47
5.2 - Pilares SCRUM

Como o Scrum baseado no empirismo, os pilares do Scrum
baseiam-se em:
Transparncia:
Todo o processo deve estar visvel a todos os envolvidos. Esta
transparncia deve ser refletida, no ambiente, nas pessoas e nos
processos.
Inspeo:
O processo em si deve ser inspecionado regularmente na busca por
anomalias e/ou oportunidades de melhorias.
Adaptao:
Caso a inspeo detecte algum processo que precise ser ajustado ou
melhorado, as adaptaes devero ser feitas o mais rpido possvel.
O quanto antes as mudanas sejam feitas, antes o novo processo
proposto testado e validado.
No Scrum temos oportunidades constantes de verificar os 3 pilares
(Transparncia Inspeo e Adaptao), e estas oportunidades so nos
eventos da Reunio de Planejamento, Scrum Dirio, Reunio de Reviso da
Sprint e Reunio de Retrospectiva da Sprint
5.3 - O Framework SCRUM

Scrum um framework para suportar o desenvolvimento e
manuteno de projetos/produtos complexos. Na verdade ele simplesmente
fornece uma estrutura para entrega, mas no diz como fazer prticas
especficas, deixando isso para a equipe de determinar.
48
O projeto comea com uma viso clara oferecido pelo negcio, e um

conjunto de caractersticas do produto em ordem de importncia. Esses
recursos fazem parte da carteira de produtos, que mantido pelo cliente ou
representante do cliente referido como o Product Owner. Uma caixa de
tempo comumente referido como uma iterao ou Sprint, a quantidade de
tempo que a equipe tem para concluir as caractersticas selecionadas.
Sprints so geralmente de uma a quatro semanas de durao, e esta
durao mantida durante toda a vida do projeto. O Product Owner
(negociando com o time) seleciona itens do Product Backlog que acredita que
pode ser concluda no Sprint, e cria um Sprint Backlog composto pelos
recursos e tarefas, como parte da Reunio de Planejamento (Planning
Meeting) do Sprint.
O tamanho da Sprint influenciado (ou pode ser
alterado) dependendo do escopo, tamanho do time,
disponibilidade do cliente, conhecimento do time sobre
agilidade, conhecimento do time sobre a tecnologia,
mudanas na formao do time. Porm sempre que um
novo tamanho definido, as mtricas de produtividade
devero ser
Uma vez que o time se comprometeu com um Sprint Backlog, o
trabalho comea tarefa. Durante este tempo no Sprint, a equipe est
protegida de interrupes e permitiu a concentrar-se em atender o objetivo do
49
Sprint. Nenhuma alterao para o Sprint Backlog so permitidos, no entanto,

o Product Backlog pode ser alterado, em preparao para o prximo Sprint.
A regra do SCRUM no permite que a Sprint Backlog
seja alterada, porm se o item que est em
desenvolvimento perde o objetivo de negcio, isto ,
no agrega mais valor, no faz sentido continuar a ser
desenvolvido, e deve ser interrompido. Geralmente o
tempo restante da Sprint pode ser dedicado a
refatorao de cdigos existentes ou pode se iniciar
uma nova Sprint, mas so casos de exceo.
Durante o Sprint, a equipa de verifica no dirio com o outro sob a
forma de uma reunio, geralmente de 10 a 15 minutos conhecido como Daily
Scrum (Scrum Dirio).
No final do Sprint, o time (e o cliente, quando possvel) renem-se

para a reunio conhecida como Reviso (Review Meeting) . Eles tambm
possuem uma Reunio de Retrospectiva (Retrospective Meeting) com o
objetivo de aprender como melhorar. Esta reunio fundamental, pois seu
foco sobre os trs pilares do Scrum: transparncia, inspeo e adaptao.
50
5.4 - Artefatos, Eventos e Papis

Artefatos
O Scrum prev alguns artefatos que nos permite ter uma viso sobre
o andamento do projeto e da Sprint. Estes artefatos so conhecidos como
Backlog.
5.4.1 - Backlog de Produto( Product Backlog)
uma lista ordenada criada pelo Time.
O formato da lista pode variar de acordo com cada time, pode ser
formadas por casos de uso, Funcionalidades (do FDD), porm os mais
comuns so user stories, que veremos mais adiante quando tratarmos de
Backlog e priorizaes.
Durante a evoluo do projeto podem ocorrer alteraes nesta
lista, como a incluso de novos itens, mudanas na prioridade de
desenvolvimento e entrega, alguns itens podem ser ajustados de acordo
com importncia para o negcio ou at mesmo eliminados. Mas o NICO
que pode inserir, alterar ou remover o Dono do Produto ( Product
Owner).
5.4.2 - Backlog da Sprint (Sprint Backlog)
um conjunto de itens selecionados para serem implementados (e
entregues como incremento ao produto) durante a Sprint.
O objetivo do Backlog da Sprint tornar o trabalho visvel e tangvel
para que o Time atinja a META da Sprint.
Meta: A meta da Sprint so os itens(casos de uso, funcionalidades ou

estrias do usurio) que precisam ser adicionadas ao produto(incremento
gerado pela Sprint) com sucesso. Geralmente na promoodos itens do
backlog de produto para o backlog da Sprint, definimos itens a mais do que
a meta, pois como as estimativas possuem certo grau de impreciso,
possvel que a meta seja atingida antes do trmino da Sprint, assim o time
ainda tem itens para serem implementados.
51
Definio de Pronto: Esta definio precisa ser acordada e

respeitada por todos do time, geralmente a definio de
pronto significa dizer que o item j est codificado (de
acordo com patterns definidas), testado (teste unitrio,
integrao,...),
documentado
(manual
atualizado),
implemetvel. Em quanto um item no atingiu todas as

caractersticas determinadas na definio de pronto, ele
considerado WiP (Work In Progress Trabalho em
Progresso).
5.5 - Os papis e responsabilidades no Scrum:

A organizao dos recursos humanos envolvidos no projeto utilizando
o Framework Scrum separada em trs papis: Product Owner, Scrum
Master, Dev. Team (Desenvolvedores).
O Product Owner ou dono do produto, basicamente o representante
do cliente dentro do time Scrum , ele responsvel por entender o que o
cliente precisa e transportar este conhecimento para os desenvolvedores.
Algumas de suas responsabilidades so:
Participar do Daily Scrum
Responder dvidas dos desenvolvedores sobre o que
est sendo desenvolvido ou indicar que poderia respond-las
Prover uma meta clara para cada Sprint
Obter feedback e expectativas dos clientes e extrair
deles as necessidades
Manter o Product Backlog atualizado
52
O Product Owner uma pessoa e no um comit. O Product

Owner pode representar o desejo de um comit no Backlog do
Produto,
mas
aqueles
que
quiserem uma
alterao
nas
prioridades dos itens de Backlog devem convencer o Product

Owner. Para que o Product Owner tenha sucesso, toda a
organizao deve respeitar as suas decises. As decises do
Product Owner so visveis no contedo e na priorizao do
Backlog do Produto. Ningum tem permisso para falar com a
Equipe de Desenvolvimento sobre diferentes configuraes de
prioridade, e o Time de Desenvolvimento no tem permisso para
agir sobre o que outras pessoas disserem.
As responsabilidades do Product Owner, so listadas abaixo para
cada fase do projeto, mas no se limitam a elas.
Antes do incio do trabalho, fase conhecida como Pre-Game:
Identificar as necessidades Estratgicas do Projeto (Patrocinador,

Time, Infraestrutura, reas Envolvidas, etc)
Realizar Kick-Off
Descobrir a viso do produto e elaborar artefatos necessrios
Descobrir os requisitos para o Product Backlog
Organizar e priorizar o Product Backlog
Durante o Trabalho, fase conhecida como Game:

Participar de todas as Reunies de Planejamento e de Reviso.
Quando necessrio visitar a reunio diria e participar da
retrospectiva (geralmente, quando convidado pelo Time)
Estar disponvel para o Time (ou garantir que algum designado por
ele esteja)
Elaborar Plano de Release (Plano de verses, veremos mais adiante)
Manter o Product Backlog
Atualizar o Plano de Release
53
Aps a concluso das entregas do projeto, na finalizao do projeto,

fase conhecida como Post-Game:
Promover e participar da Retrospectiva do Projeto
Tornar resultados visveis para outros (e futuros) projetos Scrum na
empresa
muito comum empresas que iniciam nos mtodos geis
definir Product Owner sem poder de deciso; Com baixa
disponibilidade; Com interesse em apenas uma parte do
projeto; ou com acmulo de outras funes no time(ou
desenvolvedor ou Scrum Master). Todas estas caractersticas
enfraquecem e podem comprometer a adoo da agilidade e
do projeto.
P.O. sem poder de deciso
P.O. com baixa disponibilidade
O metade P.O.
P.O. distante
P.O. proxy
P.O. da sua parte
Segundo o Scrum Guide, o Scrum Master responsvel por garantir
que o Scrum seja entendido e aplicado. O Scrum Master faz isso para
garantir que o Time Scrum adere teoria, prticas e regras do Scrum. O
Scrum Master um servo-lder para o Time Scrum.
O Scrum Master ajuda aqueles que esto fora do Time Scrum a
entender quais as suas interaes com o Time Scrum so teis e quais no
so.
54
O Scrum Master ajuda todos a mudarem estas interaes para

maximizar
valor
criado
pelo
Time
Scrum.
Algumas
de
suas
responsabilidades so:
Educar o Time e stakeholders sobre o processo
Assegurar que a equipe faz o Daily Scrum no horrio certo e de
modo produtivo
Resolver os impedimentos da melhor maneira possvel
Manter o foco das reunies
Indicar pontos de melhoria no processo e no ferramental
Segundo o Scrum Guide, a Equipe de Desenvolvimento (Dev.
Team) consiste de profissionais que realizam o trabalho de entregar uma
verso usvel que potencialmente incrementa o produto Pronto ao final de
cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam
incrementos.
As Equipes de Desenvolvimento so estruturadas e autorizadas pela
organizao para organizar e gerenciar seu prprio trabalho. A sinergia
resultante aperfeioa a eficincia e a eficcia da Equipe de Desenvolvimento
como um todo.
Os Times Scrum so auto organizveis e multifuncionais. Equipes
auto organizveis escolhem qual a melhor forma para completarem seu
trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes
multifuncionais possuem todas as competncias necessrias para completar
o trabalho sem depender de outros que no fazem parte da equipe.
O que auto-organizao?
A auto organizao o processo onde uma estrutura ou padro aparece
em um sistema sem uma autoridade central ou elemento externo que define um
planejamento.
Segundo a fsico-qumica, a auto organizao a caracterstica de que
sistemas abertos podem se organizar espontaneamente quando sujeitos a um dado
gradiente. O termo auto, nesse caso, reflete o fato de que no h nenhuma instruo
do ambiente sobre como a organizao deve ocorrer ou como o sistema deve se
adequar em resposta ao gradiente. Em outras palavras, o gradiente imposto
completamente neutro em termos de informaes e a organizao emerge de dentro
55
do sistema. Processos de auto organizao so ubquos na natureza: de clulas a

rgos e organismos, de indivduos a organizaes sociais, de casas a bairros,
cidades, etc.
(Fonte:http://cienciaecultura.bvs.br/scielo.php?pid=S0009-67252011000100010&script=sci_arttext)
Para a qumica, a capacidade de auto organizao (self-assembly) consiste

na formao (espontnea) de estruturas complexas a partir de componentes
simples. Por exemplo, as espcies qumicas denominadas anfiflicas -que incluem os
detergentes e alguns lipdios - contm uma parte hidroflica (que gosta de gua), e
uma hidrofbica (que no gosta de gua). Por este motivo, estas espcies
agregam-se na presena de gua, formando, por exemplo, micelas ou bicamadas,
isto , se auto organizam.
(Fonte: http://dererummundi.blogspot.com.br/2007/11/auto-organizao-de-sistemas-qumicos.html)
muito comum auto organizao ser chamada de anarquia, mas vamos a

alguns esclarecimentos:
Anarquia vem do grego anarchia que significa sem regras. Encontramos
outras variaes sobre o significado da palavra como: falta de ordem ou negao
ou ausncia de autoridades ou ordem estabelecida. Estes significados so tratados
como sinnimos para caos(sem ordem) ou complexidade(ordem, mas no imposta
por uma autoridade).
Na mente da maioria das pessoas, anarquia igual ao caos. Este equvoco

provavelmente a principal razo pela qual algumas pessoas especialistas no
gostam de associar a auto organizao com anarquia. Vejam, as galxias se
comportam de uma maneira anrquica, e ainda assim elas no so caticas, os
pases(no estamos falando dos governos) as suas relaes de comrcio so
anarquias e tambm no so necessariamente so caticas.
A auto organizao pode ser considerada uma variao complexa da
anarquia. Tanto a qumica, fsica e a biologia possuem suas prprias definies de
auto-organizao, mas nenhuma delas aborda a liderana, gerncia ou autoridade.
Assim, no faz muito sentido alterarmos os conceitos de auto organizao apenas
para aplicar no contexto social.
Por exemplo, quando todos as netas e netos de minha me(crianas entre
2 e 7 anos) se renem na casa dela com seus muitos amiguinhos, correndo e
gritando para todos os lados, ns adultos podemos acreditar que um sistema
anrquico quando na verdade eles esto auto organizados. Isto ocorre porque a
forma como eles se auto organizam no necessariamente agrada(ou aprovada)
por ns(suas principais partes interessadas).
56
Este comportamento observado em empresas/departamentos de software

onde os desenvolvedores disputam em horrio de trabalho campeonatos de vdeo
game e ainda sim entregam seus trabalhos. Isso provoca um choque cultural na
empresa que pode atingir at a diretoria executiva com essa nova forma de
relacionamento.
importante observar que a auto organizao no faz distino entre bem
e mal, virtudes ou vcios, atitude que agregam valores ou no.
Outra confuso muito comum entre a auto organizao e as Propriedades
(Tcnicas) Emergentes. Quando uma propriedade no pode ser rastreada
qualquer uma das partes individuais do sistema, Esta propriedade chamada de
uma propriedade emergente. Por exemplo, sua personalidade uma propriedade
emergente do seu crebro. Ela no pode ser atribuda a neurnios individuais.
As propriedades emergentes possuem as seguintes caractersticas:
Supervenincia a observao de que a propriedade deixar de existir se
voc tirar as peas individuais do sistema. Por exemplo, a sua personalidade
desaparece se remover seus neurnios.
A propriedade no um agregado, ou seja, esta propriedade no
simplesmente o resultado da soma das propriedades das partes individuais. Por
exemplo, uma nica molcula no tem fluidez. Ento voc no pode simplesmente
somar a fluidez de um bilho de molculas individuais para determinar a fluidez da
gua.
Deve haver causalidade para baixo (downward causality), o que significa
que a propriedade emergente deve influenciar o comportamento das peas
individuais. Por exemplo, a cultura de um grupo de pessoas influencia o
comportamento dos seus membros.
O comportamento emergente em times o resultado da interao entre os
seus membros. Assim, o time responsvel por sua prpria cultura, processos,
imagem perante a organizao e muitas vezes at pelo seu prprio nome.
57
Como regra geral, podemos dividir os papis e responsabilidades

como:
Observe que dentro do Scrum as responsabilidades de

Gerenciamento de Projetos esto distribudas em papeis
distintos.
Assuntos relacionados ao macro negcio, priorizao, definio do

que ser feito, oramento, ou qualquer outro assunto associado ao negcio
de responsabilidade do Product Owner (P.O.). Assuntos referentes a tcnica
de desenvolvimento, arquitetura, e assuntos mais tcnicos so de
responsabilidade do time de desenvolvimento(Dev. Team) e por fim, assuntos
associados aos processos de trabalho so de responsabilidade do Scrum
Master. Estes personagens formam o TIME SCRUM e so, em conjunto,
responsveis pelo gerenciamento do projeto.
58
5.6 - Eventos Scrum
5.6.1 - Sprint
Segundo o Scrum Guide, a Sprint um time-box de um ms ou
menos, durante o qual um Pronto, verso incremental potencialmente
utilizvel do produto, criado. Sprints tem duraes coerentes em todo o
esforo de desenvolvimento. Uma nova Sprint inicia imediatamente aps a
concluso da Sprint anterior.
As Sprints so compostas por uma reunio de Planning meeting
(Planejamento da Sprint), Daily Scrum (Reunies Dirias), o trabalho de
desenvolvimento, uma Review Meeting (Reviso da Sprint) e a Retrospective
Meeting (Restrospectiva da Sprint).
5.6.2 - Reunio de Planejamento - Planning Meeting

A reunio de planejamento de Sprint, realizada no primeiro dia de
cada Sprint. O Scrum Master, Product Owner, e o Dev. Team esto todos os
presentes. Esta reunio no deve ocupar mais de 5% da durao da Sprint (
por exemplo, em uma Sprint de 2 semanas, no deve durar mais de 4 horas)
e dividida em duas partes e deve chegar responder as seguintes perguntas:
O que ser entregue no Incremento resultante nesta Sprint ?
Como faremos para entregar o Incremento nesta Sprint ?
59
Na primeira parte, o Product Owner apresenta o conjunto de

caractersticas que ele gostaria de ver concluda no Sprint ("o qu"), os itens
do topo do backlog do produto. O Time avalia o esforo necessrio para a
concluso de cada item e negocia o que possvel entregar na Sprint.
A quantidade de itens selecionados para a Sprint
prerrogativa do Time de Desenvolvimento. Ele o nico
capaz de avaliar o esforo para cada item j que ser ele
que ir desenvolv-los. Em times com baixa maturidade
importante que o Scrum Master relembre da importncia de
no subestimar ou sobrecarregar a Sprint.
Aps selecionar os itens que sero realizados na Sprint, o Time com

o P.O. definem a Meta da Sprint.
Na segunda parte da Reunio de Planejamento, o Time define como
ir transformar os itens do backlog da Sprint em Incrementos do produto.
Nesta etapa o time determina as tarefas necessrias para implementar esses
recursos ("o como"). Estimativas de trabalho so revistas para ver se a
equipe tem o tempo para concluir todas as caractersticas solicitadas na
Sprint. Se assim for, a equipe se compromete com a Sprint. Se no, os
recursos de menor prioridade voltam para o Product Backlog, at que a carga
de trabalho para a Sprint seja de tamanho adequado para obter o
compromisso da equipe
5.6.4 - Scrum Dirio - Daily Scrum

O Daily Scrum uma reunio rpida e informal , com durao
mxima de 15 minutos onde participam apenas o time Scrum. Geralmente
cada membro do time responde as seguintes perguntas:
O que fiz desde o ltimo Daily Scrum;
O que irei fazer at o prximo e;
Quais impedimentos esto me atrapalhando.
60
O objetivo desta reunio melhorar a comunicao na equipe e dar

para todos uma viso mais clara do andamento do time na Sprint, alm de
facilitar a identificao e resoluo de problemas e impedimentos.
5.6.5 - Reunio de Reviso da Sprint - Review Meeting

No final da Sprint, o time convida os interessados (clientes) para uma
reunio de reviso da Sprint, onde as tarefas que foram concludas na Sprint
so demostradas e o feedback solicitado.( APENAS AS QUE ATENDAM A
DEFINIO DE PRONTO). Esta reunio no deve ocupar mais de 2.5% do
tamanho da Sprint ( por exemplo, em uma Sprint de 2 semanas, no deve
durar mais de 2 horas).
Esta reunio importante para demostrar para demostrar ao cliente
as novidades que estaro disponveis para o uso, quanto para que o time de
desenvolvimento receba o feedback real dos usurios do sistema e entenda
melhor suas necessidades.
Caso o cliente tenha dvidas, estas devero ser respondidas e
qualquer problema(ou possvel problema) encontrado deve ser anotado.
Nesta reunio o Product Owner aprova ou rejeita os itens implementados.
Caso rejeite, o item volta para o Backlog do Produto (e pode ou no entrar na
prxima Sprint, depender da avaliao do Product Owner).
5.6.6 - Reunio de Retrospectiva da Sprint - Retrospective

Meeting
A Reunio de Retrospectiva um recurso de melhoria contnua, uma
ferramenta de comunicao e evoluo do time. Times imaturos costumam
dar menos valor para este evento, porm a prtica de Retrospectiva vem
sendo utilizada em diversos ambientes de equipes e projetos (mesmo em
61
ambientes no geis), pois permite intensificar as caractersticas fortes de

cada time e eliminar pontos de fraqueza.
Uma vez que a reviso est concluda, o time(sem as partes
interessadas, a no ser que o time de desenvolvimento e o Scrum Master
decidam convidar...) realizam uma retrospectiva para determinar o que eles
fizeram bem que eles querem continuar fazendo, o que foi ruim na Sprint, e
quais as recomendaes de melhoria daqui para frente. Um plano de ao
criado e esses itens so implementadas ao longo da prxima Sprint, e
revisado para a eficcia na retrospectiva da Sprint seguinte. Geralmente a
reunio de retrospectiva no deve ocupar mais de 3,75% da Sprint (por
exemplo, em uma Sprint de 2 semanas, no deve durar mais de 3 horas).
Existem diversas tcnicas de Retrospectiva, porm todas elas
possuem etapas:
Identificar o
Problema
Indetificar Causas
Razes
Identificar
Solues
Propor Solues
para diminuir ou
eliminar o
Problema(em sua
causa Raz)
Testar a Soluo
Incorporar a
Soluo no
Processo e no Time
Independente do mtodo/framework gil que for utilizado existe

elementos comuns que quando bem utilizados agregam valor ao projeto.
62
Nesta seo vamos apresentar algumas dinmicas que podem ser utilizadas
nas reunies de retrospectiva.
5.6 - Dinmica Bons e Ruins

Esta dinmica muito interessante em retrospectivas de equipes
com alguma experincia em agilidade ou para times que j se conhecem a
algum tempo:
Permite a exposio dos problemas relevantes no momento em que
o time se encontra
Permite que o time apresente, entenda e proponha solues para os
problemas(autogerenciamento)
Integra o time.
Gesto do conhecimento do time.
Nunca tarde para lembrar ao time que a Retrospectiva no
caa as bruxas e sim uma ferramenta de melhoria, logo,
no o momento de acusaes e sim de solues. O time
deve ter maturidade e no levar nada para o lado pessoal e
o facilitador deve lembrar o time estes pontos sempre que
necessrio!
1) Cada membro do time ganha post it e canetas(de preferncia
todos da mesma cor) e escreve os pontos bons e ruins da Sprint
63
2) Quando todos finalizarem, colam-se os post its em um lugar

visvel(veja um exemplo de quadro sugerido abaixo)
3) feita a leitura dos tpicos ruins, observe que os problemas mais

srios tero mais post its
4) O time discute os problemas e PROPE AES DE SOLUO

OBS: Dependendo do nmero de problemas interessante concentra
esforos para resolver 2 ou 3 mais srios.
64
5) Se faz a leitura dos pontos bons !(Prticas que devem ser

mantidas)
5.7 - Consideraes:
Problemas que no geram aes e solues podem ser adiados para
discusso posterior, estes problemas devem ficar na rea de parking
lot do quadro
Aes devem ser atitudes concretas que permitam a execuo
sem dupla interpretao. Por exemplo: Quem desenvolveu deve
realizar testes unitrios!
Sugiro que aes sejam endereadas, por exemplo, fulano de tal
o responsvel por lembrar-se da importncia da ao XYZ, durante o
prximo sprint
Ao final da retrospectiva, deve-se jogar no lixo os post its e deixar
fixadas as aes combinadas visveis para todos, sugiro que elas
fiquem no quadro kanban para que todos se lembrem !
65
5.8 - Dinmica Mercado de Habilidades (Market ofSkills)

Esta dinmica muito interessante em retrospectivas de equipes que
esto no processo de transformao para times! Alguns benefcios so:
-
Acelera o autoconhecimento como time.

Permite que o time inicie seu auto gerenciamento, onde
cada um assume como e quando ajudar.
Integra o time.
Gesto do conhecimento do time.
1) Liste as habilidades que voc tem e julgue ser til para o time
e para o produto
2) O que voc tem vontade de aprender ? Como isso ser til para o
time ? Como isso ser til para o produto ?
Nesta etapa, os membros do time identificam interesses

comuns, o que facilita o processo de comunicao e
aproximao.
66
3) Informaes adicionais. Apresente o que voc tiver vontade para

o time( extra time, extra produto, ...) que voc sinta vontade de compartilhar
4) Venda-se para o time !
Durante a venda, todos podem acrescentar habilidades

esquecidas pelo vendedor(passo 1), formas de ajudar nas
vontades.
5) Defina aes !
Aps a primeira aplicao desta dinmica, o time deve repeti-l (mais

adiante no projeto) e verificar a evoluo do time. Por exemplo, na primeira
dinmica, o time tinha identificado o seguinte quadro de conhecimento:
Conhecimento/Habilidade
Nmero de Membros com

Domnio
Java
SQL Server
CSS
Teste Automatizado
67
Aps aes como programao pareada, a tendncia que o time

compartilhe conhecimento e melhore suas habilidades. A prxima dinmica
poderia gerar um resultado melhor, como o ilustrado abaixo:
Conhecimento/Habilidade
Nmero de Membros com

Domnio
Java
SQL Server
CSS
Teste Automatizado
5.8 - Tcnica PrOpER

A abordagem mais simples escolher uma coisa e pular dentro. Se
no bvio qual o problema para trabalhar em primeiro lugar, ento voc
pode ter uma abordagem gil. Faa uma tempestade de ideias, gere uma
lista de reas problemticas para trabalhar no que poderia melhorar a vida da
sua equipe no projeto. Ento priorize esta lista com base em sua misso de
treinamento - agora voc tem um ponto de partida !
Voc pode aplicar o ciclo PrOpER adequando a cada episdio de
coaching ou na retrospectiva.
5.8.1 - Problema:
Escolha o problema para trabalhar. Veja como a equipe trabalha. O
que precisa ser melhorado?
68
5.8.2 - Opes:
Considere as suas opes. O que voc poderia tentar que podero
influenciar a situao para melhor? Relacione pelo menos trs opes.
5.8.3 - Experimente:
Escolha uma opo e a execute.
5.8.4 - Reviso:
Analise o resultado. Voc melhorou as coisas? Mesmo se as coisas
no melhoraram, voc j aprendeu alguma coisa ?
Vamos praticar o PrOpER atravs de um exemplo.
5.8.5 - EXEMPLO:
Problema:
Jack chegou tarde para a reunio de Daily Scrum hoje. Aconteceu na
semana passada tambm. Voc est preocupado, porque ele est
trabalhando na construo de um ambiente de teste novo. Ele est perdendo
informaes importantes sobre os problemas da equipe com o ambiente de
teste atual.
Opes: Aqui esto algumas opes que voc pode considerar:
Pegue o touro pelos chifres: Quando Jack chega, pea um tempo para
inform-lo sobre o que ele perdeu at o momento no Daily Scrum.
Enquanto voc est revendo os pontos, fale com ele sobre a importncia
de participar do Daily Scrum todo dia.
Educar a equipe: Executar uma sesso de treinamento para toda a
equipe para aprender a melhorar o Daily Scrum, o que pode ajudar o Jack
a entender porque importante para todos na equipe a participao na
reunio.
69
Deixe-os segurando o beb: Voc precisa de algum para cobrir a voc:

pergunte se Jack pode ajud-lo, executando o amanh o Daily Scrum.
Espere e veja: No fazer nada, e esperar para ver se a equipe faa que
Jack perceba que o seu atraso um problema por si s.
Experimente:
Voc escolhe a opo para primeiro falar com Jack sobre isso. Inicie
a conversa, mencionando que voc percebeu que ele perdeu o Daily Scrum
algumas vezes. Ele parece genuinamente surpreso que isso era importante,
j que a partir de sua perspectiva, seu trabalho no est diretamente ligado a
nenhuma em estrias de qualquer cliente, por isso certamente que ele no
precisaria estar l. Explique o motivo que sua preocupao que ele est
perdendo informaes de seus companheiros de equipe que precisaro ser
consideradas na construo do ambiente de teste novo. Tambm explique
que o Daily Scrum para a equipe, e no para o cliente. Sugerira que ele
convoque uma reunio com o testador(e time) para verificar as questes que
provavelmente no foram atendidas. Ele acena que concorda ele chegar no
horrio da prxima Daily Scrum.
Reviso: Reviso do resultado. No dia seguinte, Jack chegou a
tempo? A sua conversa fez a diferena? Se ainda h problemas, ento que
outras opes voc pode tentar?
Ao tentar chegar com as opes, esto aqui algumas ideias a serem
considerados:
Traze tona o problema: Torne o problema visvel para a
equipe
Socializar o problema: Converse com a equipe sobre o
problema
Espere e Veja: Deixe este problema: Se piorar, a equipe
provavelmente notar
70
Tire o corpo fora: Transfira o problema para outra pessoa dentro

ou fora da equipe
Anlise de causa raiz: Procure a causa raiz do problema
Educar a equipe: Fornea a equipe mais informaes para que
eles vejam uma soluo
Coloque-os no comando: entregue a responsabilidade para a
equipe ou a um membro da equipe.
71
CAPTULO 6
6.1 - Planejamento Orientado Valor
Em projetos geis, devido a sua prpria caracterstica de incerteza, o
planejamento de verses e a priorizao do que ser desenvolvido (Backlog)
estratgica para melhorar o ROI (Return Over Investiment).
As tcnicas de planejamento de gil tem forte afinidade com o
planejamento em ondas dos mtodos de gerenciamento de projetos
orientados planos, porm com algumas diferenas conforme apresentadas
na figura abaixo. Veja que no interessante antecipar todo o planejamento
j que como temos muitas incertezas, teremos grandes probabilidades de
mudanas caso a antecipao seja feita. Ao invs disso, fazemos um
planejamento de alto nvel para identificar e planejar os releases, e
posteriormente planejamos mais detalhadamente cada iterao.
Como vimos no fluxo do framework Scrum, tudo se inicia na definio

da viso do projeto.
72
6.2 - Viso em um projeto gil

Viso uma clara imagem que gera uma atrao emocional
entre pessoas e produto (quando se fala a viso quem escuta deve ser
capaz de imaginar como ser o produto). A viso deve responder as
seguintes perguntas:
Quem ir comprar este produto? Quem o cliente alvo? Quem
ir usar o produto? Quem so os usurios alvo?
Quais problemas do cliente(ou usurios) o produto pretende
resolver? Qual valor o produto adicionar?
Quais atributos o produto deve possuir para resolver estes

problemas e quais garantiro o sucesso do produto?
Como o produto pode ser comparado a produtos ou alternativas
existentes ? Quais so os pontos diferenciais deste produto?
Qual o preo alvo do produto? Como a empresa pretende

ganhar dinheiro com este produto? Quais sero as fontes de faturamento
e qual o seu modelo de negcio?(quando aplicvel )
Lembre-se que uma boa viso de produto permanece relativamente
constante ao passo que o caminho para implementao da viso
frequentemente adaptado.
73
Uma das tcnicas bem interessantes de se iniciar a identificao e

criao da Viso conhecida como Elevator Statement, esta tcnica prev
que voc deve apresentar o produto que ser criado em poucos segundos,
como em uma viagem no elevador. Como sugesto, existe um modelo
proposto apresentado abaixo.
Para <cliente/pblico-alvo> que <necessidade do cliente/pblicoalvo ou oportunidade>, o <nome do produto> um <categoria do
produto> que <principal benefcio ou razo para comprar o produto>.
Diferentemente do <principal competidor ou alternativa> nosso produto
<principal diferenciao> .
Se aps apresentar seu ElevatorStatement, no fique claro o que
seu produto, qual o objetivo e para quem se destina, ele NO est bom!
Voc pode consultar mais sobre esta tcnica na URL: http://www.flyingsolo.com.au/marketing/businessmarketing/preparing-your-elevator-statement
O prximo passo materializar seu produto, mesmo sendo um

software!
A tcnica de Product Vision Box prope a criao da caixa do seu
software com informaes como:
Nome do Produto
Grficos
Trs ou quatro pontos chave(benefcios) para vender o
produto
Principais funcionalidades no verso
Principais requisitos operacionais
74
Voc pode fazer esta dinmica com o time envolvido no projeto

usando caixa de sapato, cola e canetas coloridas lembrem-se que na
agilidade temos diversas tcnicas Low-Tech, High Touch.
Observe que neste passo, conseguimos identificar os principais
diferenciais e as funcionalidades essenciais do futuro software, alm de
alinhar as expectativas dos os participantes.
Voc pode consultar mais sobre esta tcnica na URL: http://www.agileux.com/2011/03/04/a-day-in-life-of-an-agileux-practitioner-vision/
Aps a criao da caixa do produto, podemos iniciar o Product Road

Map, que apresenta as funcionalidades e caractersticas do produto(e em que
verso a funcionalidade ser inserida). Para esta etapa podemos usar a
tcnica Rememberthe Future, esta tcnica tem como objetivo descobrir o
entendimento do sucesso do cliente e iniciar a visualizao do Road Map do
produto/projeto.
Nesta tcnica ao invs de olhar o passo a passo, voc deve se
posicionar no momento final desejado e relembrar o que foi feito para
chegarmos neste ponto.
75
A tcnica Remember the Future no um jogo de

adivinhao do futuro e sim uma ferramenta que nos auxilia
no entendimento do sucesso do projeto/produto e como
podemos atingir o objetivo final. Logo, NO plano, NO
cronograma, NO determinstico!
Voc
pode
consultar
mais
sobre
esta
tcnica
na
URL:
http://innovationgames.com/remember-the-future/
Aps a aplicao das etapas anteriores, conseguimos ter um melhor

entendimento da viso do projeto e criar o Project Data Sheet, a planilha de
dados do projeto.
Exemplo de Planilha de Dados do Projeto
6.3 - Planos Adaptativos

As estratgias, portflio e produto podem ser planejados com
tcnicas de gesto de Portflio, Planejamento Estratgico e outras
conhecidas e utilizadas no mundo dos negcios, porm algumas tcnicas
geis de definio de viso (como vimos anteriormente) auxiliaro a todos a
76
entender o que realmente necessrio para o sucesso do projeto. A figura

abaixo apresenta a cebola do planejamento estratgico em projetos
orientados valor.
Cebola de Planejamento
6.4 - Planejamento de Release

Este planejamento uma reunio de planejamento de alto nvel que
trata de iteraes das futuras Sprints. O objetivo planejar quais itens sero
desenvolvidos, quando devero estar prontos e quais recursos sero
necessrios para isso. As entregas iro ocorrer ao longo do projeto e a
performance do time, assim como as aes de monitoramento e controle.
O fluxo abaixo ilustra uma sugesto de planejamento de Release.
77
Observe que sero necessrios que o Product Backlog j esteja

definido e priorizado, as datas das Sprints definidas, e (se for um time j
existente) a velocidade mdia do time.
As datas de incio/fim das futuras Sprints j devem

considerar os feriados, frias de membros do time e
quaisquer interrupes j planejadas.
A formao do time impactar em todo o andamento, em
projetos que temos uma restrio de tempo mais severa,
a montagem de um time snior mitiga o risco de atraso,
porm impactar no custo.
Com os itens pontuados e priorizados e com a estimativa mdia de

entregas do Time, podemos definir quantas Sprints sero necessrias. Por
exemplo, um projeto de 60 pontos com um time de 12 pontos de
produtividade por Sprint durar 5 Sprints.(60 / 12 = 5).
6.5 - User Story

No levantamento tradicional de requisitos, o partimos do princpio que
o cliente, em linguagem de negcios identifica suas necessidades, estas
necessidades identificadas so passadas ao analista que traduz em
linguagem tcnica que posteriormente so entregues aos desenvolvedores
que as transforma em cdigos.
Observe que neste processo temos pontos fracos como:
Premissas falsas podem ser geradas pelo cliente ou pelo analista
Requisitos detalhados desnecessariamente(desperdcio)
78
Na tcnica de User Story, o dono do produto descreve o que precisa

ser feito, identifica quem usar a funcionalidade e porqu (ajuda a no gerar
itens que no agregam valor ao negcio).
Esta tcnica utiliza os 3 Cs:
Carto:
Cada estria escrita em um carto com um objetivo especfico, o
que permite mais clareza no que necessrio que seja
desenvolvido.
Conversa:
Como o carto uma descrio simples, ele leva a conversas com
o time e com o cliente sobre a funcionalidade, o que permite um
melhor entendimento sobre a percepo de valor, identifica riscos
e prioridades.
Confirmao:
Atravs das conversas com o time e clientes poderemos entender
como validar o carto e confirmar se o que o temos definido
realmente o necessrio o sucesso da demanda.
As estrias tambm utilizam os conceitos conhecidos com INVEST:
Independente: A estrias so mais fceis de se trabalhar quando so

independentes, isto , no dependem de outras estrias para
acontecerem.
Negocivel
A estria no um contrato com definio de
funcionalidades,
ela
negocivel
para
melhor
atender
as
necessidades do negcio.
79
Valiosa para usurios e clientes - A estria precisa estar associada a

um valor para o usurio ou clientes, sem isso, no existe razo para
ela existir.
Estimvel A estria precisa ser estimvel, mesmo que com alguma

impreciso, precisamos dimensionar o esforo para implement-la.
Small(pequena)
Estrias representam situaes simples, com
poucos personagens.
Testvel
Toda estria precisa ser testvel. O cliente deve
identificar quais seriam as condies de testes da estria escrita. As

condies de teste definidas pelo cliente ajudam o time a entender se
a meta da estria foi bem sucedida.
Uma boa estria deve responder: QUEM? COMO? POR QUE?
Como um <PERFIL> eu posso /gostaria/devo <FUNO> para
<VALOR AO NEGCIO>
Ou POR QUE? QUEM? COMO?
Com o propsito de<VALOR AO NEGCIO>, como um<PERFIL>,
eu posso/gostaria/devo<FUNO>
Exemplo 1:
Uma estria para criar uma panela especfica:
Como um Cozinheiro( Usurio)
Quero panela de inox, com fundo oval e antiaderente
(Funcionalidade)
Para cozinhar um salmo(Valor de Negcio)
80
Exemplo 2:
Como comprador que no tem carto de crdito
Quero que o sistema de suporte a pagamento em boleto bancrio
6.6 - Stories, Temas e EPICS

Algumas estrias podem ser mais complexas e com uma previso
maior do que a capacidade de entrega da Sprint, estas estrias so
conhecidas com EPIC. Estas estrias precisam ser analisadas e revistas com
o objetivo de identificar melhor seus objetivos e a sua possvel decomposio
em estrias menores.(Lembre-se que as estrias devem respeitar as
premissas do INVEST).
Geralmente os EPICs aparecem na base do backlog do produto, pois

ainda no possuem granularidade para serem implementadas.
Existem casos em que um grupo de estrias est associado a um
determinado tema especfico, nestes casos, no momento de priorizao do
backlog do produto, estas estrias tendem a serem produzidas na mesma
Sprint ou em Sprints prximas.
81
As estrias que esto agrupadas no tema NO esto

associadas a nenhuma regra de precedncia, lembre-se
que as estrias devem ser Independentes.
6.7 - Priorizao de Backlog

A priorizao do Backlog de responsabilidade do Product Owner e
est diretamente associada a melhoria do retorno sob investimento (ROI),
pois quanto antes as funcionalidades mais importantes forem entregues,
antes geraro retorno para o negcio.
82
Em geral, a priorizao do backlog do produto segue uma sequncia

lgica, conforme apresentado abaixo:
Valor
Qual a importncia deste item para que o produto seja lanado ? Quanto mais
importante, mais no topo ele dever estar.
Riscos
Qual o nosso grau de conhecimento sobre o item ? Quais as incertezas ?
Identificamos os riscos associados ? Em geral, quanto menos conhecemos ou
de maior riscos devem ser priorizados. Quanto mais cedo falharmos, mais
cedo corrigimos e obtemos sucesso.
Releasability( Capacidade para Lanamento)

Itens que permitam lanar mais rapidamente o produto devem ser
priorizados(Minimum Marketable Feature - MMF), como veremos mais
adiante.
"Dependncia"
Temas e "dependncias" devem ser considerados na priorizao.
Tcnicas que podem ser utilizadas na priorizao do Backlog de

Produto
83
6.8 - Priority markets

Nesta tcnica de priorizao, simulamos um mercado, onde para
cada avaliador dado algum dinheiro virtual(Reais de desenvolvimento), que
devero ser usados para licitar itens do backlog.
O mtodo democrtico, em que todos os interessados possuem voz
no processo de priorizao. Tambm permite transparncia para que todos
possam ver como ocorreu a priorizao de cada item.
Esta ferramenta simples de administrar e se adapta bem a um
grande nmero de interessados e listas longas de itens do backlog, mitigando
os debates sem fim em busca de um consenso para a priorizao.
Passo 1: Defina a lista de itens ou temas.
Passo 2: Identifique as partes interessadas e o peso para cada parte
de acordo com sua importncia para o projeto.
Para nosso exemplo, vamos definir 4 atores e seus pesos.
Rafael
(2.0)
Emanuel
Helga
Letcia
(1.0)
(1.0)
(1.0)
Passo 3: Defina a quantidade de Reais de desenvolvimento no jogo

e distribua-os entre os participantes. Estes Reais sero utilizados pelas
partes interessadas para licitar e comprar as mudanas no sistema.
Dica:
O nmero exato do total de Reais de desenvolvimento no critico.
Na prtica valores pequenos como R$10,00 por participante, j podem
apresentar uma distribuio que representa bem a priorizao. No nosso
exemplo utilizaremos um valor de R$20,00 por peso/participante, como temos
5, o total ser de R$100,00 de desenvolvimento
84
Por exemplo:
Total de Reais de Desenvolvimento no alocado: R$100,00

Rafael
Emanuel
Helga
Letcia
(2.0)
(1.0)
(1.0)
(1.0)
Carrinho de
Compras
Alerta de
Estoque
Lista de Mais
Vendidos
Gerao de
Boleto de
pagamento
TOTAL NO
GASTO
Divida o total de Reais de desenvolvimento de acordo com o peso de
cada participante.
Carrinho
Rafael
Emanuel
Helga
Letcia
(2.0)
(1.0)
(1.0)
(1.0)
de
Compras
Alerta de Estoque
Lista
de
Mais
Vendidos
Gerao
de
Boleto
de
pagamento
85
TOTAL
NO R$40,00
R$20,00
R$20,00
R$20,00
GASTO
Passo 4:Os interessados distribuem seus Reais de desenvolvimento
sobre os itens do backlog de acordo com suas preferncias. Reais de
desenvolvimento que foram licitadas so deduzidos seus Reais no
gastos. Imagine as partes interessadas alocar seus Reais da seguinte forma:
Rafael
Emanuel
Helga
Letcia
(2.0)
(1.0)
(1.0)
(1.0)
R$6,00
R$8,00
R$5,00
R$5,00
Alerta de Estoque
R$5,00
R$4,00
R$3,00
R$4,00
Lista de Mais
R$3,00
R$3,00
R$4,00
R$5,00
R$6,00
R$5,00
R$8,00
R$6,00
R$20,00
R$0,00
R$0,00
R$0,00
Carrinho de
Compras
Vendidos
Gerao de
Boleto de
pagamento
TOTAL NO
GASTO
Passo 5: O time estima o custo do desenvolvimento de cada item.
Rafael
Emanuel
Helga
Letcia
TOTAL
CUSTO
(2.0)
(1.0)
(1.0)
(1.0)
PAGO
ESTIMAD
O(DEV.
TIME)
Carrinho de
R$6,00
R$8,00
R$5,00
R$5,00
R$14,00
R$5,00
R$4,00
R$3,00
R$4,00
R$16,00
R$3,00
R$3,00
R$4,00
R$5,00
R$15,00
R$6,00
R$5,00
R$8,00
R$6,00
R$24,00
11
Compras
Alerta de
Estoque
Lista de Mais
Vendidos
Gerao de
Boleto de
86
pagamento
TOTAL NO
R$20,00
R$0,00
R$0,00
R$0,00
GASTO
Passo 6:O ROI calculado e a proposta de priorizao

determinada.
Vamos calcular retorno sobre o investimento (ROI) de cada item

backlog dividindo a oferta total (Total Pago) pelo custo de desenvolvimento
(CUSTO ESTIMADO). Aps o clculo, vamos ordenar o backlog do maior
para o menor ROI. No nosso exemplo, temos:
Rafael
Emanuel
Helga
Letcia
TOTAL
CUSTO
TOTAL
(2.0)
(1.0)
(1.0)
(1.0)
PAGO
ESTIMA
PAGO/
DO(DE
V.
CUSTO
ESTIMADO
TIME)
Carrinho de
R$6,00
R$8,00
R$5,00
R$5,00
R$14,00
14/7 = 2
R$5,00
R$4,00
R$3,00
R$4,00
R$16,00
16/5 =
Compras
Alerta de
Estoque
Lista de
3,2
R$3,00
R$3,00
R$4,00
R$5,00
R$15,00
15/5 = 3
R$6,00
R$5,00
R$8,00
R$6,00
R$24,00
11
24/11 =
Mais
Vendidos
Gerao de
Boleto de
2,18
pagamento
TOTAL
R$20,0
NO
R$0,00
R$0,00
R$0,00
GASTO
87
Lista no priorizada
Carrinho de
Lista priorizada
TOTAL PAGO/
TOTAL PAGO/
CUSTO
CUSTO
ESTIMADO
ESTIMADO
14/7 = 2
Compras
Alerta de
3,2
Estoque
Alerta de Estoque
Lista de Mais
16/5 = 3,2
15/5 = 3
Vendidos
Lista de
Mais
Vendidos
Gerao
Gerao de Boleto
de pagamento
24/11 = 2,18
2,18
de Boleto
de
pagamento
Carrinho
de
Compras
Dica:
Ordenando por ROI nos permite identificar a priorizar as
melhores oportunidades. Veja que o item Gerao de Boleto
de pagamento tem a maior oferta global(R$24,00), ele tambm
tem um custo de desenvolvimento alto(R$11,00) e por isso est
mais abaixo na lista de prioridades.
Em um projeto tpico, haver um grande nmero de itens que no

tm Reais de desenvolvimento pagos por eles. Esta realmente uma
vantagem do mtodo, como as partes interessadas podem concentrar a sua
ateno em um nmero limitado de itens crticos no Product Backlog.
88
Passo 7: Realocao de Reais de Desenvolvimento

Aps a entrega do item Carrinho de Compras, por exemplo, os reais
gastos nele esto podero ser realocados. Este montante primeiro
colocado nos itens sem Reais pagos por eles. Os itens completos devero
ser removidos da tabela de licitao.
Nota: Reais de desenvolvimento no alocados podero ser
redistribudos para as partes interessadas para a prxima rodada de
priorizao(geralmente na prxima iterao). Redistribuindo Reais de
desenvolvimento e permitindo que as partes interessadas possam alterar
lances anteriores, somos geis na resposta a mudanas nas prioridades dos
stakeholders.
Geoff Watts e Jason Haines, em seu trabalho sobre Priority Markets,
(disponvel em https://www.scrumalliance.org/community/articles/2009/february/prioritymarkets
) cita alguns comportamentos que surgem desta dinmica, o qual os
autores chama de A psicologia do mercado. So eles:

Negociao: Os interessados podem ver os lances uns dos outros
e ajustar o seu lance de acordo com o mercado.
Negociao: Uma das partes interessadas possa "vender" seus
Reais de desenvolvimento para outro dos interessados para as
prestaes em espcie.
Votao ttica: Com base em outros lances, umas das partes
interessadas
podem
alocar
mais
ou
menos
Reais
para
determinados itens.
Interveno governamental: Quando o mercado livre gera
prioridades que no esto nos interesses estratgicos do projeto, o
Product Owner pode intervir e alocar Reais adicionais para um
determinado item. Como em qualquer mercado livre, a interveno
governamental pode ter uma srie de consequncias negativas:
extras Reais injetados no sistema reduzem o valor relativo de outros
89
Reais, resultando em inflao; os interessados podem tambm se

sentem marginalizados por terem suas prioridades substitudas.
6.9 - Theme screening

Outra tcnica bem interessante de priorizao a Theme Screening.
Para esta tcnica, geralmente selecionamos de 5 a 9 critrios para avaliar o
que mais importante para o prximo Sprint. Estes critrios devem
representar aspectos do nosso produto que consideramos importantes para a
priorizao de requisitos.
DICA:
Esses critrios podem ser definidos a partir da nossa
viso de produto, ou de requisitos de negcio a que
desejamos atender. Exemplos comuns podem incluir itens
como Colabora para atingir a meta, Impacto nos
processos organizacionais, Elimina problemas antigos
dos
usurios,
Facilidade
de
desenvolvimento,
Posicionamento do produto, etc.
Aps definir os critrios, selecione um tema que servir como base

para os fatores de comparao. Lembre-se que temas so grupos de
requisitos funcionalmente ligados ou que tenham objetivos de negcio
complementares. Este tema deve ser algo que deveria entrar no prximo
Sprint.
Um fator importantssimo a ser considerado na escolha dos critrios
de anlise e dos temas que todos devem ser capazes de entender o
significado de cada critrio de anlise e serem capazes de avaliar cada tema
relativo a esses critrios.
90
Por exemplo, aps a escolha podemos ter um quadro conforme

apresentado abaixo.
CRITRIOS
Temas
Tema
Tema
Tema
Tema
Tema
(Base)
Colabora para atingir a meta
Elimina problemas antigos dos usurios
Facilidade de desenvolvimento
Impacto nos processos organizacionais
Score
-1
-2
Legenda:
+ = Mais que
- = Menos que
0 = mesmo que
Devemos agora escolher um tema como base line(no nosso exemplo,

o Tema C), isto , um tema que servir de base de comparao para todos
os demais temas. Procure buscar sempre um tema que tenha uma prioridade
intermediria entre os temas escolhidos.
Agora, comparamos cada critrio de anlise com o nosso base line,
ou seja, perguntamos pros nossos envolvidos se determinado tema melhor
ou pior que o base line em cada critrio de anlise. No nosso exemplo
usamos + quando o tema comparativamente melhor que o tema base
para o critrio, - se o tema contribui menos ou 0 se tem a mesma
contribuio(Lembre-se que esta percepo subjetiva).
Somamos o total para cada temas, e teremos uma pontuao total
para o tema. Basta ento ordenar nossos temas, veja como ficou a
priorizao de nosso exemplo.
1) Tema A
2) Tema D
3) Tema C
91
4) Tema B
5) Tema E
ATENO
Existem 2 grandes riscos nesta tcnica. O primeiro a
escolha de critrios equivocados, geralmente quando no foi
bem desenvolvida a viso do produto. O segundo risco est
associado a escolha do Base line, um com prioridade muito
alta far com que muitos temas pontuem negativo. Um base
line muito baixo far com que muitos temas pontuem muito
alto. Assim, a escolha de um base line intermedirio na escala
de prioridade bem importante. Se errarmos na escolha da
base line, poderemos criar distores nos resultados.
6.10 - Kano model

A tcnica Kano baseada em entrevistas com os usurios e experts.
Ela bem interessante quando a opinio de todos tem o mesmo valor
(diferentemente da tcnica de Priority Markets, onde podemos atribuir pesos
maiores para os Decision Makers). Esta tcnica foi desenvolvida por um
professor de gerenciamento de qualidade chamado Noriaki Kano que
estudou e classificou as preferncias dos clientes em 3 categorias:
1. Mandatrio (Basic expectations): so caractersticas que so
consideradas bsicas que devem estar presentes no produto. A
ausncia delas ir frustrar o cliente, mas a sua presena no ir
aumentar a satisfao dele, j que o cliente espera que aquela
caracterstica esteja presente.
2. Linear (Satisfiers): so caractersticas que quanto mais, melhor
e que podem aumentar ou diminuir a satisfao do cliente. Geralmente
esto ligadas performance.
92
3. Desejadas (Delighters): so caractersticas que satisfazem o

cliente quando esto presentes no produto, porm, caso no estejam
no iro causar insatisfao.
Aps a identificao das funcionalidades, realizamos questionrios
com grupos de 10 a 30 usurios com perfis variados, com uma pergunta
funcional e outra disfuncional.
Pergunta Funcional: Como voc se sentir se esta funcionalidade
estiver presente?
Por exemplo:
Se o prximo release incluir o carrinho de compras, como voc
se sentir ?
( ) Eu gostaria que fosse desta forma
( X ) Eu ficarei neutro
( ) Eu posso viver desta forma
( ) Eu no gostaria que fosse desta forma
Pergunta
Disfuncional:
Como
voc
se
sentir
se
esta
funcionalidade estiver ausente ?

Por exemplo:
Se o prximo release NO incluir o carrinho de compras, como
voc se sentir ?
( ) Eu gostaria que fosse desta forma
( ) Eu ficarei neutro
( ) Eu posso viver desta forma
(X ) Eu no gostaria que fosse desta forma
93
E ento utilizando-se a seguinte categorizao para cada conjunto de

respostas(funcional e no funcional):
Nota: O exemplo abaixo foi baseado no trabalho de Martin Eriksson,
chamado MindtheProduct, disponvel na URL
http://www.mindtheproduct.com/2013/07/using-the-kano-model-to-prioritize-productdevelopment/
e adaptado pelo autor.
Disfuncional
Gostaria
Funcional
Deveria
Indiferente
Suporta
No
Gostaria
Gostaria
Deveria
Indiferente
Suporta
No
Gostaria
LEGENDA
M
Mandatrio
Indiferente
Linear
Reverso
Desejado
Questionvel
No caso do exemplo essa funcionalidade seria Desejado. Agora,

agregando os resultados, onde as funcionalidades que estamos verificando o
grau de satisfao que elas apresentam:
Funcionalidade
A
Funcionalidade
B
Funcionalidade
C
Desejado
Linear
Mandatrio
Indiferente
Reverso
Questionvel
12
29
22
21
21
23
94
Com base nesse ltimo quadro temos que a funcionalidade A o

bsico que os clientes esperam ter, veja que temos 29 entrevistados que
classificaram a funcionalidade A como Mandatrio. Mas preciso lembrar
que, uma vez alcanado o bsico, no devemos mais adicionar esforo
nessa funcionalidade pois ela no ir aumentar a satisfao do cliente.
Devemos apenas mant-la. A funcionalidade B parece ser vista por algumas
pessoas como bsica e por outras como quanto mais, melhor e a
funcionalidade C vista como um diferencial. Portanto, a prioridade seria A >
B > C.
Para se manter o Product Backlog priorizado por esse modelo
necessrio que todas as funcionalidades/caractersticas mandatrias estejam
no Road Map (sem exceder a quantidade de esforo necessria para
alcanar
bsico
esperado),
fazer
mximo
de
funcionalidades/caractersticas lineares e sempre tentar deixar um espao

para as funcionalidades desejadas, pois essas podem aumentar o grau de
satisfao do cliente rapidamente a seu favor.
6.11 - MMF Minimum Marketable Feature

A Tcnica de MMF pode ser utilizada para priorizao de seu backlog
de produto e para o planejamento de verses. Ela baseia-se em identificar as
caractersticas mnimas comercializveis de seu produto. Ela baseia-se no
princpio de priorizar o essencial para a gerao de valor, por exemplo, para
o desenvolvimento de um telefone celular as funcionalidades essenciais so
as de ligar e desligar e o envio de mensagens de texto, assim estas
funcionalidades devem ser priorizadas e estarem na primeira verso do
produto(ou no topo do backlog de produto), ouvir msica, registrar fotografias
e outras podem aparecer em verses mais avanadas(base do backlog de
produto).
A regra de ouro : desenvolva as caractersticas de maior valor
primeiro (maximizao do seu retorno).
95
Dica
Para simplificar o planejamento de verses, elimine
dependncias tcnicas, lembre-se que as estrias devem
respeitar o conceito de INVEST.
96
CAPTULO 7
7.1 - Estimativas geis
Um
dos
grandes
desafios
de
profissionais
da
rea
de
desenvolvimento de software como estimar o esforo para a criao de

novas funcionalidades, tarefas ou estrias. O principal objetivo de se estimar
criar uma mtrica comum para definio e comparao de esforos, e
consequentemente definies de prazos(e oramentos) para projetos e/ou
atividades.
Temos diversas formas de estimar software desde os antigos
KLOCs( Kilo lines of Code ou mil linhas de cdigo), homens hora, pontos de
funo entre outras. inegvel que estimar FUNDAMENTAL! Mas vemos
que grande parte do esforo empreendido em estimar com preciso
perdida, ou devido a alguma premissa que no se tornou verdadeira ou
porque a medida que trabalhamos no projeto, com mais conhecimento,
somos obrigados a ajustar nossas estimativas.
As formas mais comuns em estimativas so as apresentadas pelo
PMBok, guia de Boas Prticas do Project Management Institute e esto
apresentas abaixo:
Estimativa de um ponto: Apresenta a estimativa por atividade. Pode
ser
baseada
na
opinio
especializada,
informaes
histricas
ou
simplesmente adivinhao.
Estimativa Anloga(Top Down): Usam opinio especializada e
informaes histricas para prever o futuro
Estimativa Paramtrica: Observa os relacionamentos entre as
variveis em uma atividade para calcular estimativas.
97
Estimativa de Trs Pontos(Anlise PERT): Considera a mdia

entre a estimativa no melhor cenrio(O), adicionada a quatro vezes a
estimativa mais provvel(M), mais a estimativa do pior cenrio(P) , divido por
seis.
( P + 4M +O ) / 6
Atividades de desenvolvimento de software (projetos orientados
valor) geralmente so bem mais complexas do que atividades da construo
civil (como uma pintura de corredor) projetos orientados planos, pois em
um novo projeto de software, os requisitos nunca sero completamente
conhecidos at que o usurio os tenha utilizado, assim o grande desafio
nas estimativas de software est relacionado s dificuldades da clara
definio do escopo do produto, da definio da estratgia de como uma
atividade ser realizada e pelo simples fato que em um grupo distinto, a
experincia, conhecimento tcnico, cultura, etc. iro influenciar na estimativa
de cada um, por isso todas as estimativas tendem a apresentar impreciso.
Lembre-se que quando utilizamos horas ou dias como unidade de medida,
estamos estimando no s o esforo necessrio para a tarefa mas tambm a
velocidade individual dos membros que trabalharo nela.
A comunidade adepta aos mtodos e frameworks geis, geralmente,
procura utilizar estimativas que levam em considerao apenas o esforo
para a realizao de determinada tarefa(estrias) , onde todos os envolvidos
no desenvolvimento, medem as diversas tarefas e assim definem estimativas
comparativas(com margens de erro) entre todo o trabalho que precisa ser
realizado.
98
Veja a histria relatada por James Surowiecki que em seu trabalho

intitulado A Sabedoria das Multides queapresenta uma experincia
realizada em 1906, quando o cientista britnico Francis Galton ficou chocado
com o resultado de um experimento realizado por ele, em uma feira
municipal. O desafio era que um aougueiro profissional deveria adivinhar
com preciso o peso de um boi abatido. Sua surpresa ocorreu ao descobrir
que pessoas que visitavam a feira(com pouca ou nenhuma experincia em
cortes de carne) eram capazes no s de adivinhar o peso final do animal,
mas eram capazes de adivinhar com grande preciso(inclusive com
quilogramas e os detalhes em gramas).
A expectativa de Sir Francis era que os peritos(aougueiros
profissionais) estavam sempre bem e iria superar com folga uma multido, o
que no ocorreu.
Quando estamos jogando o Planning Poker, uma tcnica de
estimativa
utilizada
pela
comunidade gil,
ns igualmente estamos
aproveitando a sabedoria das multides com relao a nossas estimativas.

Estamos apostando que o pblico ser capaz de chegar a um melhor palpite
do que qualquer indivduo nico.
O Planning Poker uma tcnica de estimativa baseada no consenso
de toda a equipe(em suas experincias, conhecimentos e aptides), onde
utilizado um conjunto de cartas com valores especficos(pontos) relativos. O
Product Owner apresenta a tarefa ou estria para o time, e, aps uma breve
discusso, cada um escolhe uma carta e coloca virada para baixo sobre uma
mesa. Quando todas as cartas estiverem lanadas, elas so viradas e caso
no haja consenso nos valores escolhidos, estas diferenas so discutidas
de forma breve, geralmente, quem estimou com os maiores e menores
valores explicam o motivo de sua estimativa, e uma nova rodada acontece
at que haja a convergncia.
99
Exemplo de cartas que geralmente so utilizadas no Planning Poker
O Planning Poker funciona porque utiliza opinio de diversos

especialistas( que iro realmente realizar a tarefa), promove o dilogo que
permite maior acuracidade das estimativas, principalmente em itens com
maior incerteza. Alm de ser uma tcnica de estimar considerando a
experincia de todos da equipe, proporciona um conhecimento do negcio
mais homogneo e mais atraente (e divertida) que as demais tcnicas.
Grfico da Sequncia de Fibonacci
100
Geralmente o baralho do Planning Poker apresenta cartas com

escala da sequncia de Fibonacci, isso se deve ao fato da sequncia de
Fibonacci ser uma funo quadrtica, ao invs de uma funo linear, assim,
as diferenas entre valores so produzidas de forma muito rpida criando
intervalos logo no incio da sequncia, veja que as estimativas apresentam
erros, mas quando podemos comparar as tarefas(uma tarefa com 8 pontos
no significa que ela tem exatamente este tamanho mas algo entre 5 e 13
pontos) conseguimos dimensionar com mais preciso o esforo que dever
ser empreendido. Existe tambm a opo infinita, carta com a marcao ,
geralmente quando o time identificou uma estria que considera EPIC.
Outra forma de estimativa muito utilizada no mundo gil, a tcnica
PMG, uma analogia as medidas de roupas, onde cada item classificado
como P para pequeno, M para mdio e G para grande, de acordo com a
percepo de esforo do time para entreg-la.
Sempre devemos lembrar que:
A Definio dos pontos de cada estria de exclusividade do

Time. Lembre-se que o esforo empreendido em cada Sprint(ou
interao) pode variar de acordo com cada time. 18 pontos para o
time A e 18 pontos para o time B, NO SO O MESMO
ESFORO. A percepo de quanto esforo necessrio para
realizar um ponto subjetiva e diferente para cada time.
Os pontos definido em cada estria devem envolver TODO o

esforo para entreg-la pronto para funcional no ambiente real.
Significa que devemos considerar a complexidade devido ao
desconhecimento ou incertezas, o Esforo do trabalho e os Riscos
associados em nossas estimativas.
101
O Tamanho do esforo deve ser relativo. Isto , quando dizemos

que para entregar a estria A definimos 8 pontos e para a estria
B 16 pontos, significa que o esforo para entregar B o dobro de
A(mesmo que haja uma pequena variao devido a natureza
imprecisa das estimativas geis). Observe que neste ponto
devemos estar atento as estimativas por afinidade, podemos
agrupar as estrias por proximidade de esforo pontuado(pelo
TIME), o que facilita o dimensionamento do trabalho como um todo.
7.2 - Um pouco mais sobre times geis

Como nos vimos diversos mtodos geis temos processos e eventos
como as reunies de planejamento, reunies dirias, retrospectivas e outras,
porm o primeiro valor do manifesto gil :
Indivduos e interaes mais que processos e ferramentas
Os processos e eventos so facilmente descritas (at seguidas),
porm eles sempre dependero dos indivduos e suas interaes, e estes j
so mais difceis de serem generalizados e documentados como regras. Veja
que cada indivduo possui caractersticas nicas como personalidade,
conhecimento tcnico, cultura, valores, momento de vida, etc. e todos estes
fatores influenciaro nas interaes e em como o trabalho fluir.
Este valor do manifesto gil reflete a seguinte sentena mensagem :

Bons profissionais mesmo com poucos processos(ou at
mesmo sem nenhum) conseguem superar os maiores
desafios. Mesmo utilizando os melhores processos, um time
ruim ir falhar at mesmo em algumas tarefas simples.
102
Lderes de times geis devem concentrar-se nos fatores

humanos(pessoas e relacionamentos) para obterem o melhor
resultado.
7.3 - Liderana Adaptativa

O Termo liderana adaptativa se refere a como devemos lidar com
time dependendo da maturidade do time e de cada circunstncia. O autor
Bruce Tuckman, no trabalho Developmental Sequences in Small Groups
Psychological Bulletins 63(1965) foi um dos primeiros a identificar as fases
em que um time pode se encontrar desde a sua formao at chegar a um
estado de time de alta performance.
FORMAO
TEMPESTADE
(Storming)
NORMALIZAO
PERFORMANCE
SUSPENSO
103
Na fase de Formao os membros (ainda no so um Time)

comeam a trabalhar em grupo, nesta fase eles iniciam o processo de
aprendizado
uns
sobre
os
outros,
neste
momento
inicia-se
autoconhecimento do futuro time. Nesta fase identificamos um grupo

altamente comprometido, porm sem grandes conhecimentos, logo, a
liderana dever atuar bastante no direcionamento do trabalho, para isso
questionamentos como: Deixe-me ver isso? Onde est o problema? Qual o
prximo passo? Sero bem comuns.
Nota: A Formao ocorre sempre que um novo membro
introduzido ao time(mesmo que os demais, ou a maior parte do time
permanea). Nestes casos o tempo tende a ser menor do que a formao de
um time completamente novo.
Com o andamento do trabalho diversos conflitos e divergncias iro
surgir, o grupo passou para a fase de Tempestade, agora o grupo se torna
um pseudo-time, os seus membros desafiam-se entre si para a realizao
dos trabalhos. Durante a fase da Tempestade observa-se dilogos mais
speros, conflitos abertos e at insatisfao por isso a liderana precisa atuar
orientando o time nos diversos aspectos e auxiliando na soluo de
questes.
104
ATENO
Quando falamos em CONFLITO, devemos sempre
lembrar que:
O conflito natural e fora uma busca de
alternativas
O conflito uma questo de equipe
A abertura resolve conflitos
A resoluo de conflitos deve se concentrar
em questes e no em personalidade
A resoluo de conflitos deve se concentrar
no presente e no no passado
O Project Management BodyofKnowledge(PMBok), guia de Boas

Prticas do Project Management Institute(PMI), sugere que podemos
mitigar os conflitos, sempre lembrando e relembrando ao time:
Exatamente para onde o projeto est direcionado
As restries e objetivo do projeto
O contedo do Termo de Abertura do Projeto
Mudanas
Decises Importantes
Tornar as tarefas desafiadoras
Seguir as boas prticas de gerenciamento de projetos(Lembro que
estamos tratando de projetos orientados valor !)
O PMBoK, apresenta as sete origens de Conflitos em ordem de
freqncia:
1) Cronogramas
2) Prioridades do Projeto
3) Recursos
4) Opinies Tcnicas
5) Procedimentos Administrativos
105
6) Custo
7) Personalidade
Na fase de Normalizao o time em potencial comea a se tornar
um verdadeiro time, aprendendo como trabalhar uns com os outros e como
time, neste momento o TIME deve criar regras para ajudar\governar o
trabalho do prprio time. Neste momento a liderana um pouco mais
tmida e concentra-se mais no auxilio resoluo de alguns conflitos, assim
como lembrar constantemente das regras criadas por eles mesmos. Nesta
fase um bom momento para desafiar o time, para auxili-lo a se tornar um
time de alta performance.
Na fase de Performance os times so altamente competentes e
comprometidos, autnomos, empoderados, auto organizados e autopoliciados. O time trabalha com um s, com alta performance no trabalho e
nas suas entregas. Cada indivduo conhece bem as caractersticas dos
demais membros do time, a liderana assume um papel de trazer novos
desafios(para que o time resolva) sempre buscando a melhoria contnua.
Muitos times dificilmente chegam a fase final devido a mudanas na sua
composio.
106
7.4 - Inteligncia Emocional

Inteligncia emocional a nossa capacidade de identificar, avaliar e
influenciar nossas prprias emoes, de outros indivduos e de grupos. A
imagem abaixo identifica os diferentes aspectos da inteligncia emocional.
Prprio
Outros
Auto-Gerenciamento
Habilidades Sociais
Auto-Controle
Auto-Controle
Conscincia
Liderana Inspiradora
Adaptabilidade
Desenvolvimento dos demais
Direcionamento e
Trabalho em equipe e
Motivao
colaborao
Auto-Conhecimento
Conscincia
Regular
Social
Auto-Confiana
Empatia
Auto-conhecimento
Conscincia Organizacional
Emocional
Compreender o Ambiente
Reconhecer
Precisa Auto-Avaliao
A separao dos aspectos da inteligncia emocional nos quadrantes

significa que primeiro precisamos conhecer nossas emoes para poder
control-las, isto , precisamos saber o que nos irrita, nos frustra, nos faz
perder o foco para depois escolhermos uma estratgia para tratar e
responder a estas situaes e sentimentos. Devemos desenvolver estas
habilidades para decidir se vamos deixar estas emoes nos afetar ou se
iremos responder de maneira diferente. Daniel Goleman, no artigo Primal
Leadership: The Hidden Driver of Great Performance, publicadonaHarvad
Business Review, em 2001, afirma:
107
"O humor e comportamento do Lder conduz os humores e

comportamentos de todos os outros. Um chefe mal-humorado
e cruel cria uma organizao txica preenchida com
sentimentos negativos que ignoram as oportunidades."
Como lderes de times devemos trabalha as habilidades que nos
permitam identificar as situaes que influenciam negativamente os membros
do time a ajuda-los (os membros) a desenvolverem estratgicas para mitigalas ou elimin-las. Reconhecer que outros precisam de ajuda nos ajuda a
melhorar a performance individual e do time, promove a colaborao e o
trabalho em equipe.
7.5 - Comunicao e o ambiente de trabalho

Segundo o Antigo Testamento (Gnesis 11,1-9), os descendentes de
No, com a inteno de eternizar seus nomes, iniciaram o projeto da
construo da torre do templo de Marduk,(nome cuja forma em hebraico
Babel ou Bavel e significa "porta de Deus") uma torre to alta que chegaria
cu. O projeto provocou a ira de Deus que para puni-los, decidiu criar os
diversos idiomas para o povo da Terra, assim o processo de comunicao
entre os construtores foi comprometido e a torre no foi terminada. Este
mito uma tentativa de se explicar as diversas origens dos idiomas e
apresenta um risco real em todos os projetos (inclusive nos projetos atuais).
Segundo
Project
Management
Institute(PMI)
existe
uma
correlao direta entre a capacidade de comunicao e o desempenho do

projeto, isto , um bom gerenciamento de comunicaes fator determinante
de sucesso ou fracasso em projetos. Segundo o Project Management Body of
Knowledge(PMBok) que um conjunto de boas prticas em gerenciamento
de projetos, o gerenciamento das comunicaes do projeto inclui os
processos necessrios para assegurar que as informaes do projeto sejam
geradas, coletadas, distribudas, armazenadas, recuperadas e organizadas
de maneira oportuna e apropriada.
108
Observe que muitas vezes no dedicamos o tempo necessrio neste

gerenciamento, mas vamos a um simples exemplo:
Se o projeto possui 5 integrantes, existem 10 canais de comunicao,
veja a imagem abaixo.
Pode-se descobrir o nmero de canais de comunicao de uma

forma relativamente simples, veja:
[N *(N-1)] / 2
Onde: N o nmero de pessoas envolvidas no projeto
Existem vrias barreiras no processo de comunicao como:
ambientes ruidosos, distncia, codificao inadequada da mensagem, fazer
declaraes negativas, hostilidade, idioma, cultura e outros. Um ponto crtico
das interaes dentro do projeto deixar claro que as comunicaes
precisam de formalidade e devem necessariamente passar pelo gerente de
projetos, caso contrrio, o risco de problemas de comunicao podem
crescer significativamente.
O primeiro passo para um bom plano de comunicao identificar
todas as partes interessadas em um projeto - elas so: quem influencia ou
influenciado pelo projeto ou pelo resultado do projeto j que elas podem
109
influenciar o fracasso ou o sucesso do projeto, claro que algumas partes

interessadas podem influenciar mais do que outras em um projeto, mas
importante que TODAS sejam identificadas. Dentre muitos fatores, a
identificao das partes interessadas, possibilita ao gerente ter uma viso
dos interesses e expectativas de cada parte em relao ao projeto, o que
ajuda muito em negociaes e no gerenciamento das expectativas.
Um conceito bsico que as comunicaes devem ser eficientes(
fornecendo apenas as informaes necessrias) e eficazes( fornecendo
informaes nos formatos certo, no momento certo).
Quem deve receber quais informaes?
Quais so as reais necessidades de informao?
Qual informao necessria, de que tipo?
Em que formato e meio deve ser transmitida a informao?
Com que frequncia?
Qual o fluxo de informaes?
Existem diversos tipos de comunicao, escrita, verbal, formal,
informal, no formal, para-lingustica, interativa, passiva, ativa e outras. A
cultura da empresa pode ser uma barreira ou um facilitador, por isso uma
analise da cultura organizacional fundamental no papel do gerente de
projetos como integrador de reas, ou seja, inteligncia conversacional. Um
gerente de projeto passa aproximadamente 90% do seu tempo se
comunicando e para que o projeto tenha maiores chances de sucesso, entre
outras coisas, um bom plano de comunicao fundamental.
Muitas tcnicas, ferramentas e recomendaes geis preveem a
interao cara-a-cara, assim o espao onde o time ir trabalhar pode ser
uma fator de melhora nos processos. Times geis preferivelmente devem
trabalhar em espaos sem barreiras e de fcil acesso, agrupar os times em
um mesmo ambiente facilita a interao, diminui o desperdcio(provocado por
110
espera por uma informao ou deslocamento) alm de promover a

comunicao osmtica.
Comunicao Osmtica: Refere-se a toda informao til que flui de
membros da equipe como parte de conversas e perguntas dirias, quando
trabalham em estreita proximidade um do outro.
Alistair Cockburn, em seu trabalho Agile Software Development
define a comunicao osmtica como:
Campos de energia que irradiam de pessoas. Se voc est
muito longe, voc recebe muito pouco, mas se voc estiver
trabalhando em estreita proximidade, voc obter todos os
benefcios.
DICA
Para facilitar a comunicao cara-a-cara e o
compartilhamento de conhecimentos, recomendado
que os times sejam de tamanho reduzido, geralmente
at 12 membros ou menos(Lembre-se que o aumento
da complexidade da comunicao diretamente
proporcional ao nmero de pessoas envolvidas).
Quando os projetos so maiores o recomendado
trabalhar com diversos times, utilizando tcnicas como
o Scrum sob Scrum.
111
7.6 - Equipes virtuais

Quando
trabalhamos
com
equipes
virtuais
(distantes
geograficamente) demos utilizar os recursos tecnolgicos(Programas de

Mensagens Instantneas, Videoconferncias, VoIPs, Interfaces Remotas e
Colaborativas e outros, para promover a comunicao constante.
Sempre que possvel promova pelo menos uma reunio onde todos
os membros do time estejam presentes, mesmo que no dia a dia eles
trabalhem distante, uma atividade para que eles se conheam(fisicamente)
catalisa a fase de formao e melhora as futuras comunicaes.
7.7 - Acompanhamento de produtividade

Um dos grandes desafios de projetos geis o acompanhamento de
produtividade. A medio fundamental para planejarmos cronologicamente
as verses e itens que sero entregues em cada Sprint.
Antes de apresentarmos as formas de acompanhamento de
produtividade, devemos lembrar que:
A mudana do tamanho da Sprint ou da composio do Time

(mesmo que seja a sada ou entrada de apenas um novo
membro) alterar a base histrica de entrega do time e as
medies devero ser novamente contabilizadas.
Release Burndown Chart
A ferramenta de Release Burn-down permite acompanhar a evoluo
das verses de seu produto de maneira simples e visual. O eixo vertical
apresenta o esforo do release (este esforo foi estimado pelo time, em
pontos, horas ou outra mtrica pr-acordada), o eixo horizontal representa as
112
sprints. Observe que o eixo tem comportamento decrescente e inicia-se no

topo do eixo vertical e termina na base(ponto O) deste mesmo eixo.
113
Podemos acompanhar o Previsto X Realizado em cada Sprint, assim

como a velocidade do time(pontos ou horas) por Sprint, o que facilitar o
planejamento para prximas verses do produto.
7.8 Cumulative Flow Diagram(CFD)

O CFD uma tima ferramenta para monitoramento do trabalho de
desenvolvimento. Com ele podemos acompanhar o trabalho que falta, o
trabalho em progresso (WIP) e o trabalho pronto. Seu funcionamento
simples, no eixo vertical temos o trabalho estimado em pontos, horas ou
outra mtrica pr-definida pelo time, no eixo horizontal, o tempo(em dias,
semanas ou sprints). Uma grande diferena entre o CFD e o Burn-down
Chart que podemos visualizar o trabalho em progresso.
Na imagem abaixo, a rea em cor amarela apresenta o trabalho que
114
est pendente, isto , trabalho no iniciado, a rea laranja representa o

trabalho em progresso e a azul o trabalho pronto.
Observe que o grfico pode ajudar o Scrum Master e o time a

analisarem o comportamento do processo e auxiliar os ajustes necessrios.
No exemplo da imagem temos uma rea com grande amplitude na cor
laranja(WIP), significa que o time iniciou mais tarefas em paralelo antes de
finalizar as que j estavam em desenvolvimento, esta ao, em geral, deve
ser evitada, lembre-se que mais importante entregar tarefas do que iniciar
novas(acumulo de WIP, NO bom sinal!).
Dica:
Quando o grfico de seu time apresenta grande distncia
do pronto para o no iniciado significa que seu time est
com muitos trabalhos em progresso, possvel(e
aconselhvel) determinar um limitador para atividades em
andamento, por exemplo, s 2 estrias em paralelo, para
evitar o acmulo do trabalho em andamento e o atraso
nas entregas.
115
MENSAGEM FINAL
Os novos cenrios organizacionais, com o uso estratgico de
informaes e conhecimentos como o principal diferencial competitivo
demanda novas tcnicas de gesto e gerenciamento diferentes das
tradicionais estratgias de comando e controle, assim a adoo de tcnicas
emergentes para projetos orientados valor vem ganhando grande
crescimento
em
diversas
reas
que
lidam
com
profissionais
de
conhecimento. A mudana de qualquer cultura um grande desafio, mas

necessria para a adaptao e sobrevivncia nas novas dinmicas
empresarias. Evoluir questo de sobrevivncia, e para isso
preciso novos conhecimentos e CORAGEM!
116
SOBRE OS AUTORES:
Rafael Dias Ribeiro

Analista de Sistemas formado pela Universidade
Estcio de S, Mestre em Sistemas e Computao pelo
Instituto Militar de Engenharia, Project Management
Professional pelo PMI , Certified Scrum Master CSM e
Certified Scrum Product Owner - CSPO pela
ScrumAlliance e COBIT Foundation Certificate pela
ISACA. Possuo experincia nas reas de modelagem e
desenvolvimento
de
sistemas
de
computao,
gerenciamento de projetos, prticas emergentes de
agilidade em gerenciamento de projetos complexo,
mapeamento de processos de negcio, planejamento e
gerncia acadmica, ensino distncia e gesto
estratgica.

Graduado em Engenharia Eltrica pela Universidade do
Estado do Rio de Janeiro (1975) , Mestrado em Engenharia
de Sistemas - Informtica pelo Instituto Militar de
Engenharia (1985), MBA em Gesto de IES pela UNESA.
Diretor Geral do Instituto Superior de Tecnologia do Estado
do Rio de Janeiro (FAETEC) - Coordenador de Ps-graduao
dos cursos de Especializao de professores em TICS, e do
curso de especializao em Metrologia para Software.
Professor de banco de Dados, Inteligncia Artificial, Sistemas
de Informaes, Engenharia de Software, Anlise e
Linguagens de Programao, Produtividade e mtricas de
Software. Pesquisador de processos de negcio e sua
ergonomia. Pesquisador de objetos de ensino visando
otimizao do aprendizado. Autor do primeiro livro sobre
Inteligncia Artificial do Brasil. Primeiro livro de anlise
orientada a objetos do Brasil. Diretor Geral da FAETERJ-Rio
(antigo IST-Rio). A FAETERJ-Rio tem um curso de formao
de analistas de sistemas de nvel superior e duas psgraduaes (TIC aplicadas para professores - Metrologia
aplicada ao software), Desenvolveu e implantou novas
formas de atendimento pela secretaria, implantou a
utilizao de metodologias dinmicas de ensino nas salas
hbridas. Desenvolveu a biblioteca virtual em Q-RCode.
Desenvolvimento de planejamento participativo e utilizao
do site virtual (AVA). Desenvolveu conjunto de indicadores
de desempenho para a Faculdade e com isto obteve a
certificao ISO-9001; duas vezes o conceito 4 (2009 e
2011).
117
Diferentes tipos de projetos necessitam de diferentes mtodos de

gerenciamento. A abordagem gil muito utilizada em projetos orientados
a valor. Como vimos projetos orientados a valor geralmente so realizados
por profissionais do conhecimento e possuem elevado grau de incerteza,
por grande indefinio do escopo e elevado nmero de mudanas.
A maior parte dos conceitos e princpios geis surgiu com foco em
projetos de desenvolvimento de software e atualmente so utilizados em
diversos tipos de projetos que possuem grandes incertezas, como
campanhas publicitrias, novos produtos, planejamento de oramento e
muitas outras reas. Este livro apresenta conceitos para todo o tipo de
projeto.
Rafael Dias Ribeiro

As tcnicas apresentadas neste livro so fundamentais para todo o
gerente de projeto.
So tcnicas que devem ser obrigatoriamente do
conhecimento de engenheiros, economistas, pesquisadores de todas as

reas, analistas de sistemas e profissionais interessados
em formas
modernas de desenvolvimento e gesto de projetos.

Modernamente os projetos devem ser desenvolvidos para acelerar os
resultados. So estas tcnicas que so apresentadas neste livro.

ISBN: 978-85-919102-1-2
Telefone (92) 3584-1966
118

Livro Metodosageis

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro Metodosageis

Enviado por

Direitos autorais:

Formatos disponíveis

Rafael Dias Ribeiro,MSc,CSM,CSPO,ACP,PMP.

Horcio da Cunha e Sousa Ribeiro,MSc.

Rafael Dias Ribeiro

Gerenciamento de Projetos com

Catalogao na fonte por: Edirlane Carvalho de Souza Freitas CRB7-5463

Ribeiro, Rafael Dias; Ribeiro, Horcio da Cunha e Sousa Ribeiro.

Gerenciamento de projetos com mtodos geis / Rafael Dias Ribeiro, Horcio da

Dedico este livro a Vera Lcia Dias Ribeiro

4.2 - Como realizar o TDD ? .......................................................................................42

6.11 - MMF Minimum Marketable Feature...............................................................95

1.2 - Anlises de Ambientes

1.2.1 -Teoria de Cynefin

O Cynefin Framework tem cinco domnios. Os quatro primeiros so:

Por exemplo, em uma loja do McDonalds, s existe uma melhor

O sistema imprevisvel em detalhes, mais ainda podemos discernir

complexidade confuso difcil trabalhar a questo, e muito menos a

Desordem: o quinto domnio. o estado de no saber que tipo de

economicamente mais interessante e facilita a expanso do modelo.

1.3 - Tolerncia ao Erro

Cenrios simples e complicados so mais comuns em projetos de

nfase na execuo das etapas.

Mais estruturao e menos deciso.

Menos estruturao e mais deciso.

Foco nas respostas certas.

Foco nas perguntas certas.

Entendimento das tarefas.

trabalhador por tarefas.

Trabalhador visto como um ativo e

1.4 - Projetos Direcionados Valor e Projetos Direcionados

1.4.1 - Projeto Direcionado Plano:

Em projetos direcionados a plano, como o prprio nome sugere,

1.4.2 - Projeto Direcionado Valor:

Em projetos orientados a valor, quando se investe muito no

Outro ponto importante que tcnicas de gerenciamento de projetos

comunicaes, estimativas de custo, declaraes de trabalho de aquisio,

depende se voc deseja pendurar um quadro ou fazer uma instalao

Development, criado em Fevereiro de 2001, por diversos especialistas em

Manifesto para Desenvolvimento gil de Software

Indivduos e interaes mais que processos e ferramentas.

2.2 - Indivduos e interaes mais que processos e ferramentas

envolvidos no projeto e enfatizando as interaes produtivas e eficazes,

2.3 - Software em funcionamento mais que documentao

intermedirias(incrementos), raramente a documentao completamente

2.4 - Colaborao com o cliente mais que negociao de

2.5 - Responder a mudanas mais que seguir um plano

planejamento e apenas reagir s mudanas. Ns ainda precisamos planejar,

2.6 - Os 12 Princpios por trs do Manifesto:

1. Nossa maior prioridade satisfazer o cliente atravs da entrega

semanas a poucos meses, com preferncia menor escala de

diariamente em conjunto por todo o projeto.

As melhores arquiteturas, requisitos e designs emergem de

Em intervalos regulares, a equipe reflete sobre como se tornar

mais eficaz e ento refina e ajusta seu comportamento de acordo.

2.7 - Declarao de Interdependncia

promove abordagens geis e

adaptveis para unir as pessoas , projetos e valor. Para alcanar estes

Crie uma lista de

O FDD recomenda uma srie de boas prticas oriundas da

3.1.2 - Desenvolvimento por Funcionalidade:

3.2 - Dynamic Systems Development Method(DSDM) Metodologia de Desenvolvimento de Sistemas Dinmicos

3.2.1 - - Ciclo de Vida DSDM

O ciclo de vida do DSDM tanto iterativo e incremental. Portanto, a

CICLO DE VIDA DSDM