ti-enxame.com

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ê conceda/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?

665
Sergio Acosta

From O 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.
395
Thomas Owens

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 suas suposições
  4. Faça com que se sentem, leiam e concordem com suas suposições (ou, se tiver sorte, faça com 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 pegue algumas roupas, ou eu vou as escolher para você!"

172
Fishtoaster

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 XYZ de mudança, 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 quis desejar investir as 8,5 horas, o trabalho detalhado que fiz para a estimativa foi o 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. Fiquei contente por ter experiência em estimar, nas quais sempre fui péssimo.

145
Kyralessa

Muitas vezes nos pedem uma "estimativa aproximada" durante as reuniões nas quais 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 fornecer muito mais detalhes e algum tempo para analisá-los, posso refinar esses números para você".

Eles quase sempre entendem o ponto.

65
Walter

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 usado, 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 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 acumule-o 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?
55
darreljnz

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 "concluído". 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 exprimem 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ê conceda/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 por si mesmo 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.

28
user204677

"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 tentar pensar sobre quanto tempo acho que algo levará, tentando identificar todos os possíveis pontos e bits de problemas que parecem muito pretos para que eu possa 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.

18
BlairHippo

Existe um entrada no blog que descreve como manter um registro de quão precisas suas estimativas anteriores foram e, na próxima vez em que você disser a alguém "serão duas semanas", você pode olhar para o seu história anterior e veja quanto tempo realmente levou a última vez em que você disse "serão duas semanas".

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

17
Richard

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 um detalhamento completo 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 uma parte do trabalho é superior à outra, seja claro como isso afetará o cronograma.

11
g .

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.

Pequenas tarefas - Planejando pôquer Eu 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).

9
mlk

Apresente um intervalo com base no que você conhece hoje. Use o cone de incerteza para fornecer o intervalo 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.

7
Paddyslacker

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 uma estimativa 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.

7
Moshe

Às vezes, estimar 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

Naturalmente, esses tipos são distintos. Ballpark é o que é frequentemente chamado de “estimativa de estimativa”. Portanto, é um número ou intervalo aproximado que fornece uma ideia geral de 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 um bom passo para receber estimativa componencial (que é flexível, pode-se usar estimativa de tipo componencial para todo o processo de desenvolvimento, sem 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!

6
Olha

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 uma estimativa. São coisas diferentes, mas se você puder gerenciar os 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 grande incerteza, 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
5
jamesfmackenzie

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 ajudaria apenas até certo ponto. Somente quando você começa a codificar, você pode encontrar os problemas exatos

4
Gopi

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".

1
moritz

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é receberem de volta seus equipamentos de comunicação. Um que eu usei é este Calculadora PERT Online Grátis

0
xtreampb