度量敏捷开发的生产率一直是个难题，确切说度量任何开发方法的生产率都是一个难题，但它实际上有答案，这个答案是本文的主要内容。
度量敏捷生产率的目的
真正难以回答的是度量生产率的目的是什么？
很多人都认为是考核绩效，发奖金。根据上一篇文章的内容我们可以知道，这完全是行不通的：客户并不购买我们的生产率，生产率高也并不能证明产品或项目盈利，应该为团队设立外部目标，否则很可能得到一个生产率很高，但是实际上很烂产品——质量上或易用性上很差，抑或其他想象不到但一定遇到的原因。这是我们说为什么用外部目标而非内部目标考核团队的原因。
或许又有人说：“开发得快不快是团队的事情，产品好不好则是产品负责人的事情。”这样也不对，相当于我们在自组织之后，当我们享有勇气，尊重，沟通……这些敏捷的特质之后，我们居然得到了一个只关心自己的开发速度，而置客户价值和企业利益于不顾的团队。“受激励的个体”只被自己小团队的绩效所激励，并不爱也不关心自己的产品，这绝对不是敏捷开发的初衷。
度量生产率的目的不是绩效考核，而是是希望提升生产率绩效。将度量结果进行横向和纵向比较，可以分析造成生产率差异的原因，并进而提升生产率绩效。
微观度量方法-故事点
故事点估算方法
“每月完成的人天数”这个方法不说了，用尺子量尺子，肯定不行的。不过通过统计每月的实际投入天数，可以优化人员利用率，并间接提升生产率。
“每月完成的故事点”这个是比较好的方法。
所谓故事点法，就是提前选择一些大家都熟知的、以往做过的、典型的故事，比如：
1. 对单个表进行增删改查
2. 对父子表的增删改查
3. 为一个已经存在的数据表增加一个复杂报表
4. 修改一个中等难度的BUG
……
（实际上这些故事应该是具体的，而不是像上面例子中一样看起来更像是“分类”）
然后人拿出当年的历史记录，将当时所投入的人天数称为“故事点数”（也有别的做法但这个最简单）。比如“对单个表进行增删改查”当年用了4天，那么标准故事点就是4。
当下次估算时，人们又发现有一个故事也是“对单个表的增删改查”，于是就先选定基数为4，再讨论这次与上次比，到底复杂多少。如果一致认为可能复杂20%，那么故事点就是5。
如果大家的生产率不变，那么这个故事应该5天完成，但是如果结果却是4天就完成了，则表明大家的生产率提高了。当然不是一个一个故事度量，而是把整个迭代内的故事点加起来度量。
通过纵向比较故事点，可以知道大家是否比以前的生产率提高了。
横向比较故事点比较有难度，因为每个团队乃至项目都会选定自己特有的标准故事，而且极难说明这个团队和那个团队的标准故事的转换关系。
故事点的局限性
在推广故事点这件事情上笔者有所保留，建议尝试但需注意风险，必要时知难而退。在笔者遇到的这么多做敏捷的企业和人里边，还没有见到有人提到他们的故事点应用是成功的。
原因在于找到大家都熟知的、以往做过的、典型的故事很难，而让所有人记住它们当年的详细情况以便日后对比修订就更难。
04年笔者去做咨询的一家企业有他们的故事点模板（他们并不做敏捷开发，但却使用完全类似的方法），一共有17种标准故事，已经记录了25个项目的故事点数据和实际工作量数据，每个项目从4个故事到上百的故事不等，他们希望笔者能帮他们计算一下“17个标准故事分别对应多少人天”。终于遇到了又有标准故事又有历史数据的情况，这比所有一穷二白想使用故事点的企业可乐观多了。
这是一个所谓“线性规划”的问题，涉及“最小二乘法”“超越方程”这些玄乎的名词，但却在Excel表里有这个功能，不过是10分钟的事情并不费力，真正费力的是解释其结果：求解的答案是——某些标准故事是负数，也就是说如果把这几种故事当作负数对待，那么以往发生的25个项目的预测结果与实际结果最符合。
再换一种直白的解释：用这17种故事预测工作量不准。
或许有人会说他们的17种故事选得不好，或他们的水平很差。怎么说呢，他们是一家1000多人的电信企业，专职做过程管理的人就有5人，还认真地记录了这么多数据，恐怕当年选定故事的过程也是经过思考的。倘若他们都难以建立其故事点，一般的10人团队想自己做一套恐怕更难。
回过头来观察他们公司的失败原因，是在为新的故事找到对应的标准故事后，没有根据其差异进行调整，而是机械地选择了标准故事的故事点，导致误差很大。在采用故事点的时候应该注意。但他们考虑到某些故事的回归结果居然是负数，即使“进行调整”结果也会是血淋淋的，甚至可以说基本扔到了标准故事从头估算，最终放弃了故事点，采用了另外一种方法，就是下篇文章提到的“功能点估算”。
作者：陈勇
本专栏经作者授权开设，专栏文章未经许可不得转载
