Como responder quando lhe pedem uma estimativa?

Nós, como programadores, somos constantemente perguntados 'Quanto tempo vai demorar'?

E você sabe, a situação é quase sempre assim:

• Os requisitos não são claros. Ninguém fez uma análise aprofundada de todas as implicações.
• O novo recurso provavelmente quebrará algumas suposições feitas no seu código e você começará a pensar imediatamente em todas as coisas que talvez precise refatorar.
• Você tem outras coisas a fazer em tarefas passadas e precisará elaborar uma estimativa que leve em conta esse outro trabalho.
• A definição de 'pronto' provavelmente não é clara: quando será feito? 'Concluído' como acabado de codificá-lo ou 'pronto' como em "os usuários o estão usando"?
• Não importa o quão consciente você esteja de todas essas coisas, às vezes o seu "orgulho do programador" faz com que você aceite / aceite tempos mais curtos do que você supõe que possa levar. Especialmente quando você sente a pressão dos prazos e das expectativas da gerência.

Muitos desses são problemas organizacionais ou culturais que não são simples e fáceis de resolver, mas no final a realidade é que você está sendo solicitado para uma estimativa e eles esperam que você dê uma resposta razoável. Faz parte do seu trabalho. Você não pode simplesmente dizer: eu não sei.

Como resultado, sempre acabo dando estimativas que mais tarde percebo que não posso cumprir. Isso já aconteceu inúmeras vezes, e eu sempre prometo que não acontecerá novamente. Mas sim.

Qual é o seu processo pessoal para decidir e fornecer uma estimativa? Que técnicas você achou úteis?

Do Programador Pragmático: Do ​​Journeyman ao Master :

O que dizer quando solicitada uma estimativa

Você diz "eu voltarei para você".

Você quase sempre obtém melhores resultados se atrasar o processo e passar algum tempo executando as etapas descritas nesta seção. As estimativas fornecidas na máquina de café voltarão (como o café) para assombrá-lo.

Na seção, os autores recomendam o seguinte processo:

• Determine a precisão que você precisa. Com base na duração, você pode citar a estimativa com precisão diferente. Dizer "5 a 6 meses" é diferente de dizer "150 dias". Se você entrar um pouco no sétimo mês, ainda será bem preciso. Mas se você entrar no dia 180 ou 210, não muito.
• Certifique-se de entender o que está sendo solicitado. Determine o escopo do problema.
• Modele o sistema. Um modelo pode ser um modelo mental, diagramas ou registros de dados existentes. Decomponha esse modelo e construa estimativas a partir dos componentes. Atribua valores e intervalos de erro (+/-) a cada valor.
• Calcule a estimativa com base no seu modelo.
• Acompanhe suas estimativas. Registre informações sobre o problema que você está estimando, sua estimativa e os valores reais.
• Outras coisas a incluir em sua estimativa são o desenvolvimento e documentação de requisitos ou alterações nas especificações de requisitos, criação ou atualização de documentos e especificações de projeto, testes (unidade, integração e aceitação), criação ou atualização de manuais do usuário ou READMEs com as alterações. Se duas ou mais pessoas trabalhando juntas, há uma sobrecarga de comunicação (telefonemas, e-mails, reuniões) e a combinação do código-fonte. Se for uma tarefa longa, leve em consideração coisas como outro trabalho, folga (férias, férias, licença médica), reuniões e outras tarefas gerais ao escolher uma data de entrega.

A estimativa de software é a tarefa única mais difícil em engenharia de software - sendo a segunda a elicitação de requisitos.

Existem muitas táticas para criá-las, todas baseadas na obtenção de bons requisitos primeiro. Mas quando suas costas estão contra a parede e elas se recusam a fornecer melhores detalhes, Fake It:

1. Dê uma boa olhada nos requisitos que você possui.
2. Faça suposições para preencher as lacunas com base no seu melhor palpite sobre o que eles querem
3. Anote todas as suas suposições
4. Faça com que se sentem, leiam e concordem com suas suposições (ou, se tiver sorte, peça que desistam e forneçam requisitos reais).
5. Agora você tem requisitos detalhados dos quais pode estimar.

É como minha mãe costumava ameaçar quando eu era criança "Apresse-se e escolha algumas roupas, ou eu as escolherei para você!"

Fiz um desenvolvimento para um cara que era muito inflexível em querer estimativas precisas. O que decidimos, que funcionou muito bem, foi o seguinte:

• Fiz cobrança por todo o tempo que gastei estimando. Chegou a cerca de 20 a 25% do que faturei.
• Eu fiz um exame extremamente detalhado das tarefas. Nenhum tiro do quadril. Entrei no código, descobri quais linhas precisavam ser alteradas, quais outras partes do programa afetariam, quantos testes eu teria que fazer para garantir que as coisas ainda funcionassem. Eu estimaria cada peça em unidades de 0,1 hora (6 minutos).
• Enviei a ele minha estimativa para cada tarefa, juntamente com o detalhamento detalhado.

20 a 25% do faturamento parece muito.

Mas ele me pedia para fazer a mudança XYZ, pensando que levaria cerca de 2 horas. Em uma hora de estimativa detalhada, eu determinaria que levaria 8,5 horas. Então, ele decidia se valia 8,5 horas de pagamento. Caso contrário, ele economizou 7,5 horas sobre o que teria custado a ele se eu o tivesse feito sem uma estimativa.

E se ele se quiser investir os 8,5 horas, o detalhe trabalho que fiz para a estimativa era de trabalho que eu teria que fazer de qualquer maneira.

Eu descobri que com esse método eu era capaz de executar a maioria das tarefas no prazo ou até mais cedo, sem ter que superestimar demais. Como o tempo foi dividido tão minuciosamente, eu poderia dizer desde cedo se estava escorregando. Se eu batesse em obstáculos para que, depois de três horas, pudesse dizer que minha tarefa de 8,5 horas levaria 12, eu poderia falar com ele antes que passasse mais tempo para que ele pudesse reavaliar e puxar o recurso se estivesse preocupado com o custo. .

Ele era níquel e escuro? Não, eu olhei para ele como o deixando aplicar seu dinheiro onde ele viu o maior benefício. E fiquei feliz em ter experiência em estimar, nas quais sempre fui péssima.

Muitas vezes nos pedem uma "estimativa aproximada" durante as reuniões em que recebemos idéias muito amplas e variadas sobre o que eles gostariam de fazer. Eu sempre digo: "se você quer uma resposta hoje, é um ano e um milhão de dólares. Se você gostaria de me dar muito mais detalhes e algum tempo para analisá-los, posso refinar esses números para você".

Eles quase sempre entendem o ponto.

Depende do objetivo da estimativa.

Para uma estimativa inicial de alto nível para um caso de negócios, as principais coisas são:

1. Rapidez. Qualquer que seja o método que você use, ele precisa ser rápido. O ponto principal é que as partes interessadas não têm certeza se vale a pena fazer o projeto - e é por isso que precisam dos números para o caso de negócios. Se o caso de negócios fosse sólido, eles não precisariam de suas estimativas. A maior parte desses projetos não vai adiante, por isso é importante que não seja gasto muito esforço para fornecer a estimativa.
2. Dê um intervalo. Faça amplo. Você não teve tempo para analisar requisitos, realizar um workshop com as partes interessadas, validar suposições. Uma ampla variedade informa ao destinatário da estimativa "Os projetos de software são naturalmente complexos e arriscados - se você deseja uma estimativa adequada, precisa me fornecer mais detalhes e mais tempo". O problema de fornecer um número único ou um intervalo estreito é que isso o leva a um canto, definindo expectativas antes que qualquer análise real seja feita.

Acho a melhor técnica para escolher um projeto comparável que "pareça" o mesmo. "Sensação" é completamente subjetivo - mas com esse tipo de estimativa, minha experiência me diz que você não encontrará medidas objetivas. Em seguida, forneça uma ampla variedade. Eu li alguns livros que dizem que um intervalo de -50% a + 100% é bom, mas depende de muitos fatores.

Para uma estimativa detalhada e de baixo nível:

1. Você precisa de uma linha de base. Se a linha de base não for estável, a estimativa não terá sentido.
2. De baixo para cima é o melhor. Obtenha uma análise detalhada do trabalho, faça uma estimativa de cada componente e enrole em um número maior. Acho que planejar o poker é uma ótima técnica aqui.
3. Contingência de documentos. Deixe claro onde qualquer contingência (se houver) é adicionada. É adicionado a cada item de linha? Ou para toda a estimativa? Ou a riscos específicos? Ou não existe?
4. Declare suas suposições. Valide o maior número possível, de acordo com o prazo.
5. Declare explicitamente o que está incluído e excluído na estimativa. Por exemplo, a revisão está incluída? Atrasos técnicos estão incluídos?

Alguns conselhos do lado sombrio de quem aprendeu da maneira mais difícil.

Os requisitos não são claros. Ninguém fez uma análise aprofundada de todas as implicações.

Não faça uma estimativa neste momento. Não se estima quantos soldados são necessários para vencer uma batalha sem nenhuma pista sobre o número de inimigos. A estimativa é feita após a verificação. Isso é a menos que você já tenha lutado contra esse inimigo.

O novo recurso provavelmente quebrará algumas suposições feitas no seu código e você começará a pensar imediatamente em todas as coisas que talvez precise refatorar.

É sua responsabilidade levar em consideração, a menos que você espere que outros tenham conhecimentos sobre esta área.

Você tem outras coisas a fazer em tarefas passadas e precisará elaborar uma estimativa que leve em conta esse outro trabalho.

O mesmo que acima, mesmo para o trabalho imprevisto que é criado por um colega de equipe slob próximo a você com um procedimento de teste quase inexistente que faz com que seu código ocorra, que você não pode prever perfeitamente com antecedência. É uma previsão do tempo.

A definição de 'pronto' provavelmente não é clara: quando será feito? 'Concluído' como acabado de codificá-lo ou 'pronto' como em "os usuários o estão usando"?

Entenda o requisito de usuário final aqui, pense como um usuário. Não faça o que seus colegas fazem se estimarem que algo deve ser "feito" apenas porque alguma funcionalidade básica com um fluxo de trabalho de barebones que nenhum usuário pode tolerar é o que eles consideram "feito" . Pense nisso do ponto de vista do usuário, porque isso é tudo que o cliente que você está fazendo a estimativa normalmente entenderá. Faça uma estimativa para os requisitos completos do usuário final, não para os requisitos técnicos do barebone. E saiba que seus clientes que solicitam estimativas serão totalmente imprecisos aqui sobre como eles expressam as coisas e entendem os aspectos técnicos do que você diz.

Não importa o quão consciente você esteja de todas essas coisas, às vezes o seu "orgulho do programador" faz com que você aceite / aceite tempos mais curtos do que você supõe que possa levar. Especialmente quando você sente a pressão dos prazos e das expectativas da gerência.

Não faça isso! Você parece um trabalhador motivado e possivelmente um que cede facilmente à coerção.

O problema aqui é o seguinte: digamos que você e Joe fizeram estimativas de tempo para a mesma tarefa (mas entre dois funcionários separados, desconhecendo as duas estimativas ao mesmo tempo). Você estima valentemente "uma semana" . Tudo bem, você pensa que trabalha mais de 100 horas por semana, horas extras não remuneradas. Agora você está três dias atrasado.

Enquanto isso, Joe estima 5 meses. Você acha que isso é ridículo, você pode conseguir isso em uma semana. Quanto Joe trabalha? 10 horas por semana? ... exceto que ele termina no prazo em exatamente 5 meses.

Adivinha quem é percebido como o imbecil? Isso mesmo, você. Joe parece ser um grande trabalhador, você não parece confiável agora. Não importa tanto que você possa ter conseguido um resultado ainda melhor em ~ 7% do tempo que Joe levou. O que importa é que você tinha três dias de folga de uma estimativa de uma semana.

Nunca erre no lado da estimativa mais apertada. Erre no lado da estimativa mais flexível. Há uma reputação a ser construída em sua empresa e ela não se baseará no comprimento de suas estimativas quase tanto quanto na precisão de suas estimativas. É fácil ser preciso com uma estimativa muito longa, você só tem mais tempo para trabalhar no problema e resolvê-lo melhor. Uma estimativa muito curta não deixa espaço para respirar, ou você a encontra desesperadamente ou está ferrado.

"Duas semanas!"

A sério. Minha primeira estimativa é sempre de duas semanas. Porque eu tenho algum tipo de bloqueio mental bizarro que me faz pensar que tudo soa como se fosse duas semanas.

Eu tento contornar isso, realmente penso em quanto tempo acho que algo levará, tentando identificar todos os possíveis pontos de problemas e bits que parecem muito pretos para eu estimar com precisão. E tente reconhecer que, se minha resposta for "Duas semanas!", Provavelmente não consegui.

Praticamente todo bom gerente que aprendi a reconhecer "Duas semanas!" como uma resposta que requer um leve tapinha verbal de cafetão em resposta.

Existe uma entrada de blog que descreve como manter um registro de quão precisas suas estimativas anteriores foram e, da próxima vez que você disser a alguém "daqui a duas semanas", você poderá examinar seu histórico anterior e ver quanto tempo realmente demorou a última vez que você disse "serão duas semanas".

Eu ainda não tentei, mas gostaria de ver como minhas estimativas são precisas.

Depende da organização e como as estimativas são usadas.

Se a estimativa é apenas para fornecer uma idéia geral de quando estará pronta, geralmente posso fazer uma estimativa rápida com base na minha experiência. Muitas vezes, incluirei qualquer incerteza ou variação possível na estimativa, além de como as mudanças podem impactar outras áreas do sistema e a extensão dos testes de regressão necessários.

Se a estimativa for usada para qualquer coisa contratual ou em um cenário em que seja necessário um tempo mais preciso, eu faço uma análise completa do trabalho. Isso é mais trabalhoso e exige uma reflexão mais aprofundada sobre o design e as alterações no sistema, mas é muito mais preciso, especialmente para trabalhos maiores.

Em ambos os casos, a comunicação contínua é fundamental. Se você encontrar algo inesperado, informe-o no momento, em vez de esperar até o prazo. Se os requisitos não estiverem claros, certifique-se de documentar sua compreensão deles e a funcionalidade que planeja entregar. Isso também é útil com quaisquer suposições que você fizer. E, no que diz respeito às prioridades concorrentes, quando um trabalho é superior ao outro, seja claro como isso afetará o cronograma.

Estimativas para quê? Pequenas tarefas ou soluções completas.

O último que eu raramente faço, mas adivinho, adicione um pouco, peça ao gerente para adicionar um pouco e transformá-lo em um intervalo, com uma pequena nota ao lado, afirmando que o acima é um palpite.

Tarefas pequenas - Planejando o poker , achei que funcionou muito bem (não é perfeito, algumas tarefas de 1 ponto demoraram muito mais tempo e outras de 5 pontos levaram minutos, mas tudo fica equilibrado no final).

Apresente um intervalo com base no que você conhece hoje. Use o Cone de incerteza para fornecer o alcance em torno de suas estimativas iniciais.

Toda semana, calcule quanto resta, re-estimar com base no que você sabe. Depois de ter uma amostra suficiente de quanto trabalho você está realizando a cada semana, forneça um intervalo de confiança de 90% para o que resta para dar (geralmente) um intervalo de datas cada vez menor à medida que o projeto avança e a quantidade de trabalho restante (espero ) encolhe.

Confiantemente. Não sei dizer quantas vezes eu estraguei uma reunião inicial com um cliente por não colocar profissionalismo ao fazer uma estimativa. Mesmo se você estiver soprando números do nada - certifique-se de manter sempre algumas estimativas por perto. Dito isto, tome cuidado para não se estimar em um buraco. Coisas diferentes demandam quantidades diferentes de tempo, esforço e recursos para montar. Aqui está uma boa maneira de fazer isso:

Eles: quanto vai custar?

Eu: Depende do que você quer que eu faça. Geralmente, inicio esse tipo de projeto em cerca de US $ X.

Às vezes, a estimativa se torna um enorme desafio para você e sua equipe, especialmente quando estamos falando sobre estimativa de projeto de software.

Uma vez que decidimos compartilhar nossa experiência e nosso conhecimento sobre o processo de estimativa de software e definimos quatro tipos distintos de estimativa :

• valor aproximado
• estimativa de serviço
• estimativa de recursos
• estimativa componencial

Claro, esses tipos são distintos. O estádio é o que costuma ser chamado de "estimativa de estimativa". Portanto, é um número ou intervalo aproximado que fornece uma idéia geral do custo e pode ajudar um possível cliente a decidir se gostaria de levar a discussão adiante.

Como regra, os clientes precisam de uma estimativa aproximada no início do projeto. E o nosso conselho é: a discussão do projeto e o fornecimento de valores aproximados devem ser apenas passos importantes para receber a estimativa de componente (que é flexível, pode-se usar a estimativa de tipo de componente para todo o processo de desenvolvimento. Não há necessidade de re-estimar do zero quando você deseja adicionar, remover ou substituir recursos, serviços etc).

Todos devem ter em mente os riscos que advêm da estimativa de desenvolvimento de software: subestimação, superestimação, cenário de falha épica total etc.

Você pode ler mais em nosso blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Espero que esta informação o ajude!

Eu sempre acabo dando estimativas que depois percebo que não posso cumprir. Isso já aconteceu inúmeras vezes, e eu sempre prometo que não acontecerá novamente.

Parece que você está sendo solicitado por um compromisso, não por uma estimativa. Essas são coisas diferentes, mas se você puder gerenciar compromissos com segurança, isso realmente ajudará sua credibilidade e carreira.

Alguns conselhos baseados nos meus 10 anos de experiência:

• Sempre forneça um intervalo (ou seja, limite inferior e superior). Isso comunicará seu nível de incerteza
• Se você tiver uma incerteza muito grande, peça um adiamento (por exemplo, 1 dia para fazer a análise e forneça um intervalo mais restrito)
• Se a tarefa for muito grande, divida-a e forneça um intervalo para cada peça

Primeiro, se alguma tarefa fosse atribuída a mim, eu a dividiria em subtarefas. Eu estimaria o tempo de cada subtarefa e, provavelmente, com subtarefas, seria capaz de encontrar a área problemática e, portanto, seria capaz de prever quanto tempo duraria. levar até certo ponto.

Mas todo o planejamento ainda ajudaria apenas até certo ponto. Somente quando você começa a codificar, você pode encontrar os problemas exatos

Se você faz muitos projetos para o mesmo chefe ou cliente, pode tentar estimar em amplos traços de complexidade, em vez de semanas ou meses, possivelmente em tamanhos de camiseta. Identifique alguns projetos anteriores e atribua a eles os tamanhos S, M, L, XL.

E então pergunte-se: a qual projeto isso parece semelhante no escopo? E então, em vez de responder com "2 meses", você pode responder com "soa como um L para mim" (ou qualquer que seja sua calibração para o projeto).

Isso é muito fácil de entender e também é claro que há muita incerteza nessas suposições.

Então, quando os requisitos mudam, você pode dizer "essa mudança faz parecer mais um XL".

Um pouco tarde, mas quando eu estava no exército, fomos instruídos a usar o PERT para determinar estimativas. Requer alguma experiência em seu campo e a tarefa em questão. Foi surpreendentemente preciso ao determinar o tempo estimado de conclusão ao manter e reparar dispositivos eletrônicos (rádios complexos e equipamentos de comunicação via satélite), onde qualquer coisa pode estar errada ou encontrada, e precisando ser corrigida durante a manutenção de rotina. As estimativas foram importantes porque outras unidades podem ficar inoperantes até receber de volta seus equipamentos de comunicação. Uma que eu usei é esta Calculadora PERT Online Grátis