logo标签列表

评估软件估算：怎样确定不现实的数字？

project-managementevaluationestimation
24
在回答“应对糟糕的估算”这个问题时，由Ash发布，我分享了一些我学习和使用的技巧来发现弱势估计。但我相信还有很多方法！在需要快速评估由第三方（同事、商业伙伴或外部公司）编制的软件项目估算的情况下，可以使用哪些启发式方法？在不需要太详细了解手头任务的情况下，可以发现什么明显和不那么明显的软件估算弱点？
我投票关闭此问题，因为它与编程无关。 - Vadim Kotov
1
这个问题不在本站的范围内，因此属于不适当的话题。请参阅我可以在这里问什么样的问题？和哪些类型的问题应该避免提出？。您可以尝试在其他 Stack Exchange 网站上提问，也许是[pm.se]或[softwareengineering.se]。请务必阅读有关任何您打算发布问题的网站的帮助中心的相关页面。 - Makyen
我投票关闭此问题，因为它与编程无关。 - double-beep
17个回答
22
  • 单独一人完成估算，而非使用基于共识的估算（如Wideband Delphi）以充分理解需求的范围。
    • 特别是当进行估算的人不是实施者时！！ 我曾经参与过一个项目，需求还没有给出，就由其他人估算为60天。我只能说我很不开心。
  • 没有时间编写文档。
  • 没有时间进行培训（学习和团队规模方面）。
  • 没有风险清单以及它们对时间表的影响。
  • 没有为意外事件留下缓冲时间 - 包括迟到的需求和风险。
19
没有人说出来，所以我来说吧。显然的答案是，如果你有软件安排时间的估计，那就是不切实际数字的明显迹象。是的，有许多估算软件的方法，但它们都没有任何准确性。通常情况下，截止日期被设定。如果任务被高估了，那么会花费额外的时间来改进结果。如果任务低估了，那么为了满足交付（如测试和功能），就会有某些东西被牺牲掉。
我知道这个答案并不是人们想要相信的，但估算总是一个猜测。往往，开发人员甚至无法预测他们一天结束时会完成多少工作。你期望他们在几个月/几年后猜测一些他们甚至不确定实际涉及的事物的东西。
除非你一遍又一遍地制作完全相同的系统，否则任何认为自己已经解决了这个问题的人都是在愚弄自己。涉及的变量太多了。
唯一实用的回答你的问题而不易产生不切实际的结果的方法是使用基于公司之前历史记录的工作表进行猜测。不幸的是，这不会考虑到估算师错过的任务。但至少这可以给出大致的数字。
我喜欢你的想法，但是你表达得太强烈了。准确地估算是非常困难的，但我见过有些人可以做到，如果正确和持续使用敏捷方法，它可以朝着准确估算的方向发展。这需要大量的前期设计工作，将项目分解成足够小而已知的部分，通过原型消除不确定性和问题。虽然很难但可行。 - Bill K
11

估算分为两种类型：任务估算和项目估算。你可以将它们视为大局和细节。

项目估算必须是高层级的（一般不小于天数），必须包括以下内容：

  • 高层架构；
  • 测试时间；
  • 上升时间；
  • 缺陷处理过程；
  • 文档编写时间；
  • 相关培训；
  • 假设；
  • 依赖项（例如，A团队在B团队交付第1阶段之前无法完成他们需要做的事情）；
  • 关键路径（哪些部分可能确定项目是否会延迟以及延迟多长时间）；
  • 风险。

如果缺少这些内容中的任何一项，则估算将变得不切实际（或有风险）。

第二种类型是任务估算，通常更低级别。对于这种估算，应该简单地进行任务分解（没有一个任务要大于5天）。

这些估算不倾向于涉及上述项目估算中的内容，但其中一些可能是相关的，例如对尚未做出决定的假设（例如生产硬件）。还可以指定由于相关经验、背景知识或技能而无法完成任务的人员（这些人可能会过度承诺）。

其他文章提到测试时间应该等于或超过开发时间。我强烈不同意这一点。我见过8小时的开发任务导致100多个小时的测试时间，80小时的开发任务只导致不到2小时的测试时间。在这两种情况下，测试时间都是完全合理的。两者之间没有绝对的相关性。最多，只有松散的联系。

我会说更小。在非常大的项目中，这可能是不切实际的，但在我的经验中，估计几个小时的任务非常可靠。 - Hanno Fietz
详细估算的问题在于其成本，如果不小心的话，你会花费太多时间去估算那些最终没有实施的3或4个项目，而忽略了那个得到批准的1个项目的编程工作。 - Ian Ringrose
速度和准确性之间存在权衡。选择对你更重要的方面。 - cletus
6
  • 这个估算是否符合管理层想要听到的内容？
  • 这个估算是否与下一个版本计划中的发货日期相匹配？
  • 管理层是否更加奖励那些带来好消息的人而不是坏消息的人？
  • 在知道谁将参与项目之前，是否已经准备好了这个估算？
  • 是不是某个想要实现该功能的人准备了这个估算？
  • 是否有软件延误的历史？
  • 开发人员在项目进行过程中被调到其他任务上是正常的吗？
  • 是不是一些或所有开发人员已经放弃对坏估算进行评论，认为这是浪费时间？

统计你得到“是”或“可能”的答案的数量……

如果你对以上问题大多数的回答都是“否”，那么值得仔细检查估算是否包括其他人在本主题中列出的任务。

5

哇...我真的很喜欢Toolkit的回答。

我同意，任何估算都存在缺陷，因为它假定估算者在项目被估算时对如何解决问题比任何估算者实际上拥有更多的线索。然而，我认为你至少需要在开始之前估算一下山的大小。在进行任何努力之前应该考虑是否值得尝试，这就是估计的本质。

我想出了几个危险估计的指标：

  • 无交叉验证 - 如果估算不能至少通过两种不同的方式进行验证，那么它很可能不可靠。例如，我最近做的估算中，我能够将工作分解成小特性块，并考虑我们团队完成类似范围特性所需的时间。然后我能够查看这些成本的总和，并查看其相对于我曾经参与过的其他项目的规模大小。这就是两种验证方法。
  • 估算者的背景 - 如果这是一个由硬件人员完成的软件估算，而从未编写过代码的话，那么要非常小心。更微妙的是，估算者的背景越接近项目的技术和问题领域，就越好。
  • 细节 - 如几个不同帖子中所说 - 我喜欢看到单个特性以及完成每个特性所需的任务的详细信息。大多数我见过的估算都没有在正式演示中显示详细信息，但如果你向完成估算的人询问，他们应该会有一个文件。希望它不是用啤酒和番茄酱弄脏的纸巾背面。 :)
  • 记录的假设 - 任何估算者都必须对任务进行一些假设。这些应该有记录在某个地方，最好是在正式文件中。当我看到短小的提案并没有很多记录的假设时，我总是有点担心。它们是否经过深思熟虑并未与客户沟通，或者它们没有经过深思熟虑。老实说，我不确定哪一个更糟糕。当然，这些假设也应该是合理的。
  • 平衡的生命周期 - 不管任务如何拆分，设计、代码和测试的比例是多少？文档、与外部系统的集成以及发布后的支持情况如何？还有那些至关重要的额外事项（系统管理员、配置管理专家、管理工作）呢？
  • 弹性时间 - 我相信公司节约成本的鬼怪会来折磨我，但是进度表和成本计划应该有一些弹性。如果对经验丰富的人来说，估算看起来雄心勃勃且积极进取，那么它很可能太低了。估算几乎从来不会太高。
3
一个好的启发式方法是看测试时间是否与开发时间大致相同。这是一个良好的估计指标。
如果他们无法给出估计的详细信息，那就不太好了。通常这意味着有很多小事情可能被遗忘了。他们不需要提供完整的原始细节，只需要提供以下细节：
- 需求 - 开发 - 测试 - 打包和部署 - 等等
他们应该使用标准模板来计算其估计值。他们不需要在每一列中都填写数字，但模板需要列出所有可能的任务。这样，当进行估计时，可以使用该模板来激发人们的思维。
如果估计值过于精确，例如0.25小时的增量，则对我来说是个坏迹象。
如果有缺少需求捕获、测试、部署和移交给任何运营组的情况？如果其中任何一个缺失，那么这种情况将会回来咬你一口。
另外要注意的是旧的“永远完成90%”的任务。你会得到一个又一个进度更新，列出一个任务为“90%完成”。这不是什么好现象！
希望对您有所帮助。
谢谢。
如果它们大致相等，这是好事还是坏事？测试是否包括修复漏洞？ :-) - Vlad Gudim
我不同意。测试时间和开发时间可能会（而且通常是）截然不同。 - cletus
@cletus，我在某些条件下同意。但是通常对于一个全新的项目，它们应该大致相等。 - Rob Wells
@cletus，他们经常被迫/推动变得截然不同 - 话虽如此，团队可以以许多不同的方式组织，这极大地影响了每个角色所做的事情。 - eglasius
2

  • 编译器的估算是否可用且愿意与其他高级项目成员讨论？如果不是，这通常是一个问题。

  • 在了解开发人员的经验和技能之前，是否将估算发送给客户。两个点的估算可能有所帮助，但只能在一定程度上。

  • 甚至在看估算之前，您就被告知必须在特定日期之前交付所有描述的功能。

（顺便感谢您回答我的问题。）

2
如果你看到以下一项或多项内容，你的估算可能存在问题：
  • 单点估算：一个估算应该与可能日期范围或置信度值相关联。
  • 任务细化不充分：大型任务集通常表示功能没有被很好地理解（尤其是因为理解不足的问题通常会被低估）。
  • 未表达假设和/或风险。
  • 为常常被忽略或低估的项目分配的工作量不足（例如构建脚本、文档、部署等）。
我同意Sateesh所说的，我真的很喜欢Steve McConnell的《软件估算：揭开黑匠之谜》。他有几个清单在审查和/或准备估算时非常有用。
2
我完全同意Dunk的看法，糟糕的估算首要标志就是存在一个大而详细的前期计划表。估算本质上是一种近似值，否则我们会称之为精确估算。因此，在项目管理中不应仅仅使用估算。
最重要的考虑点不是估算的准确性，而是一致性。如果第三方为您进行估算，请要求查看他们的成功或失败历史记录，与他们的过去客户交谈并确定他们的可靠性。
话虽如此，从敏捷的角度来看，我们在项目中尝试获得更一致的估算的方式包括：
- 使用相对大小标准（S、M、L、XL）而不是基于时间的理想天数。 - 关注复杂性而不是时间。 - 始终使用群体估算而不是单个人的估算。 - 在项目中经常收集估算，通常在每个迭代的开始时。 - 使用以往迭代的反馈来确定故事复杂性。 - 跟踪速度以赋予相对大小意义。 - 经常和早期地审视故事以检查/了解任何混乱情况。
如果您正在与使用这些估算方法的公司打交道，那么您很可能会得到一致的、因此更好的结果。
1

以3、6或12个月为形式的估计（基本上是任何整数）都充满了猜测的味道。通常当你猜测时，你会选择比你认为需要更长时间的一些整数——季度、半年等——通常是罪魁祸首。我更喜欢用实际开发迭代（无论其大小）来进行估算。

选择一个比你认为的更大的数字只会改善估计，因为大多数人低估了。如果估计在商业目标上正确，那是一个不好的迹象。 - David Thornley
我并没有考虑到有人故意增加估算时间来弥补未知因素的情况。我更多地考虑的是根本没有对问题进行深思熟虑，只是随意选择一个整数的情况。 - tvanfosson
或者情况可能是信息不足，这种情况下最好的做法是猜测一个较高的整数。如果日程安排没有标记为暂定，那么我同意，使用整数会有危险信号。 - David Thornley
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接