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 dias-homem 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?

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". É muito difícil estimar no sentido do tempo do relógio.

Mas 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.

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 período 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 para algo simples, por exemplo, "menos de um dia", "mais de uma semana" etc. etc. -alguns pontos da história.

É 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 dois dias úteis ... mas no último sprint subestimamos tudo, talvez sejam realmente 2,5 dias úteis. Ou 3?", Eles continuam o mesmo de sempre. "5 pontos da 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: vi 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 trabalho, já que receberam uma tarefa confortável. Tirar as unidades reais de tempo de uma estimativa pode conter essas tendências. Termine a alternativa cínica.

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 de quantos pontos 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 com o tempo e isso é uma conseqüência para terminar ao longo do tempo em 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.

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

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, sem interrupções e com tudo o que preciso para "implementar a história", ou seja, sem atividades periféricas 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 base na complexidade total da implementação, desde a interface do usuário até o 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 somente a complexidade do tamanho. 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 uma vez que você pega o jeito dos SPs, 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 realmente não beneficiam muito os SPs (e Mike Cohn também defende SP junto com muitos outros evangelistas ágeis).

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 de 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. Portanto, a equipe reestima 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ê reestima novamente, e essa 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 os 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 da sua equipe aumentar.

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 é direcionar 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%.

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 ao Dono do Produto.

Os dias de homem estimam o tempo necessário 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.

Os pontos da história determinam 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 para medir quantos podem ser feitos em um período de tempo fixo. Eles estimam a complexidade dos pedaços de trabalho em comparação 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 é.

Se você se aproximar de 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 giram em ciclos com " eu entendi! .. eu tenho o segredo para uma previsão precisa! " Óleo de cobra para as massas. Quando você realmente faz uma previsão, está dizendo em voz alta: " PERMITIDO x dias / horas / pontos para que isso seja concluído " - é, de certa forma, a criação de uma "caixa de tempo" para a realização desse evento.

Para mim, o Points está apenas mudando os limites, no final do dia, a menos que você esteja em um time que tenha o prazer de dizer " * Bem, temos 3 semanas por sprint e chupa o polegar ... acho que devemos atirar para 30 pontos para completar nesse 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 orçamento, perguntando em voz alta " Já atingimos 15 pontos ainda?"mas o perigo aqui é que agora você está usando o Velocity para medir a produtividade, não a capacidade, o que, pelo que entendi, dá um chute na 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 com essa tarefa "tripa inata 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, então é 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 das previsões 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 estiver 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 nós, gerentes de produto, esperamos até depois de concluir sua lista de pendências e juntar 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 durante o 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ê poderá 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ê acabou de voltar para 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 ... "

O livro de Mike Cohn "Estimativa e planejamento ágeis" descreve as vantagens e desvantagens de estimar com "dias ideais" ou pontos da história, portanto, a resposta rápida à sua pergunta é que você não precisa estimar com pontos da história. Se for mais natural estimar em dias ideais, vá em frente.

Eu acho que o método Story Point tem pelo menos duas vantagens importantes sobre o método do dia dos homens: Primeiro, é mais fácil estimar em SP. SP é relativo e humano como nós é melhor em estimativa relativa do que absoluta, como no método homem-dia.

Segundo, quando você estima em SP, obtém "Team SP" e não "Individual Manday". Quando você pergunta "Quanto tempo essa tarefa levará?", O desenvolvedor sênior pode fornecer 1 dia, mas 5 dias, para um júnior. Esse é o dia do homem que decide quem executará essa tarefa. Se o proprietário for forçado a mudar (e vai mudar!), Você deve remarcar tudo. Com SP, ainda é o mesmo quem assume a tarefa.

Estou surpreso que ninguém tenha mencionado a 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 levar 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.

A estimativa do ponto da história segue a série de fibonacci 1,2,3,5,8,13,21 ...

Um cérebro humano pode facilmente mapear as coisas com base em tamanhos. Por exemplo: Temos um cartão postal e atribuímos um ponto 2 da história e três o tamanho do cartão postal significaria 2 * 3 = 6 pontos da história.

O Ponto de História 6 fica entre as séries 5 e 8 de fibonacci, sendo 5 o número mais próximo e, portanto, o ponto de história seria 5.