Aula 3 - conceito de métrica-PlanningPoker

Prévia do material em texto

1
Qualidade de Software
O conceito de métrica de software
O que são Métricas de Software?
◼ Uma métrica é a medição de um atributo 
(propriedades ou características) de uma 
determinada entidade (produto, processo ou 
recursos).
◼ Exemplos:
◼ Tamanho do produto de software (ex: Número de Linhas de 
Código – LOC)
◼ Número de pessoas necessárias para preparar a especificação 
técnica de uma aplicação.
◼ Número de defeitos encontrados no documento de requisitos 
do software
O que são Métricas de 
Software?
◼ Esforço (Horas, pontos)
◼ X
◼ Prazo (Duração Cronológica)
◼ X
◼ Custo
O que são Métricas de Software?
◼ Exemplos:
◼ Tempo, em dias, para realizar a programação 
de um sistema
◼ Custo, em R$, para a realização de uma tarefa
◼ Grau de satisfação do cliente com um 
determinado software (muito satisfeito, 
satisfeito, pouco satisfeito)
Por que Medir Software?
◼ Avaliar a produtividade do processo de 
desenvolvimento
◼ Melhorar a gerência de projetos e o 
relacionamento com clientes
◼ Reduzir frustrações e pressões de cronograma
◼ Gerenciar contratos de software
◼ Indicar a qualidade de um produto de software.
◼ Avaliar os benefícios (em termos de produtividade 
e qualidade) de novos métodos e ferramentas de 
engenharia de software
◼ Avaliar retorno de investimento
Motivação
◼ Um dos objetivos básicos da Engenharia de 
Software é transformar o desenvolvimento de 
sistemas de software, 
◼ partindo de uma abordagem artística e 
“indisciplinada”, 
◼ para alcançar um processo controlado, 
quantificado e previsível.
Motivação
◼ “Se você não sabe para onde quer ir, 
pode seguir qualquer caminho. 
◼ Se você não sabe onde está, não adianta 
ter um mapa, que ele não vai ajudar!”
◼ Roger Pressman
Motivação
◼ Quando se pode medir aquilo sobre o qual se 
está falando e expressá-lo em números, sabe-
se alguma coisa sobre o mesmo; 
◼ mas quando não se pode medi-lo, quando não 
se pode expressá-lo em números, o 
conhecimento que se tem é de um tipo 
inadequado e insatisfatório; 
◼ este pode ser o começo do conhecimento, mas 
dificilmente alguém terá avançado em suas 
ideias para o estágio da ciência.
◼ Roger Pressman
Motivação
9 mães não fazem 
um bebe 
em 1 mês
Propriedades Desejáveis de uma
Métrica
◼ Facilmente calculada, entendida e 
testada
◼ Passível de estudos estatísticos
◼ Expressa em alguma unidade (tempo, 
pessoas, $)
◼ Obtida o mais cedo possível no ciclo de 
vida do software
Uma métrica deve ser:
◼ Válida: quantifica o que se quer 
medir
◼ Confiável: produz os mesmos 
resultados, dadas as mesmas 
condições
◼ Prática: barata, fácil de calcular e 
fácil de interpretar
Categorização de Métricas
◼ Métricas diretas (fundamentais ou 
básicas)
◼ Medidas realizadas em termos de 
atributos observados (usualmente 
determinadas pela contagem)
◼ Ex.: custo, esforço, número de linhas de 
código, número de páginas, número de 
diagramas, etc.
Categorização de Métricas
◼ Métricas indiretas (derivadas)
◼ Medidas obtidas a partir de outras 
métricas
◼ Ex.: complexidade, eficiência, 
confiabilidade, facilidade de 
manutenção
Categorização de Métricas
◼ Métricas orientadas a tamanho
◼ São medidas diretas do tamanho dos 
artefatos de software associados ao 
processo por meio do qual o software 
é desenvolvido.
◼ Ex.: custo da implementação, número de linhas de 
código (LOC, KLOC)
◼ número de páginas de documentação,
◼ número de defeitos em uma especificação de 
requisitos, etc.
15
O Processo de gerência de projetos
A gerência é a primeira camada do processo de 
engenharia de software
 Para um trabalho bem sucedido deve compreender:
◼ o trabalho a ser feito
◼ os riscos envolvidos
◼ os recursos exigidos
◼ as tarefas a serem executadas
◼ os marcos de referência a serem acompanhados
◼ o esforço necessário
16
Estimativa é uma das principais atividades do planejamento 
de software.
Estima-se: 
1. Esforço humano exigido (horas?Pontos?) 
2. Duração cronológica do projeto
3. Custo
Estimativa é a essência da dificuldade em controlar 
projetos de software
Estimativas
Projetos de software
31% são cancelados
 53% custam o dobro do estimado
 Apenas 16% são completados no 
prazo e custo estimados
* dados do CHAOS report
Mas por que?
Mas por que?
Falta de envolvimento do 
usuário
Requisitos e especificações 
incompletas
Falta de suporte da direção
Falta de Pessoas e Recursos
Falta de ESTIMATIVAS!!!
20
Causas de estimativas de software mal feitas 
➢ Falta de especialização em estimativas (falta de 
treino)
➢ Falta de se fazer provisões adequadas para 
contrabalançar o efeito das distorções 
(Estimativa de três pontos). 
➢Falta de informações úteis para o processo de 
estimativas
Estimativas
21
Falta de se fazer provisões adequadas para 
contrabalançar o efeito das distorções 
(Estimativa de três pontos). 
Uma técnica que usa três estimativas de custos ou 
duração para representar os cenários:
- otimista, mais provável e pessimista. 
Esta técnica é aplicada para melhorar a exatidão das 
estimativas de custos ou duração quando não há 
certeza em relação à atividade subjacente ou ao 
componente de custo.
Estimativas
22
Atributos comuns de técnicas de estimativas:
• o escopo do software deve ser estabelecido 
antecipadamente.
• métricas de software são utilizadas.
•histórico de medidas passadas é usado como uma 
base.
• o projeto é particionado em pequenas partes que 
são estimadas individualmente .
Estimativas
23
Determinação de Prazos
Envolve as seguintes atividades:
◼ Planejamento da programação a ser realizada
◼ Identificação do conjunto de tarefas de projeto
◼ Estabelecimento das interdependências entre as 
tarefas
◼ Estimativa do esforço associado a cada tarefa
◼ Atribuição de pessoas e outros recursos para a 
realização e tarefas específicas.
24
Estabelecimento de uma linha básica 
(baseline)
Linha básica: dados compilado de projetos passados de 
 desenvolvimento de software.
Linha básica de métricas: benefícios em nível estratégico, 
 técnico e de projeto.
Diretrizes para a coleta de dados históricos:
◼ Devem ser precisos (evitar chutes)
◼ Devem ser obtidos do maior número de projetos possível
◼ As medições devem ser consistentes
◼ As aplicações devem ser idênticas ao trabalho que será 
estimado
APF
Análise de Pontos de Função
Análise de Sistema
Análise de Pontos de Função
Análise de Pontos de Função
◼ A Análise de Pontos de Função (APF) é um método 
padronizado para medição de sistemas, o qual visa 
estabelecer uma medida de tamanho do software. 
◼ Utilizada por instituições públicas e privadas para:
◼ Estimar o custo e recursos requeridos para o desenvolvimento, 
melhoria e manutenção do software
◼ Estabelecer um fator de normalização para a comparação de softwares
Análise de Pontos de Função
Visão Geral
◼ Independência de tecnologia;
◼ unidade de medida padrão para software;
◼ técnica de estimativa de software;
◼ ser simples;
◼ se consistente e intercambiável;
◼ ser compreensível por não-técnicos;
◼ utilizável desde o início do sistema.
Processo de Medição
1. Reunir a 
documentação 
disponível
2. 
Determinar
Escopo e a
Fronteira da 
Contagem 
3. Medir
Funções
de Dados
4.Medir
Funções
de Transação
5. Calcular 
tamanho 
funcional
6.
Documentar 
Desenvolvimento
Manutenção
Aplicação
ALI (Arquivo Lógico Interno)
AIE (Arquivo de Interface 
Externa)
EE (Entrada Externa)
SE (Saída Externa)
CE (Consulta Externa)
Distribuição de Esforço e 
Tempo
◼ Projeto de tamanho médio:
◼ Concepção: 5%
◼ Elaboração: 20%
◼ Construção: 65%
◼ Transição: 10%
◼ Projeto mais complexo:
◼ Concepção: 8%
◼ Elaboração: 24%
◼ Construção: 60%
◼ Transição: 8%
Estimativas 
O que fazer agora?
◼ Pouco frustrante para empresas recém-criadas
◼ Comparar com projetos anteriores, planejar e 
estimar melhor o novo desenvolvimento
◼ Obtendo o número de Pontos de Função pode-se 
estimar o esforçode projeto por fases de 
desenvolvimento
Estimativas 
Vai que não racha Software
◼ Imaginemos um projeto no qual obtemos um total 
de 100 PF
◼ Numa fase que utilize 20% do Projeto
◼ Numa equipe de 4 pessoas
◼ Considerando uma produtividade média de 
20hs/PF
◼ Considerando uma jornada de 6 horas diárias
◼ Considerando um valor de R$35,00 o valor de 1 
Hora de Trabalho
Estimativas 
◼ 20% de 100 PF = 20 PF
◼ Esforço - 20hs/PF então: 20hs/PF x 20PF 
= 400h
◼ Prazo - 400h/ (4 pessoas x 6 h/dia) = 16,7 
Dias
◼ Custo - 400h x R$ 35,00 = R$ 14.000,00
Planning Poker
Estimativas de tempo usando 
Planning Poker
Técnica Planning Poker
Técnica Planning Poker 
materiais
As cerimonias do Scrum
Estimation Meeting*
Sprint Planning
• Sprint Planning 1
• Sprint Planning 2
Daily Scrum
Sprint Review
Sprint Retrospective
Reunião de Estimativa:
• Preparação para o Sprint Planning.
• Estimar baseado no tamanho, 
nunca em tempo.
• Atualizar Product Backlog com as 
estimativas.
• Importante para o PO criar o 
release plan.
Artefatos
O Product Backlog
Emergente
Priorizado e estimado
Maior prioridade, mais detalhes
Qualquer um pode contribuir
Priorização é tarefa do PO
Sempre visível
Alinhado ao plano de negócios
O Product Backlog é uma lista de todas 
as funcionalidades desejadas no produto, 
estimadas pelo time e priorizadas pelo
Product Owner.
Estórias
Estórias
◼ Trazem Valor para o cliente
◼ Testáveis
◼ Independentes
◼ Negociáveis
◼ Pequenas
Exemplo de Product Backlog
Planning Poker
◼ Técnica para realizar estimativas de 
esforço de tarefas por meio do consenso 
entre o time.
◼ A estimativa de uma história de usuário com 
pontos de história pode ser feita através da 
dinâmica chamada de Planning Poker.
◼ A escala (1, 2, 3, 5, 8, 13, 20, 40, 100), 
usada para definir os pontos de história é 
inspirada na sequência de Fibonnacci.
Para estimar
Técnicas:
◼Opinião de um especialista
◼ Rápido, mas raramente em times ágeis possuem 
especialistas. 
◼Analogia
◼ Valores relativos, comparação com algo já construído.
◼ Desagregação
◼ Dividir para conquistar. Dividir Estórias maiores em 
menores.
Para estimar
Alternativa:
 Planning Poker: Técnica (método) de atribuição de 
estimativas colaborativo
◼Os estimadores justificam suas estimativas
◼Considera uma média das estimativas 
◼Estimativas são feitas pelo TIME
Para estimar - Processo
Planning Poker
Método foi descrito inicialmente por James Grenning em 2002 e 
depois popularizado por Mike Cohn no seu livro Agile Estimating 
and Planning, essa técnica é muito conhecido em XP e SCRUM.
http://blog.mountaingoatsoftware.com/?p=13
http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415
http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415
Planning Poker
Se preparando para jogar....
Participantes: todos do TIME (programadores, analistas, 
designers etc.. ) e o Product Owner!
Planning Poker
Se preparando para jogar....
• Defina a medida que será utilizada: Pontos de Estória!!
• Identifique o que será estimado: História de usuários
• Descrever as “Histórias” em cartões
Como estimar com 
dimensionamento relativo
Planning Poker
Se preparando para jogar....
• Definir escala
• Sequência de Fibonacci: 
1,2,3,5,8,13,21,34,55,89,…refletem o 
aumento da incerteza relacionados a 
maiores unidades de trabalho. 
•Fica mais fácil você ter uma noção de 
separação de complexidade.
Planning Poker – Cartas especiais
• Pode se usar uma Ampulheta
• Um conjunto de cartas para cada participante com a 
escala definida e as cartas especiais:
Carta 0: a tarefa não precisa ser feita por algum 
motivo (talvez já esteja pronta).
Carta Interrogação (?): não entendi a tarefa sr. 
Scrum Master, pode lê-la de novo e dar mais 
detalhes?
Carta Café: estou cansado de tanto estimar, que tal 
tomarmos um café e depois voltamos?
Carta Infinito (quando houver, caso contrário, 
use a 100): não temos como fazer esta tarefa sr. 
Scrum Master, ela é longa demais. Sugiro 
quebrarmos ela em tarefas menores.
Planning Poker
◼ 1,2,3 → História fácil de desenvolver
◼ 5 → Média
◼ 8, 13 → difícil
◼ 20, 40, 100 → Devolver para o PO (Épico)
Planning Poker - Cartas
•Carta 1: a tarefa é muito, mas muito simples, 
provavelmente menos de 1h de desenvolvimento de 
qualquer da equipe
•Carta 2: a tarefa é simples, provavelmente leve menos 
de um turno de trabalho, como uma manhã por 
exemplo.
•Carta 3: a tarefa é simples, mas trabalhosa e não deve 
ser subestimada ocupando pelo menos um turno de 
trabalho, como uma tarde (geralmente é mais longa 
que uma manhã)..
Planning Poker - Cartas
•Carta 5: a tarefa é de complexidade mediana, 
provavelmente tomando um dia de trabalho de um 
desenvolvedor, se não tiver impedimentos
•Carta 8: a tarefa é complexa, vai demandar algum 
estudo ou muito desenvolvimento, provavelmente 
tomando alguns dias da semana, com 2 ou 3 no 
máximo.
•Carta 13: a tarefa é muito complexa, vai demandar 
estudo moderado ou é apenas muito longa de 
desenvolver, levando em média uma semana de um 
desenvolvedor (5 dias úteis)
Planning Poker - Cartas
•Carta 20 em diante: a tarefa é complexa demais e não 
vale a pena ser estimada. 
•Sugere-se quebrar a tarefa em tarefas menores, que 
possam ser estimadas com mais exatidão
Planning Poker – Regras do 
jogo
• Estórias são apresentadas pelo Product Owner.
• Inicialmente, o time identifica o item de backlog 
mais simples (para este item é atribuído o valor 1) 
que passa a ser o item de referência na estimativa 
dos demais.
Fonte: Dennis Williams Alves da Silveira. Ferramenta para apoio à estimativa baseada em
Planning Poker utilizando a metodologia Scrum
Planning Poker – Regras do 
jogo
•Após uma breve discussão, o participante escolhe de suas 
cartas qual deve representar sua estimativa - para quanto 
trabalho envolve aquela estória em relação a referência pré-
definida.
• Todos devem apresentar sua estimativa em um mesmo 
momento.
Fonte: Dennis Williams Alves da Silveira. Ferramenta para apoio à estimativa baseada em
Planning Poker utilizando a metodologia Scrum
Planning Poker – regras do 
jogo
. Após apresentação das cartas, novas discussões iniciam.
• O product owner deve esclarecer quaisquer dúvidas que 
surjam quanto a estória ou requisito apresentado para 
estimativa.
• Caso haja muitas divergências, o maior e o menor estimador 
devem apresentar as suas premissas.
• Novas rodadas de estimativas devem ocorrer até que exista 
um consenso. 
•Normalmente três rodadas são suficiente para um consenso.
Planning Poker – regras do 
jogo
Planning Poker em ação
Cenário para uma estimativa 
de esforço
Planning Poker em ação
◼Cenário em que já forma 
definidas quais tarefas deverão 
ser executadas primeiro e agora 
a equipe esta reunida para 
estimar o esforço para 
desenvolvimento.
Planning Poker em ação
◼Todos (menos o ScrumMaster e 
o P.O.) receberão seus 
respectivos baralhos, cada um 
com os números 0, 0.5, 1, 2, 3, 
5, 8, 13, 21 e os símbolos de 
interrogação, infinito e xícara de 
café.
Planning Poker em ação
◼O ScrumMaster pede 
então que o Product 
Owner leia a primeira 
estória de usuário, 
conforme segue:
Planning Poker em ação
◼“Como usuário, quero acessar 
o site através do celular e 
usar todos os recursos, assim 
como no navegador do 
desktop”. 
Planning Poker em ação
◼O ScrumMaster pede que todos 
os participantes pensem um 
pouco sobre o esforço para 
desenvolver aquela estória e, em 
seguida, que todos mostrem 
suas cartas.
Planning Poker em ação
◼ O resultado da jogada é o seguinte:
Planning Poker em ação
◼ Fica claro que Alan (21) e Carlos (3) 
fazem jogadas extremas. 
◼ Nesta situação o ScrumMaster 
pergunta a ambos o motivo de suas 
escolhas, eles respondem:
Planning Poker em ação
◼ Alan responde:
◼ Teríamos que fazer um outro site para o 
ambiente mobile, um novo HTML,CSS, JS e 
integrar uma nova rotina à existente hoje. 
◼ É necessário um grande esforço no design e 
na programação para que o site se torne 
mobile. 
◼ Temos que considerar os plugins utilizados 
hoje e encontrar similares no mercado para 
customização.
Planning Poker em ação
◼ Carlos responde:
◼ Na verdade, poderíamos utilizar a estrutura já 
existente hoje e apenas ajustar o CSS e 
alguns elementos HTML, assim manteríamos 
tudo junto e o esforço para manutenção seria 
menor. 
◼ Devemos levar em consideração que o 
usuário deseja ter os mesmos recursos, ou 
seja, seria uma replica. O site possui muitas 
páginas dinâmicas e isso faz com que o 
ajuste em uma, replique em várias.
Planning Poker em ação
◼ Acontece então uma breve discussão e 
uma nova rodada é realizada. 
Planning Poker em ação
◼ O resultado é o seguinte:
Planning Poker em ação
◼ Agora os valores estão mais uniformes, com 
esse cenário você pode assumir algumas 
opções:
◼ Continuar a incentivar a discussão até que 
um consenso geral entre os membros seja 
obtido;
◼ Fazer uma média dos valores, levando em 
consideração a proximidade entre eles;
◼ Como os valores estão próximos, assumir o 
maior valor.
Planning Poker em ação
◼ Neste caso optou-se por escolher o maior 
valor, sendo assim, o número de pontos para 
essa tarefa (Story Points) seria de 8. 
◼ Esse ciclo de jogadas é repetido em cada 
tarefa do sprint backlog (pode ocorrer 
também no product backlog) até que todas 
sejam concluídas. 
◼ Com o tempo consegue-se definir quantos 
Story Points uma equipe consegue assumir 
em cada sprint, ajustando-se as estimativas 
durante o projeto.
Planning Poker
Ao fazer o planning poker, estamos discutindo 
requisitos funcionais e não funcionais, que 
visam a realização de um desejo do cliente, e 
geralmente, durate o planning poker está o 
Product Owner, para tirar todas as dúvidas em 
relação ao negócio e verificar se está sendo 
feito o que foi acordado.
Planning Poker
• Prática... Simulação do jogo com o estudo de caso 
“HealthWatcher”.
ID Descrição da Estória
1
Eu como Cidadão posso consultar uma guia 
de Saúde e obter quais especialidades de 
uma unidade de saúde.
2 Eu como Funcionário posso logar no sistema.
3
Eu como Funcionário posso cadastrar novo 
funcionário.
...
Planning Poker
Site idealizado por Mike Cohn, e propõe uma 
ferramenta para que time distribuídos façam a 
estimativa em conjunto:
"http://www.planningpoker.com/“
http://www.planningpoker.com/
Estimando tempo
A estimativa do esforço necessária para desenvolver o projeto é 
derivada a partir do tamanho estimado em Story Points 
considerando-se a capacidade ou VELOCIDADE de produção 
do time. 
 Definir a VELOCIDADE!!!
 Medida de trabalho feito
 Não precisa ser estimada
 Baseado no histórico
 Após realizar 1 iteração
Estimando tempo
VELOCIDADE
Estimando tempo
VELOCIDADE
Para ganhar os pontos designados para uma Estória, a 
equipe deverá concluir todas as tarefas para essa Estória 
dentro da iteração. 
• O número médio de pontos de Estória por iteração é 33.
• A velocidade atual da equipe é 35 pontos de Estória.
• A média das três iterações mais lentas é 30 pontos de 
Estória.
Vantagens do Planejamento 
Ágil / Estimativas Ágeis
• Replanejamentos acontecem constantemente
• As prioridades são atualizadas constantemente
• Estimativas podem ser refinadas
• Estimativas de tamanho e duração são separadas
• Planos são feitos em vários níveis
• Planos são feitos baseados em funcionalidades, não em 
tarefas
• Assumimos a incerteza e nos preparamos para ela
◼ Manual de Práticas de Contagem de Pontos de Função. 
International Function Point Users Group (IFPUG), 2010.
◼ SOMMERVILLE, Ian. Engenharia de Software, 2011. 9ª Edição. 
Makron Books.
◼ VAZQUEZ, Carlos; SIMÕES, Guilherme; ALBERT, Renato. Análise de 
Pontos de Função: Medição, Estimativas e Gerenciamento de 
Projetos de Software. 13ª ed, Editora Érica, 2013.
◼ IFPUG - International Function Point Users Group (www.ifpug.org)
◼ BFPUG – Brazilian Function Point Users Group (www.bfpug.com.br).
Referências Bibliográficas
http://www.ifpug.org/
http://www.bfpug.com.br/
	Slide 1: Qualidade de Software O conceito de métrica de software
	Slide 2: O que são Métricas de Software?
	Slide 3: O que são Métricas de Software?
	Slide 4: O que são Métricas de Software?
	Slide 5: Por que Medir Software?
	Slide 6: Motivação
	Slide 7: Motivação
	Slide 8: Motivação
	Slide 9
	Slide 10: Propriedades Desejáveis de uma Métrica
	Slide 11: Uma métrica deve ser:
	Slide 12: Categorização de Métricas
	Slide 13: Categorização de Métricas
	Slide 14: Categorização de Métricas
	Slide 15: O Processo de gerência de projetos
	Slide 16
	Slide 17: Projetos de software
	Slide 18: Mas por que?
	Slide 19: Mas por que?
	Slide 20
	Slide 21
	Slide 22
	Slide 23: Determinação de Prazos
	Slide 24: Estabelecimento de uma linha básica (baseline)
	Slide 25: APF Análise de Pontos de Função Análise de Sistema
	Slide 26: Análise de Pontos de Função
	Slide 27: Análise de Pontos de Função
	Slide 28: Análise de Pontos de Função
	Slide 29: Visão Geral
	Slide 30: Processo de Medição
	Slide 31: Distribuição de Esforço e Tempo
	Slide 32: Estimativas 
	Slide 33: Estimativas 
	Slide 34: Estimativas 
	Slide 35: Planning Poker
	Slide 36: Estimativas de tempo usando Planning Poker
	Slide 37: Técnica Planning Poker
	Slide 38: Técnica Planning Poker materiais
	Slide 39: As cerimonias do Scrum
	Slide 40
	Slide 41
	Slide 42
	Slide 43
	Slide 44
	Slide 45
	Slide 46: Estórias
	Slide 47
	Slide 48: Planning Poker
	Slide 49: Para estimar
	Slide 50: Para estimar
	Slide 51: Para estimar - Processo
	Slide 52: Planning Poker
	Slide 53: Planning Poker
	Slide 54: Planning Poker
	Slide 55: Como estimar com dimensionamento relativo
	Slide 56: Planning Poker
	Slide 57: Planning Poker – Cartas especiais
	Slide 58: Planning Poker
	Slide 59: Planning Poker - Cartas
	Slide 60: Planning Poker - Cartas
	Slide 61: Planning Poker - Cartas
	Slide 62: Planning Poker – Regras do jogo
	Slide 63: Planning Poker – Regras do jogo
	Slide 64: Planning Poker – regras do jogo
	Slide 65: Planning Poker – regras do jogo
	Slide 66: Planning Poker em ação
	Slide 67: Cenário para uma estimativa de esforço
	Slide 68: Planning Poker em ação
	Slide 69: Planning Poker em ação
	Slide 70: Planning Poker em ação
	Slide 71: Planning Poker em ação
	Slide 72: Planning Poker em ação
	Slide 73: Planning Poker em ação
	Slide 74: Planning Poker em ação
	Slide 75: Planning Poker em ação
	Slide 76: Planning Poker em ação
	Slide 77: Planning Poker em ação
	Slide 78: Planning Poker em ação
	Slide 79: Planning Poker em ação
	Slide 80: Planning Poker em ação
	Slide 81: Planning Poker
	Slide 82: Planning Poker
	Slide 83: Planning Poker
	Slide 84: Estimando tempo
	Slide 85: Estimando tempo
	Slide 86: Estimando tempo
	Slide 87: Vantagens do Planejamento Ágil / Estimativas Ágeis
	Slide 88: Referências Bibliográficas