评估软件估算：确定的不切实际的迹象？

Question

在回答Dealing with awful estimates发布的“Ash”时，我分享了一些我学到并亲自用来发现弱估计的提示。但我确信必须有更多！

当需要快速评估由第三方（同事，业务合作伙伴或外部公司）编制的软件项目估算时，在场景中使用什么启发式？

如果没有对手头任务的详细了解，可以发现软件估算较弱的明显且不那么明显的迹象是什么？

Answer 1

• 一个人已经完成了估算，而不是使用基于共识的估算（以完全理解需求的隐含范围），例如Wideband Delphi。
  • 如果进行估算的人不是执行人员的话，尤其如此!! - 我曾经在其他任何人提出要求之前的60天内对其他人进行了估算。让我们说我不是一个快乐的兔子
• 没时间提供文件。
• 没有时间提升（在学习和团队规模方面）。
• 没有风险清单及其对时间表的影响。
• 对于意外情况没有缓冲 - 就最新要求和风险而言。

Answer 2

没有人说过，所以我愿意。显而易见的答案是，如果你有软件进度估计，那么这是不切实际的数字的明确信号。是的，有很多估算软件的方法，但它们都不是以任何方式，形状或形式准确的。通常发生的是设定截止日期。如果任务被高估，那么花费额外的时间来使结果更好。如果任务被低估，那么就会牺牲某些东西来满足交付（如测试和功能）。

我知道这个答案不是人们想要相信的，但估算总是一个猜测。通常情况下，开发人员甚至无法预测他们将在一天结束时完成多少工作。你期待他们在未来几年/几年内猜测他们甚至不确定真正涉及到什么的事情。

对于您的问题，不容易产生不切实际的结果的唯一实际答案是使用根据您公司以前的历史记录提出猜测的工作表。不幸的是，这不会解释估算人员遗漏的任务。至少这可能会给出球门号码。

除非你一遍又一遍地开发同一系统的敲门声，否则任何认为他们已经弄明白这一点的人都在欺骗自己。涉及的变量太多了。

Answer 3

估算有两种类型：任务估算值和项目估算值。您可以将这些视为大小图片。

项目估算必须是高级别的（粒度通常不小于几天），并且必须包含以下内容：

• 高层架构;
• 测试时间;
• 加速时间;
• 缺陷流程;
• 记录时间;
• 相关培训;
• 假设;
• 依赖关系（例如，在团队B交付第1阶段之前，团队A无法做他们需要的事情）;
• 关键路径（哪些部分可能决定项目是否滑落以及减少多少）;和
• 风险。

缺少的东西越多，估计就越不现实（或冒险）。

第二种任务估算，通常低得多。对于这种估计，它应该只是一个任务分解（没有任务大于5天）。

这些不倾向于解决上述问题，但其中一些可能是相关的，例如关于尚未做出的决定的假设（例如生产硬件）。由于相关经验，背景知识或技能（因为该人或那些人可能最终过度使用），也可能值得确定谁能够和不能完成任务。

其他帖子提到测试时间应等于或超过开发时间。我强烈反对这一点。我已经看到8小时开发任务导致100多个小时的测试时间和80小时开发任务导致不到2小时的测试。在这两种情况下，测试时间都是完全合理的。这两者之间没有绝对的相关性。充其量，连接松散。

Answer 4

• 估计管理是什么 想被告知？
• 是吗？ 估计很好地适应 计划的下一个发货日期 发布？
• 管理层会奖励吗？ 那些给予好消息的人 人们给坏消息？
• 是的 估计在知道谁之前做好准备 会在这个项目上工作吗？
• 没有符合 有人想要这一点 功能实施准备 估计？
• 有没有历史 软件迟到了？
• 这是正常的吗？ 开发人员转移到其他人 任务虽然是一个项目？
• 有 部分或全部开发人员放弃了 评论坏的估计作为一个 浪费时间？

计算你得到“是”或“可能”答案的问题数量......

如果您对上述问题的回答大多为“否”，则可能值得详细查看估算值，以确定其是否包含此主题中列出的其他人的任务。

Answer 5

哇...我真的很喜欢toolkit的答案。

并且我同意任何估计都是有缺陷的，因为它假设估算器比估算项目估计时任何估算器实际上做的更多地提供了解决问题的线索。但是，我认为你还需要在开始之前至少估计山的大小。一些人认为是否值得尝试这样做应该先于任何努力，这就是估计的本质所在。

我确实想出了一些危险估计的指标：

• 无交叉引用 - 如果无法通过至少两种不同方式验证估算值，则可能不可靠。例如，我做过的最后估计我已经能够将工作细分为小特征块，并考虑我们的团队花了多长时间来做类似的范围特征。然后，我能够查看这些成本的总和，看看范围相对于我工作过的其他项目有多大。这是两种验证方式。
• 估算工具的背景 - 如果这是由从未编写代码的硬件人员完成的软件估算 - 非常害怕。更微妙 - 估算者的背景越接近项目的技术和问题领域越好。
• 详细信息 - 在几个不同的帖子中说了几种不同的方式 - 我希望看到各个功能的详细信息，以及完成每个功能所需的任务。我看到的大多数估计都没有在正式演示文稿中显示详细信息，但如果您询问进行估算的人员，他们应该在某个地方有文件。希望它不是用啤酒和番茄酱沾上纸巾的背面。 ：）
• 记录假设 - 任何估算工具都必须对该任务做出一些假设。这些应记录在某处，最好是在正式的文书工作中。当我看到一个没有多少记录的假设的简短提案时，我总是有点担心。他们是经过深思熟虑而未与客户沟通，或者他们没有被考虑过。我不确定哪一个更糟糕。不言而喻，这些假设也应该是合理的。
• 平衡生命周期 - 然而，任务被细分，设计，代码和测试的比例是多少？文档，与外部系统的集成以及发布后支持如何？那些如此重要的额外事情（系统管理员，CM专家，管理工作）怎么样？
• Slack - 我确信便宜的公司守护进程会来，并且会让我感到害怕，但是时间表和成本应该有些松懈。如果估计对于有经验的人来说看起来雄心勃勃且具有攻击性，那么它可能太低了。估计几乎不会太高。

Answer 6

一个好的启发式方法是查看测试时间与开发时间大致相同。这是估计的一个好兆头。

如果他们不能给你一个估计的细分那么这是一件坏事。通常是许多可能被遗忘的小事的标志。他们不需要提供完整的原始细分，只需要像以下一样细分：

• 要求
• 发展
• 测试
• 打包和部署
• 等

他们应该使用标准模板来计算他们的估计。它们不需要每列中的数字，但是它们会使用模板列出所有可能的任务。这样，在进行估算时，模板可以用来慢慢考虑人们的想法。

如果估算过于精确，例如0.25小时的增量，那对我来说是难闻的气味。

如果缺少需求捕获，测试，部署和切换到任何Ops组？如果其中任何一个缺失，那就会回来咬你。

编辑：要注意的另一件事是旧的“永久完成90％”的任务。在将任务列为“90％完成”的进度更新后，您将获得进度更新。那不好！

HTH

欢呼声

Answer 7

• 是编译器的 估计可用和愿意 与其他高级项目讨论 成员？如果没有，那往往是一个 关注。

• 估算是否发送给了 客户之前的体验和 开发人员的技能是 众所周知。两点估计可能有所帮助 但只是在某种程度上。

• 在有机会查看估算之前，您会被告知您致力于提供特定日期所描述的所有功能。

（顺便说一下，谢谢你回答我的问题。）

Answer 8

我完全赞同Dunk，估计错误的第一个迹象只是存在大量详细的前期计划。估计恰好是近似值，否则我们称之为精确 imates。所以他们永远不应该单独用于项目的管理。

要考虑的最重要的一点不是估算的准确度，而是一致性。如果第三方正在为您做估计，那么请询问他们成功或失败的历史，与过去的客户交谈并确定他们的可靠性。

从敏捷的角度来看，我们试图在项目中获得更一致的估算的一些方法是：

• 使用相对尺寸标准（S，M，L，XL）而不是基于时间（理想天数）。
• 专注于复杂性而非时间
• 始终使用群体估算而非单人估算
• 在整个项目中经常收集估算值，通常是在每个sprint开始时
• 使用之前冲刺的反馈来确定故事复杂性
• 跟踪速度以赋予相对大小调整含义
• 频繁和早期的故事回顾，以检查/理解任何颠簸

如果您正在与使用这些估算方法的公司打交道，那么您很可能会获得一致且因此更好的结果。

Answer 9

如果你看到其中一个或多个，你可能估计不好：

• 单点估算：估算应与一系列可能的日期或置信度值相关联
• 任务的粒度不足：大型任务桶通常表明功能未被充分理解（这尤其是一个问题，因为通常对低估的问题估计不足）。
• 没有表达假设和/或风险
• 为通常跳过或低估的项目（例如构建脚本，文档，部署等）分配的工作量不足。

我同意sateesh，我真的很喜欢软件评估：揭开Steve McConnell的黑色艺术神秘面纱。他有几个清单，在审查和/或准备估算时很有用。

Answer 10

估计表格3个月，6个月或12个月（基本上任何轮数字）的猜测。通常当你猜测你选择一些比你想象的更大的圆数 - 四分之一，半年等 - 是通常的嫌疑人。我非常喜欢在实际开发迭代方面的估计（无论其大小如何）。

Answer 11

  

有什么显而易见的，不是这样   软件薄弱的明显迹象   可以在没有发现的情况下发现估计   非常详细的任务知识   手？

在没有详细了解手头任务的情况下给出的估计通常不好。

您可以采取的一般方法是检查要求中的项目是否与估算中的项目相对应。如果你想非常快速地检查相对大小，如果对一个100,000字的简报有一个100字的估计，它就没有机会正确。

另外（正如其他人所说）检查分析，编码，调试，测试，集成，应急等。它表明了一些想法。

在各个阶段取得成功并签署标准是一个好兆头。如果他们有一个定义的点，至少在估计错误的情况下完成了10％，你就知道了，并且有机会适应。如果在“完成”之前没有检查点，您可能不知道自己落后，直到该日期被击中。

Answer 12

与做这项工作的人一起估计的人有多熟悉？

我经常看到有一个普通人做这项工作的估计，即使团队由背景不同的人组成。最有可能的任务和专业没有完美排列，你得到一个c ++服务器端程序员，最终做你的gui或你的数据库...有时团队的经理并不真正欣赏团队成员的优势，所以如果他被要求自己拿出估计，因为他的团队忙于上一个项目，你会发现有问题的工作真的只适合团队的一部分（不是激励，缺乏技能等）< / p>

Answer 13

“四到六周”，如果没有细分任务......

Answer 14

以下任何一项：

• 这是一个大项目，并没有描述
的简短高级策略
• 对于希望通过该项目实现的目标，没有明确，简洁和简洁的愿景
• 该项目并非围绕逐步交付的业务价值构建
• 团队正在尝试为一个大型项目提供“准确”的估算，进入（或完成）长期分析阶段？ （变化将会到来，并且通常会影响那些在没有更大努力的情况下无法轻易量化的估算值）
• 整个项目有“详细”估算（与之前相关）
• 第一阶段没有详细的估计，或者有些错误。

Answer 15

一个好的估计将有一个很好的细分，涉及项目的所有阶段。

几乎肯定不会在方便的日期完成业务。

它将包括各种风险。

它将以置信区间表示，无论是隐式（10-12个月）还是使用大单位（约四分之三）。

这将由负责完成项目的人制作，最好是不止一个人。

如果一开始有延迟，最后会有延迟（表示从开始10-12个月，如果我们现在开始，大概是2010年第一季度，而不是像项目尚未开始的2010年1月那样）

将清楚明确地列出假设和依赖性。

编辑：部分内容取决于项目所处的阶段。早期但精确的估计是一个警告标志，特别是如果没有分配置信区间。这对Procrustean的估计很不满意。

另外，请注意其他开发方法。时间盒项目可以有严格的任意计划，但功能集将是灵活的。

Answer 16

我检查了对人力的估计。虽然不是一个非常准确的启发式，但很明显，如果一些大型工作只分配了一个或两个开发人员，那么任务就没有被正确估计

Answer 17

评估估算值的另一种有用方法是将其与之前类似项目的实际工作量进行比较。比较的最佳数据是组织已完成的先前项目的工作量数据。如果没有组织历史数据，您可以尝试将估算值与行业广泛的基准进行比较。

我还会说，如果估算值是单个绝对数字（比如说180天），那么这不是一个好兆头。单个绝对数字表示估计是任务将以给定数据的100％概率完成。在一个范围内（例如130到180天）提出的估计值表明可以完成任务的范围。

我上面写的大部分内容都归功于这本书：

软件评估：揭开黑人艺术的神秘面纱 作者：Steve McConnell