Universidade de Brasília – UnB

Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

RESUMO DO LIVRO “AGILE ESTIMATING AND PLANNING”

Bernardo Jacob Nunes MAT: 17/0006883

Igor Barbosa Ribeiro MAT: 14/0143734
Luísa Gonçalves Cury MAT: 16/0134633
Mateus Atique MAT: 17/0003485
Pâmella Oliveira MAT: 12/0131617
Patricia Helena dos Santos Martins MAT: 13/0057215
Rodrigo Cabral Ibraim MAT: 17/0071812
Vitor Dolabela de Lima Gonçalves MAT: 15/0151594

Metodologia de Projetos de Sistemas de Produção, João Mello da Silva

3 de setembro de 2017

I. INTRODUÇÃO
O título do livro “Agile Estimating and Planning” expressa que os processos de
estimativa e planejamento devem ser ágeis. Sem uma estimativa ágil e planejamento, não
se pode ter projetos ágeis. O autor discursa, principalmente, sobre o planejamento,
respondendo à questão de "o que construir e quando?". No entanto, para responder
perguntas sobre o planejamento, também deve-se abordar questões de estimativa e
agendamento.
O livro está organizado em sete partes e vinte e três capítulos, sendo que cada
capítulo termina com um resumo de pontos-chave e com um conjunto de perguntas de
discussão. A ideia de Cohn é que a estimativa e o planejamento devem ser atividades
inteiras de uma equipe, e o livro é a ferramenta para encontros semanais e discussão do
que foi lido e das perguntas no final de cada capítulo. A Parte I descreve o motivo pelo
qual o planejamento é importante, os problemas encontrados e os objetivos de uma
abordagem ágil.
O Capítulo 1 começa o livro descrevendo o propósito do planejamento, o que faz
um bom plano e o que torna o planejamento ágil. Já as razões mais importantes pelas
quais as abordagens tradicionais para estimar e planejar levam a resultados insatisfatórios
estão descritas no Capítulo 2. Finalmente, o Capítulo 3 começa com uma breve
recapitulação sobre o que significa agilidade e depois descreve a abordagem de alto nível
para estimativa e planejamento ágil abordadas pelo o resto deste livro.
A segunda parte introduz o princípio de estimativa, em que as estimativas de
tamanho e duração devem ser mantidas separadas. Os capítulos 4 e 5 apresentam pontos
de história e dias ideais, caracterizando as duas unidades apropriadas para estimar o
tamanho dos recursos a serem desenvolvidos. O Capítulo 6 descreve técnicas para estimar
pontos de história e dias ideais, e inclui uma descrição de “planejamento de poker”. O
Capítulo 7 descreve quando e como reavaliar e o Capítulo 8 oferece conselhos sobre como
escolher entre os pontos da história e os dias ideais. Parte III, “Planejando o Valor”,

Página 1 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

oferece conselhos sobre como uma equipe de projeto pode garantir que eles estão
construindo o melhor produto possível e o Capítulo 9 descreve a combinação de fatores
que precisam ser considerados ao priorizar os recursos.
O Capítulo 10 apresenta a abordagem para modelar o retorno financeiro de um
recurso ou conjunto de recursos e descreve como comparar os retornos de vários itens
para priorizar o trabalho no mais valioso entre eles. O Capítulo 11 inclui conselhos sobre
como avaliar e, em seguida, priorizar o desejo de certos recursos para os usuários de um
produto. Por fim, o Capítulo 12 conclui esta parte com conselhos sobre como dividir
recursos grandes em pequenos, mais gerenciáveis.
Na Parte IV, desloca-se a atenção em questões sobre o agendamento de um
projeto. O Capítulo 13 começa por analisar as etapas envolvidas na programação de um
projeto de equipe simples relativamente simples. Em seguida, o Capítulo 14 analisa a
forma de planejar uma iteração. Os capítulos 15 e 16 analisam como selecionar um
comprimento de iteração apropriado para o projeto e como estimar a taxa de progresso
inicial de uma equipe. O capítulo 17 analisa em detalhes como agendar um projeto com
uma grande quantidade de incerteza ou uma maior implicação de estar errado sobre o
cronograma e o Capítulo 18 descreve as etapas adicionais necessárias para estimar e
planejar um projeto que está sendo executado por várias equipes.
Uma vez que um plano foi estabelecido, ele deve ser comunicado ao resto da
organização e o progresso da equipe contra ele monitorado, tais tópicos são abordados
pelos capítulos 19, 20 e 21 da Parte V: o Capítulo 19 examina especificamente o
monitoramento do plano de lançamento, enquanto o Capítulo 20 analisa o monitoramento
do plano de iteração. O capítulo final desta parte aborda especificamente a comunicação
sobre o plano e o progresso em direção a ele.
O Capítulo 22 é o único capítulo da Parte VI, o qual discute o argumento de por
que a estimativa ágil e o planejamento e se posiciona como uma contrapartida ao Capítulo
2, que descreveu por que as abordagens tradicionais fracassam tantas vezes. Finalmente,
a Parte VII inclui apenas o capítulo 23 que, em um cenário fictício, é um estudo de caso
prolongado que reafirma os principais pontos do livro. A seguir, apresentam-se resumos
detalhados de cada capítulo, demonstrando seus pontos-chave no processo de
planejamento.

II. CAPÍTULO 1
O Capítulo 1 discursa sobre o aspecto crítico que a estimativa e o planejamento
têm, no entanto, ainda possuem altas chances de erros e são caracterizados pela sua difícil
maneabilidade. Ainda assim, tais atividades, por serem difíceis, não são justificativas para
baixos resultados em um projeto. O autor desenvolve o capítulo mostrando que o
refinamento de um projeto é progressivo, visto que as estimativas dadas no início de um
projeto são muito menos precisas do que as fornecidas mais tarde.
A ferramenta chamada de cone de incerteza é responsável por ilustrar a melhora
progressiva de um empreendimento, sendo que o seu objetivo é encontrar uma resposta
ótima para a questão geral do desenvolvimento de produtos sobre o que construir

Página 2 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

auxiliado por um cronograma. Tal processo de planejamento é responsável por reduzir o

risco e a incerteza, além de apoiar a tomada de decisão confiável e transmitir informações.
O capítulo finaliza com a conclusão de que um bom plano é suficientemente
confiável para que possa ser usado como base para tomar decisões sobre o produto e o
projeto; sendo assim, o planejamento ágil concentra-se mais no planejamento do que na
criação de um plano, incentiva a mudança e resulta em planos que são facilmente
alterados e estão espalhados por todo o projeto.

III. CAPÍTULO 2
O capítulo anterior argumenta que o propósito do planejamento é chegar
iterativamente a uma resposta otimizada para a questão do desenvolvimento de novos
produtos do que deve ser construído. Assim, o planejamento apoia quais recursos o
produto deve exibir, em que prazo e com quantos recursos; reduzindo o risco e a incerteza
sobre o que o produto deveria ser, apoiando uma melhor tomada de decisões,
estabelecendo confiança e transmitindo informações. Por outro lado, o autor afirma que
as formas tradicionais de planejamento de projetos geralmente geram decepção, pois o
planejamento baseado em atividades distrai a atenção dos recursos, que são a verdadeira
unidade de valor do cliente.
Cohn aponta que uma variedade de problemas seguidos leva à probabilidade de
entrega tardia contra um cronograma decorrente de um plano baseado em atividade. Com
boas intenções, os membros da equipe do projeto veem a multitarefa como uma possível
cura, mas acabaram por ser forçados a atrasar ainda mais o atraso devido aos custos
ocultos da multitarefa. Agora, quando a programação do projeto fica sem tempo, as
características são inevitavelmente descartadas. Como os recursos são desenvolvidos na
ordem considerada mais eficiente pelos desenvolvedores, os recursos descartados não são
necessariamente aqueles com o menor valor para os usuários. Ignorando-se a incerteza
sobre exatamente o que os usuários acabarão por querer, conclui-se um projeto no
cronograma, mas sem incluir recursos importantes que foram identificados após a criação
do plano.
Por fim, ignorar a incerteza sobre como o produto será desenvolvido levará a
atividades perdidas no plano do projeto, aumentando a probabilidade de que o projeto
seja atrasado. Assim, recursos serão descartados no final ou atividades de qualidade
inadequadas podem ser feitas. O que ocorre é que diversas organizações confundem
estimativas com compromissos, levando-os a perda de tempo hábil com o
comprometimento com tais estimativas.

IV. CAPÍTULO 3
Os rolamentos de feedback são mostrados na Figura 3.2 do novo incremento
resultante do produto nas condições de caixas de satisfação no início do planejamento de
lançamento e iteração. Com base em sua experiência no desenvolvimento do incremento
do produto durante a iteração, a equipe pode ter adquirido conhecimento ou experiência

Página 3 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

que afete o planejamento em um ou mais desses níveis. Da mesma forma, mostrar o

incremento do produto para usuários existentes ou prováveis pode gerar novos
conhecimentos que podem causar alterações nos planos. Uma equipe ágil incorporará
essas mudanças em seus planos na medida em que eles conduzam a um produto de maior
valor.
As equipes ágeis trabalham juntas como uma equipe, mas incluem papéis
preenchidos por indivíduos específicos. Primeiramente, o proprietário do produto é
responsável pela visão do produto e pela prioridade dos recursos que o time irá trabalhar.
Em seguida, o cliente, quem é a pessoa que paga pelo projeto ou compra o software, uma
vez que está disponível; e os usuários, desenvolvedores e gerentes são outros atores em
um projeto ágil. As equipes ágeis trabalham em iterações de caixa que fornecem um
produto de trabalho no final de cada iteração. Os recursos desenvolvidos nessas iterações
são selecionados com base na prioridade para o negócio, garantindo que os recursos mais
importantes sejam desenvolvidos primeiro.
As histórias de usuários são uma maneira comum para as equipes ágeis
expressarem as necessidades dos usuários, visto que um plano pode rapidamente ficar
desatualizado. Por isso, eles adaptam seus planos conforme apropriado: os projetos
devem ser vistos de forma rápida e confiável, gerando um fluxo de novas capacidades
úteis e novos conhecimentos e não como apenas a execução de uma série de etapas.
Os projetos geram dois tipos de novos conhecimentos: conhecimento sobre o
produto e conhecimento sobre o projeto e cada um é útil na refinação de um plano de
produto para alcançar o maior valor para a organização. Compreender as condições de
satisfação do proprietário do produto é fundamental no planejamento de lançamento e
iteração. Assim, as equipes ágeis usam três níveis de planejamento: planejamento de
lançamento, planejamento de iteração, e planejamento diário. O plano de lançamento olha
adiante para a duração do lançamento, geralmente de três a seis meses. O de iteração
avança apenas na duração de uma iteração, usualmente de uma a quatro semanas; e o
diário é o resultado dos compromissos dos membros da equipe assumidos, geralmente
durante uma reunião diária permanente.
Durante o planejamento de lançamento, toda a equipe identifica uma maneira de
atender às condições de satisfação para o lançamento, que inclui escopo, cronograma e
recursos e, para isso, o proprietário do produto pode desvalorizar uma ou mais das suas
condições de satisfação. O autor define que um processo semelhante ocorre durante o
planejamento da iteração quando as condições de satisfação são os novos recursos que
serão implementados e, os casos de teste de alto nível, demonstram que os recursos foram
implementados corretamente.

V. CAPÍTULO 4
O capítulo 4 aponta que os pontos da história são uma medida relativa do tamanho
de uma história de usuário: uma história de usuário estimada como dez pontos de história
é duas vezes maior, complexa ou arriscada como uma história estimada com cinco pontos
de história. Uma história de dez pontos é semelhante à metade do grande, complexo ou
arriscado como uma história de vinte pontos.

Página 4 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

Ou seja, o que importa são os valores relativos atribuídos a diferentes histórias e

a velocidade é uma medida da taxa de progresso de uma equipe por iteração. No final de
cada iteração, uma equipe pode observar as histórias que eles completaram e calcular sua
velocidade, somando as estimativas do ponto para cada história completa; sendo que os
pontos da história são puramente uma estimativa do tamanho do trabalho a ser realizado.
Por fim, o capítulo afirma que a duração de um projeto não é estimada tanto quanto é
derivada, levando o número total de pontos da história e dividindo-a pela velocidade da
equipe.

VI. CAPÍTULO 5
Cohn, discursa sobre o tempo ideal e o tempo decorrido, os quais são diferentes.
Usando o exemplo de um jogo de futebol, americano, ele afirma que o momento ideal de
um jogo é de sessenta minutos (quatro tempos de quinze minutos). No entanto, podem
ser usados três ou mais tempos e geralmente o tempo utilizado é maior que o tempo total.
O motivo da diferença é causado por toda a interrupção que pode ocorrer durante o jogo.
Assim, a quantidade de tempo que uma história de usuário levará para se desenvolver
pode ser mais facilmente estimada em dias ideais do que nos dias realmente decorridos.
A estimativa nos dias decorridos considera todas as interrupções que podem
ocorrer ao trabalhar na história. Se estimarmos em dias ideais, consideramos apenas a
quantidade de tempo em que a história vai demorar. Desta forma, os dias ideais são uma
estimativa de tamanho, embora menos restritos que pontos da história. A estimativa nos
dias ideais é melhor associada a uma única estimativa com cada história de usuário. Em
vez de estimar que uma história de usuário levará quatro dias programados, o autor afirma
que é melhor somar os dois dias do testador e três dias de proprietário do produto,
totalizando nove dias ideais como resultado.

VII. CAPÍTULO 6
O gasto de mais tempo e esforço para chegar a uma estimativa não aumenta
necessariamente a precisão da estimativa. O capítulo afirma que a quantidade de esforço
colocada em uma estimativa deve ser determinada pelo propósito dessa estimativa.
Mesmo que as melhores estimativas sejam dadas por aqueles que vão fazer o trabalho,
em uma equipe ágil, não se sabe quem fará o trabalho antecipadamente. Portanto, estimar
deve ser uma atividade colaborativa para a equipe e as estimativas devem estar em uma
escala predefinida.
As características que serão trabalhadas em um futuro próximo e que precisam de
estimativas razoavelmente confiáveis devem ser feitas pequenas o suficiente para que elas
possam ser estimadas em uma escala não-linear. As características maiores, que
provavelmente não serão implementadas nas próximas iterações, podem ser majoradas e
estimadas em unidades maiores.

Página 5 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

Para chegar a uma estimativa, aborda-se a opinião, analogia e desagregação de

especialistas através do “planejamento do poker”, onde cada estimador recebe um baralho
de cartas com uma estimativa válida em cada um. Uma característica é discutida e cada
estimador seleciona o cartão que representa sua estimativa; por fim, todos os cartões são
exibidos ao mesmo tempo, as estimativas são discutidas e o processo é repetido até a
conclusão de um acordo sobre a estimativa.

VIII. CAPÍTULO 7
Lembrando que os pontos da história e os dias ideais são estimativas do tamanho
de um recurso, o autor afirma que o processo de reavaliação pode ser previsto. A
reavaliação ocorre quando a opinião sobre o tamanho relativo de uma ou mais histórias
muda. O melhor cenário é deixar a velocidade servir como equalizador do processo e
cuidar da maioria das imprecisões de estimativa e não é recomendado pelo livro o crédito
parcial a histórias de usuários parcialmente finalizadas.
Mike Cohn afirma que é preferível que uma equipe conte toda a estimativa em
relação à sua velocidade (se eles terminaram completamente e o recurso foi aceito pelo
proprietário do produto) ou para que eles não contenham nada em direção a sua história.
No entanto, a equipe pode optar por reexaminar histórias de usuários parcialmente
completas; o que normalmente significará estimar uma história de usuário representando
o trabalho que foi concluído durante a iteração e apresentar uma ou mais histórias de
usuários que descrevem o trabalho restante. Assim, a soma dessas estimativas não precisa
igualar a estimativa inicial encontrada.

IX. CAPÍTULO 8
O capítulo discursa sobre a vantagem que os pontos de história têm de ajudar a
promover o comportamento da equipe multifuncional. Além disso, porque os pontos da
história são uma medida mais pura de tamanho, eles não precisam ser reestimados se a
equipe melhorar em uma tecnologia ou no domínio. A estimativa dos pontos da história
é frequentemente mais rápida do que estimar os dias ideais. Finalmente, ao contrário dos
dias ideais, os pontos da história podem ser comparados entre os membros da equipe se
um membro pensa que algo levará seus quatro dias ideais e outro membro pensa que
levará um dia ideal, cada um pode estar certo e não tem base para argumentar e estabelecer
uma única estimativa.
Os dias ideais têm as vantagens de serem facilmente explicados para os atores que
estão fora da equipe, de serem mais fáceis de começar e de facilitar a previsão da
velocidade inicial. No entanto, o autor finaliza com a preferência por pontos de história,
por serem estimativas mais convincentes para uma equipe.

Página 6 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

X. CAPÍTULO 9
O capítulo aborda que a situação em que o tempo é suficiente para realizar todas
as tarefas, é quando a organização mais precisa priorizar o que é trabalho primeiro para
um planejamento ágil. Assim, existem quatro fatores principais a serem considerados:
1. O valor financeiro de ter as características;
2. O custo do desenvolvimento (e talvez do apoio) dos novos recursos;
3. A quantidade e significado da aprendizagem e do novo conhecimento criado
pelo desenvolvimento dos recursos; e
4. A quantidade de risco removido ao desenvolver os recursos.
Esses fatores são combinados pensando primeiro no valor e custo do tema. Assim,
classifica os temas em uma ordem inicial e os temas podem então ser movidos para a
frente ou para trás com base nos outros fatores.

XI. CAPÍTULO 10
O autor afirma que a análise financeira dos temas ajuda na priorização, visto que
para a maioria das organizações, a linha inferior é a quantia de dinheiro ganhos ou salvos.
Geralmente, é suficiente prever a eficiência de receita operacional nos próximos dois
anos. No entanto, olhando mais adiante, uma boa maneira de modelar o retorno de um
tema é considerar a receita que ele gerará de novos clientes, de clientes atuais comprando
mais cópias ou serviços adicionais, de clientes que poderiam ter ido de outro modo para
um produto competitivo e de qualquer eficiência operacional que poderá fornecer.
O autor afirma que o dinheiro que ganhou ou gastou hoje vale mais do que o
dinheiro ganho ou gasto no futuro. Para comparar um valor atual com um valor futuro, o
valor futuro será descontado novamente em um valor atual, sendo que o valor atual é o
montante que pode ser depositado em um banco ou em algum outro investimento
relativamente seguro e que crescerá para o valor futuro no tempo futuro.
O capítulo 10 aponta quatro maneiras de avaliar um fluxo de caixa: o valor
presente líquido, taxa interna ou retorno (retorno sobre o investimento), período de
retorno e período de retorno descontado. Assim, ao calcular esses valores para cada tema,
o proprietário e a equipe do produto podem tomar decisões inteligentes sobre as
prioridades relativas dos temas.

XII. CAPÍTULO 11
O capítulo anterior descreveu a importância do “factoring” de aprendizagem e
redução de risco na priorização geral de um recurso. Já o capítulo 11 discursa sobre duas
abordagens para priorizar a desejabilidade de características: análise de Kano e
ponderação relativa. Na primeira, os recursos são segregados em recursos indispensáveis,
recursos lineares e excitadores. Isso é feito perguntando a potenciais usuários duas

Página 7 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

perguntas sobre cada recurso: como eles se sentiriam se o recurso estava presente e como
eles se sentiriam se não estivesse presente.
Já a ponderação relativa fornece uma abordagem para avaliar os benefícios da
implementação de um recurso, as penalidades de não o implementar e o custo em um
único valor que representa a prioridade de um recurso.

XIII. CAPÍTULO 12
Pode ser útil dividir uma história que não se encaixa em uma iteração, seja devido
a sua grandiosidade para qualquer iteração ou para caber no tempo restante em uma
iteração que está sendo planejada. Também, é útil dividir um grande ponto de história se
precisar fornecer uma estimativa mais precisa do que pode ser feita com uma grande
história, pois uma história pode ser dividida pelo tipo de dados que irá suportar ou pela
base nas operações inerentes à história.
O autor afirma que a partilha de histórias nas operações Common CRUD (Create,
Read, Update, Delete) é comum. Uma história pode ser reduzida ao segmentar quaisquer
preocupações transversais, como a segurança, o registro, o tratamento de erros e assim
por diante ou ao ignorar alvos de desempenho durante a iteração em que a história é
tornada funcional. O objetivo do desempenho pode ser feito por sua própria história e
satisfeito em uma iteração posterior, onde muitas histórias descrevem duas ou mais
necessidades. Se essas necessidades forem de prioridade diferente, divide-se as histórias
dessa maneira; procurando sempre evitar a divisão de uma história nas tarefas de
desenvolvimento que serão necessárias para implementar o recurso.
O trabalho de divisão de tarefas necessárias é um hábito que é fácil para a divisão
de histórias de usuários, mas é importante evitar a tentação de fazer uma grande história
em grande escala, incluindo mudanças relacionadas que não são necessárias para a
entrega da história do usuário. Finalmente, o autor lembra que às vezes é apropriado
combinar histórias de usuários, especialmente no caso de correções de bugs.

XIV. CAPÍTULO 13
O capítulo 13 apresenta que um plano de lançamento é um plano de alto nível que
cobre um período maior de uma iteração. Para a maioria das equipes, uma liberação
ocorre a cada três a seis meses, mas não é incomum ter versões mais (ou menos)
frequentes dependendo do tipo de software. No seu nível mais simples, o planejamento
de lançamento é trivial: é necessário multiplicar a velocidade esperada pelo número de
iterações planejadas e selecionar as histórias cujas estimativas somem para preencher o
lançamento.
O autor afirma que um plano de lançamento não precisa descrever exatamente o
que será trabalhado durante cada iteração. Na verdade, esse nível de detalhe raramente é
necessário; pois, para a maioria dos projetos, é bastante adequado identificar as histórias
que serão trabalhadas no primeiro par de iterações, deixando as restantes histórias serem

Página 8 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

priorizadas em iterações específicas em outro momento do planejamento. O planejamento

de lançamento é um processo iterativo que começa por identificar as condições de
satisfação do proprietário do produto para o projeto e geralmente incluem metas para o
cronograma, escopo e recursos.
Porém, se um projeto não puder ser planejado e não atender ao conjunto de
condições iniciais de satisfação, o processo de planejamento é repetido para ver se um
conjunto de condições reduzidas pode ser cumprido, colocando a funcionalidade desejada
para ser entregue mais tarde ou com uma equipe maior, em um cenário fictício. Assim,
uma vez que um plano de lançamento é criado, ele é atualizado no início de cada iteração.

XV. CAPÍTULO 14
Neste capítulo, ao contrário de um plano de lançamento, um plano de iteração
examina mais detalhadamente o trabalho específico de uma única iteração. Ao invés do
horizonte de três a nove meses de um plano de lançamento típico, o plano de iteração não
dá mais atenção que uma única iteração. As histórias de usuários bastante grandes de um
plano de lançamento são decompostas em tarefas no plano de iteração.
Assim, o autor afirma que cada tarefa é estimada em termos do número de horas
ideais que a tarefa levará para concluir e explicita que existem duas abordagens gerais
para o planejamento de uma iteração-velocidade e motivada por compromissos. Sendo
que as duas abordagens compartilham muitos dos mesmos passos e muitas vezes
resultarão na criação do mesmo plano de iteração.

XVI. CAPÍTULO 15
Nessa parte do livro, o autor chama a atenção para evitar-se o fim do trimestre
embora seja tentador alinhar as iterações com o final do mês; gravando-se as iterações até
os finais dos meses, uma em cada três iterações, coincidirá com o final de um trimestre
fiscal. Embora não seja um problema com as empresas privadas, há uma enorme pressão
nas empresas públicas para atingir metas de receita trimestral.
Com o exemplo apresentado pelo autor, a diferença de uma semana talvez não
pareça altamente crítica para um projeto de nove meses, mas o fato de que a demora fez
a entrega de um quarto do projeto ser comprometido foi extremamente importante para
chamar atenção a esse ponto. Quando o envio inicial planejado de centenas de cópias não
aconteceu em 31 de março, a receita dessas pré-vendas e atualizações não poderia ser
reconhecida até o segundo trimestre.
Por outro lado, a entrega podia ter ocorrido antes, mas a falta de planejamento
para o final do mês e a despensa de diversas incógnitas e incertezas comprometeram o
desenvolvimento de software para reconhecimento da receita ao atingir o final do
trimestre.

Página 9 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

XVII. CAPÍTULO 16
Nesse capítulo o autor afirma que existem três maneiras de estimar a velocidade:
primeiro, usando médias históricas e considerando se houveram mudanças significativas
na equipe, a natureza do projeto, a tecnologia e assim por diante. Em segundo lugar,
diferindo a velocidade estimada até executar algumas iterações, sendo esta geralmente a
melhor opção. E, em terceiro lugar, prevendo a velocidade, quebrando algumas histórias
em tarefas e vendo o quanto se encaixará em uma iteração. Tal processo é semelhante ao
planejamento da iteração.
Independentemente de qual abordagem será escolhida, as estimativas de
velocidade devem ser dadas em um intervalo que reflete a incerteza inerente à estimativa
e o tamanho da gama de uso pode ser dimensionada através do cone de incerteza.

XVIII. CAPÍTULO 17
Aqui, o livro aponta que a maioria dos projetos contém uma enorme quantidade
de incerteza, a qual muitas vezes não é totalmente refletida nos horários e nos prazos que
as equipes criam. Há momentos em que essa incerteza é tão grande ou significativa que
etapas adicionais devem ser tomadas ao estimar a duração do projeto. Este pode ser o
caso quando o projeto for planejado com antecedência, cumpre o prazo com um conjunto
funcional, o projeto é terceirizado, os requisitos ainda estão em um nível superficial, ou
quando há um impacto significativo (financeiro ou de outra forma) está equivocado sobre
uma data.
Os dois tipos mais comuns de buffers são buffers de recursos e buffers de
agendamento. Um buffer de recurso é criado quando os requisitos de um produto são
priorizados e é reconhecido que nem todas as características podem ser entregues. O
processo ágil DSDM, por exemplo, recomenda que 30% do esforço do projeto seja
considerado opcional, o que cria um buffer de recurso para o projeto. Se o tempo for curto,
o cronograma ainda pode ser cumprido descartando itens no buffer de recursos.
Um buffer de agendamento, por outro lado, é criado incluindo na agenda uma
quantidade de tempo que reflete a incerteza inerente ao tamanho de uma equipe. Ele pode
ser construído estimando um tamanho provável de 50% e um tamanho provável de 90%
para cada história de usuário. Ao aplicar uma fórmula para cada uma das estimativas de
50% e 90%, um buffer de agendamento de tamanho adequado pode ser estimado.
Um projeto deve se proteger contra a incerteza do recurso com um buffer de
recurso e contra a incerteza da agenda com um buffer de agendamento e um buffer de
recurso pode ser combinado com um buffer de agendamento. Sendo o último caso uma
boa ideia para permitir que o tamanho de cada um seja o menor possível.

Página 10 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

XIX. CAPÍTULO 18
O último capítulo da Parte IV apresenta que os projetos ágeis tendem a evitar
grandes equipes, utilizando equipes menores para o desenvolvimento de grandes projetos.
Quando várias equipes estão trabalhando em um projeto, eles precisam coordenar seu
trabalho e este capítulo descreveu quatro técnicas úteis para ajudar várias equipes a
trabalhar no mesmo projeto.
Primeiro, as equipes devem estabelecer uma base comum para suas estimativas,
onde todas as equipes devem concordar em estimar na mesma unidade, pontos da história
ou dias ideais. Eles devem concordar ainda mais sobre o significado dessas unidades,
concordando com as estimativas de um pequeno conjunto de histórias.
Em segundo lugar, quando várias equipes precisam trabalhar juntas, muitas vezes
é útil adicionar detalhes às histórias de usuários mais cedo. A melhor maneira de fazer
isso é identificando as condições de satisfação do proprietário do produto para uma
história, sendo estas demonstradas como verdadeiras sobre uma história uma vez que ela
está completamente implementada.
Terceiro, as equipes múltiplas se beneficiam com a incorporação de um plano
avançado para o processo de planejamento de lançamento. Um plano avançado de
“lookahead” espera um pequeno número de iterações (normalmente apenas duas ou três)
e permite que as equipes coordenem o trabalho, compartilhando informações sobre o que
cada um estará trabalhando no futuro próximo.
Por fim, em quarto lugar, em projetos altamente complexos e com muitas
dependências entre equipes, pode ser útil incorporar buffers de alimentação no plano.
Sendo que um buffer de alimentação é uma quantidade de tempo que impede a entrega
tardia de uma equipe causando o início tardio de outra.
Essas técnicas apresentadas geralmente são introduzidas em um projeto na ordem
descrita, mas podem ser introduzidas em qualquer ordem desejada pela equipe de
planejamento.

XX. CAPÍTULO 19
O autor explicita que a velocidade mede a quantidade de trabalho completada por
uma equipe em cada iteração e deve ser calculada usando uma regra de tudo ou nada. Se
uma história é concluída, a equipe conta sua estimativa completa ao contar a velocidade.
Agora, se uma história é parcialmente concluída durante uma iteração, ela não é contada
ao determinar a velocidade. Como auxilio, o gráfico de queima de lançamento mostra o
número de pontos da história ou dias ideais restantes no projeto a partir do início de cada
iteração.
Por outro lado, o gráfico de Burndown de uma equipe nunca é perfeitamente
suave, variando devido a estimativas imprecisas, estimativas alteradas e mudanças no
escopo, por exemplo. Um gráfico de queima pode até mostrar uma queima durante uma
iteração, significando que, mesmo que a equipe provavelmente tenha completado algum

Página 11 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

trabalho, eles perceberam que o trabalho restante foi subestimado ou aumentaram o

alcance do projeto. O ponto-chave para interpretar um gráfico de queima de liberação é
entender que ele mostra o progresso líquido da equipe, ou seja, seu progresso menos
qualquer trabalho adicionado ao lançamento.
Por fim, um gráfico de barra de queima de lançamento oferece uma variação às
vezes útil no gráfico de queima de liberação padrão. Isso ocorre separando o progresso
de uma equipe em relação ao trabalho planejado e mudanças no escopo da versão e as
mudanças do escopo são mostradas deixando cair a barra abaixo do eixo horizontal. O
autor afirma que este tipo de gráfico é mais expressivo do que um gráfico de queima
padrão, mas deve ser usado com cuidado, pois pode causar argumentos em algumas
organizações sobre se uma alteração afeta a parte superior ou inferior de uma barra no
gráfico. Por outro lado, o gráfico de estacionamento é útil para apresentar uma visão de
alto nível do progresso de uma equipe na implementação dos vários temas planejados em
um projeto.

XXI. CAPÍTULO 20
O presente capítulo apresenta que uma placa de tarefa, que geralmente é um
quadro branco, uma placa de cortiça ou apenas um espaço designado na parede, ajuda
uma equipe a organizar e visualizar seu trabalho. As colunas de uma placa de tarefas são
rotuladas e os membros da equipe movem as cartas de tarefas através das colunas à
medida que o trabalho avança. Um gráfico de queimação de iteração é semelhante a um
gráfico de queima de liberação, mas é usado para rastrear apenas o trabalho da iteração
atual.
O gráfico com o número de horas restantes no eixo vertical e os dias da iteração
no eixo horizontal demonstra que as equipes devem ser relutantes em rastrear as horas
reais gastas nas tarefas, a fim de melhorar a estimativa. Assim, os riscos e o esforço para
fazê-lo geralmente superam os benefícios e as equipes não precisam calcular ou rastrear
a velocidade individual.

XXII. CAPÍTULO 21
O capítulo 21 afirma que a comunicação sobre estimativas e planos de maneira
frequente, honesta e bidirecional é o almejado pelas organizações e utiliza um gráfico de
Gantt como ferramenta útil para comunicação sobre um plano. No entanto, não deve ser
tomado abaixo do nível de repartição de recursos e os recursos dele devem ser mostrados
como em processo durante toda a duração da iteração.
Outras ferramentas, os gráficos de Burndown, são o método principal para se
comunicar sobre o progresso, mas eles são frequentemente acompanhados por um gráfico
que mostra a velocidade da equipe de desenvolvimento por iteração, sendo útil pensar na
velocidade como uma gama de valores em vez de um valor.

Página 12 de 13
 Universidade de Brasília – UnB
Faculdade de Tecnologia – FT
Departamento de Engenharia de Produção

De acordo com o livro, uma boa maneira de fazer isso é usar a velocidade da
iteração mais recente, a média das oito iterações anteriores e a média das três mais baixas
das oito iterações anteriores. Esses três valores apresentam uma boa imagem do que
aconteceu, uma média de longo prazo e um pior caso do que poderia acontecer. Em alguns
projetos, um resumo final da iteração pode ser útil, tanto na divulgação de informações
atuais quanto como documento histórico para uso no futuro.

XXIII. CAPÍTULO 22
Por fim, o capítulo 22 aponta que o objetivo do planejamento ágil é descobrir de
forma iterativa uma solução ótima para as questões gerais de desenvolvimento de
produtos sobre quais recursos com quais recursos em que linha de tempo. Uma
abordagem ágil para estimar e planejar consegue encontrar essa solução porque os planos
são feitos em diferentes níveis e o replanejamento ocorre com frequência; porque os
planos são baseados em recursos e não em tarefas, o tamanho é estimado primeiro e, em
seguida, a duração é derivada da estimativa de tamanho. Com isso, pequenas histórias
mantêm o trabalho fluindo e o trabalho em processo é eliminado no final de cada iteração,
visto que o progresso é medido na equipe, em vez do nível individual e porque a incerteza
é reconhecida e planejada.

Página 13 de 13