INSTITUTO FEDERAL DO TRIÂNGULO MINEIRO

Campus Avançado Uberaba Parque Tecnológico – IFTM

Engenharia da Computação

Engenharia de Software

Relatório apresentado ao Instituto Federal do Triângulo

Mineiro – Campus Avançado Uberaba Parque
Tecnológico, como requisito avaliativo da disciplina
Engenharia de Software. Profª. Mauro Borges

Discente: Lucas Ferreira Nunes

UBERABA - MG
Abril/2020
 INSTITUTO FEDERAL DO TRIÂNGULO MINEIRO
Campus Avançado Uberaba Parque Tecnológico – IFTM
Engenharia da Computação

Atividade Avaliativa – Pesquisa e elaboração de um trabalho

explicando os seguintes itens: Story Point, Gráficos BurnDown e
Poker Planning. – 30/04/2020

Relatório apresentado ao Instituto Federal do Triângulo

Mineiro – Campus Avançado Uberaba Parque
Tecnológico, como requisito avaliativo da disciplina.
Engenharia de Software. Profª. Mauro Borges.

UBERABA - MG
Abril/2020
 3

Sumário

1.DESENVOLVIMENTO ......................................................................................4
1.1) StoryPoint........................................................................................................4
1.2) Gráficos BurnDown ..............................................................................................5
1.3) Poker Planning .................................... ...................................................................6

2.REFERÊNCIAS .....................................................................................................7
 4

1.DESENVOLVIMENTO

1.1) Story Point

Story Points é um método de estimativa ágil que ajuda o time a visualizar

quando uma história estará terminada. Cada time define o tamanho do seu
story point. Uma das formas é considerar que um story point é um dia ideal de
trabalho, isto é, um dia sem interrupções como reuniões, e-mails ou ligações
telefônicas. Um Story Point é uma estimativa relativa de ―tamanho‖ da
atividade comparada com outra atividade no projeto. Portanto, espera-se que
uma história de 10 pontos demore o dobro do tempo que uma história de 5
pontos
 5

1.2) Gráficos BurnDown

Um Gráficos BurnDown mostra o montante de trabalho restante através do tempo.

Uma maneira de visualizar o montante de trabalho restante em qualquer ponto do
tempo e o progresso do time em reduzir esse montante. Mostra a tendência do
trabalho realizado, com a fonte de dados crus sendo o SprintBacklog e o Product
Backlog.

O trabalho restante é visto no eixo horizontal e os períodos de tempo (dias de um

Sprint ou Sprints) são visto no eixo vertical. A intersecção de uma linha de
tendência do trabalho restante e o eixo horizontal mostra o quanto do trabalho
estará completo naquele ponto do tempo(COHN, 2002) . Um Gráficos BurnDown
nada mais é que um diagrama tradicional de Gantt com os eixos invertidos.
Portanto, como em um diagrama de Gantt, serve para ilustrar os avanços das
etapas de um projeto. A diferença é que no Gráficos BurnDown não visualizamos
cada tarefa de cada membro da equipe, como em Gantt, mas o todo do trabalho
realizado pela equipe no espeço de tempo de uma iteração.

O Gráficos BurnDown é a colisão da realidade (trabalho feito e velocidade com que

está sendo feito) com o que foi planejado.

Figura: Exemplo de Gráficos BurnDown

Pode-se criar um artefato correlato, o Gráficos burnup, que tem a mesma

função, mas mostra linhas ―subindo‖, somente trocando os eixos. A confecção
de burndown ou burnup, por terem o mesmo papel, fica pela preferência e
adaptação de cada equipe. O Gráficos burnup mantém a estrutura tradicional
de eixos dos diagramas de Gantt. Podem também ser usados dois gráficos, um
para o Sprint corrente e outro para o projeto como um todo.
 6

1.3) Poker Planning

Planning Poker (poker de planejamento) é uma abordagem para estimativa

ágil. Para iniciar uma sessão de estimativa, o Product Owner ou o cliente lê uma
User Story ou descreve um recurso para os estimadores, que deve incluir todos na
equipe. Cada estimador está segurando um baralho de cartas com valores. Os
mais comumente utilizados são os primeiros números da sequência de Fibonacci
(0, 1, 2, 3, 5, 8, 13, 20, 40 e 100), porém, podem ser utilizados outros valores que
expressem a mesma ideia. Os valores representam o número de Story Points, dia
ideal, ou outra unidade de estimativa que faça sentido para o time.
Os estimadores discutem a função, fazendo perguntas para o Product Owner,
conforme necessário. Quando o recurso tiver sido amplamente debatido, cada
estimador seleciona uma carta para representar a sua estimativa, sem mostrá-la
aos demais. Todos os cartões são, então, revelados ao mesmo tempo. Se todos
os estimadores houverem selecionado o mesmo valor, ele se torna a estimativa.
Se não, os estimadores discutem as suas estimativas. As estimativas mais alta e
baixa deve principalmente partilhar as suas razões. Após um debate, cada
estimador seleciona novamente um cartão de estimativa e todas as cartas são
novamente reveladas são mesmo tempo.
O processo é repetido até que o consenso é alcançado ou até que os estimadores
decidirem que a estimativa de um determinado item deve ser adiada até que
informações adicionais possam ser adquiridas. um determinado item deve ser
adiado até que informações adicionais possam ser adquiridas.
 7

2.REFERÊNCIAS

• <https://www.lume.ufrgs.br/handle/10183/31028>

• <ANDREA RAYMUNDO BALLEAnálise de Metodologias Ágeis: Conceitos, Aplicações e

Relatos sobre XP e Scrum>