在回答Ash发布的“<a href="https://stackoverflow.com/questions/549597/dealing-with-awful-estimates/553200#553200">处理糟糕的估计”时，我分享了一些我学到的技巧和个人用来发现弱估计。但我确信肯定还有更多！
在需要对第三方（同事、业务合作伙伴或外部公司）编制的软件项目估算进行快速评估的场景中使用什么启发式方法？
在没有对手头任务的详细了解的情况下，可以发现哪些明显的和不那么明显的软件估计弱的迹象？
Totophil
问问题
1779 次
17 回答
22
- 一个人完成了估计，而不是使用基于共识的估计（以充分理解隐含的需求范围），例如Wideband Delphi。
- 如果进行估算的人不是执行实施的人，则尤其如此！- 我曾经在一个项目上工作过，这个项目被别人估计是在提出任何要求之前 60 天。可以说我不是一只快乐的兔子
- 没有时间做文档。
- 没有时间提升（在学习和团队规模方面）。
- 没有列出风险及其对时间尺度的影响。
- 对意外情况没有缓冲 - 就最新要求和风险而言。
于 2009-02-16T13:25:04.083 回答
19
没有人说过，所以我会的。显而易见的答案是，如果您有软件进度估算，那么这肯定是不切实际数字的迹象。是的，有许多评估软件的方法，但没有一种方法在任何方面、形状或形式上都是准确的。通常发生的情况是设定了最后期限。如果任务被高估，则需要花费额外的时间使结果更好。如果任务被低估了，那么就会牺牲一些东西来满足交付（比如测试和特性）。
我知道这个答案不是人们愿意相信的，但估计总是一种猜测。通常情况下，开发人员甚至无法预测他们将在一天结束时完成多少。您期望他们在几个月/几年后猜测他们甚至不确定真正涉及的事情。
对于您的问题，唯一不会给出不切实际结果的实用答案是使用根据您公司以前的历史提出的猜测的工作表。不幸的是，这并不能解释估算器错过的任务。至少这可能会给出大致数字。
除非你一遍又一遍地开发出相同系统的仿制品，否则任何认为他们已经弄清楚这一点的人都是在自欺欺人。涉及的变量太多了。
于 2009-02-16T18:12:52.457 回答
11
有两种类型的估算：任务估算和项目估算。您可以将这些视为大小图片。
项目估算必须是高水平的（粒度通常不小于天），并且必须包括以下内容：
- 高级架构；
- 测试时间；
- 加速时间；
- 缺陷过程；
- 文件时间；
- 相关培训；
- 假设；
- 依赖关系（例如，在 B 团队交付第一阶段之前，A 团队无法做他们需要做的事情）；
- 关键路径（哪些部分可能决定项目是否会滑倒以及滑倒多少）；和
- 风险。
遗漏的东西越多，估计就越不切实际（或冒险）。
第二种任务估计，通常低得多。对于这种估计，它应该只是一个任务分解（没有任务大于 5 天）。
这些并不倾向于解决上述项目，但其中一些可能是相关的，例如关于尚未做出决策的假设（例如生产硬件）。由于相关经验、背景知识或技能（因为那个人或那些人最终可能过度投入），确定谁可以和不能完成任务也可能是值得的。
其他帖子提到测试时间应该等于或超过开发时间。我强烈不同意这一点。我已经看到 8 小时的开发任务导致 100 多个小时的测试时间，而 80 小时的开发任务导致不到 2 小时的测试。在这两种情况下，测试时间都是完全合理的。两者之间没有绝对的相关性。充其量是松散的连接。
于 2009-02-16T13:24:50.933 回答
6
- 估计是管理层想要被告知的吗？
- 估计是否与下一个版本的计划发货日期吻合？
- 管理层是否奖励给予好消息的人多于给予坏消息的人？
- 在知道谁将从事该项目之前，是否已准备好估算？
- 是否有人想要在功能上实现这一点准备估算？
- 有软件迟到的历史吗？
- 开发人员在项目中途转移到其他任务是否正常？
- 是否有一些或所有开发人员放弃评论错误估计是浪费时间？
数一数你得到“是”或“也许”答案的问题数量……</p>
如果您对上述问题的回答大多是“否”，那么可能值得详细查看估算，看看它是否包括其他人在此线程中列出的任务。
于 2009-03-09T15:56:55.357 回答
5
哇...我真的很喜欢工具包的答案。
而且我同意任何估算都是有缺陷的，因为它假设估算者比任何估算者在估算项目时实际上拥有更多关于如何解决问题的线索。但是，我认为您仍然需要在开始之前至少估计这座山的大小。一些人认为是否值得尝试做它应该先于任何努力，这就是估计的本质应该是什么。
我确实提出了一些危险估计的指标：
- 没有交叉引用——如果估计不能以至少两种不同的方式进行验证，它可能是不可靠的。例如，我所做的最后一次估计，我已经能够将工作分解成小的功能块，并考虑我们的团队花了多长时间来完成类似范围的功能。然后，我能够查看这些成本的总和，并了解相对于我从事的其他项目的范围有多大。这是两种验证方式。
- 估算器的背景——如果这是一个从未编写过代码的硬件人员所做的软件估算——要非常害怕。更微妙 - 估算者的背景越接近项目的技术和问题域越好。
- 细节- 正如在几篇不同的帖子中所说的几种不同的方式 - 我喜欢查看单个功能的详细信息，以及完成每个功能所需的任务。我看到的大多数估算都没有在正式演示中显示细节，但是如果你问做估算的人，他们应该在某个地方有一个文件。希望它不是沾满啤酒和番茄酱的餐巾纸的背面。:)
- 记录假设- 任何估算者都必须对任务做出一些假设。这些应该记录在某个地方，最好是在正式的文书工作中。当我看到一个没有太多记录假设的简短提案时，我总是有点担心。要么是经过深思熟虑而没有与客户沟通，要么是没有经过深思熟虑。老实说，我不确定哪个更糟。不用说，假设也应该是合理的。
- Balanced Lifecycle - 然而任务被分解，设计、代码和测试的比例是多少？文档、与外部系统的集成和发布后支持如何？那些非常重要的额外事情（系统管理员、CM 专家、管理工作）怎么样？
- 松懈——我敢肯定，廉价的企业守护进程会来剥我的皮，但时间表和成本应该有一些松懈。如果估计在有经验的人看来是雄心勃勃和激进的，那么它可能太低了。估计几乎永远不会太高。
于 2009-03-11T19:02:40.807 回答
3
一个很好的启发式方法是查看测试时间是否与开发时间大致相同。这是估计的好兆头。
如果他们不能给你估计的细目，那是一件坏事。通常是许多可能被遗忘的小事的标志。他们不需要提供完整的原始细分，只需提供如下细分：
- 要求
- 发展
- 测试
- 打包和部署
- 等等
他们应该使用标准模板来计算他们的估计。他们不需要在每一列中都有一个数字，但他们使用模板来列出所有可能的任务。这样，在进行估算时，模板就可以用来激发人们的思想。
如果估计过于精确，例如增量为 0.25 小时，那么对我来说，那是一种难闻的气味。
如果缺少诸如需求捕获、测试、部署和移交给任何 Ops 组之类的东西？如果其中任何一个缺失，那就是那种会回来咬你的东西。
编辑：要注意的另一件事是旧的“永远完成 90%”的任务。在将任务列为“90% 完成”的进度更新后，您将获得进度更新。这不好！
高温高压
干杯
于 2009-02-16T13:15:58.583 回答
2
估算的编制者是否可用并愿意与其他高级项目成员讨论？如果没有，这通常是一个问题。
在开发人员的经验和技能已知之前，是否将估算发送给客户。两点估计可能有所帮助，但仅在一定程度上有所帮助。
- 甚至在有机会查看估算之前，您就会被告知您致力于交付特定日期所描述的所有功能。
（顺便说一句，感谢您回答我的问题。）
于 2009-02-16T13:55:07.007 回答
2
如果您看到其中的一个或多个，您可能有一个错误的估计：
- 单点估计：估计应该与一系列可能的日期或置信度值相关联
- 任务的粒度不足：一个大的任务桶通常表明功能没有被很好地理解（这尤其是一个问题，因为理解不足的问题通常被低估了）
- 不表达假设和/或风险
- 为通常被跳过或低估的项目（例如构建脚本、文档、部署等）分配的工作量不足
我同意 sateesh 的观点，我真的很喜欢软件估算：史蒂夫·麦康奈尔 (Steve McConnell) 的《揭秘黑色艺术》。他有几个清单，在审查和/或准备估算时很有用。
于 2009-03-09T16:34:17.653 回答
2
我完全同意 Dunk 的观点，糟糕的估计的第一个迹象就是存在大量详细的前期时间表。估计值就是这样，一个近似值，否则我们会称它们为精确估计值。因此，它们不应该单独用于项目管理。
要考虑的最重要的一点不是估计的准确性，而是一致性。如果第三方正在为您进行估算，请查看他们成功或失败的历史，与他们过去的客户交谈并确定他们的可靠性。
话虽如此，从敏捷的角度来看，我们试图在项目期间获得更一致的估计的一些方法是：
- 使用相对尺寸标准（S、M、L、XL）而不是基于时间（理想的日子）。
- 关注复杂性而不是时间
- 始终使用群体估计而不是单人估计
- 在整个项目中经常收集估算，通常在每个 sprint 开始时
- 使用以前冲刺的反馈来确定故事的复杂性
- 跟踪速度以赋予相对大小以意义
- 频繁和早期的故事回顾以检查/理解任何颠簸
如果您正在与使用这些估算方法的公司打交道，那么您很可能会收到一致的结果，因此会得到更好的结果。
于 2009-03-15T10:58:01.200 回答
1
3、6 或 12 个月（基本上是任何整数）形式的估计令人难以猜测。通常，当您猜测您选择的整数比您认为的要大的时候——季度、半年等——是通常的嫌疑人。我更喜欢根据实际开发迭代（无论它们的大小）进行估计。
于 2009-02-16T13:17:25.773 回答
1
在没有对手头任务的详细了解的情况下，可以发现哪些明显的和不那么明显的软件估计弱的迹象？
在对手头任务没有详细了解的情况下给出的估计通常不好。
也许您可以采取的一般方法是检查需求中的项目是否与估算中的项目相对应。如果您想快速检查相对大小，如果对 100,000 字的简报给出 100 字的估计，那么它就不可能是正确的。
另外（正如其他人所说）检查是否提到了分析、编码、调试、测试、集成、应急等。它表明一些想法已经进入它。
在各个阶段取得成功并签署标准是一个很好的迹象。如果他们有一个确定的点，如果估计是错误的，那么至少完成 10%，那么您就可以及早知道并有机会适应。如果在“完成”之前没有检查点，你可能不知道在那个日期之前你落后了。
于 2009-02-16T13:34:14.563 回答
1
给出估价的人与从事这项工作的人有多熟悉？
我经常看到有一个普通人在做这项工作的估计，即使团队是由背景非常不同的人组成的。很可能任务和专业没有完美结合，你会得到一个 c++ 服务器端程序员，他最终会做你的 gui 或你的数据库......有时团队的经理并不真正欣赏团队成员的优势，所以如果由于他的团队忙于上一个项目而要求他自己提出估算，您会发现所讨论的工作实际上只适合团队的一部分（没有动力，缺乏技能等）
于 2009-03-14T15:21:39.517 回答
0
评估估算的另一种有用方法是将其与在以前类似项目上花费的实际工作量进行比较。用于比较的最佳数据将是该组织以前完成的项目的工作量数据。如果没有组织的历史数据，您可以尝试将估计与行业范围的基准进行基准比较。
我还要说，如果估计以单个绝对数字（比如 180 天）的形式呈现，那么这不是一个好兆头。单个绝对数字表示估计任务将以 100% 的概率在给定数据上完成。在一个范围内（比如 130 到 180 天）呈现的估计值将表明可以完成任务的范围。
我上面写的大部分内容都归功于这本书：
软件估计：揭秘史蒂夫·麦康奈尔的黑色艺术
于 2009-02-16T14:09:32.043 回答
0
我对照人力检查估算值。虽然不是一个非常准确的启发式方法，但很明显，如果某些大型工作只分配了一个或两个开发人员，那么任务估计不正确
于 2009-02-16T14:27:48.880 回答
0
一个好的估算将有一个很好的细分，涉及项目的所有阶段。
它几乎肯定不会在业务方便的日期完成。
它将包括各种风险。
它将以置信区间的形式呈现，隐含（10-12 个月）或使用大单位（大约四个季度）。
它将由负责完成项目的人制作，最好是不止一个这样的人。
如果一开始有延迟，最后也会有延迟（表示为从开始开始的 10-12 个月，或者如果我们现在开始，大约是 2010 年 1 季度，而不是像 2010 年 1 月项目尚未开始时那样）。
假设和依赖关系将被清楚且突出地列出。
编辑：这部分取决于项目所处的阶段。早期但精确的估计是一个警告信号，特别是在没有分配置信区间的情况下。这有点像 Procrustean 的估计。
此外，请注意其他开发方法。一个有时间限制的项目可以有一个严格和任意的时间表，但功能集将是灵活的。
于 2009-02-16T15:03:25.987 回答
0
以下任何一项：
- 这是一个大项目，没有描述一个简短的高级策略
- 对项目想要实现的目标没有清晰、简短和简明的愿景
- 该项目不是围绕逐步交付的业务价值构建的
- 团队正试图为一个大项目提供“准确”的估计，进入（或完成）一个漫长的分析阶段？（变化将会到来，并且通常会影响那些如果不付出更大努力就无法轻易量化的估计）
- 整个项目都有“详细”的估算（与之前有关）
- 第一阶段没有详细的估计，或者这些估计有问题。
于 2009-03-10T06:11:26.003 回答
0
“四到六周”，当没有分解成更短的任务时......
于 2009-03-15T11:21:40.053 回答