第2个问题，敏捷项目肯定是可以用功能点方法的。对于敏捷，这两种方法都可以用来度量规模，并进行一系列的绩效管理。

敏捷项目的每个sprint周期已经固定了，一般是2个星期。所以，在这个层次，我们推荐敏捷团队继续使用故事点的方法。

而在整个项目的层次，例如在这敏捷项目开始时，或者有产出物时，功能点方法更加有效。

项目开始时，可以用功能点来估算整个backlog的规模以及成本、工期。而在项目结束时，可以用功能点来统计实际的产出规模，计算实际的生产效率；比较敏捷与其他方法的绩效。

第3个问题，答案也是肯定的——故事点肯定是功能点更快、更容易。

使用故事点的方法，几乎不用什么培训和练习，所有的人都会很快的掌握和应用。

而功能点方法，使用者需要有专业知识，并经过大量训练；需要了解用户故事的详细信息。（这一点，我深有体会，要成为一个熟练的功能点专家，需要科学的培训，并进行大量的训练。）

故事点方法提倡敏捷团体在一起讨论，为用户故事计数，以此来衡量故事的难度和所需的工作量。 如此，可以保证敏捷团队都能够很好地理解故事。

而功能点方法的使用，让敏捷团队的每个成员都有这方面的技能是不现实的，通常的做法就是在整个组织层面成立“功能点专家小组”，为各个敏捷团队服务。

无论如何，将敏捷团队成员纳入规模估算的工作中，要比让他们强迫接受功能点专家的结论要强。（这一点，我们在很多咨询项目中都是如此。我们大量的培训了客户的需求、开发、测试以及项目管理和过程改进人员，让他们也尽量地参与到度量过程中，都取得了非常好的效果。）

“快和容易”不是关键，关键是你需要什么样的度量，需要什么样的信息——更好地管理产出物、制定决策、管理预期。

故事点度量的最大缺陷就是“缺乏一致性”，在一个敏捷小组的内部，用此方法是不成问题；但是不能在多个敏捷团队之间进行横向比较。

对于整个组织而言，需要的是——建立生产率基线、缺陷密度基线、测试案例密度基线、产品路线图、年度预算、人力资源计划等等。

对于这个组织级的管理需求，使用功能点方法，可以有效地来建立度量基础。

除此之外，功能点方法也可以帮助组织迅速提升业务分析、需求管理等方面的能力；可以有效地帮助IT组织从“成本型”向“价值型”转型。返回搜狐，查看更多