Qual é a melhor explicação sobre o que são os Story Points?


36

Estamos começando a usar os Story Points aqui para o nosso desenvolvimento Agile, mas acho difícil explicar e também não consigo encontrar uma resposta definitiva para o que são. A melhor coisa que posso fazer é apontar para outros sites (como http://blog.mountaingoatsoftware.com/tag/story-points ) e fornecer uma vaga generalização do que eles são. Estou procurando uma boa explicação com alguns exemplos de uso que seriam úteis para outras pessoas. Existem bons recursos para explicar os pontos da história?


1
Explicação para quem ou você está querendo uma explicação geral? O problema com o último é que ele pode ser encarado com alguma surpresa, pois nem todo mundo quer ter uma resposta detalhada.
perfil completo de JB King

Um link para uma resposta detalhada seria suficiente. Fui solicitado por gerentes, membros de produtos, líderes de equipe e programadores. É um novo conceito para a maioria deles (eu também).
six8

Respostas:


36

Isso pode ajudar como iniciante: Mike Cohn nos pontos da história . Mas este é muito melhor: equipes de desenvolvimento ágil: escopo e escala com Mike Cohn

A solução de Mike para as métricas de estimativa de software é simples e eficaz. Fatos biológicos:

  • O cérebro humano é incapaz de estimar corretamente no tempo. Especialmente se mais de algumas horas.
  • Isso é bastante amplificado pela quantidade de incertezas no desenvolvedor de software, pelas pressões psicológicas da gerência (quando você estima, se compromete ...) e pela diferença de habilidades na equipe.
  • No entanto, somos muito bons em comparar coisas. Nós somos bastante precisos lá.

A idéia é pegar uma história de usuário de referência e atribuir a ela um número arbitrário de pontos (história) ; outras histórias obterão pontos relacionados a essa referência.

Se a sua história de referência for 100 pontos e outra for três vezes maior, serão 300 pontos.

Para converter os pontos da história em tempo para o seu planejamento, você precisa conhecer sua velocidade .

Para obter uma velocidade precisa, você deve fazer poucas iterações e calcular quantos pontos sua equipe completou em um determinado período de tempo.

Isso funciona .


5
+1 melhor explicação. Mas fazer a história de referência 100 não é uma boa ideia. pois implica que você pode estimar com precisão em relação à referência. ou seja, minha próxima tarefa é 42% do trabalho da referência. Como você mencionou, o cérebro humano é horrível em estimar. Portanto, temos uma história de referência de 2 pontos. Em seguida, use a sequência de Fibonacci (quanto mais longe da história de referência, mais imprecisão você tem, por isso não faz sentido ser exato). O Planning Poker é seu amigo.
Martin York

1
Se você não quer assistir, Mike Cohn no Youtube, ele também tem um artigo de blog muito bom sobre esse assunto: blog.mountaingoatsoftware.com/tag/story-points . Parte interessante é que, mesmo com o sistema de pontos, ele disse que os humanos só são bons até cerca de 8 anos, então eles começam a subestimar.
DXM

Votei positivamente nesta resposta e ela continha informações muito valiosas. No entanto, tecnicamente, a pergunta era perguntar mais sobre o que define especificamente um ponto da história, em vez de como usá-los efetivamente.
Panzercrisis 26/09

5

Concordo com tudo o que o @Pierre 303 disse acima: (além do ponto de referência 100).

A única coisa que gostaria de acrescentar (ênfase) é que não somos bons em estimar tarefas. Podemos estimar tarefas em relação a outras tarefas, desde que tenham aproximadamente o mesmo tamanho. Quanto maior a diferença entre as tarefas, pior fica.

Portanto, não concordo em usar um ponto de partida de 100.

Não é como se você estimasse a próxima tarefa como 42% da tarefa de referência. É a mesma metade do trabalho, o dobro do trabalho, o triplo do trabalho, etc.

Nossa equipe usa o Planing Poker : nisso, temos uma tarefa de referência de 2 pontos na história. Em seguida, usamos a série Fibonacci para estimar tarefas: 1,2,3,5,8,13,21, Enorme ,? em relação à tarefa de referência (em vez de Fibonacci, vi outras equipes usarem poderes de 2. 1,2,4,8,16,32, Enorme ,?) Já vi outras equipes usarem (pequena (1), média ( 2), grande (3), XLarge (4) quando calcularam a velocidade ainda funcionava.).

O ponto é que, à medida que o tamanho da tarefa aumenta em relação à tarefa de referência, nos tornamos menos capazes de estimar com precisão seu custo. Portanto, não faz sentido tentar. Isso é refletido pelo gradiente maior no final da trilha de estimativa.

Portanto, se sua tarefa de referência for 2SP. Fazer uma estimativa de 1/2/3/5 é relativamente fácil, pois as tarefas são de tamanho semelhante. Depois que você ultrapassa o triplo do tamanho da tarefa de referência (5SP), a estimativa se torna mais difícil (8/9 / 10SP importa) Tudo o que você pode dizer é maior que 5SP e menor que 13SP e, em seguida, 8SP se encaixa na conta.

Qualquer coisa com um valor de SP de 13/21 / Huge é muito grande para o backlog do sprint. Essas são estimativas para as coisas nas quais você ainda não está pronto para trabalhar (e, portanto, não foram divididas em tarefas menores (não as divida até que você também precise)). Mas eles fornecem uma estimativa do tamanho de uma tarefa no backlog do produto (o que permite um planejamento futuro). Quando você chegar ao ponto em que irá trabalhar neles, deverá ter conhecimento suficiente para dividi-las em tarefas menores para a lista de pendências do sprint e reestimá-las individualmente (Observação: é um equívoco comum que a soma de as partes são iguais ao original).

  • Tudo o que você estima como Enorme precisa ser dividido em tarefas menores.
  • Algo que é estimado como? significa que não está suficientemente definido para estimar.
    Você precisa adicionar uma tarefa especificamente para defini-la
    (por exemplo, escreva alguma documentação ou apresentação).

2

Os pontos da história são uma medida relativa de quão difícil é uma tarefa. Isso ocorre porque os humanos são realmente melhores em estimativas relativas do que medições precisas.

A maneira como você usa os story points é executar duas tarefas no projeto e atribuir a eles dois valores diferentes de story story. Em seguida, você estima as outras tarefas usando essas duas aproximações de pontos da história como base para sua estimativa. Ou seja, a Tarefa C não é muito mais difícil que a Tarefa A, mas é incrivelmente mais fácil que a Tarefa B, por isso é apenas cerca de 2 pontos na história mais trabalho que a Tarefa A.

Quando você terminar de estimar todos os requisitos que você tem até agora, você estima quantos poderá realizar em um sprint. Durante os próximos sprints, você estima quantos completou. Os pontos de história de um requisito só são contados como concluídos se o requisito for cumprido. Não há "80% concluído" no Scrum. Isso ocorre porque os humanos são realmente ruins em estimar a integridade. Após alguns sprints, você deve ter uma idéia de quantos pontos da história você pode fazer por sprint.

Como você estima? Você pode usar o planejamento de pôquer para determinar quanto trabalho seus desenvolvedores acham que um requisito exigirá em relação aos requisitos básicos.

Eu também recomendaria a leitura do The Agile Samurai . Faz um bom trabalho explicando esses e outros conceitos ágeis na minha opinião.

Aqui está um link com mais sobre os pontos da história.

Aqui está outro link.


2

Eles são uma perda de tempo.

insira a descrição da imagem aqui

http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

Interessante que essa opinião agora venha do cara que escreveu Scrum e XP da Trenches e cujo nome da empresa ( Crisp ) pode ser encontrado em tantos decks de planejamento de cartas de pôquer usadas por tantas equipes ao redor do mundo.

A última frase do OP: "Existem bons recursos para explicar os pontos da história?" Sim, este livro é um bom recurso. Alimento para o pensamento.


Dar uma opinião sobre se são úteis ou não, não responde à pergunta sobre o que são.
Bryan Oakley

0

A explicação mais fácil que posso encontrar é usar um objeto tangível e que possa fornecer um exemplo concreto.

Pegue uma casa móvel. Se eu estivesse no negócio de casa móvel, saberia que a construção de uma única largura normalmente leva 5 (pontos, sapos, widgets ... a forma de medição é arbitrária) e, portanto, a construção de uma largura dupla deve levar o dobro do esforço ou 10 (pontos , sapos, widgets).

A mentalidade dos programadores, neste momento, entra em cena e fala sobre uma abordagem simplificada; não leva o dobro do tempo devido à infra-estrutura que consome a maior parte do tempo e a outros exemplos semelhantes. Isso é inevitável. Adote o fato de que essa é uma estimativa em (pontos, sapos, widgets), pois NUNCA podemos estimar com precisão no tempo e, portanto, estimar em (pontos, sapos, widgets) remove a crença de que podemos.

Para saber quanto tempo levará para construir, usaremos nossas tendências ao longo do tempo; assim, com o tempo, cada vez mais, as nossas estimativas são mais precisas.

Não se esqueça de planejar o pôquer quando o time estiver pronto para ir.


0

Como outros já mencionaram, os pontos da história são uma medida relativa da complexidade de uma história do usuário. O verdadeiro benefício dos pontos da história é percebido quando

  1. Os pontos são medidos pela unidade responsável pela implementação (um indivíduo ou a equipe).
  2. As métricas são mantidas para quantos pontos agregados são concluídos pela mesma unidade dentro de uma duração constante (velocidade).

Após algumas iterações de medição em pontos da história e velocidade de rastreamento, você deve ser capaz de estimar com precisão quantos pontos da história podem caber em um determinado período de tempo (iteração ou sprint se estiver usando o scrum). Observe que aplicar essa técnica a um grupo e tentar usar essas métricas para uma equipe diferente não funcionará bem. Ou seja, se a equipe a pode completar 120 pontos de história em uma corrida de duas semanas, esperar que a equipe b tenha os mesmos resultados é irreal.

Como outra pessoa mencionou, planejar o poker é uma grande ajuda ao usar esse método, pois ajudará a identificar histórias que precisam de aprimoramento (se houver discrepância entre os votos, isso significa que há incerteza nos requisitos).


1
"Como outros já mencionaram, os pontos da história são uma medida relativa da complexidade de uma história do usuário". Observe que Mike Cohn realmente argumenta que "É esforço, não complexidade"; consulte mountaingoatsoftware.com/blog/its-effort-not-complexity para obter uma discussão detalhada sobre esse tópico.
datentyp
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.