有关功能点的一些问题：

1)进行估算是否合理合理？ (我在这里并不是没有道理的，只是想知道与其他估算方法相比)

2)付出的努力是否值得我们从中受益？

3)我们使用哪种类型的功能点？

4)我们是否使用任何工具来执行此操作？

编辑：我有兴趣听取使用过或者曾经使用过的人的来信。我已经阅读了估计实践，包括各种技术的利弊，但我对实践的价值感兴趣。

解决方案

• 不可以，因为根据需求的作者的精确度(或者不精确度)以及功能点评估者的经验水平，任何特定的需求都可以花费任意的精力。
• 否，因为对抽象功能的不精确衍生的管理不会产生可靠的估计。
• 如果可以的话，没有帮助。
• 工具？对于功能点？ Excel怎么样？还是字？还是记事本？还是埃德林？

伟大的hacknot现在离线，但是它是书本形式。他有一篇关于功能点的文章：http://www.scribd.com/doc/459372/hacknot-book-a4，认为它们是一个幻想(我同意)。

Joel on Software有一个合理的替代方案，称为"基于证据的计划"，至少听起来像是可行的……。

迈克·科恩(Mike Cohn)在他的《敏捷估算与规划》中认为FP很棒，但是很难做到正确。他(显然)建议改为使用基于故事点的估计。我倾向于同意这一点，因为对于每个新项目，我越来越看到敏捷方法的好处。

1)进行估算是否合理合理？ (我在这里并不是没有道理的，只是想知道与其他估算方法相比)

就估计精度而言，功能点非常好。以我的经验，如果我们想正确地做的话，它们是很棒的，但是付出的努力却很昂贵。并不是很多项目都能提供详细的阶段来完成基于FP的估算。

2)付出的努力是否值得我们从中受益？

FP之所以出色，是因为它们已获得ISO的正式认可，这使估计具有很高的可信度。如果我们为大客户从事大型项目，则投资于看起来正式的详细估算可能会很有用。但是，如果不确定性的程度很高(例如其他供应商的集成，旧系统，宽松的要求等)，那么我们无论如何都无法获得精确的结果，因此通常我们必须接受这一点并在以后再次重申估计。如果是这种情况，一种更便宜的估算方法(用户故事和故事点)会更好。

3)我们使用哪种类型的功能点？

如果我正确理解了问题的这一部分，我们曾经根据特征点进行估算，但是逐渐远离这些特征点，几乎所有项目都期望对内部功能给予极大的重视。

4)我们是否使用任何工具来执行此操作？

Excel非常适合我们可以使用的所有公式。如果我们要协作使用Google Spreadsheets而不是Excel会有所帮助。

Sparx Enterprise Architect内置了一个很棒的工具，它使我们可以基于用例进行估算，这些用例也可以用于FP估算。

我从2002年至2005年是获得IFPUG认证的功能点专家，但我仍然使用它们来估计业务应用程序(基于Web的客户端和胖客户端)。我的经验主要是在较小的项目(1000 FP或者更小)上。

在使用了用例点和代码行之后，我确定了功能点。 (我已经在10多年的时间里一直积极地使用估算技术)。

Some questions about Function Points:
  
  1) Is it a reasonably precise way to
  do estimates? (I'm not unreasonable
  here, but just want to know compared
  to other estimation methods)

很难回答，因为这取决于我们在生命周期中所处的位置(从闪闪发光到完成)。我们还必须意识到，估算不仅要涉及精度。

它们的最大优势在于，结合历史数据，它们在决策者的压力下保持良好的状态。通过将项目范围与生产率(h / FP)分开，它们可以进行更具建设性的对话。 (当我是一名网络程序员，不得不说服我公司的创始人兼首席执行官的亲朋好友回去告诉他的投资者，并告诉他们他承诺的日期无法实现时，我第一次参与了基于指标的评估。我们所有人知道是这样，但是真正使他信服的是项目历史和功能大小(当时是本地的用例点)。

当我们必须在团队组建之前评估项目的可行性时，它们的优势在生命周期的早期是最大的。

与通常的看法相反，如果我们知道自己在做什么，那么花很长时间就能得出有用的数字。仅仅根据初次客户会议中推论出的基本信息类型(逻辑文件)以及我们团队的平均生产率，我可以得出一个粗略的数字(但不比那个阶段的所有其他未知数更粗糙)和一个有用的估计在一个下午。

将功能点分析与简化的需求研讨会相结合，我们将拥有一个很棒的项目设置方法。

一旦事情变得很严重并且我们提名了一个团队，我们将使用Planning Poker和其他一些估算技术得出一个独立的数字，然后将两者进行比较。

2) And is the effort required worth
  the benefit you get out of it?

绝对地。我发现准备计数是除所有其他好处外，它是查看用户目标级别的一致性和完整性要求的绝佳方法。甚至在建立敏捷项目时。我经常发现客户错过的暗示故事。

3) Which type of Function Points do
  you use?

IFPUG CPM(计数实践手册)4.2

4) Do you use any tools for doing
  this?

培训我的人给了我一个Excel电子表格模板。我们放入文件或者事务属性，它会为我们执行所有表查找。

最后，由于许多其他地方已充分记录了这些原因，因此NO估算值与Bean计数器所需的精度一样(或者更精确)。因此，我们必须以能够适应这种情况的方式来运行项目(为敏捷项目打三声欢呼)。

但是估算仍然是业务环境中决策支持的重要组成部分，而我永远也希望没有功能点。我怀疑把它们描述为"幻想"的人们从未见过它们的正确使用(相信我，我见过他们被夸大和滥用得怪诞)。

不要误会我的意思，FP有时会对他们有专横的感觉。但是，用丘吉尔的话来说，功能点是已知的最糟糕的早期生命周期估算技术，除了所有其他方法。

根据我对功能点的研究(我的一位老师非常参与功能点的理论研究)，他无法回答我们所有的答案。功能点在很多方面失败了，原因不是因为我们拥有可以正确评估的读写内容。我们可能会得到450个功能点，其中一些功能点将花费1个小时，而有些则需要1周。这是我将不再使用的指标。