ti-enxame.com

Por que usamos pontos de história em vez de dias de trabalho ao estimar histórias de usuários?

Nas metodologias ágeis (por exemplo, SCRUM), a complexidade/esforço necessário para histórias de usuários é medida em pontos de História. Os pontos de história são usados ​​para calcular quantas histórias de usuário uma equipe pode obter em uma iteração.

Qual é a vantagem de introduzir um conceito abstrato (story points), onde podemos apenas usar uma medida concreta, como o número estimado de homens-dia? Também podemos calcular a velocidade, estimar a cobertura de uma iteração etc. usando homens-dia estimados.

Por outro lado, os pontos da história são mais difíceis de usar (porque o conceito é abstrato) e também mais difíceis de explicar às partes interessadas. Que vantagem isso oferece?

141
Louis Rhys

Eu acho que uma das principais vantagens é que humanos e desenvolvedores são realmente muito ruins em estimar o tempo. Pense também na natureza do desenvolvimento - não é uma progressão linear do início ao fim. Geralmente é "escrever 90% do código em 10 minutos e depois arrancar o cabelo por 17 horas". Isso é muito difícil de estimar no sentido do tempo do relógio.

Porém, o uso de uma abstração retira o foco do tempo real em horas ou dias e, em vez disso, coloca o foco na descrição da despesa relativa e da complexidade de uma tarefa em comparação com outras tarefas. Humanos/desenvolvedores são melhores nisso. E então, quando você começar a cantarolar com essas estimativas pontuais e algum progresso real, poderá começar a olhar as horas de maneira mais empírica.

Suspeito que também exista um efeito de observador que ocorre com estimativas de tempo que não aconteceriam com estimativas pontuais. Por exemplo, o incentivo para enviar uma estimativa e entregar de maneira "antecipada" será silenciado com indireção em um sistema baseado em pontos.

130
Erik Dietrich

Se você estiver usando números de Fibonacci (ou algo semelhante), isso limitará o número de opções ao estimar uma história. Trabalhei com um grupo que usava apenas números baixos: 1, 2, 3, 5, 8 e 13. Tínhamos uma história de referência que era 5. Isso nos permitiu tomar decisões rápidas sobre a complexidade de uma história enquanto fazia o Planning Poker . O outro efeito colateral foi que qualquer coisa classificada como 13 provavelmente tinha informações insuficientes e precisava ser mais detalhada. Eu duvido seriamente que teria sido tão fácil e direto se estivéssemos usando horas cruas.

O Dono do produto fala o idioma das partes interessadas e deve ser capaz de traduzir entre pontos da história e horas de trabalho (ou outras unidades), conforme necessário. Durante meu tempo como PO, tive alguns dados concretos que 1 ponto de história = 4 horas-homem, mas obviamente toda equipe é diferente.

Editar:

Com o conhecimento de que 1 ponto = 4 horas, você poderia, teoricamente, mudar seu deck do Planning Poker para 4, 8, 12, 20, 32 e 52. Mas esses números parecem mais difíceis de lidar. Eu acho que abstraia mentalmente os valores de volta a algo simples, por exemplo, "menos de um dia", "mais de uma semana" etc. etc. E se eu for fazer isso, também devo ficar com a unidade abstrata -alguns pontos da história.

60
Michael Kristofik

É para permitir que a estimativa melhore com o tempo, sem que todos os estimadores tenham que ajustar sua estimativa.

Em vez de todos os envolvidos na estimativa terem que pensar como "OK ... parece 2 dias de homem .. mas no último sprint subestimamos tudo, talvez sejam realmente 2,5 dias de homem. Ou 3?", Eles continuam o mesmo de sempre. "5 pontos de história!"

Em seguida, você ajusta sua estimativa de quantos pontos da história a equipe pode passar em um sprint, com base no desempenho real medido nos sprints anteriores. "Nós fizemos 90-110 pontos de história por sprint anteriormente!"

Eu diria que a teoria por trás disso é que os desenvolvedores são melhores em estimar a complexidade relativa de diferentes tarefas de desenvolvimento do que em estimar absolutos . Especialmente se várias pessoas estão estimando uma tarefa que poderia ser realizada por qualquer uma delas (e nem todas as pessoas trabalham na mesma velocidade que todas as outras).

Alternativa cínica: Eu já vi isso dizer que os desenvolvedores nunca chegam com estimativas de tempo. Se algo demorar mais do que o estimado, você já passou por isso. Mas se algo leva menos tempo do que o estimado, os desenvolvedores podem mexer com ele, em ouro ou apenas diminuir a velocidade e facilitar o processo, pois dada uma tarefa confortável. Tirar as unidades reais de tempo de uma estimativa pode conter essas tendências. Fim da alternativa cínica.

25
Carson63000

Os dias ou horas de trabalho são como você diz concretos. Portanto, quando uma tarefa é estimada em 5 horas e leva 6, agora é uma tarefa tardia.

Quando você tem uma história de 3 pontos e leva 6 horas, levou 6 horas, não é tarde, levou apenas seis horas. A medição de velocidade é mais um fator do número de pontos que você faz em um sprint, e esse número pode variar, porque não é concreto. Você também não está medindo cada tarefa, mas o total de todas as tarefas. Quando você tem horas em cada tarefa, existe a tentação de medir cada tarefa. Quando isso acontece, você não obtém nenhum benefício para o sprint por terminar no decorrer do tempo e isso é uma conseqüência para terminar ao longo do tempo de uma determinada tarefa.

Pode ser uma transição para o pensamento em termos de pontos. Um lugar em que trabalhei antes de introduzirmos tamanhos de camisetas usadas ágeis apenas para ter uma idéia do nível de esforço. Os pontos são apenas uma extensão disso.

Isso não quer dizer que não haja controvérsia ou alguma atribuição arbitrária aos pontos. Temos membros de nossa equipe que quase sempre votam no número mais baixo e reclamamos quando pensam que uma tarefa é 1 e achamos que é um 3 que estamos sofrendo de inflação pontual.

18
Bill Leeper

A abstração é uma espécie de argumento. Usar o 'dia do homem' como uma medida tem várias armadilhas, incluindo:

  1. Se a equipe não estiver familiarizada com a tecnologia que usará, pode ser muito difícil fornecer estimativas em tempo real de quanto tempo uma tarefa pode levar. É muito mais provável que sejam capazes de fornecer boas estimativas relativas - por exemplo, "a tarefa A provavelmente levará o dobro do tempo da tarefa B".
  2. Pessoas diferentes trabalham a taxas diferentes! Se você usa 'man days', praticamente precisa alterar a estimativa de tempo quando uma tarefa é passada de um desenvolvedor para outro. Quem define quanto trabalho constitui um 'dia do homem', afinal?

Se você deseja estimar homens-dia, é um cálculo simples:

user points in story / average user points per developer per day = estimated man days
14
vaughandroid

Como já mencionado, os pontos da história são uma medida relativa de complexidade. Pode-se usar potência de 2 séries (1,2,4,8,16 ...) ou uma escala de Fibonacci (1,2,3,5,8,13,20 ...) para estimativa. Como desenvolvedores esposos são bastante hábeis em dizer algo como isto:

O recurso A é quase duas vezes mais difícil que o recurso B

Mas é realmente difícil dizer 'quanto tempo' esse recurso levará para a implementação. Você deixa que isso seja equilibrado pela velocidade. Portanto, se algo foi estimado como 5, mas acabou sendo 13, uma velocidade mais lenta normalizaria isso para a iteração (ou você poderia re-estimar).

Agora, há outra alternativa, chamada de 'dias ideais' (alguns semelhantes aos dias de homem, mas não tenho certeza se foi isso que você quis dizer) e conheço algumas equipes que preferem isso. Os dias ideais devem ser interpretados como:

Se isso é tudo o que faço depois de chegar ao cargo e fazer apenas as pausas necessárias, não ter interrupções e ter tudo o que preciso para 'implementar a história', ou seja, nenhuma atividade periférica como reuniões, responder a e-mails etc.,

Mike Cohn, um dos muitos evangelistas ágeis conhecidos, fornece a seguinte comparação entre histórias e dias ideais

pontos da história

  • Ajuda a impulsionar o comportamento multifuncional, ou seja, as equipes estimam histórias com total complexidade de implementação, da interface do usuário ao banco de dados e vice-versa.
  • As estimativas de SP não decaem, ou seja, daqui a alguns meses, uma história de 5 pontos provavelmente ainda será de 5 pontos, mas uma estimativa de dia ideal pode mudar dependendo da habilidade/velocidade de desenvolvimento adquirida desse programador em particular
  • SP são uma medida pura de tamanho, isto é, refletem apenas e apenas o tamanho w.r.t. complexidade. Período. Sem duração, etc, jogou-o. Esse é o trabalho da velocidade. Mas não é assim com os dias ideais. De fato, com dias ideais, há uma tendência a confundi-lo com dias corridos. Mantendo-o abstrato, os SPs lutam contra a tentação de comparar com a realidade. Apenas uma medida de tamanho. Sem bobagem.
  • Geralmente é mais rápido que os dias ideais. Pode ser complicado para o primeiro par de histórias, mas depois que você pega o jeito, é mais rápido.
  • Diferentes desenvolvedores podem ter uma visão diferente da estimativa do dia ideal para concluir uma história. Eu poderia fazer o mesmo em 3 e você em 5. Os SPs são mais ou menos uniformes em todos os aspectos. Eles nivelam o campo de jogo, por assim dizer.

dias ideais

  • Mais fácil de explicar fora da equipe; por razões óbvias :)
  • Mais fácil estimar a princípio, como mencionado acima. Mas quando você pega o jeito dos SPs, ele vem naturalmente

Agora, qual escolher depende da equipe. No entanto, como a maioria das respostas aqui e minha experiência pessoal, prefiro os pontos da história. Os dias ideais não beneficiam muito dos SPs (e Mike Cohn também defende SP junto com muitos outros evangelistas ágeis).

7
PhD

Os pontos da história também ajudam a medir a melhoria de desempenho da equipe ao longo do tempo. Além disso, você não precisa reestimar tudo à medida que o desempenho melhora.

Veja este exemplo que usa dias do homem:

A equipe estima diferentes tarefas em dias-homem. Funciona por um tempo, mas depois de algum tempo você vê que a equipe é executada mais rapidamente com muitas tarefas do que se pensava inicialmente. Então a equipe re-estima as tarefas. Funciona por um tempo e, depois de algum tempo, você vê novamente a mesma coisa: a equipe é executada mais rapidamente com muitas tarefas novamente. Então você re-estima novamente, e esta história se repete novamente, e novamente e novamente ...

Por quê? Porque o desempenho da sua equipe aumentou. Mas você não sabe disso.

O mesmo exemplo com pontos da história:

A equipe estima o tamanho das histórias de usuários. Após alguns sprints, você vê que a equipe pode fazer cerca de 60 pontos de história por sprint. Mais tarde, você verá que a equipe alcançou mais de 60 pontos na história, talvez 70. E a equipe continua assim e extrai mais histórias de usuários para os próximos sprints e os entrega.

Por quê? Porque o desempenho aumentou. E você pode medir. E você não precisa reestimar tudo depois que o desempenho de sua equipe aumentar.

4
Uooo

Primeiro, as pessoas são melhores em estimativas relativas do que em estimativas absolutas. Os babilônios que mapeiam e classificam o brilho relativo das estrelas são um ótimo exemplo. Eles não acertaram os números absolutos, mas a ordem era quase sempre exata, mesmo para intensidades muito semelhantes.

A segunda vantagem é que uma das principais razões para fazer este exercício é impulsionar a conversa. Se você começar a discutir em dias exatos, a conversa poderá rapidamente atrapalhar.

Como Napoleão disse: o plano é inútil, o planejamento é inestimável.

Terceiro, o gerente de projeto não precisa editar todas as estimativas, apenas porque as estimativas foram desativadas por um fator de, por exemplo, 130%.

3
Tormod

dias do homem estimar o tempo que leva para fazer alguma coisa. Eles são mais usados ​​quando os itens que você está estimando são muito precisos e mensuráveis. Tarefas específicas, bem conhecidas e repetíveis são estimadas em dias de trabalho.

Por exemplo, se uma pessoa de vendas pode fazer 20 chamadas de clientes por dia, em média, podemos calcular quanto tempo cada chamada leva e, a partir disso, podemos estimar quantos dias de trabalho serão necessários para fazer 1000 chamadas.

Neste exemplo, pode-se pensar concretamente, em termos estatísticos, sobre a duração média de uma chamada, porque todas as chamadas podem ser consideradas efetivamente a mesma coisa.

pontos da história determina qual combinação de histórias pode ser feita em uma iteração. Eles são usados ​​para combinar objetivos heterogêneos com limites difusos e medir quantos podem ser feitos em um período de tempo fixo. Eles estimam a complexidade dos pedaços de trabalho comparados entre si para poder adicioná-los.

Por exemplo, sua equipe desenvolveu 5 histórias para um total de 23 pontos na iteração 1 e 8 histórias para 20 pontos na iteração 2. A partir disso, você pode estimar que na iteração dois sua equipe fará algumas histórias cujo total é de aproximadamente 20 pontos na iteração 3.

Observe que não precisamos determinar o tamanho de um ponto e, em particular, não há nenhuma suposição de que cada história do mesmo tamanho levará o mesmo tempo para ser desenvolvida! Trabalhamos apenas em somas e pontos por iteração. Eu nem mencionei quanto tempo a iteração é.

0
Sklivvz

Estou surpreso que ninguém tenha mencionado Lei de Parkinson ainda.

O trabalho se expande para preencher o tempo disponível para sua conclusão.

Basicamente, se você estiver estimando em qualquer tipo de unidade de tempo para grandes tarefas, os desenvolvedores tenderão a demorar o tempo estimado para concluí-lo ou repassar. Quando você estima em um tempo nebuloso, como pontos de história ou tamanhos de camisa, evita essa armadilha.

0
Vadim

Os Story Points refletem a complexidade do problema e, portanto, refletem a confiança (ou risco) de quão precisa é a estimativa.

Uma história com um ponto alto da história me diz que há muita coisa acontecendo com a história do usuário que não é concreta.

A idéia é ver o que é um bom equilíbrio entre os vários pontos da história. Se estiver sendo mostrado um plano de iteração com histórias com todos os pontos altos da história, isso me dará pouca confiança de que a iteração será executada conforme o esperado e que precisamos procurar outras histórias para a iteração ou começar a desmembrar as histórias.

Ao se comunicar com um gerente ou Dono do produto, os pontos altos da história significam que será extremamente nebuloso quando eles receberão um recurso específico. Uma das soluções para isso é desmembrar a história, e esperamos que você tenha uma combinação de pontos altos e baixos da história para trabalhar, para que você possa demonstrar iterativamente o progresso para o Dono do Produto.

0
grumpasaurus

Se você for até um humano na rua e perguntar "Qual o tamanho de um T-rex?" as respostas flutuariam mesmo que a maioria dos humanos soubesse o que é um T-rex, quão grande era, mas ninguém realmente sabe ao certo - porque não temos escala relativa para basear.

Esse é o comportamento cognitivo que você está tentando descobrir com a previsão e muitas metodologias geram ciclos com "Eu entendi! .. eu tenho o segredo da previsão precisa! "óleo de cobra para as massas. Quando você realmente faz previsões, está dizendo em voz alta "Permitirei x dias/horas/pontos para que isso seja concluído" - é de certa forma criando uma "caixa de tempo" para que esse evento seja realizado dentro.

Para mim, o Points está apenas mudando os limites, no final do dia, a menos que você esteja em uma equipe feliz em dizer " * Bem, temos 3 semanas por sprint e thumb suck ... eu acho que devemos disparar por 30 pontos para completar esse ciclo! quem está comigo! * "e isso é tão profundo quanto você na modelagem de previsão - tudo bem! ... como realisticamente você está apenas definindo um orçamento arbitrário e é isso. Você também está olhando retrospectivamente para o trabalho concluído com uma sensação de "porcaria sagrada, fizemos 33pts que correram, isso foi bem legal" e não se pode fazer muito sobre isso. Você pode usar a velocidade para determinar no meio do sprint que está ganhando dinheiro pelo seu orçamento, perguntando em voz alta "Já atingimos 15 pontos ainda? Vamos?", Mas depois, você volta a acrescentar tempo relativo a a equação não é você? "mas o perigo aqui é que agora você está usando o Velocity para medir a produtividade, não a capacidade que, pelo que entendi, chuta a cabeça do Gerenciamento de Liberação Reativa (pontos da história) ..

O sistema de pontos é quase inteligente demais para não notar que você ainda atribui tempo relativo à equação, tudo, desde os "ciclos de sprint" acordados até as posições diárias em que você estabelece alguma regra oculta em torno da duração + complexidade = "Max está demorando muito nessa tarefa "inato, sentindo o código da equipe, momento vermelho?

O cérebro humano não pode prever porque envolve muita memória de trabalho misturada com recordações de longo/curto prazo, por isso é como pedir a um estudante de matemática iniciante que faça frações na cabeça e não no papel. É por isso que outras indústrias nunca concordam com uma previsão e validar constantemente as previsões em tempo relativo (por exemplo, o geólogo nunca interrompe a modelagem de previsão até que o metro cúbico tenha sido escavado no chão e depois "pronto").

Eu diria que o sistema de pontos funciona se você não está prevendo . Você está concordando com uma parte do trabalho baseada em um algoritmo de sub-partes, mas essa é realmente a abordagem mais próxima possível da previsão. Na verdade, o gerenciamento de versões procuraria pausas naturais na fila de "lista de pendências" que se encaixam nos temas (ou seja, no Silverlight, os gerentes de produto esperariam até depois de concluir sua lista de pendências e reunir os temas que definimos inicialmente. nunca soubemos o que a equipe de engenharia estava fazendo especificamente, tínhamos apenas um esboço básico.

Quando você começa a bloquear as expectativas de velocidade dentro de ciclos de sprint que dependem de velocidade + tempo, você volta a prever estimativas novamente só que desta vez fica pior porque está jogando o "jogo depende" ... Mais importante, você também está matando o potencial de crescimento da equipe/carreira também.

O imposto que você paga por Pontos versus tempo é com pontos que você precisa procurar por fórmulas de medição alternativas para acompanhar o desenvolvimento/orientação de habilidades no trabalho ou o comportamento do desenvolvedor.

Como você ainda precisará olhar para um "desenvolvedor mediano" como sua pessoa ideal para anexar habilidade/esforço, você pode basear outros desenvolvedores com essa pessoa para determinar como eles estão se saindo no crescimento contínuo de sua equipe. Ele também destaca situações em que os desenvolvedores "rápidos" carregam a maior parte da água, mas ficam entediados ou, pior, trabalham mais horas e não reconhecem/recompensam por causa de prazos competitivos, etc. Os standups não descobrem isso na realidade, são realmente lá para detectar maus cheiros dentro da equipe, por exemplo, como em "essa pessoa está lutando, vamos ajudar"

A seguir, também vêm as histórias de "carry over", histórias que não são agrupadas nesse ciclo de sprint, mas depois se espalham para o próximo ciclo de sprint. O que pode facilmente criar um efeito indireto se você levar em consideração o tempo, mas no momento em que você leva em consideração o tempo relativo ... novamente, você voltou a "previsão/estimativa com base no tempo" e, novamente, o sistema de pontos é apenas enlameando as águas.

Se você vai em pontos, ignora completamente o tempo, e eu quero dizer completamente, no momento em que você deixa o tempo passar, você está jogando a idéia/metodologia.

Tendo viajado ao redor do mundo como evangelista, vi muitas equipes jurando suas mãos sobre o que quer que tenham quebrado o código do Agile Forecast ... mas eu sempre clicava na minha língua, sorria e saía com o pensamento "sim ... você quase fez, mas aquela amante que chamamos de 'tempo' ... ela é apenas cruel ... "

0
Scott Barnes