project-management - 功能点分析——一种严重高估的技术？

Question

关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。












想改进这个问题？将问题更新为 on-topic对于堆栈溢出。

2年前关闭。




Improve this question




赏金澄清

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

如果您认为所引用的场景并不令人惊讶并且可以预期，请分解步骤以证明这样一个小应用程序如何花费一个多月和数千美元的开发。我做了相当多的计算(例如，查找最低工资)，所以我希望理想的答案能做类似的事情。

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

我知道关于 FPA 的问题已经被问过很多次了，但是这一次我会从一个更加分析的角度来分析它，并有数据支持。

1.首先，一些数据

此问题基于 tutorial .他有一个“样本计数”部分，他一步一步地演示了它。你可以看到一些screenshots of his sample application here .

最后他calculated the unadjusted FP成为 99 .

还有一个article on InformIT具有典型小时/FP 的行业数据。它的范围从 2 小时/FP 到 27.4 小时/FP。让我们尝试坚持2目前(因为 SO 读者可能是更有效率的人群:p)。

2.现实检查!？

现在只需查看 screenshots再次。

在这里做一个小数学

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

严重地？该示例应用程序将需要 5 周的时间来实现？仅仅是我的感觉，任何体面的程序员都不会花费超过一周的时间(我什至没有说周末)来完成它？

现在让我们尝试估算项目的成本。我们将使用目前纽约的最低工资 ( Wikipedia)，即 7.25 美元

198 * 7.25 = $1435.5

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

(作为记录，同一个网站还有另一篇讨论生产力的文章。似乎他们通常使用 4.2 小时/FP，这给了我们更令人震惊的统计数据:

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

(这甚至假设我们所有可怜的程序员都拿到了最低工资!)

3. 我在这里遗漏了什么吗？

现在，我可以想出几个可能的解释:

FPA 实际上只适用于较大的项目(1000+ FP)，因此它在较小的规模上变得极其不准确。

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

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

FP 专家对此有何回答？

Answer 1

大约十年前，我的一个酒友给了我一个非常棒的智慧。在任何项目咨询中，要问三个问题: 1. 我们要解决的问题是什么？ 2. 可交付成果是什么？ 3. 我们如何知道何时完成？他补充说，任何人都不应该承担在项目开始之前没有回答任何问题的任何项目。

在手头的案例中，我们还有另一个软件估算方法的恐怖故事，其中估算值似乎高得离谱。我会通过指出他没有回答第二个和第三个问题来回答他的恐怖故事，他也没有真正回答第一个问题，只是说“我们想要 build 一些像这样工作的东西”。

我将对此进行扩展，指出他甚至没有明确询问功能点估计包括或排除在估计总数中的任务。例如，功能点估计器允许记录多少额外的工作？如果他的估计是针对没有任何文档的应用程序，而功能点估计器的估计是针对具有完整文档的应用程序，那么我想说在所需的工作总量(和时间)上有一些分歧的余地。