Como é possível estimar o tempo para projetos de programação? [duplicado]

40

Parece ser quase impossível chegar perto porque você pode encontrar um grande número de problemas e coisas que não foram antecipadas. Quão perto podemos esperar para estimar razoavelmente? Nosso PM quer ser capaz de ter coisas como gráficos de Gant e tal mapeamento de semanas a fio e tal ... Então, nós dizemos que podemos fazer esses bugs, e isso é quanto tempo cada um levará, e o objetivo será sexta-feira. , mas as coisas são jogadas fora e empurradas para a próxima semana, como sempre! Como devemos supor a hora certa?

    
por BigOmega 23.03.2009 / 20:12
fonte

12 respostas

43

Nosso anfitrião Joel recomenda o agendamento baseado em evidências , que inclui métodos para explicar estimativas imprecisas , interrupções e distrações, e todos os outros suspeitos do costume.

Os maiores itens de estrondo:

  • A pessoa fazendo um dado trabalho tem a palavra final sobre sua estimativa. Nenhum administrador, líder ou comitê pode ignorar as estimativas, apenas reatribuir o trabalho a outra pessoa.
  • Quanto mais você interromper as tarefas, mais confiável será a estimativa final. O efeito é duplo: primeiro, os erros de superestimativa e subestimação tenderão a se anular mais um ao outro e, segundo, para realizar a análise, você acabará pensando no trabalho com mais detalhes, melhorando a precisão geral.
por 23.03.2009 / 20:15
fonte
17

Eu realmente gosto do livro Estimativa de Software: Desmistificando a Arte Negra de Steve McConnell. Um par de pontos realmente importantes que ele enfoca:

  1. Você está procurando uma estimativa ou um alvo? Uma estimativa significa "Quanto tempo levará para implementar esses recursos?" Um destino significa "Quantos recursos posso implementar por esta data?" São duas coisas diferentes, e é importante garantir que todos os envolvidos saibam de que coisa vocês estão falando e não confundam os dois.

  2. Tenha cuidado ao dar uma estimativa com muita precisão, especialmente antes. Não dê estimativas de ponto único; Se o seu melhor palpite no início de um projeto é de 4 semanas, calcule algo como "2 a 8 semanas". É impossível ser mais preciso até você trabalhar as fases do projeto (desenvolvimento de requisitos, design, etc.) que eliminam algumas das incertezas.

por 23.03.2009 / 20:41
fonte
7

Eu recomendaria dividir a tarefa tanto quanto possível antes de realizar qualquer avaliação, este exercício apenas o forçará a ter uma compreensão profunda do que você tem que fazer e como você planeja fazê-lo. Feito isso, você aumenta suas chances de comparar a subtarefa com algo que já fez e tem algo mais próximo da realidade. Se a especificação do que você tem que fazer não for clara, você também descobrirá neste momento, o que é uma coisa boa.

Tarefas acima de 40h dificilmente podem ser avaliadas com precisão, se seu gerente de projeto for bom, ele saberá disso! É certo estar errado, a experiência é a única coisa real que fará uma diferença real em suas avaliações (e, no final, apenas ajudará você a estar mais perto de uma resposta correta, não perfeita).

Eu também tive uma experiência muito boa com o planejamento do poker, quanto mais minha equipe usa, melhor as avaliações deles (além disso, é divertido!)

    
por 23.03.2009 / 20:54
fonte
4

Trabalhando como freelancer, isso é um problema constante para mim. Se eu entendi errado, perco dinheiro.

O problema de estimar para programação é precisamente o que várias pessoas identificaram aqui - são as incógnitas e as armadilhas que podem soprar e estimar em uma terra nunca-nunca.

Então, cada vez mais eu uso uma abordagem dupla

Se o problema está em um domínio conhecido em software, estou totalmente familiarizado com o que faço, e faço uma citação. Muitas vezes, com clientes, eles pedem um adiantamento quando discutem o projeto e, com isso, geralmente fico feliz em concordar - eu estou do lado da cautela, mas isso é apenas experiência em projetos anteriores.

Se o problema for um domínio desconhecido. Nesse caso, tentarei identificar quais são os problemas iniciais do crux e codificarei um caso de teste em torno deles para "dimensionar" o problema. Às vezes, é possível persuadir o cliente a pagar por isso como um estudo de "viabilidade", mas mesmo que você não consiga colocar o tempo não pago e definir o escopo, o problema é mais barato do que citar o cliente X. p>

Identificar quais problemas se enquadram em A ou B, e identificar quais são os itens cruciais em B, depende da experiência, mas acho que a regra geral é universalmente aplicável: sempre isolar os problemas do crux e lidar com eles primeiro. Uma vez que eles saibam, técnicas mais convencionais podem ser usadas com alguma confiança.

    
por 23.03.2009 / 20:47
fonte
3

Este é o melhor método que já usei: link

Ainda não é perfeito, mas se bem feito, pelo menos, você fica no estádio.

    
por 23.03.2009 / 20:18
fonte
3

Aqui estão dois métodos de estimativa que usei no passado. Eles funcionam, mas eu não os recomendo.

  1. Estime por quanto tempo você acha que deve ser feito e depois duplique. No início de cada projeto, deixei claro que as mudanças aumentariam a quantidade de tempo. Também gostaria de lembrar disso toda vez que uma mudança foi solicitada. É muito mais do que um método de estimativa, mas era impossível estabelecer algo realista porque a empresa não acreditava em metodologias ou reuniões.

  2. Isso será feito quando estiver pronto. Isso geralmente só funciona para projetos freebie de tempo livre, mas eu consegui convencer um ex-gerente dele quando ele ficou sábio com o método double-your-guess. Eu acho que a única razão que funcionou é porque o benefício esperado do projeto foi enorme e a necessidade da solução foi considerada crítica. Sua única alternativa era comprar software de prateleira, que eles se recusavam a fazer 99% do tempo.

por 23.03.2009 / 20:48
fonte
1

Vai levar de 6 a 8 semanas.

Poupe alguns dias planejando e dividindo o projeto em unidades de 2 ou 3 dias e, em seguida, calculando o tempo gasto fazendo atividades de não desenvolvimento. Mas qualquer coisa mais do que algumas semanas, será uma estimativa baseada em outros projetos de dificuldade similar.

    
por 23.03.2009 / 20:16
fonte
1

Quando surgem coisas inesperadas, reagimos mudando a arquitetura, o design ou o código, etc. A estimativa em si deve evoluir junto com essas coisas. Não deve ser um valor determinado no início de um projeto e nunca atualizado quando tudo mais puder ser atualizado e evoluir durante o projeto.

    
por 23.03.2009 / 20:19
fonte
1

Uma coisa é que a estimativa só é possível se você estiver trabalhando com algo familiar, usando tecnologias familiares. Se você está trabalhando em algo genuinamente novo, as estimativas de tempo certamente não serão válidas. No entanto, fazer um plano (quebrar o projeto em pedaços e ordená-los de alguma forma) é bastante benéfico por si só, mesmo que as estimativas de tempo sejam realmente apenas suposições. Seu PM provavelmente sabe disso; O principal é fazer algum tipo de plano , não que as estimativas estejam corretas.

    
por 23.03.2009 / 20:23
fonte
0

a experiência conta. Você sabe o que aconteceu da última vez, e o tempo antes disso, e você sabe o quanto você pode fazer um tipo específico de tarefa - então a estimativa é realmente fácil. Você escolhe um número no ar baseado em um palpite. À medida que você obtém mais experiência para estimar e desenvolver, você se sentirá melhor com isso.

Você nunca será perfeito o suficiente para satisfazer um gerente de projeto e seus gráficos de Gantt (suspiros, tais coisas devem ter bordas difusas ativadas por padrão), mas você está estimando o tempo, não dando uma garantia tempo.

    
por 23.03.2009 / 20:20
fonte
0

Para mim, é apenas algo que vem com a experiência. Quando eu era um garoto pequenino como programador, parecia que eu estava sempre subestimando a duração de um projeto. Como você disse, as coisas surgiriam e o projeto levaria mais tempo. Agora que tenho "tempo de voo", sou muito melhor em antecipar o que são essas "coisas". Coisas inesperadas ainda acontecerão, mas em geral os prazos são muito mais precisos nos dias de hoje.

    
por 23.03.2009 / 20:20
fonte
0

Eu recomendo strongmente "Agile estimating and planing", de Mike Cohn. Ele descreve a estimativa relativa com base em pontos mais fáceis de serem feitos pela natureza humana. Este livro também descreve o planejamento de pôquer que é realmente divertido.

    
por 23.03.2009 / 20:29
fonte