本博客中关于功能点分析FPA的文章索引

本博客中有不少篇幅是关于功能点分析的（也称功能点度量），不过都是分散在各自的系列中，因整个开发过程的需要而存在。

最近不少人问到哪里有功能点度量的内容，所以做一个索引，来总体说一下本博客的相关内容。

基本介绍类文章

敏捷开发绩效管理之五：敏捷开发生产率（上）（故事点估算） 及同系列的之六、之七（在文章的第一行有链接）.

之五主要提到故事点（一种尝试使用功能、历史数据进行绝对规模度量的敏捷方法）及其局限性，而之六、之七则提到NESMA的早期功能点估算法。

NESMA功能点估算法是国际标准之一（一共有五个，大家比较熟悉的应该是IFPUG的FPA方法，两者大同小异，几乎可以直接通用，对同一软件的度量差别可以忽略不计）。为了适应早期需求文档不明的状态，NESMA推出了两种简化方法，其中一种（indicated function point具有指导性的功能点)非常适合早期使用，是未来中国造价估算国标的估算模型。

不过，尽管用起来简单，但组织内应该有一个或一些人对标准方法（即非简化的方法）有所了解，才能保证可以大胆而正确地使用简化方法。

敏捷开发用户故事系列之九：用户故事早期估算

本篇描述了一种在敏捷开发中使用FPA的方法。实际上，它通用于任何试图将需求进行条目化的场合。

实践类文章

敏捷开发中史诗故事与用户故事的颗粒度

本文是下面三次研讨的总体框架，但编写的时间很早，所以不如下面的研讨深入。

【在线研讨】《敏捷开发用户故事分类与组织结构（一期）》2012-06-26（周二）

本次在线研讨的一期，整体描述了在火星人软件开发过程中功能点的实际使用情况。注意度量生产率在火星人开发过程中不是核心价值（在产品开发中，生产率相对次要；在项目开发中，生产率占有主导地位），更多地是如何使用功能点分析方法实现用户故事的合理结构。

之所以将功能点分析方法的概念引入敏捷开发，是因为敏捷开发没有很好地定义用户故事的绝对颗粒度，甚至连何为一个用户故事，都没有被广泛达成共识的定义。

而功能点不但形成了五个国际标准（实际上其内容大同小异，可以理解是不同地区的功能点组织独立发展的结果，但其度量方法和结果几乎相同），还被很多国家政府广泛用于软件采购中的报价。国际上现在掌握在不同组织手中的基于功能点的项目度量数据大约在3～5万个左右，还没有任何另外一种方法比如故事点、代码行、用例点拥有相同乃至于次一数量级的度量级。

本次研讨的第二期描述了功能点与后期的开发任务之间的关系；第三期则描述量功能点与编码的关系。在这两期中，功能点中的ILF和EI/EO/EQ以文件故事（或数据故事）及操作故事的名称存在，请注意区分。

数据分析类文章

敏捷开发“松结对编程”系列之十：L型代码结构（技术篇之一）

本文包含火星人中基于功能点度量的一种用法：如何度量“编码有效性”，即大约多少行代码可以实现一个功能。为了产生通用的可比较的“一个功能”，在这里使用了功能点度量。

国际网站

国内对功能点的讨论不但少而且浅，基本上达不到实际使用或数据分析的程度。当前国内的功能点度量数据不超过30个（至2012-10-15），所以缺少分析价值。

国外的网站可参考以下几个，上面有大量的免费资料可下载：

http://www.ifpug.org 最大的功能点国际组织，在中国组织过1次功能点培训。

http://www.nesma.org 第二大功能点组织，也是本博客中提到的早期功能点分析方法的推广者，注意他们有英文和荷兰文两个网站。

http://www.isbsg.org 世界上最大的软件度量公益机构，其CEO Peter Hill多次来到中国，我曾经为他进行过多次翻译。可以向他们提交数据以换取对在线估算系统的使用；另外以前可以购买数据光盘包含6000多个基于功能点的估算数据，不过数据相对有点陈旧，开发语言也和国内相差较大，需要有经验的人才能用好。

http://www.spr.com 美国生产力研究所网站，实际上是一家公司，拥有多达两万多个项目数据，不完全是功能点。其北京办事处曾设于笔者的楼上，所以接触很多并一起给中国银行和广州从兴做过功能点咨询。现在亚太办事处改为菲律宾了。