Como estimar o comprimento de tarefas imprevistas? [em espera]

Question

Gostaria de saber se alguém sabe uma metodologia ou o que quer que seja capaz de estimar o comprimento de tarefas imprevistas.

Muitas vezes eu tenho que deixar alguma tarefa e participar de muitos outros, eu tenho lido sobre o troca de contexto , mas o meu problema é que eu não posso, becouse eu não sei, como estimar o comprimento da tarefa imprevista. É possível ?

Answer 1

I tendem a dar estimativas de horas de trabalho, de modo que, se for puxado para fora de uma tarefa, então eu pode apontar para o que eu fiz, e por quanto tempo.

I tendem a usar este método no entanto: http://www.joelonsoftware.com/articles/fog0000000245.html

Dessa forma, os supervisores podem ver como muito mais trabalho que resta, uma vez que eu voltar da tarefa imprevista.

Answer 2

A chave é de dados históricos.

Se você gravar quanto tempo (incluindo interrupções) que leva para completar um determinado tipo ou tamanho de tarefa, do que para as tarefas futuras, você só precisa identificar o tipo / tamanho de uma nova tarefa, e aplicar os dados históricos para a figura quanto tempo tal uma tarefa normalmente demora. Uma vez que os dados que você esteve gravação incluiu várias interrupções, etc., em seguida, a estimativa para o futuro será factor aqueles em bem.

Exemplo: digamos que este é os dados para os últimos 10 vezes que você teve que fazer uma atualização textuais para uma página web:

time     note
10m
10m
1.5h     got pulled away to fix a production bug
10m
45m      server offline due to upgrade
10m
10m
4h       entire staff evacuated due to bomb scare
10m
10m

Claramente, leva apenas 10 minutos para fazer a atualização real. No entanto, o tempo médio que tomou na vida real é de cerca de 45 minutos. Se você tem 5 atualizações para fazer amanhã, estimar-los em 45 minutos cada.

Esta abordagem deve também fator de ajuda para itens imprevistos que fazem parte da tarefa - ele só tem 10 minutos para fazer o código, mas 15 minutos para implantá-lo porque você tem que FTP sobre isso aqui, então rsync-lo lá , etc. Novamente, isso vai aparecer nos dados históricos.

Answer 3

Os Pragmatic Programmers aconselham a escolha de suas unidades de medida com sabedoria para dar-se margem de manobra.

Então, ao invés de dizer "120 dias" dizem "4 meses" (ou "meio ano").

Além disso, se você tem incógnitas, indicando este fato a seus clientes iniciais, e mantê-los no circuito, não pode ferir.

Answer 4

Não é provável até você perceber que uma tarefa tem sido negligenciado desde que você não pode saber o que está perdendo por definição.

Answer 5

Primeiro de tudo, não há nenhuma maneira que você pode estimar o comprimento de cada pequena tarefa em grandes projetos. Categorizar suas tarefas por criticidade, e apenas estimar vezes para essas tarefas que são cruciais para o seu projeto.

O próximo passo seria a de atribuir tempo livre em meio a tarefas menos importantes que estão acontecendo simultaneamente com as tarefas críticas. gráficos de Gantt iria servir a esse propósito lindamente.

Answer 6

Se você tem tarefas de forma consistente imprevistas, então você pode est. A cerca de tempo que você trabalhar sobre aqueles e adicionar como um amortecedor para determinar data final (não esforço de trabalho para o projeto desde as tarefas imprevistas soar como se eles estão assoc. Com Outros projetos). Há estudos que mostram um avg. programador é de 60% produtiva em um projeto atribuído, de modo buffer de 30% -40% pode parecer alto (ou talvez não), mas seria um ponto de partida bom.