Quanto tempo gasta estimando tarefas de programação?

9

Por exemplo, se eu dividir um projeto em n produtos de trabalho distintos (por exemplo, classes, funções ou componentes), existe um tempo t tal que n * t é uma quantidade adequada de tempo para gastar em estimativas?

estimation

— Michael Behan
fonte

9

É fácil. Apenas planeje algum tempo para analisar sua carga de trabalho e estimar aproximadamente quanto tempo as estimativas levarão ... e, espere.

— Joshin4colours

Como todas as suas estimativas estarão erradas o tempo todo, zero retorno do investimento = zero tempo gasto. Ah, exceto que os chefes o forçarão a criar estimativas falsas. As estimativas ágeis em que você escolhe um número aleatório de fibonacci em alguma unidade de medida aleatória sem unidade chamada BogoEstimons, ou algo assim, parecem melhores do que as estimativas em unidades de trabalho reais para horas humanas.

— Warren P

Estimar o tempo para estimar a tarefa. Deixe o Estimateception começar

— usuário

13

Se você tiver informações suficientes para dividi-las nesse nível, não gaste mais de um minuto em cada uma. Você não estará correto de qualquer maneira, mas estará tão correto depois de um minuto quanto depois de uma hora.

Se, por outro lado, você estava falando sobre histórias de usuários , eu sugeriria colocar as partes interessadas em uma sala e passar cinco minutos fazendo perguntas antes de estimar.

Independentemente disso, não perca muito tempo fazendo estimativas. Eles não são úteis ou precisos o suficiente para valer o esforço.

— pdr
fonte

3

+1. mas não concordo que as estimativas não sejam muito úteis. Eles ajudam a planejar melhor e, portanto, são mais produtivos.

— SuperM

4

@ superM: Eu não disse que eles não eram úteis. Eles certamente são. Eu disse que eles não valem muito tempo gasto. O software de trabalho é muito mais útil, portanto, gaste a maior parte do seu tempo nisso.

— Pdr3

@superM: Você já fez uma comparação entre suas estimativas e os valores reais? Isso fornecerá uma ótima lição sobre o valor real da adivinhação (que é uma estimativa por definição). A estimativa é uma coisa clássica de Pareto: você obtém uma estimativa razoavelmente boa em 20% do tempo. Perder mais tempo tornará apenas 5% melhor.

— JensG

Para mim, quanto mais trabalho em um projeto, melhores estimativas faço. Existem muitos fatores e alguns deles não posso controlar, e conhecer esses fatores [específicos do projeto] vem com a experiência. Às vezes, você simplesmente não consegue escapar da estimativa e, às vezes, está entre aqueles que sofrem com suas estimativas imprecisas.

— superM 08/11/13

2

Na minha experiência, uma das principais partes de uma abordagem ágil 'sim, que realmente funciona' é a diretriz 'Tarefas devem levar menos de um dia'. Se você está estimando coisas que demoram mais de um dia, estará bem longe.

Depois de dividi-los para que você possa fazer isso, você já fez o suficiente; independentemente realmente do que essas coisas são.

— Telastyn
fonte

2

Na metodologia ágil de scrum, o Planning Poker é visto como uma maneira eficaz de usar toda a equipe para estimar rapidamente o esforço necessário para as histórias de usuários em um sprint (presumindo que seja disso que você está falando). Caso contrário, eu não gastaria mais do que alguns minutos estimando uma única tarefa que faz parte de uma história de usuário.

Eu recomendo o uso dessa técnica baseada em consenso se você estiver tentando fazer estimativas para uma equipe de desenvolvedores.

Planejar o pôquer significa que você pode obter boas estimativas para cada história de usuário em uma única sessão (não mais que uma a duas horas).

Faça uma leitura sobre isso e tente!

Além disso, como regra geral, nenhuma tarefa na história do usuário deve exceder 7,5 horas (um único dia de trabalho). Se isso acontecer, você precisará dividir a tarefa em tarefas menores.

— Ciaran Gallagher
fonte

11

Planejando pontos de estimativas de pôquer, que não estão em nenhuma unidade real. O que os torna análogos de como as estimativas são realmente; Adivinhação Wild Ass.

— Warren P

11

A idéia é que, se soubermos que uma tarefa de 1 ponto levará 7,5 horas, por exemplo, podemos dizer que uma história de usuário de 5 pontos levará 30 horas e que uma história de usuário de 10 pontos levará 60 horas. Por exemplo, podemos escolher uma das menores tarefas e o tempo estimado pode ser atribuído como o valor de um único ponto da história do usuário. Em seguida, podemos usar essa história de usuário como base para estimar tarefas maiores. Se pensarmos que outra tarefa levará o dobro do tempo, atribuiremos 2 pontos de história do usuário (15 horas) e assim por diante.

— Ciaran Gallagher

1

Eu acho que depende do que você precisa. Se, por exemplo, a alocação de recursos do seu projeto depender dele (como era o caso por aqui às vezes), é melhor fazê-lo com cuidado. Por outro lado, se você estiver executando um projeto que não possui esse tipo de necessidade, poderá não entrar em muitos detalhes. Passar muito tempo com isso não é uma boa idéia, porque fazer uma estimativa precisa é muito difícil.

Existe um conceito famoso chamado Cone da Incerteza e Cone da Incerteza na Wikipedia que diz o quanto uma estimativa pode ser precisa. Vale a pena ler sobre.

— Joqus
fonte

1

O que você obtém de suas estimativas?

Dependendo do seu trabalho, estimativas individuais precisas podem ser relevantes (o cliente está pagando no final da semana ou a tarefa / história está bloqueando para outras pessoas e é necessária uma ETA precisa) ou não (você tem 200 histórias no backlog, ninguém vai morrer se uma história mudar por uma semana e você conta com erros de estimativa para calcular a média correta em um grande número deles).

Basta gastar o tempo mínimo para obter uma estimativa que seja boa o suficiente para suas necessidades. Não existe fórmula.

Pessoalmente, considero que mais de um minuto ou dois significa que você provavelmente está estimando a coisa errada (divida-a ou planeje a descoberta).

— ptyx
fonte

0

Na verdade, você precisa de estimativas para ajudar outras partes interessadas a atribuir prioridade relativa - estimativas tão amplas que, pelo menos, dizem que a tarefa1 é aproximadamente três vezes o esforço em comparação com a tarefa2 (mesmo que em termos de horas não sejam muito precisas no final) sejam úteis. Gaste o tempo necessário para entender quais são essas tarefas (para atingir certos objetivos) e depois fazer estimativas aproximadas para eles.

Depois de ter relativa prioridade, concentre-se em fazer as coisas e ajustar as estimativas durante o percurso. Em outras palavras, gaste pouco tempo em estimativas iniciais, mas refine suas estimativas com o passar do tempo, para que o plano do projeto tenha uma boa idéia de quando o que será feito.

— Roopesh Shenoy
fonte

0

Boas estimativas são as que se baseiam em fatos, não em suposições.

Portanto, se você já teve um projeto semelhante e capturou seu tempo de estimativa anterior, esse servidor pode ser uma boa base de estimativa para começar . No entanto, dependendo do escopo do projeto , pode haver artefatos desconhecidos , o que é melhor esclarecer com a BA ou com o proprietário do produto o mais rápido possível.

Também é verdade que: A estimativa de projeto de software é inerentemente imprecisa . No entanto, existem algumas práticas de estimativa realistas que podem ajudar:

As pessoas que fazem o trabalho devem participar da estimativa do projeto
Traga os especialistas: o julgamento dos especialistas é essencial para o sucesso do projeto
Estimar peças grandes como uma variedade
Use a técnica Delphi: Este é um método que ajuda a convergir as opiniões da equipe em caso de conflito na estimativa do projeto de software.
Tenha em mente o custo
Lembre-se dos recursos alocados disponíveis para executar o trabalho

— Yusubov
fonte

Nunca observei uma equipe ou indivíduo que fizesse estimativas que, rotineiramente (mais de 50% do tempo), eram precisas em 10% do tempo real gasto. Outras pessoas em outros lugares reivindicam sucessos que me parecem difíceis de imaginar acontecendo em qualquer lugar em que trabalhei.

— Warren P

"preciso dentro de 10% do tempo real gasto" - é realmente um resultado muito ruim. Também leve em consideração a margem de erro, que aumenta pela complexidade e dependências externas do projeto.

— Yusubov 03/10/2012

É isso que eu estou dizendo. A estimativa é péssima.

— Warren P

yeap, que é realmente grande golpe para ter "precisos dentro de 10% do tempo gasto" ...

— Yusubov