O que posso fazer para melhorar a estimativa de quanto tempo os projetos levarão? [duplicado]

Você precisa perguntar por algum tempo antes de dar uma resposta à gerência. Volte e estude a tarefa:

• Anote uma abordagem geral
• Talvez faça alguma exploração do código por algumas horas
• Divida a tarefa em etapas em um excel (sugiro o Microsoft Project, mas isso pode ser um exagero)
• Contra cada tarefa, tente atribuir sua melhor estimativa de estimativa
• Adicione-os e adicione um buffer de 20 a 30% e forneça ao Gerenciamento

Com o tempo, você ficará melhor.

Atualização:

Bem, não precisa ser de dois dias. Você basicamente não dá uma resposta imediatamente. Não há como você saber (com exceção das tarefas mais triviais) quanto esforço vai levar de imediato. Se for uma tarefa grande (talvez de 3 a 4 semanas), levará alguns dias para estimar, mas se for uma tarefa de 3 a 4 dias, levará apenas 3 a 4 horas para quebrá-la. e estimar.

Esta pergunta tem uma resposta longa e uma resposta um pouco menos longa (mas nenhuma resposta curta).

A resposta longa é de 255 páginas (e alguns apêndices) e é chamada de " Estimativa de Software: Desmistificando a Arte Negra

A resposta um pouco menos longa é na verdade apenas um conjunto de heurísticas / dicas:

1. Divida a tarefa em pequenos itens - de preferência de 1 a 3 dias cada
2. Tente encontrar uma tarefa semelhante - no mesmo domínio ou envolvendo tecnologias semelhantes. Quase nunca é o caso que você está estimando uma tarefa que você fez antes (porque já está feito ...). Exemplo: Se a sua tarefa é "melhorar o SharePoint de maneira X", talvez você tenha feito uma tarefa que envolvia a integração com o SharePoint e / ou outro produto do Office e / ou outro "sistema de gerenciamento de conteúdo"
3. Dê sua estimativa como um intervalo em vez de uma única estimativa de ponto
4. Entenda suas margens - se você estiver estimando algo completamente novo, talvez seja necessário um fator de 100% ou mesmo 400% (ou seja, se sua estimativa for de 2 dias e o fator for de 400%, poderá levar entre 0,5 dia a 8 dias). Quanto mais incerteza, maior o fator.
5. Entenda que, à medida que avança na tarefa, você precisa revisitar e refinar sua estimativa
6. Comunique-se, comunique-se, comunique-se! Certifique-se de que a gerência esteja ciente de quão confiável é uma estimativa específica (ou não).
7. Forneça estimativas em escalas e números que reflitam a exatidão (por exemplo, estimar em horas implica mais precisão do que dar a mesma estimativa em dias; estimar que levaria 3,75 dias faz com que as pessoas assumam que sua estimativa é mais precisa do que se uma estimativa de 4 teria sido dado)
8. Reconheça o "Cone of Uncertainty" (veja mais detalhes abaixo)
9. Ao fazer uma estimativa, digamos "3 dias", pense na seguinte pergunta: "Pode levar menos de 3 dias?". Se a resposta for Não, então esta é uma estimativa otimista, já que levaria 3 dias se e somente se nada der errado ...

Várias mais notas:

• As imprecisões podem ir para os dois lados, para cima ou para baixo (embora os projetos de software sejam notórios por subestimativas, e não por estimativas exageradas)
• Observe que os efeitos da subestimação geralmente são mais prejudiciais ao projeto do que superestimadores (isso também é discutido na primeira parte do livro acima mencionado)

O Cone da Incerteza:

A idéia do "cone" é que você inicia um projeto com estimativas de alto nível / baixa precisão e sua confiança e precisão aumentam à medida que você avança no projeto. Por exemplo:

• No momento da coleta de requisitos, suas estimativas são muito menos precisas do que depois que o design de alto nível estiver pronto
• Que são bem menos precisos do que depois que o design detalhado foi feito
• Qual é menos preciso do que na metade da codificação.

Este é um fato da vida e, em vez de combatê-lo, esse entendimento deve ser incorporado ao seu plano. Isso é mais relevante quando se estima um projeto inteiro ou uma tarefa grande (ou seja, mais de duas semanas), já que dividi-lo em itens refinados como sugeri no item 1 não é realmente viável (ou custo-efetivo).

Tente agendamento baseado em evidências .

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

The steeper the curve, the more confident you are that the ship date is real.

Here’s how you do it...

Você pode tentar ler esses dois livros, eles são ótimos (eu os leio mais de uma vez)

• Estimativa de software
• Desenvolvimento rápido

E eles também lidam com o aspecto humano na construção de software (o que parece ser útil para você)

faça estimativas rapidamente, reestime regularmente e, o mais importante, mantenha o gerenciamento atualizado.

É tudo sobre gerenciamento de expectativas, portanto, certifique-se de que eles entendam as limitações da sua estimativa, isso é fundamental, especialmente para gerentes de projeto não técnicos.

Não obstante a sua ressalva de que agora está obsoleto, o artigo de Joel sobre os Cronogramas do Software sem dor é extremamente útil se você for novo no conceito.

So, you have to make a schedule. This is something almost no programmer wants to do. In my experience, the vast majority just try to get away with not making a schedule at all. Of the few that make a schedule, most are only doing it because their boss made them do it, halfheartedly, and nobody actually believes the schedule except for upper management, which simultaneously believes that "no software project is ever on time" and in the existence of UFOs...

Here's a simple, painless way to make schedules that are actually correct...

Isso pode parecer simplista, mas na verdade ajuda. Eu tive um par de clientes internos ao longo dos anos que iriam invadir meu escritório com uma nova ideia. "Quanto tempo levaria para escrever um novo recurso para o nosso grande programa que faz [descrição extremamente vaga]?" Eu achei que pedir mais detalhes era freqüentemente fútil. "Apenas me dê uma estimativa aproximada", ele exigiria.

Então, eu chegava na gaveta da minha escrivaninha e pegava um dado de seis lados. Eu agitá-lo na minha mão e jogá-lo na mesa. "Quatro semanas", eu pronunciaria.

"Vamos, seja sério", o cliente reclamava.

Nesse ponto, eu explicaria que sem pelo menos uma ideia coerente de como esse novo recurso funcionaria, eu não tinha absolutamente nenhuma ideia, e a rolagem do dado era tão boa quanto qualquer outro método de estimativa. Em última análise, todos eles receberam a dica. A maioria das ideias foi embora para morrer. Com o resto, meu cliente voltaria com algo com o qual eu poderia trabalhar.

Existe algum material escrito muito bom por aí sobre o tópico de estimativa. Os livros de Steve McConnell (mencionados anteriormente aqui) são excelentes, e eu também recomendaria o Estimativa e planejamento ágil de Mike Cohn .

Eu estudei este livro antes de planejar e estimar um grande projeto com minha equipe há 18 meses, e foi extremamente útil. As abordagens e técnicas do livro não são apenas para grandes projetos - elas são úteis para qualquer tamanho de tarefa.

A estimativa é difícil. Trabalhar sem estimativas é um sonho. Então é uma espécie de mal necessário.

• Comece por deixar claro que as estimativas iniciais estão muito baixas, por isso, se chegar a uma estimativa da Unidade X, atribua um intervalo de 0,6X a 1,6X.
• Depois, há o truque de dobrar a estimativa (no entanto, dizer que um ~ 2 anos levará 4 anos, pode ser um problema)
• (Há mais uma que envolve escalar o magniture e bater na próxima unidade superior. Preciso me referir ao meu livro para este.)

Em seguida, vem a parte de como chegar a essa estimativa para duplicar / multiplicar? Nenhuma resposta fácil.

• As tendências históricas fazem sentido se você estiver fazendo o mesmo tipo de projeto com o mesmo nível de habilidades de equipe.
• O próximo é o "Deixe-me guiar o navio por 2-3 iterações" e, em seguida, voltarei com uma estimativa melhor.
• Finalmente vem o "Diga-me quanto vai custar .. Até então ninguém trabalha sobre isso." Neste caso, você não tem anjo da guarda. Sente-se e divida-o e, em seguida, aplique suposições parciais até que você tenha uma estimativa cumulativa. Então faça o double-n-bump.

Nos meus 5 anos de vida nas trincheiras .. A única coisa que eu vi é a estimativa de "adivinhar o assento das suas calças ..." Não FP .. Nenhum processo .. ajuda nas restrições do mundo real. Ainda assim as coisas podem melhorar ... para isso, eu sugiro que o livro 'Estimativa e planejamento ágeis' de Mike Cohn - seja o livro mais próximo de nós, pecadores programadores e da realidade. O resto são pregadores em seus cavalos altos ... Caper Jones qual planeta é a sua morada?

Boa pergunta .. Eu continuo perguntando isso quando todo projeto começa e então uma vez por semana eu estou fazendo o GRIND. Ainda não há resposta das vozes na minha cabeça.

Além disso, como parece que você não trabalha em uma empresa de software, lembre-se de que nem de perto 100% do tempo do desenvolvedor é gasto em codificação. Certifique-se de que você tenha tempo para planejar, documentar, pesquisar e testar. Essas são geralmente as etapas que a administração gostaria de interromper o processo, mas não ficarão felizes com os resultados se o fizerem. Se você receber qualquer reação, deve lembrá-los de que: A) Você acabará gastando tempo nesses itens de qualquer maneira, estejam eles orçados ou não. B) Você acabará gastando mais tempo na manutenção e correção de erros sem o planejamento adequado. Se você ainda não leu "The Mythical Man Month", de Frederick Brooks, eu recomendo enfaticamente. Ele tem muitos bons conceitos e você provavelmente se relacionará mais do que um pouco com alguns dos cenários. Alguns dos itens são um pouco datados, mas há muita informação boa e você deve ser capaz de obter um no barato.

Não faça estimativas. Em vez disso, use uma técnica de gerenciamento de projetos que não seja dependente de estimativas. O Scrum, por exemplo, enfatiza fazendo trabalho ao invés de falar sobre fazendo trabalho (isto é, estimativas).

Se você gastar um ou dois dias, cinco ou qualquer estimativa, não seria melhor ter codificado, projetado ou testado nesses dias, em vez de gastar o tempo "estimando"?

Lembre-se da lei de Hofstadter:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

É engraçado e tudo mais, mas eu costumo fazer estimativas razoáveis, então coloco alguns (pelo menos) 10% em cima dele e depois arredondo tudo. Em algumas ocasiões eu não tinha permissão para fazer isso, eu lamento dizer que acabei falhando miseravelmente em cumprir o cronograma.

Duplique sua estimativa inicial.

Falando sério, tente dividir a tarefa em bits menores e estimados. E depois dobre.

Principalmente, é apenas uma questão de prática.

Aqui estão algumas coisas importantes para lembrar ao estimar:

1. Use o método some para acompanhar quanto tempo você acha que vai demorar vs. quanto tempo isso realmente levou.
2. Assegure-se de dividir suas tarefas nas menores etapas possíveis antes de apresentar sua estimativa.
3. Não se esqueça de incluir o tempo de teste / correção de erros na sua estimativa.
4. Não deixe que as pessoas o obriguem a fazer planejamentos artificiais.

O artigo de Joel que harpo menciona é uma grande expansão dessas idéias.

Não acho que exista uma receita universal passo a passo.

Todo projeto é diferente. Se você conhece seu código e conhece seus processos, sabe o suficiente para fazer uma estimativa séria. Pense em todas as etapas, todos os componentes e seja realista. Não seja excessivamente otimista. Construa contingências para todos os lugares onde há risco potencial. É muito melhor ser preciso do que ser rápido.

Como qualquer outra coisa: você consegue estimar fazendo muito isso. Quanto mais você se forçar (ou for obrigado) a fazer estimativas, melhor você conseguirá fazê-lo.

Para melhorar as estimativas, você precisa comparar suas estimativas anteriores com o tempo real necessário e, em seguida, procurar padrões na diferença.

Como outros já sugeriram, o primeiro passo é dividir o projeto o máximo possível para que você trabalhe com tarefas discretas gerenciáveis. Registre suas estimativas para cada tarefa e, ao fazer o trabalho, registre o tempo real que leva (incluindo o tempo de todos os bits que você esqueceu ao fazer a estimativa - eles geralmente estão onde estão os maiores problemas).

No final do projeto, compare seus dois conjuntos de figuras para ver onde você errou (porque, mesmo depois de anos de experiência, todos nós erramos em algum lugar). Você pode então procurar melhorar de duas maneiras:

• Tente identificar onde você está constantemente subestimando ou esquecendo tarefas e, em seguida, leve esse aprendizado para a próxima estimativa, ou seja, tente melhorar a precisão com a qual você estimar cada tarefa. Quanto mais você trabalha em projetos semelhantes a cada vez, mais fácil é fazer isso.

• Procure também um padrão geral na diferença entre a estimativa total e o tempo real gasto. Se você está levando, digamos, 50% a mais do que o estimado para cada projeto, você tem uma diretriz para aumentar suas estimativas futuras. Portanto, mesmo que a precisão das estimativas de tarefas individuais não melhore, você deve ter uma estimativa geral mais realista.

Você pode se beneficiar da primeira abordagem após um projeto - a segunda abordagem se torna mais eficaz, já que você tem mais dados para comparar.

Também acho que a segunda abordagem é mais útil se você precisar estimar o tempo que outros desenvolvedores levarão. Eu acho difícil estimar em nome de outro desenvolvedor em uma equipe, mas sei que certas pessoas sempre levam mais ou menos tempo do que eu em determinados tipos de tarefas. Então, ao invés de tentar descobrir quanto tempo eles demoram, eu estimo o tempo que demoro e aplico um multiplicador geral baseado em projetos anteriores. (Idealmente, é claro, eu faria com que eles fizessem suas próprias estimativas, mas isso nem sempre é possível.)

Pergunte ao seu chefe que decisões ele / ela fará com base na estimativa que você der.

As estimativas são de apoio à decisão. O que a maioria das pessoas realmente quer são melhores decisões.

Talvez possamos conseguir isso melhorando nossas estimativas (e tem havido muitas sugestões boas dadas) mas, vamos encarar, as estimativas nunca serão tão precisas quanto a PM média quer, nem tão baixas quanto a média vendedor quer.

Todas as estimativas são intervalos e probabilidades (mesmo quando somos forçados a fornecer um único número), e você pode fornecer um suporte a decisões muito melhor se você souber para o que a estimativa será usada.

Há muito mais a ser dito sobre isso, mas eu queria ter a perspectiva como ninguém mais mencionou.

George, eu passei a maior parte da minha carreira como um time de um homem, então eu sei do que você está falando.

Alguém sugeriu que você adquira o MS Project, se tiver muita experiência com o Project, tudo estará bem. Mas se não, IMHO só vai tornar as coisas mais complicadas.

Meu primeiro insight real em estimativas veio de Cronogramas de Software sem dor de Joel Spolsky. Joel agora sugere que você use Evidence Based Scheduling em vez disso, que eu acredito que esteja no seu software de rastreamento de bugs < um FogBugz . Eu não usei isso, mas tenho certeza que é muito melhor do que o que estou prestes a lhe dizer ... mas se você quiser seguir a estrada DIY:

O que você precisa é uma maneira simples de gerenciar uma lista de tarefas. Pessoalmente, eu adicionei 4 campos personalizados ao meu software bugtracker (eu uso BugTracker.NET ), um mínimo, máximo, provável e real estimar os tempos. Eu adiciono todas as tarefas e recursos ao bugtracker junto com meu min, max e & estimativas prováveis. Quando termino cada tarefa, atualizo o tempo real. À medida que percorro minhas tarefas, vejo em minha história que, em média, minhas estimativas 'prováveis' estão em X% (para mim, são 26%), então posso aproveitar meu tempo total e projetar todas as tarefas restantes com meu tempo provável mínimo, máximo e ajustado. Depois, em tarefas ou projetos futuros, posso percorrer minha história de tarefas semelhantes e seus tempos reais e formar minhas estimativas a partir deles. Ter o histórico também ajudará a evitar tarefas perdidas.

Se você fizer isso, você também pode se deparar com BS político. Quando comecei isso, dei acesso ao meu gerente, mostrei-lhe como funciona e como ele poderia definir minhas prioridades e descobrir o andamento dos projetos. No entanto, como o software é uma ferramenta de rastreamento de bugs, acredito que todos os recursos, aprimoramentos e tarefas estejam sendo reportados como bugs! Esta é uma coisa que eu gostaria de poder desfazer.

E o livro Steve McConnell é fantástico.

Algo que eu uso é COCOMO. É uma técnica que fornece modelos probabilísticos para estimativa de custos de software. É algo que seus PMs (se formalmente treinados) provavelmente estarão familiarizados. Em vez de se preocupar com horas, você simplesmente estima o SLOC (linhas de código fonte) que espera escrever. Isso aí deve acionar alguns alarmes, mas é apenas uma parte da técnica. Em seguida, você conecta essas estimativas a um modelo e ajusta as métricas para o ajuste fino.

• Número de desenvolvedores
• Capacidade de cada desenvolvedor
• Seu calendário de trabalho (horas por semana, por recurso)
• Linguagem (s) de desenvolvimento e & porcentagens (se estiver usando mais de um)
• Familiaridade com o domínio (alguém já escreveu esse tipo de aplicativo antes)?
• Estilo de gerenciamento
• Processo de desenvolvimento (Agile, cascata, RUP, ...)
• etc.

O que todo esse processo faz é permitir que você se concentre no que é bom em estimar: código. A estimativa de tempo é abstraída e encapsulada pelo próprio modelo. Cada modelo foi construído analisando centenas de projetos do mundo real. Você pode até mesmo ajustá-los, ligando seus próprios dados.

Eu tenho muita resistência a esse método, especialmente quando me esqueço de round. "Oh, certo. Isso levará 29,02 horas." Tudo somado, tem sido o método mais preciso para mim. Meus colegas podem discordar do uso do SLOC o quanto quiserem, mas não podem debater a ciência usada para criar essa técnica.

Como único desenvolvedor, usei-o, mas tive problemas com meu ego no começo. Eu não queria reconhecer que minhas habilidades em C ++ eram mais fracas do que eu pensava na época. Isso me fez subestimar. Depois que eu liguei meus níveis de habilidade real, tudo se alinhava. Lição aprendida.

Outra técnica que uso no topo (algumas ferramentas fazem isso para você) é a técnica das três estimativas, que é amplamente aplicável em todos os lugares. Você pega o pior caso, o melhor caso e o caso esperado e calcula a média deles juntos. Peso seu esperado por um fator de quatro. Então ... "(pior + melhor + esperado * 4) / 6" É uma ajuda moderada para o risco, mas na verdade é um truque psicológico para obter estimativas precisas mais rapidamente ... em favor do seu instinto.

Superestime e divida o projeto em várias pequenas tarefas que podem ser divididas em 15 minutos, 30 minutos, 1 hora, 2 horas, 4 horas ou 8 horas; Se não couber em 8 horas, divida a tarefa novamente. Isso deve dar uma boa idéia de quanto tempo isso deve levar.

Estimar projetos de software é um tiro no escuro. Não deixe ninguém te dizer o contrário. Os gerentes de projeto, especialmente os gerentes de projetos não técnicos, geralmente não percebem isso.

Embora existam muitas diretrizes e fórmulas lá fora, eu nunca encontrei uma maneira melhor do que apenas pegar um projeto anterior, aplicar algum tipo de fator de escala e usar isso como uma linha de base. Por exemplo, meu último projeto tinha 6 meses e meu próximo tem regras mais simples, mas muito mais migração de dados e mais uma interface externa, então acho que é cerca de 50% mais difícil = 9 meses.

Algumas dicas:

Há muitas boas sugestões sobre como fazer a estimativa, mas todas levam tempo. Para que você tenha tempo para fazer uma estimativa corretamente, eu uso essa tática.

Quando me pedem uma estimativa sem ter tempo para descobrir quanto tempo o projeto levará, sempre volto e dou uma estimativa que sei que a gerência não vai gostar. Imagine que você acha que um projeto levará cerca de três meses. Eu vou dizer algo como 6 meses a um ano. Eles geralmente me dão um olhar ruim e eu digo: "Bem, se você me deixar fazer uma estimativa real, eu provavelmente posso lhe dar uma estimativa melhor."

Além disso, NUNCA diga que um projeto levará de 2 a 3 meses! Você está pensando que o projeto levará três meses e seu gerente ouvirá apenas dois meses.

Estou atrasado no jogo para esta questão, mas o seu comentário foi um acorde: você é sempre solicitado a fazer estimativas no local - sem tempo para pesquisar, detalhar, planejar, consultar o equipe, etc. Apenas um número com o seu intestino - e provavelmente um número que voltará para assombrá-lo.

Isso acontece - freqüentemente. O truque é confiar em seus instintos, mas também compensar seus erros.

Em outras palavras, dê o seu melhor palpite e multiplique o tempo por algum fator que ajude a anular a falta de informação, o tempo para fazer uma análise adequada e a eterna arrogância e otimismo.

Por exemplo, se suas últimas 3 estimativas foram:

• 1 dia
• 2 semanas
• 3 meses

e o tempo real foi:

• 4 dias
• 2 meses
• 1 ano

então, claramente, seu "coeficiente de otimismo" é 4.

À medida que você melhora a estimativa - ou evita estimar, conforme o caso -, esse coeficiente deve cair para baixo. Mas pode voltar a subir por um tempo se você começar a trabalhar em um domínio, tecnologia ou equipe diferente, etc. Por isso, é importante sempre rastreá-lo, pelo menos mentalmente.

Para uma área novinha em folha com pouca informação e tecnologia desconhecida em circunstâncias extremas - como consertar o hyperdrive em um cruzador de batalha Hutt no meio de um tiroteio quando você não pode ler Huttese - é melhor empregar o Scotty Rule : vezes dois e adicione alguns ^*

[ ^* um amigo meu insiste que a verdadeira Regra de Estimação de Montgomery Scott é pegar sua melhor estimativa, arredondar para cima, multiplicar por 10 e mudar para a próxima ordem mais alta de unidades. Portanto, se você acha que uma tarefa levará 2,5 horas, arredonda para 3 horas, multiplica por 10 para obter 30 horas e muda as unidades de horas para dias para obter a estimativa final de 30 dias.]

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 a minha equipe usa, melhor suas avaliações (além disso, é divertido!), mas é preciso mais de uma pessoa que não pode ajudar muito.

Eu usei muitos, mas talvez algo como a ferramenta de estimativa de 3 pontos possa valer a pena.

Ferramenta de estimativa de 3 pontos

Com isso, você pega o Otimista (se tudo foi planejado), Provavelmente (quanto tempo você acha que o projeto vai levar) e o Pessimista (mais tempo você acha que pode ser necessário)

Você pode calcular uma média e adicionar uma média ponderada às peças, se necessário. Quanto mais você quebrar seu projeto, melhor será o valor que você pode obter.

Como um começo rápido, você poderia ter algo como isto como seus cabeçalhos principais, com qualquer número de tarefas neles, com lá avaliações Otimistas, Mais Prováveis e Pessimistas

• Pesquisa
• Especificação de função
• Especificação de design
• Codificação
• Teste
• Implantação

É claro que você pode querer expandir alguns cabeçalhos ou adicionar você mesmo.

Normalmente há uma função de penalidade assimétrica aqui, para o gerente e a equipe de desenvolvimento. Isso é na verdade parte da lógica do preenchimento.

Atrasado: Se as pessoas disserem a seus chefes que esperem Tsched, e em vez disso ele for maior que Tsched, os horários serão cancelados e as pessoas serão culpadas por várias coisas e, no pior caso, as vendas serão perdidas ou os clientes desaparecerão ou os projetos serão recuperados. organizada ou lixeira.

Early: Se o T verdadeiro for menor que Tsched, então, dê um tapinha nas costas do time de desenvolvimento e fique ocupado no próximo projeto. Ou - Deus me livre - refatorie e melhore a qualidade do código (não, não faça isso ... faça o próximo projeto. Trabalho de trabalho).

Você deve ouvir o podcast do stackoverflow e ouvir o processo de estimativa de Jeff Atwood para este site em que você está agora. Ele era um pouco agressivo demais e Joel o convocou.

Estes são bons pontos a serem considerados, mas você precisará eliminar coisas que não funcionam ou se aplicam. Revise as sugestões depois de fazer mais estimativas e veja se alguma coisa se destaca como mais aplicável depois de usar essas sugestões.

Acompanhar o que você calculou e, em seguida, quanto tempo isso realmente levou é uma ótima idéia, e muitas vezes não é seguido, porque você precisa passar para o próximo "fogo". Porém, você só pode melhorar a estimativa se gastar o tempo para determinar como sua estimativa estava desativada e descobrir o que mudar para a próxima vez.

Você também mencionou que está trabalhando com o código existente. Conforme você faz mais alterações, sugiro aumentar o tempo necessário para testar. Você precisa ter certeza de que a mudança funciona e você precisa ter certeza de que a outra funcionalidade do código ainda funciona. Se os seus testes forem de alguma forma automatizados, talvez seja necessário alterar o teste para testar essa alteração no software. Se os seus testes são manuais, então você precisa ter certeza de testar o que você mudou (adicionando ou mudando como você testou anteriormente).

Boa sorte.

Você pode tentar dividi-lo em tarefas menores e estimar cada tarefa. Por exemplo, você pode dividi-lo em algo como:

1. Instalar o SharePoint
2. Criar uma web part de prova de conceito.
3. Implantar código personalizado no SharePoint.

Estas são tarefas para as quais você deve encontrar tutoriais e, ao lê-las, você pode entender quanto tempo levará (dica: a instalação do SharePoint é longa!).

Além disso, eu concordo que é difícil estimar tarefas que você não tenha feito antes, então tente dividi-las em tarefas que são pequenas e comparáveis (no escopo) a coisas que você fez no passado. / p>     

Se alguém na empresa tiver feito coisas semelhantes, grite sobre a parede do cubo e veja o que eles pensam. Compare isso com quanto tempo isso realmente leva você, então quando você tiver outra tarefa, pergunte ao mesmo desenvolvedor quanto tempo levaria. Multiplique esse resultado pela diferença que você fez na tarefa inicial. Realmente não há uma boa maneira de estimar novas tarefas sem uma linha de base histórica, mas pelo menos dessa maneira, você se esforçará para basear sua estimativa em algum tipo de fato.