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?
agile
estimation
planning
six8
fonte
fonte
Respostas:
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:
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 .
fonte
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).
Você precisa adicionar uma tarefa especificamente para defini-la
(por exemplo, escreva alguma documentação ou apresentação).
fonte
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.
fonte
Eles são uma perda de tempo.
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.
fonte
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.
fonte
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
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).
fonte