当要求您做出估算时如何应对？

作为程序员，我们经常被问到“需要多长时间”？

而且，情况几乎总是这样：

• 要求不清楚。没有人对所有含义进行深入分析。
• 新功能可能会破坏您在代码中所做的一些假设，并且您立即开始考虑可能需要重构的所有内容。
• 您从过去的工作中还有其他事情要做，您将不得不做出一个将其他工作考虑在内的估算。
• “完成”的定义可能尚不清楚：何时完成？就像刚刚完成编码一样是“完成”，还是像“用户正在使用它”那样是“完成”？
• 无论您对所有这些事情有多有意识，有时您的“程序员的自尊心”都会使您付出/接受的时间比您最初预期的要短。特别是当您感受到截止日期和管理层期望的压力时。

其中许多是组织上或文化上的问题，这些问题不容易解决，但最终，现实是您被要求提供估计，他们希望您给出合理的答案。这是你工作的一部分。你不能简单地说：我不知道。

结果，我总是最终给出估计，后来我意识到自己无法实现。它发生了无数次，我始终保证不会再发生。但是确实如此。

您确定和提供估算的个人流程是什么？您发现哪些技术有用？

从实用程序员：从旅人到硕士：

要求估价时要说些什么

您说：“我会尽快回复您。”

如果您减慢流程速度并花一些时间来完成我们在本节中介绍的步骤，则几乎总是可以获得更好的结果。咖啡机提供的估算值（像咖啡一样）会再次困扰您。

在本节中，作者建议执行以下过程：

• 确定所需的精度。根据持续时间，您可以用不同的精度引用估算值。说“ 5至6个月”与说“ 150天”不同。如果您稍微推迟到第7个月，那么您还是很准确的。但是，如果您进入第180或210天，就不会那么多。
• 确保您了解所要询问的内容。确定问题的范围。
• 对系统建模。模型可以是心理模型，图表或现有数据记录。分解该模型，并从各个组件建立估计。为每个值分配值和误差范围（+/-）。
• 根据您的模型计算估算值。
• 跟踪您的估计。记录有关您要估计的问题，您的估计和实际值的信息。
• 估算中要包括的其他内容包括：开发和记录需求或对需求规范的更改，创建或更新设计文档和规范，测试（单元，集成和验收），使用更改创建或更新用户手册或自述文件。如果两个或两个以上的人一起工作，则将产生通信（电话，电子邮件，会议）和合并源代码的开销。如果任务很长，请在选择交货日期时考虑其他工作，休假（节假日，假期，病假），会议和其他头顶任务。

软件评估是软件工程中最困难的一项任务，其次是需求确定。

创建策略有很多策略，所有策略都基于首先获得良好的需求。但是当您的后背靠在墙上并且他们拒绝为您提供更多详细信息时，请使用Fake It：

1. 好好看一下您的要求。
2. 根据您对他们想要什么的最佳猜测做出假设以填补空白
3. 写下所有假设
4. 让他们坐下来，阅读并同意您的假设（或者，如果幸运的话，让他们屈服并给您真正的要求）。
5. 现在，您有了可以估算的详细要求。

就像我小时候妈妈曾经威胁说：“快点挑些衣服，不然我帮你挑！”

我为一个坚决想要准确估算的人做过开发。我们选择的效果很好的是：

• 我花了所有的时间来估算。约占我帐单的20-25％。
• 我对任务做了非常详细的检查。没有从臀部射击。我进入代码，弄清楚需要更改哪些行，它将影响程序的其他部分，我必须进行多少测试才能确保一切正常。我估计每片以.1小时（6分钟）为单位。
• 我将他对每项任务的估计以及详细的细分发送给他。

20-25％的帐单听起来很多。

但是他会要求我进行XYZ更改，以为大约需要2个小时。在1个小时的详细估算中，我确定将花费8.5个小时。因此，他将决定是否值得支付8.5小时的报酬。如果没有，那么如果我不加估算的话，他将节省7.5个小时。

如果他确实想投资8.5个小时，那么我为估算所做的详细工作就是我必须要做的工作。

我发现使用这种方法，我可以按时甚至提前完成大多数任务，而不必高估。因为时间是如此短暂，所以我可以早点知道我是否在滑倒。如果我遇到障碍，那么在3个小时后我可以说我的8.5个小时的任务要花12个小时，我可以在更多时间过去之前与他谈谈，以便他在担心成本的情况下可以重新评估和重制该功能。

他是在吃喝玩乐吗？不，我把它看成是让他把钱花在他看到最大收益的地方。我很高兴获得估算的经验，这是我一直以来最糟糕的。

在会议上，经常有人要求我们提供“概算”，在会议中，我们对他们想做的事情有非常广泛而广泛的想法。我总是说：“如果您今天想要一个答案，那就是一年零一百万美元。如果您想给我更多的细节和一些时间来复习它们，那么我可以为您优化这些数字。”

他们几乎总是明白这一点。

这取决于估算的目的。

对于业务案例的初步，高层次的估算，关键是：

1. 速度。无论使用哪种方法，都必须快速。关键是利益相关者不确定是否值得进行该项目-这就是为什么他们需要业务案例的数字。如果业务案例可靠，则不需要您的估计。这些项目大部分不会继续进行，因此重要的是不要花费太多精力来提供估计。
2. 给一个范围。使其广泛。您没有时间分析需求，与利益相关者进行研讨会，验证假设。估计值的接收者范围很广，“软件项目天生就很复杂且有风险-如果您要进行适当的估计，则需要给我更多详细信息和更多时间”。给出一个单一数字或一个狭窄范围的问题是，在进行任何实际分析之前，它会通过设定期望值而使您陷入困境。

我找到了最好的技术来选择一个“感觉”相同的可比项目。“感觉”是完全主观的-但是通过这种估计，我的经验告诉我您不会找到客观的测量结果。然后提供广泛的范围。我读过一些书，说-50％到+ 100％的范围是好的，但这取决于许多因素。

有关详细的低层估算：

1. 您需要一个基准。如果基线不稳定，则估计是没有意义的。
2. 自下而上是最好的。获取详细的工作细分，估计每个组件，然后将其汇总成更大的数量。我发现在这里规划扑克是一种很棒的技术。
3. 文件意外情况。弄清楚添加任何意外事件（如果有）的位置。是否将其添加到每个订单项？还是整个估算？还是要承担特定的风险？还是没有？
4. 陈述你的假设。给定时间范围内尽可能多的验证。
5. 明确说明估算中包括和排除的内容。例如，是否包括评论？是否包括技术延迟？

那些从艰难的道路中学到了一些建议。

要求不清楚。没有人对所有含义进行深入分析。

此时不要做估算。没有人估计不知道敌方人数就能赢得一场战斗的人数。估算是在侦查之后做出的。除非您已经与这个敌人作战。

新功能可能会破坏您在代码中所做的一些假设，并且您立即开始考虑可能需要重构的所有内容。

这是您的责任，除非您希望其他人对此领域有专门知识。

您从过去的工作中还有其他事情要做，您将不得不做出一个将其他工作考虑在内的估算。

与上述相同，即使是由旁边的slob团队伙伴通过几乎不存在的测试过程创建的意外工作，也会导致您的代码出现故障，导致您无法提前完美预测。这是天气预报。

“完成”的定义可能尚不清楚：何时完成？就像刚刚完成编码一样是“完成”，还是像“用户正在使用它”那样是“完成”？

在这里了解用户端要求，像用户一样思考。不要做，如果他们估计的东西被“做”，只是因为与准系统的工作流程使用户无法忍受可能一些基本的功能是他们认为什么是你的同龄人做什么“完成”。从用户的角度考虑它，因为这就是您通常估算的所有客户。估算完整的用户端需求，而不是准系统技术需求。并意识到，您的客户要求估计的价格在他们如何表达事物以及理解您所说的技术方面方面是完全不准确的。

无论您对所有这些事情有多有意识，有时您的“程序员的自尊心”都会使您付出/接受的时间比您最初预期的要短。特别是当您感受到截止日期和管理层期望的压力时。

不要这样！您听起来像是一个有上进心的勤奋工作的人，也许是一个容易屈服于胁迫的人。

这里的问题是这样的：假设您和Joe为同一任务进行了时间估计（但是在两个单独的员工之间，一次都没有意识到这两个估计）。您英勇地估计“一个星期”。您认为可以，您每周工作超过100个小时以上，无偿加班。现在您迟到了三天。

同时，乔估计需要5个月的时间。您认为这很荒谬，您认为可以在一星期内完成。乔工作多少？一周10个小时？...除了他准时完成5个月。

猜猜谁被认为是公驴？是的，你。乔看起来像是一位伟大的工作者，您现在似乎不可靠。没关系，您可以在乔大约7％的时间内获得甚至更好的结果。重要的是您比一周的估计时间少了3天。

切勿在更严格的估算方面出错。更宽松的估算结果有误。在您的公司中有一种声誉，它不会基于估计的长度而几乎不取决于估计的准确性。估计时间太长，很容易就很准确，您将有更多的时间来解决问题并更好地解决问题。估计值太短了，根本没有呼吸空间，您要么拼命遇到它，要么就被搞砸了。

“两个星期！”

说真的 我的第一个估计始终是两个星期。因为我有某种怪异的心理障碍，使我认为一切听起来都需要两个星期。

我尝试解决此问题，尝试真正考虑我认为需要花费多长时间，试图找出所有潜在的问题点和点，这些点和点看起来对我来说太黑框了，无法准确估计。并尝试认识到，如果我的回答是“两周！”，则我可能没有这样做。

我几乎每位好经理都学会了认识“两个星期！” 作为回答，需要轻度的口头皮条打耳光。

有一个博客条目概述了如何保存以前的估算结果的准确性，然后下次您对某人说“将是两个星期”时，您可以查看以前的历史记录并查看它的历史记录实际上是您上次说“要两个星期”。

我自己还没有尝试过，但是我想了解一下我的估计有多准确。

这取决于组织以及估算的使用方式。

如果估算只是为了提供一个大概的准备时间，我通常可以根据我的经验进行快速估算。通常，我会在估计中包括任何不确定性或可能的变化，以及这些变化如何影响系统的其他区域以及所需的回归测试的程度。

如果估算值用于合同规定的任何事情或需要更精确的时间安排的情况下，我将进行全部工作分解。这是更多的工作，并且需要对系统的设计和更改进行更深入的思考，但是要准确得多，尤其是对于较大的工作。

无论哪种情况，持续的通信都是关键。如果您确实遇到了意外情况，请立即将其告知，而不要等到最后期限。如果要求不清楚，请确保记录您对要求以及计划提供的功能的理解。这对您所做的任何假设也很有帮助。至于相互竞争的优先事项，当一项工作碰到另一项工作时，请清楚这将如何影响时间表。

估计什么？小任务或完整的解决方案。

后者我很少做，但是只是猜测，添加一点，让经理添加一点，然后将其添加到一个范围内，并在其旁边加上一点注释，表明以上只是猜测。

小任务- 规划扑克非常有效（不是很完美，一些1pt任务花了更长的时间，一些5pt任务花了几分钟，但最终都平了）。

根据您今天所知道的内容提出一个范围。使用不确定度锥来提供围绕您的初始猜测值的范围。

每周计算剩余的工作量，然后根据您知道的情况重新估算。一旦您有足够的样本量来确定每周要完成的工作量，请为剩余的剩余量提供90％的置信区间，以便随着项目的进展和剩余的工作量（通常是希望的）缩小（通常）的日期范围）缩小。

信心十足地。我无法告诉您有多少次我在与客户进行初次会谈时，在给出估算时不表现出专业精神。即使您是凭空吹牛，也要确保始终保持一些估计。就是说，要小心不要估计自己陷入困境。不同的事情需要花费大量的时间，精力和资源。这是一个很好的方法：

他们：要多少钱？

我：这取决于您要我做什么。通常，我在$ X左右启动此类项目。

有时，对于您和您的团队而言，估算成为一项巨大的挑战，尤其是在我们谈论软件项目估算时。

一旦我们决定分享我们的经验和关于软件评估过程的知识，并定义了四种不同的评估类型：

• 球场图
• 服务估算
• 特征估计
• 分量估计

当然，这些类型是不同的。棒球场通常被称为“猜测”。因此，这是一个大致的数字或范围，可以大致了解成本，并有助于潜在客户确定他们是否希望进一步讨论。

通常，客户在项目开始时就需要一个大概的数字。我们的建议是：对项目的讨论和提供总体数字仅是迈向获得组件估计的好步骤（这是灵活的，可以在整个开发过程中使用组件类型的估计。在重新评估时无需重新进行估计）您要添加，删除或替换功能，服务等）。

每个人都应谨记软件开发估算带来的风险：低估，高估，全面的史诗般的失败案例等。

您可以在我们的博客上阅读更多内容！

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

希望这些信息对您有所帮助！

我总是最终给出估计，后来我意识到自己无法实现。它发生了无数次，我始终保证不会再发生。

听起来您被要求作出承诺，而不是估计。这些是不同的事情，但是，如果您能够可靠地管理承诺，那将真正帮助您提高信誉和职业生涯。

根据我大约10年的经验提供的一些建议：

• 始终提供一个范围（即上限和下限）。这将传达您的不确定程度
• 如果不确定性很大，请延期（例如1天进行分析，然后提供更小的范围）
• 如果任务太大，则将其分解并为每个零件提供一个范围

首先，如果将某些任务分配给我，我会将其分解为子任务。我将估计每个子任务的时间，并且可能通过子任务可以找到有问题的区域，因此我将能够预测出需要多长时间在一定程度上。

但是，所有的计划仍然只能在一定程度上有所帮助。只有当您开始编码时，您才能找到确切的问题

如果您为同一位老板或客户执行许多项目，则可以尝试以大笔的复杂性估算，而不是数周或数月，可能以T恤尺寸估算。确定一些过去的项目，并为其分配大小S，M，L，XL。

然后问自己：听起来哪个项目与范围相似？然后，您无需回答“ 2个月”，而可以回答“对我来说像L的声音”（或您对项目进行的任何校准）。

这是很容易理解的，而且很明显，这些猜测存在很多不确定性。

然后，当需求更改时，您可以说“更改使它听起来更像是XL”。

有点晚了，但是当我入伍时，我们被指示使用PERT来确定估计值。它确实需要您所在领域的经验和手头的任务。在维护和修理电子设备（复杂的无线电设备和卫星通信设备）时确定估计的完成时间时，它的准确性出奇地准确。在日常维护过程中，任何数量的东西都可能是错误的或被发现并需要修复的，这是非常准确的。这些估计很重要，因为其他单位在收到通讯设备之前可能无法使用。我使用过的一个免费的在线PERT计算器