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

#1 楼

从务实的程序员那里：从旅途的人到大师：


当被要求估价时该说些什么

你说“我会回头给你。”

如果您减慢该过程并花一些时间来执行我们在本节中描述的步骤，则几乎总是可以获得更好的结果。在咖啡机上给出的估算值（像咖啡一样）会再次困扰您。


在本节中，作者建议采用以下过程：


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

#2 楼

软件评估是软件工程中最困难的一项任务-紧随其后的是需求启发。

有很多创建它们的策略，所有策略都基于首先获得良好的需求。但是当您的后背靠墙而他们拒绝为您提供更多详细信息时，请假装：


仔细查看您的要求。
进行假设以填充根据您对他们想要的东西的最佳猜测得出的差距
写下所有假设
让他们坐下来阅读并同意您的假设（或者，如果幸运的话，让他们屈服）并给您真正的要求）。
现在您有详细的要求，可以从中估算。

就像我妈妈小时候曾经威胁说：“快点挑些衣服，否则我会去挑给你！”

#3 楼

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


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

20-25％的计费声音就像很多一样。

但是他要我改变XYZ，以为这需要2个小时左右。在1个小时的详细估算中，我确定将花费8.5个小时。因此，他将决定是否值得支付8.5小时的报酬。如果不是这样，那么他比我节省了7.5个小时（如果我不加估算就可以节省成本）。

如果他确实想投资8.5个小时，我所做的详细工作

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

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

#4 楼

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

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

#5 楼

这取决于估算的目的。

对于业务案例的初始，高级估算，关键是：


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

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

有关详细的低水平估算：


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

#6 楼

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


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


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


这项新功能可能会破坏您在
代码中所做的某些假设，并且您会立即开始考虑所有可能的事情
必须重构。


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


您需要根据过去的任务来做其他事情，并且必须
做出一个将其他工作也考虑在内的估算。


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


'done'的定义可能不清楚：何时完成？
'done'就像刚刚完成编码一样，或称为'done'就像“用户正在使用
”中一样？


在这里了解用户端要求，像用户一样思考。如果他们认为某人“被完成”，则不要做他们的同事所做的事情，因为他们认为某些基本功能具有准系统工作流，而这些工作流是准用户无法容忍的。从用户的角度考虑它，因为这就是您通常估算的所有客户。估算完整的用户端需求，而不是准系统技术需求。并意识到，您的客户要求估算的信息在这里是完全不准确的，他们是如何措辞和理解您所说内容的技术方面的。


无论您多么有意识地了解所有这些内容，有时候您的
“程序员的骄傲”使您付出/接受的时间比您原本认为可能需要的时间短。特别是当您感觉到期限和管理期望的压力时。


不要这样做！您听起来像是一个自我激励的勤奋的人，也许是一个容易屈服的人。

这里的问题是这样的：假设您和Joe为同一任务进行了时间估算（但是在两个独立的任务之间）员工，一次也不知道这两个估算值。您勇敢地估计，“一周”。您认为可以，您每周工作超过100个小时以上，无偿加班。现在您要迟到三天。

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

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

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

#7 楼

“两个星期！”

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

我尝试解决这个问题，尝试真正地思考我认为需要多长时间，尝试找出所有潜在的故障点和位，这些位和位看起来对我来说太黑框了，无法准确估计。并尝试认识到，如果我的回答是“两周！”，那我可能会失败。

我所学过的每一个好经理几乎都学会了识别“两周！”。作为回答，需要轻度的口头皮条回应。

#8 楼

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

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

#9 楼

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

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

如果该估计用于合同或其他目的，在需要更精确的时间安排的情况下，我会进行全部工作。这是一项更多的工作，需要对系统的设计和更改进行更深入的思考，但是更加准确，尤其是对于较大的工作。

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

#10 楼

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

我很少做，但是我只是猜测，添加一点，让经理添加一点，然后放入一个范围内，并在旁边加一点说明上面是一个猜测。

小任务-规划扑克我发现工作得很好（不是很完美，一些1pt任务花了更长的时间，一些5pt任务花了几分钟，但一切都变得平稳了）最后）。

#11 楼

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

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

#12 楼

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


他们：要花多少钱？

我：这取决于您要我做什么。通常，我在$ X左右开始这种项目。

#13 楼

有时候，评估对您和您的团队来说是一个巨大的挑战，尤其是当我们谈论软件项目评估时。

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

服务估计
特征估计
分量估计

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

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

每个人都应谨记软件开发估算所带来的风险：低估，高估，总的重大故障情况等。

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

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

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

#14 楼

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


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

基于我大约10年的经验提供的一些建议：


始终提供一个范围（即上限和下限）。这将传达您的不确定性水平
如果不确定性非常大，请推迟（例如1天进行分析，然后提供更小的范围）
如果任务太大，则将其中断并为每个零件提供范围

#15 楼

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

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

#16 楼

如果您为同一位老板或客户执行许多项目，则可以尝试以大笔的复杂性来估算，而不是几周或几个月，可能以T恤尺寸来估算。确定一些过去的项目，并为它们分配大小S，M，L，XL。然后问自己：听起来哪个项目与范围相似？然后，您无需回答“ 2个月”，而可以回答“对我来说像L的声音”（或您对项目的校准结果）。

这很容易理解，而且显然这些猜测还有很多不确定性。

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

#17 楼

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