scrumcn_efficiency

敏捷开发生产率(下)

功能点估算
第一级简化

上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够。

谁能在刚拿出2页纸的需求文档时(假设昨天老板在酒桌上刚从客户那记下来的),就猜出有多少个操作?而且还不遗漏?增删改查好猜,“加入角色”就不好猜了。

NESMA早就遇到过这个问题了,他们这么解决:通过统计发现每个数据差不多有7个操作,所以刚才咱们找出了3个数据,那么:

3个 × (数据7 + 操作4×7个操作) = 3 × 35 = 105,嘿,把角色和权限的操作问题也给解决了,不用猜了。

如果有几个数据要管理也不知道怎么办?那也太粗糙了吧,再去细化一下吧(别细化报表上有几个按钮,按了按钮后的逻辑是什么……那个和规模无关;只确认是不是数据)。

这样准吗?来自课后的10个数据表明,基于这种功能点作出的工作量估算与实际项目数据相比,最大误差在正负50%左右(本人手里没有详细数据所以没分析,应该取P50就是中值的误差比较好,可能在30%左右)。虽然听起来误差大得乍舌,但是在手里只有2张纸的时候,已经很准确了。某政府部门的要求是到400%以内都可以接受,因为他们在一个项目的招标中,4个供应商报价最大差别是12倍。

总结一下这一级别的简化方法就是:每个内部数据35点。另外如果是外部接口数据(比如要取LDAP),那么每个外部接口数据15点。

第一级简化适合项目合同期/项目初始计划的早期估算。
第二级简化

如果项目已经完成了,不用猜了,就可以数到底有几个操作,就不用猜每个数据有7个了。

不过,到软件界面上面数显的很不专业,如果我们的史诗故事是基于数据写的,用户故事是基于操作写的,数史诗故事+用户故事不就得了?比如图中这个:

scrumcn1373889054

图中就是刚才提到的用户/角色/权限的局部,一共3个数据(小课本是史诗故事),外加19个操作(蓝色的是用户故事,其中两个“新建+查看”分别代表两个,要×2),加起来是 3 × 7 + 19 * 4 = 21 + 76 = 97,已经很接近105个了……如果考虑到这个软件还没有编完,我们第一级简化还是蛮准的嘛(归功于NESMA的长期努力)。

完成这些功能需要 105 × 9 = 945 小时 = 118人天。如果我们有一个迭代,正好要完成这些功能并将其部署上线,那么就按118天计算吧(如果只编写出来不测试,大约是70%的工作量)。当然这不是说任何一个人都花相同的时间,而是基于现在业界收集上来的数据,团队人均花费这么多。个体的生产率差异可达5倍,但团队却都差不了太多。

另外单个故事的精度也很差,比如如果某人正好编过某功能,可能一小会就完成了。但是如果很多人编写很多故事,大数定理会起作用。

总结一下这级别的简化方法就是:每个内部文件按7点(每个外部接口按5点),每个操作按4点,加起来就是功能点。

这个级别的简化适合每个迭代确定工作量;还可以在项目完成后,总体计算开发效率作为绩效管理的依据(算是回到绩效管理了)。

遗留问题

正如前言,很多敏捷世界的新鲜事,在别的世界早就不是新鲜事了(当然别的世界也有他们的新鲜事),提出和解决下面这些问题的很多前辈都已经去世了。

本文只是指出有这么一种方法,并非这种方法的操作手册,这种方法还是需要培训的(有现成的)。

1. 就这么简单?

不是,简化的功能点大约需要一整天的培训,后续估算(推导工作量/工期/成本)还需要一整天。里边有很多细节。

复杂的功能点大约需要2~3天培训,另外一般5天左右的指导,如果要CFPS证书还有一个3天左右的考前指导。

2. “每个用户操作 = 一个用户故事?那修Bug怎么办?做小的改动怎么办?提升性能怎么办?”

可以记录成不同类型的故事,但是就别计算功能点了。图中三个绿色箭头,就是三个对原有故事的“增强”,其特点就是无法描述为完整的用户操作。

他们不计数,但是在统计时已经被平摊到计数的故事里边了。

我自己实践的时候发现,有些故事为了开发方便,极有可能包含两个操作(如上面的“角色首页”包含新建和查询两个操作),建议可以当作一个故事,怎么舒服怎么来不要太生硬,但是加个记号知道是2个操作,防止数错。

3. 每个数据都是/才能是史诗故事吗?

不一定,我有一个史诗故事叫做“性能优化”,它就不是,也不计算它。

4. 每个动词都是操作?

不一定。简单而言就是只有”主语是用户“的动词才是操作。”。

暂时还没有遇到有些Backlog Item不是用户操作但是很想当成用户故事的情况,如果有,可以在史诗故事/用户故事上设置一个字段,如果是才计数。

5. 非功能性需求怎么办?

最早提出来也最早被解决的问题,标准功能点的非功能性调整因子是1970左右(天啊……)提出的有点老了多数都不适用了;个人最喜欢的是韩国标准中的调整因子,大致可以理解为普通的乘1,科学计算之类的乘1.3左右,运营计费乘1.5左右,生死攸关的乘2左右。

非功能性调整因子一般包括规模因子、领域因子(韩国标准包括8大类约50小类)、质量因子(韩国标准包括4个质量因子,每个三个等级)、开发语言因子这几个。有时候不会觉得他们考虑不周,反而是多虑了……

6. 准吗?

不准。因为这种方法虽然很准,但是那个”9小时/功能点”是业界数据,最好用自己的数据重新回归一下。

本人正在回归自己的,可惜只有一个项目在做,所以不得不每个迭代都当作项目来看待。一般稍微大点的企业有一年时间积累20个(子)项目数据就可以了。

7. 有前途吗?

有。芬兰,澳大利亚,韩国,日本……的政府采购均采用这种方法计算价格。中国的国标预计在明年出台,即政府采购项目均将使用这种方法报价(或指导报价)。

8. 有的项目好坏可不是光看开发的功能多少,还要看创意和……

是的,用这种方法度量绩效的目的,是为了提升开发绩效,加快开发速度,而不是计算工资奖金或评价项目好坏。在前篇已经提到,必须在赚来钱的时候才能发奖金,它是由外部目标驱动的。

在产品开发中,往往收入与功能多少的关系不很直接甚至完全没有关系,但在一些直接由功能点报价的政府项目、外包项目里边,这个可以直接作为外部目标考核。

 

作者:陈勇

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