故事点与功能点

北京软件造价评估技术创新联盟-罗翔

这些年来，关于“敏捷”的话题兴起、沉寂、又再度有些热闹。

最近，我们经常遇到客户咨询如何进行敏捷项目的度量？刚好看到国外的杂志上有相关的文章，大致翻译+自我阐述，与大家共享。

国际上，软件度量的标准方法是“功能点”（FP），这也是ISO标准，本身有近40年的历史。是一种严谨的、可取得一致性结果的方法。

随着敏捷方法论的出现，新的度量方法也就诞生了，那就是“故事点”（SP）——方法历史较短，至今没有形成国际标准；是相对的，主要是基于团队的自我感知。

我们遇到业界中三个常见的问题：

1、故事点与功能点有什么区别和联系？

2、敏捷项目的度量能用功能点方法吗？

3、故事点比功能点更快、更容易吗？

第1个问题，——

故事点是一种“相对”的度量，敏捷小组先选定一个最简单的故事，其规模=1，其他的故事的规模，与之相比较，用“斐波那契数列”来（1,2,3,5,8,13）相应的表示。不同敏捷小组选定的基线是不一样的。

而功能点则是有明确定义的，不同团队可取得一致性的度量结果。

在估算故事点的时候，团队总是难免要考虑到产品之外的因素，例如：需要投入的工作量。而功能点分析的时候，只考虑产出物自身的功能和特性，以及复杂程度。

故事点的方法，基本上是开发者视角。

而功能点方法，是用户视角，或者说是业务视角。可以同时为开发者和最终用户服务。开发者用来管理项目的产出，最终用户（Product Owner），可以用此来建立预期——通过明确地去定义产品的功能和特性。

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

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

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

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

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

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

而功能点方法，使用者需要有专业知识，并经过大量训练；需要了解用户故事的详细信息。

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

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

无论如何，将敏捷团队成员纳入规模估算的工作中，要比让他们强迫接受功能点专家的结论要强。

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

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

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

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

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