Como estimar uma tarefa de programação se você não tem experiência nela [fechado]

Estou tendo dificuldades com a gerência, pedindo estimativas sobre tarefas de programação que usam controles de terceiros com os quais não tenho experiência anterior.

Eu definitivamente entendo por que eles querem as estimativas, mas eu sinto que qualquer estimativa que eu der será a) muito curta e me fará parecer ruim ou b) muito longa e me fará parecer ruim.

Que estimativa ou resposta eu poderia dar à administração para tirá-los de minhas costas e continuar fazendo meu trabalho!

A melhor resposta que você pode dar é pedir tempo para fazer um protótipo rápido para permitir uma estimativa mais precisa. Sem alguma experiência com uma ferramenta ou um problema, qualquer estimativa que você dê é essencialmente sem sentido.

Como um aparte, raramente há um problema em fazer uma estimativa muito longa. Ocorrem problemas inesperados, as prioridades mudam e os requisitos são "atualizados". Mesmo se você não usar todo o tempo que pediu, você terá mais tempo de testes, ou poderá lançar "mais cedo".

Sempre fui otimista demais em minhas estimativas, e isso pode colocar muito estresse em sua vida, especialmente quando você é um jovem programador, sem experiência e autoconfiança para contar verdades desagradáveis ​​aos chefes.

Vou te contar um segredo. Mesmo que você seja um especialista nessa tecnologia, sua estimativa provavelmente será altamente imprecisa. É a natureza da besta ao fazer algo que é inerentemente uma tarefa de P&D. Infelizmente, a administração muitas vezes tenta aplicar um modelo de manufatura e exige estimativas precisas. Para ilustrar meu ponto, considere a dificuldade em estimar com precisão os dois esforços a seguir:

A) Fabrique outros guarda-chuvas de 11K que são exatamente iguais aos 2K que você produziu no mês passado. B) Projete um novo tipo de guarda-chuva e construa o primeiro.

O desenvolvimento de software é B, mas eles estão pedindo uma estimativa assumindo A.

O melhor que você pode fazer é dividir a tarefa nas menores partes possíveis (não mais do que 1/2 dia cada) e, em seguida, triplicar o número final que você encontrar. (Método Spolsky)

Como alternativa, Steve McConnell tem um livro inteiro (possivelmente vários) sobre esse aspecto da engenharia de software. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (e outros) fala sobre o cone da incerteza . Basicamente, você fornece uma estimativa mais ou menos assim:

O trabalho levará entre 3 e 9 semanas, sendo 4 semanas o mais provável.

Conforme o projeto avança, você pode refinar sua estimativa. À medida que você faz mais trabalho e entende melhor o esforço necessário, você pode refinar sua estimativa para ser mais precisa.

Funcionou para mim, mas pode exigir algum esforço para que outras partes interessadas no projeto entendam o processo.

Você pode querer considerar fornecer uma estimativa e um nível de confiança, ou seja, é 50/50 que levará de 3 a 6 meses ou de 6 a 9 meses ou 75% de chance de ser concluído em 9 meses e 90% de que você o fará feito em um ano.

Outra coisa que você pode considerar é usar a abordagem da " sabedoria das multidões ". Pergunte a 25-50 pessoas quanto tempo elas acham que vai demorar e faça a média de suas estimativas. O Planning Poker de Mike Cohn é, eu acho, muito semelhante a este, embora seja difícil de planejar com apenas um desenvolvedor.

Divida sua estimativa em:

• Conhecidos conhecidos ; quanto tempo vai demorar para fazer o que você sabe fazer. Você deve ser capaz de fornecer essa estimativa com alto grau de confiança.
• Desconhecidos conhecidos ; quanto tempo você acha que vai demorar para fazer o que você não sabe fazer. Você pode usar um método como o dacracot para fornecer diferentes níveis de confiança nesta estimativa.
• Desconhecidos desconhecidos ; este é o buraco negro em tempo real. Essas são as coisas que surgem nos momentos mais inoportunos e te mordem na bunda. Forneça um intervalo para a estimativa com justificativa com base nos riscos que você prevê.

Ofereça-se para ajustar a estimativa e certos marcos ao longo do caminho. Quaisquer incógnitas desconhecidas se tornarão incógnitas conhecidas, as incógnitas conhecidas devem se tornar conhecidas à medida que você ganha experiência, e a estimativa de seus conhecidos conhecidos pode ser ajustada com base no progresso até o momento. Você pode fazer uma estimativa inicial e, em seguida, reavaliar quando tiver feito cerca de 25%, novamente em 50% e novamente em 85%. Em cada etapa, sua estimativa deve começar a convergir para o tempo real que as tarefas levarão.

Eu uso um sistema de rotulagem definido para minhas estimativas ... classe A, classe B e classe C.

A estimativa de classe C é a primeira que eles obtêm. É declarado abertamente como mais ou menos 50% devido a incógnitas. Se eles querem que eu continue dando a eles a classe B, preciso de dinheiro para pesquisar.

A classe B é mais ou menos 25%. Às vezes isso é bom o suficiente e eles me dão dinheiro para construir. Se não, menos dinheiro e mais pesquisas.

A classe A é mais ou menos 10%, o final e vai ou não vai. Se for uma tentativa e eu me desviar muito da estimativa, confesso muitas vezes e cedo.

Acho que se você remover a frase "que estão utilizando controles de terceiros com os quais não tenho experiência anterior", poderá ter uma descrição melhor do seu problema maior.

Se o "Agile" nos ensinou alguma coisa, é que, se a administração espera que você, continuamente, avalie os projetos dessa maneira, e você "ficará mal" se disser que não pode ser fornecido porque você não tem informações suficientes, você está na estrada para FALHAR.

O maior problema serão as questões sobre as quais você não tem controle e que ainda não identificou. Quantas vezes você olhou para trás e disse a si mesmo "Bem, acertei minha estimativa com o botão direito - na terceira tentativa, depois de descobrir isso ... e que eu precisava da versão ... e que o dba estaria ligado férias por uma semana e que o gerente do projeto precisaria de mim por ... por uma semana e que minha esposa estava grávida e ... ”.

Eu tentaria muito dizer: "Posso identificar os fatores de risco críticos e apresentar uma lista de verificação de resultados para testá-los em xx dias. Nesse ponto, darei outra estimativa incremental."

E seria muito bom se você pudesse sugerir que eles deveriam "Por favor, insista que eu nunca tente dar a você uma estimativa confiável desse tipo no futuro. Demita-me se eu tentar."

(Exagerado, mas apenas ligeiramente.)

Nem tente fazer uma estimativa. Não há como sua estimativa estar correta. Afinal, é apenas uma estimativa.

Em vez disso, recomendo que você divida o recurso em pequenas partes (não mais do que, digamos, 1-2 dias) e tente entregar essas partes como código funcional, completo, testável e valioso para o cliente / gerente. Dessa forma, ele verá por si mesmo o seu progresso no dia a dia. Isso também significa que ele pode, de fato, decidir interromper o desenvolvimento quando estiver satisfeito e considerá-lo concluído, mesmo que não tenha atingido todos os objetivos.

Dê uma olhada nas práticas ágeis "Planejamento de Release" e "Planejamento de Iteração" para obter informações mais detalhadas sobre essa abordagem.

Lembre-se de que se você pedir uma estimativa de tempo maior, mas chegar dentro do prazo, parece muito melhor do que subestimar e ter que pedir uma prorrogação.

Eu tentaria simular um protótipo para que você tivesse uma ideia melhor do tempo que isso levaria. Seja honesto com sua gerência para que eles possam fazer um orçamento para atrasos inesperados na curva de aprendizado.

EDIT: Você também pode ver se consegue um prazo mais "iterativo". Em "Pensamento e aprendizagem pragmáticos", Andy Hunt afirma que as pessoas são especialistas em projetos mais perto do final do projeto e com menos conhecimento no início. Não faz muito sentido fazer todo o seu design e estimativa de tempo logo no início, quando todos têm menos conhecimento sobre o projeto. Se você "iterar" os prazos e resolver o problema em partes, terá mais sucesso.

Muita estimativa precisa é autoconhecimento. Se você escreveu muito código, se teve que aprender muito sobre APIs, você começa a ter uma ideia de questões como:

• Quanto tempo levo para aprender uma nova API?
• Quanto tempo levo para aprender um novo idioma?
• Quanto tempo levo para aprender um novo conjunto de ferramentas (compilador / vinculador / IDE)?
• Quanto tempo levo para implementar uma tarefa típica?
• Quanto tempo levo para testar meu trabalho?
• Quanto tempo levo para implantar meu trabalho?

Ao longo disso, você deve ter uma noção de coisas como:

• Quantos bugs típicos você cria e como eles são categorizados (ou seja, fácil, difícil, impossível)
• Quantas complicações são introduzidas (ou seja, necessidade de refatorar devido à falta de API de terceiros ou API com bugs; necessidade de redesenho devido a mal-entendido de capacidade; ferramentas / processos de construção não padrão)
• Quanto tempo é perdido devido a interrupções / problemas externos

Com base em todas essas coisas, você será capaz de desenvolver uma noção de quanto tempo algo levará e ser capaz de declarar suas suposições ("Presumindo que a API é sã ..."), mesmo em face de informações lamentavelmente incompletas.

Faça uma estimativa de quanto tempo você precisa para aprender o suficiente para fazer uma estimativa melhor, por exemplo, "Não sei: nunca trabalhei com isso antes. Provavelmente, vou demorar para inserir sua estimativa aqui para descobrir o que você precisa aprender sobre isso, o que eu precisaria saber antes de dar uma boa estimativa de como usar isso para terminar seu projeto . "

Quando estou programando, sempre peguei o que realmente pensei que seria necessário e multipliquei isso por 3 para fornecer uma estimativa. Se eu acho que posso fazer um trabalho em 1 semana, digo ao cliente que vai demorar 3 - se eu acho que vai realmente levar 3 semanas, digo ao cliente 9 semanas.

Ao fazer isso, eu me proponho a "cumprir a promessa, entregar mais" - se você conseguir fazer isso, sua vida será muito melhor e seus clientes ficarão extremamente felizes.

No seu caso, você certamente desejará obter pelo menos ALGUM conhecimento do que está investindo antes de fornecer uma estimativa. Talvez você até precise fornecer uma estimativa de quanto tempo levará para fornecer uma estimativa. Multiplicar por 3 mantém os clientes satisfeitos.

Divida-o em coisas com as quais você tenha alguma experiência. O ato de cortá-lo lhe dará uma ideia melhor sobre o que você sabe e o que não sabe.

Uma vez que as peças são pequenas o suficiente para que possam ser vistas como tarefas definidas individualmente, algumas delas serão totalmente inestimáveis. Para esses, crie primeiro o protótipo ou apenas reserve um tempo razoável, dependendo do tamanho da peça. Se você está descobrindo que tem pedaços não estimáveis ​​maiores do que 2 a 4 semanas de trabalho, volte a cortá-los primeiro.

Eventualmente, você chegará a algumas soluções tecnológicas muito estranhas (que você acha que deveriam funcionar, mas não tenho certeza), e muito trabalho a ser feito para fazer backup disso, uma vez que funcione. Haverá alguns pedaços de design faltando, para os quais é melhor escolher alguma biblioteca bem conhecida ou um algoritmo muito simples para a versão inicial.

Se você não consegue dividir as tarefas, então você deve contratar alguém com experiência suficiente que possa (já que sua falta de experiência irá persegui-lo de outras maneiras também). Se você não pode contratar alguém, então você deve apenas negociar por um longo período aleatoriamente (6 meses a 2 anos) e ir direto para um protótipo bagunçado (até que você tenha conseguido dar a si mesmo experiência suficiente para saber o que é certo e o que é errado). Mas, se você acabar se debatendo, é importante não se enganar e pensar que está fazendo da "maneira" certa. Protótipos foram feitos para serem jogados fora. Esperançosamente, quando a contagem regressiva do protótipo for concluída, você estará pronto para construí-lo de verdade.

Paulo.

Você apenas adivinha um número externo e começa a avaliar imediatamente, avisa que informações futuras podem afetar suas estimativas, mas que você as manterá atualizadas.

Ao avaliar, mantenha-os informados - por meio de um documento publicado na web ou atualizações semanais, mas sempre inclua uma "data de término estimada" atualizada e os motivos (se houver) para as extensões.

A maioria dos gerentes deve entender isso - ao pedir datas de término, eles estão realmente dizendo "dê-nos uma ideia de como podemos planejar nossa programação" e "não demore para sempre".

Se você acabar estendendo mais de uma ou duas vezes, reavalie toda a sua programação com base em seus novos conhecimentos que você é péssimo em estimar.

Eu acrescentaria ao que a RB disse, quando me encontro nessa situação, estimo quanto tempo levaria com as ferramentas que conheço, e então dobro essa estimativa para construir alguma curva de aprendizado.

A parte importante é se comunicar com a gestão que a estimativa é um palpite , se pressionar por uma estimativa mais precisa ou se eles tentam - meu Deus - vender -lhe um limite de tempo (certamente isso só vai tomar você 2 dias para construir a Starship Enterprise, você é bom, você é) SEGUE SUAS ARMAS , não comprometa sua estimativa, ou o fato de que ela não é confiável.

Se a gerência substituir você e limitar o tempo da tarefa, por exemplo, "Bem, isso tem que ser feito em 2 dias", mais uma vez diga a eles que essa estimativa é exatamente tão confiável quanto a sua.

Coloque tudo isso por escrito.

Eu lido com estimativa no meu trabalho e é um verdadeiro desafio. Um dos meus maiores desafios é estimar quanto tempo levará um desenvolvedor diferente para realizar uma tarefa sem nenhum conhecimento de quão habilidoso esse desenvolvedor será.

Embora você possa ver algum sucesso inicial com o método "prometido demais, entregue a mais", você descobrirá que, com o tempo, será superado por outras pessoas que seguem a escola de pensamento "prometido demais, cumprido". A falta de precisão voltará a incomodá-lo de qualquer maneira. A precisão está muito ligada à experiência e à limitação do número de incógnitas com a tecnologia.

Uma coisa que eu sugiro é ter uma ideia de que tipo de orçamento sua estimativa estará trabalhando. Se você tem um orçamento pequeno, não enlouqueça com tecnologia desconhecida e se atenha ao que você conhece. Se o seu orçamento for um pouco mais flexível, você poderá experimentar um pouco mais.

Também reconheça que haverá algumas tarefas em que tudo o que você pode fornecer é um Wild Ass Guess (WAG). Para isso, você deve definir um tempo mínimo para sua estimativa e deixar claro que não sabe qual é o máximo. Muitas vezes, esse tipo de estimativa é motivo suficiente para que certos recursos / requisitos sejam eliminados pela gerência.

Essa é uma habilidade indispensável que o gerente de projeto e o programador podem ter (e, claro, podem dominar!). Achei um artigo, Estimating Software Development Tasks Made (um pouco) mais fáceis , que espero ajudar para uma melhor estimativa das tarefas do projeto.

Todas as respostas acima cobriram quase tudo com relação a fazer a estimativa em si.

Uma coisa que eu enfatizaria é manter o controle de sua estimativa (uma pequena planilha do Excel a la Joel, ou mesmo um documento do bloco de notas se for muito simples), e no final de cada dia atualize-o para os números mais precisos que você puder fornecer agora . Mesmo se você não precisar passar isso de volta para seus chefes, mantê-lo atualizado lhe dará uma ideia melhor sobre como as coisas estão progredindo e, mais importante, você terá uma boa noção do motivo pelo qual sua estimativa muda conforme o trabalho avança .

Isso o tornará melhor em fazer estimativas no futuro, tanto para esta tecnologia específica quanto para outras que você não usou antes, simplesmente porque requer que você, em algum nível, perceba quando suas expectativas mudam em intervalos regulares, e descubra por que isso aconteceu .

Estimar quanto tempo algo vai demorar faz parte do seu trabalho. Contanto que seja entendido como uma estimativa em vez de um prazo, você não deve ter nada com que se preocupar. Não há ninguém em melhor posição para fornecer uma estimativa do que a pessoa que irá escrever o código. Se você não puder fornecer uma boa estimativa, você precisa alertar a administração sobre o risco associado à sua estimativa ruim para que eles possam reconsiderar se vale a pena correr o risco na programação contra esses controles desconhecidos de terceiros.

Essa é uma situação muito comum: a necessidade de lidar com o desconhecido. Uma maneira útil de lidar com isso é perceber que, além das tarefas reais de programação, você tem algum aprendizado a fazer - e a gerência deve estar ciente disso.

Quando você está em uma situação como essa, o projeto repentinamente se torna um projeto de P&D e um tempo maior que o normal não fará você ficar mal, já que você está aprendendo e produzindo programas. Não sei o quão rápido você está aprendendo ou quais recursos você tem para lidar com quaisquer problemas que você possa encontrar (Stack Overflow é uma das opções que você tem).

Eu diria que você deve estimar como de costume e depois multiplicar por 1,5 (se você é um aprendiz rápido e tem acesso a recursos para resolver suas questões) ou por 2,5 se você é um aluno médio e depende apenas de si mesmo.

Eu espero que isso ajude!

Faça o seu melhor para dividir a tarefa em partes gerenciáveis. Com alguma sorte, existem tarefas específicas relacionadas ao componente de terceiros envolvido e outras que são menos acopladas (e, portanto, mais fáceis de estimar). Forneça à administração as estimativas divididas e indique onde residem as estimativas mais incertas.

Eu concordo totalmente com quem sugeriu brincar e fazer alguns protótipos. Defina um timebox fixo para a atividade de prototipagem. ("Preciso de dois dias primeiro para tornar esta parte da minha estimativa melhor.")

Você pode dar um intervalo? 40-60 horas, algo assim?

Quanto menores forem as tarefas, mais difícil será, se você puder agrupá-las terá um pouco mais de "desleixo", pois os erros podem se equilibrar no final do projeto.

Olhe para qualquer área em que você tenha experiência e use-a como um guia. "Da última vez que precisei criar um recurso que alterasse o banco de dados, demorei X". Boa sorte.