scrumcn_efficiency

敏捷开发生产率(上)

度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容。

 度量敏捷生产率的目的

真正难以回答的是度量生产率的目的是什么?

很多人都认为是考核绩效,发奖金。根据上一篇文章的内容我们可以知道,这完全是行不通的:客户并不购买我们的生产率,生产率高也并不能证明产品或项目盈利,应该为团队设立外部目标,否则很可能得到一个生产率很高,但是实际上很烂产品——质量上或易用性上很差,抑或其他想象不到但一定遇到的原因。这是我们说为什么用外部目标而非内部目标考核团队的原因。

或许又有人说:“开发得快不快是团队的事情,产品好不好则是产品负责人的事情。”这样也不对,相当于我们在自组织之后,当我们享有勇气,尊重,沟通……这些敏捷的特质之后,我们居然得到了一个只关心自己的开发速度,而置客户价值和企业利益于不顾的团队。“受激励的个体”只被自己小团队的绩效所激励,并不爱也不关心自己的产品,这绝对不是敏捷开发的初衷。

度量生产率的目的不是绩效考核,而是是希望提升生产率绩效。将度量结果进行横向和纵向比较,可以分析造成生产率差异的原因,并进而提升生产率绩效。
微观度量方法-故事点
故事点估算方法

“每月完成的人天数”这个方法不说了,用尺子量尺子,肯定不行的。不过通过统计每月的实际投入天数,可以优化人员利用率,并间接提升生产率。

“每月完成的故事点”这个是比较好的方法。

所谓故事点法,就是提前选择一些大家都熟知的、以往做过的、典型的故事,比如:

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人团队想自己做一套恐怕更难。

回过头来观察他们公司的失败原因,是在为新的故事找到对应的标准故事后,没有根据其差异进行调整,而是机械地选择了标准故事的故事点,导致误差很大。在采用故事点的时候应该注意。但他们考虑到某些故事的回归结果居然是负数,即使“进行调整”结果也会是血淋淋的,甚至可以说基本扔到了标准故事从头估算,最终放弃了故事点,采用了另外一种方法,就是下篇文章提到的“功能点估算”。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载