Como contabilizo tarefas alteradas ou esquecidas em uma estimativa?

Para lidar com estimativas em nível de tarefa e relatórios de tempo, tenho usado (aproximadamente) a técnica descrita por Steve McConnell no Capítulo 10 de Estimativa de software. Especificamente, quando chega a hora de eu criar estimativas no nível da tarefa (imediatamente antes do início da codificação em um projeto), eu determino as tarefas em um nível bastante granular para que, sempre que possível, não tenha tarefas com um único ponto, 50 Estimativa de% de confiança superior a quatro horas. Dessa forma, o processo de estimativa de tarefas ajuda na construção do software, ajudando-me a não esquecer as tarefas durante a estimativa. Também venho com um intervalo de horas possível para cada tarefa e, usando os cálculos estatísticos que McConnell descreve junto com meus dados de precisão histórica, posso gerar estimativas em outros níveis de confiança, quando desejado. Sinto que esse método está funcionando bastante bem para mim. Somos obrigados a colocar tarefas e suas estimativas no TFS para rastreamento, portanto, eu uso as estimativas na porcentagem de confiança que devo usar.

No entanto, não tenho certeza do que fazer quando esqueço uma tarefa ou acabo precisando fazer um trabalho que não se enquadre perfeitamente em uma das tarefas que estimei. Obviamente, é melhor tentar evitar essa situação, mas como faço para explicar tarefas esquecidas / alteradas? Quero ter os melhores dados históricos que puder para me ajudar com estimativas futuras, mas, no momento, estou apenas calculando se fiz a estimativa de confiança de 50% e se fiz dentro da estimativa à distância.

Ficarei feliz em esclarecer o que estou perguntando, se necessário - deixe-me saber o que não está claro.

O livro Waltzing With Bears: Managing Risk on Software Projects (de DeMarco e Lister, os autores da Peopleware) tem uma abordagem fantástica para isso. Aqui está minha reinterpretação:

Faça uma estimativa de "tudo corre perfeitamente". É claro que tudo raramente vai perfeitamente, de modo que há uma baixa probabilidade de acontecer, digamos 0,1%. Em outras palavras, apenas um projeto em mil será perfeitamente planejado. É isso que a maioria das pessoas usa como "estimativa", o que é obviamente insano.

Em vez disso, devemos pensar em estimativas como distribuições de probabilidade. Essa estimativa do "mundo perfeito" é o ponto mais à esquerda na distribuição de probabilidade estimada.

Em seguida, faça uma estimativa "se as coisas continuarem assim foram para projetos semelhantes como este". Essa estimativa ajuda você a ter uma "visão externa" ( http://wiki.lesswrong.com/wiki/Outside_view ), escapando da falácia do planejamento ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).

Em seguida, faça uma estimativa "Tenho 90% de certeza de que seremos feitos por X". Tenha muito, muita certeza de que você quer dizer 90% de certeza. Em outras palavras, você espera levar mais tempo do que essa estimativa apenas uma vez a cada dez projetos que realiza.

Agora, podemos usar sua primeira estimativa como estimativa de probabilidade de 0,1% e a segunda como estimativa de probabilidade de 50% (época a gosto) e a terceira como estimativa de 90%, o que fornecerá uma boa curva.

Digamos que suas estimativas de 0%, 50% e 90% foram 1º de maio, 1º de junho e 1º de agosto, então sua curva de estimativa se pareceria com isso:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Observe como o crescimento da probabilidade diminui com o tempo. Se alguém lhe pedir uma estimativa de 99,9% nesse cenário, talvez seja 1º de janeiro do próximo ano.

Em uma palavra - contingência.

Contingência é a quantia que você adiciona para "outras coisas" - as coisas que você não pode contabilizar em outro lugar na sua estimativa. O SMc cobre isso na estimativa de software? Não me lembro e minha cópia está no trabalho (estou de férias respondendo a isso - como estou triste) ...

De qualquer forma, de um modo geral, existem três tipos de contingência que eu recomendaria:

1) Contingência específica de risco - é aí que você identifica um risco específico e adiciona uma certa quantidade de tempo para cobrir o potencial excedente relacionado a ele. A primeira coisa a ser esclarecida aqui é o que é um risco - é algo que pode acontecer, que terá um impacto negativo no projeto, que está fora de seu controle .

Esta última parte é crítica - não é apenas "as coisas demorando um pouco mais do que eu pensava", é "o módulo de agendamento de terceiros que nos disseram que devemos usar, pois é um padrão da empresa que pode não estar à altura da tarefa". A maneira como você calcula a quantidade de contingência de risco a adicionar é a porcentagem de chance do risco expressa em decimal (portanto, 50% = 0,5), vezes o impacto desse risco (então, no exemplo, diga que você precisa escrever manualmente CRON trabalhos em vez de usar o agendador e isso levará 10 dias, esse número é 10 dias).

Portanto, se houver uma chance de 50% de seu risco se concretizar, e você precisará de 10 dias de esforço para contorná-lo, adicionando 5 dias. Adicione todos os valores para todos os riscos identificados no projeto e adicione-os ao total.

2) Merda Acontece Contingência - A melhor descrição que já ouvi sobre isso, mesmo que não seja elegante. É um projeto de TI, merda acontece. Nunca é como você pensa, as coisas demoram mais, são perdidas e assim por diante. Geralmente, a Contingência de SH estará entre 10% (mínimo absoluto) e 25% (embora possa ser maior), com 15% sendo típico, o nível exato depende do nível de incerteza e risco geral (mudança de metas, requisitos incertos etc.) )

Se o seu PM não aceitar a Contingência SH (e é possível, ele pode não ter experiência em projetos de TI ou ser um otimista cego), basta adicioná-lo a todos os valores individuais. Se ele souber o que está fazendo, terá um registro de riscos próprio e amará você por pensar nessas coisas. Certamente, se ele tiver algum tipo de qualificação de PM (como o PRINCE2), ele saberá disso.

3) Alterar Contingência - É aqui que você tem certeza de que o cliente fará alterações, mas não quer que seja um ponto de discórdia. Adicione X dias ou X% e ele entrará em um pote para as alterações que o cliente aumentar. Há duas maneiras de lidar com isso: ou você conta a eles e é deles que gastam ou não conta a eles.

A primeira maneira é melhor, mas precisa de um cliente razoavelmente educado e justo - as coisas são classificadas como mudanças e ele pode gastar seu pote como achar melhor (com base em você estimar as coisas à medida que elas aparecem).

A segunda maneira que você menciona é uma mudança, mas não tente cobrar mais dele. Você precisa anotar todas as coisas em que o gasta; se chegar ao ponto em que se esgote, você precisará voltar ao cliente e pedir mais tempo ou dinheiro, e eles dirão "espere, eu" estou pagando blá blá blá ", você pode apontar todas as coisas que eles já mudaram e que você não cobrou como sinal de que não está sendo totalmente irracional. Nem sempre funciona, mas quase sempre fortalece sua mão nas discussões.

Nenhum desses três cobre especificamente as coisas que você esqueceu, mas acho que entre elas você preencherá muitas lacunas que tem.

Quando for solicitada uma estimativa para uma tarefa, forneça uma estimativa de ponta para a equipe e faça uma estimativa de ponta para si mesmo, fazendo isso sempre para que você tenha tempo após a conclusão da tarefa para trabalhar em algo que você pode ter esquecido de mencionar em primeiro lugar.

Você está preocupado que, ao adicionar tarefas extras, você distorça sua precisão histórica? Ou você acha que não incluir as tarefas extras distorcerá a precisão?

Eu acho que para o melhor do projeto, as tarefas devem ser inseridas no sistema de rastreamento. Tenho certeza de que o líder do projeto poderá oferecer uma explicação adequada para o gerenciamento de discrepâncias ...