Project management 功能点分析——一种严重高估的技术？ 赏金澄清

我知道这是一个主观问题。我正在寻找的理想答案是一个解释为什么这里引用的场景会如此令人惊讶的答案

如果您认为所引用的场景是事实，这并不令人惊讶，也符合预期，请详细说明这些步骤，以证明这样一个小应用程序如何可以花费一个月的时间和数千美元的开发。我做了相当多的计算（例如，查找最低工资），所以我希望理想的答案也能做类似的计算

如果您认为引用的情景确实被高估，请准确指出您的原因。在他的计算中，你能发现哪些错误导致了这样一个简单应用程序的巨大成本？你会怎么做呢？（不需要写整个过程，但最好是细节而不是概括的感觉）

---

我知道关于FPA的问题以前被问过很多次，但这次我从一个更具分析性的角度，以数据为依据

1.首先，一些数据 这个问题是基于一个假设。他有一个“样本计数”部分，在那里他一步一步地演示。你可以看到一些

最后，他被选为

99

还有一个是关于典型小时/FP的行业数据。其范围为2小时/FP至27.4小时/FP。让我们暂时坚持使用

2

（因为读者可能是更高效的人群：p）

2.现实检查！？ 现在再检查一下

在这里做一点数学

99 * 2 = 198 hours
198 hours / 40 hours per week = 5 weeks

真的吗？这个示例应用程序需要5周的时间来实现？这只是我的感觉，它不会需要任何体面的程序员超过一个星期（我甚至不是说周末）完成吗

现在让我们试着估算一下项目的成本。我们将使用纽约目前的最低工资（），即7.25美元

198 * 7.25 = $1435.5

从截图中可以看出，这个应用程序是一个小型excel改进应用程序。我本可以花200美元购买MS Office Pro，这给了我更好的互操作性（.xls文件）和灵活性（电子表格）

（为了记录在案，同一个网站上还有另一篇讨论生产率的文章。看起来他们通常使用4.2小时/FP，这给了我们更令人震惊的数据：

99 * 4.2 = 415 hours = 10 weeks = almost 3 whopping months!
415 hours * $7.25 = $3000 zomg

（这甚至假设我们所有可怜的程序员都能拿到最低工资！）

3.我是不是遗漏了什么？ 现在，我可以想出几个可能的解释：

FPA实际上只适用于较大的项目（1000+FPs），因此在较小的规模下变得极不准确

小时数/FP指标在团队之间、项目之间突然波动。对于这样的小项目，我们可以使用0.5小时/FP之类的指标。（现在这种情况使得整个估算毫无意义，除非我的公司在同一团队中做了几年同一类型的项目，这并不常见。）

从我对几个软件指标的经验来看，功能点并不是一个轻量级的指标。如果小时/FP值波动如此之大，那么重点是什么，也许我可以选择用户故事点，它可以更快地获得，并且可以说几乎同样不确定

---

FP专家对此的答案是什么？

在我以前的公司，我们会这样计算——特别是如果有人想为此付费的话；）

这只是我的感觉吗 任何一个像样的程序员花的时间都比 一周（我甚至不说周末） 完成它

开发人员总是倾向于低估实际完成某件事情所需的时间。他们认为不会有bug，需求不会有变化，他们以前从未做过任何事情，需要花上几天的时间来解决

从照片上我可以看到 屏幕截图，此应用程序是一个 小excel改进应用程序。我可以 以200美元的价格购买了MS Office Pro 给我更多的钱 互操作性（.xls文件）和 灵活性（电子表格）

---

你是在比较一个完全定制的软件和一个销售数百万份的软件的价格？说真的？

事实是，大多数软件评估方法实际上低估了价值，尽管乍一看，这似乎违反直觉。我曾经在一家公司工作，那里每个人月300行代码被认为是一个很高的估计值，而大多数月份我们的输入量都在200-250行左右。但我们还是用200吧。这是每个工作日10行代码。谁不能在一个工作日内写出10行代码？来吧我可以在一个好日子里写50到100行甚至更多的代码！然而，使用类似数字的公司却一再推迟进度、超预算完成项目。为什么呢？正如迈克尔·博格沃德所说，范围蔓延是个大问题。但是，让我们把这一点拉出来，假设客户和客户第一次就做对了。为什么一家公司每天只估计10行代码

• 需求分析
• 基于需求的软件设计
• 与团队成员协调接口和架构的会议
• 间接费用（与管理层的状态会议、病假、休假等）
• 编写单元测试
• 为整个应用程序编写测试计划
• 应用程序级测试

---

这就是我能在3分钟内完成的所有日常软件工程，我肯定我错过了更多，但这是否有助于更完整地了解这些估算的来源？

不是FP专家。然而，我们目前正在研究FP。特别是，我们正在对旧项目执行FP分析，我们有工作量/成本等指标。然后，我们可以评估其对我们评估/确定项目规模的有用性

我的观点是，这将是一个有用的自上而下的“数量级”估计，以补充自下而上的估计。