这是敏捷开发绩效管理的第七篇。 续前文…… ## 功能点估算 ### 第一级简化 上次说到只用数据+操作就能准确计算规模，听起来够简单了，但其实还不够。 谁能在刚拿出2页纸的需求文档时（假设昨天老板在酒桌上刚从客户那记下来的），就猜出有多少个操作？而且还不遗漏？增删改查好猜，“加入角色”就不好猜了。 NESMA早就遇到过这个问题了，他们这么解决：通过统计发现每个数据差不多有7个操作，所以刚才咱们找出了3个数据，那么： 3个 × （数据7 + 操作4×7个操作） = 3 × 35 = 105，嘿，把角色和权限的操作问题也给解决了，不用猜了。 如果有几个数据要管理也不知道怎么办？那也太粗糙了吧，再去细化一下吧（别细化报表上有几个按钮，按了按钮后的逻辑是什么……那个和规模无关；只确认是不是数据）。 这样准吗？来自课后的10个数据表明，基于这种功能点作出的工作量估算与实际项目数据相比，最大误差在正负50%左右（本人手里没有详细数据所以没分析，应该取P50就是中值的误差比较好，可能在30%左右）。虽然听起来误差大得乍舌，但是在手里只有2张纸的时候，已经很准确了。某政府部门的要求是到400%以内都可以接受，因为他们在一个项目的招标中，4个供应商报价最大差别是12倍。 总结一下这一级别的简化方法就是：**每个内部数据35点**。另外如果是外部接口数据（比如要取LDAP），那么每个**外部接口数据15点**。 第一级简化适合**项目合同期/项目初始计划**的早期估算。 ### 第二级简化 如果项目已经完成了，不用猜了，就可以数到底有几个操作，就不用猜每个数据有7个了。 不过，到软件界面上面数显的很不专业，**如果我们的史诗故事是基于数据写的，用户故事是基于操作写的，数史诗故事+用户故事不就得了**？比如图中这个：  图中就是刚才提到的用户/角色/权限的局部，一共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. 有的项目好坏可不是光看开发的功能多少，还要看创意和…… 是的，**用这种方法度量绩效的目的，是为了提升开发绩效，加快开发速度，而不是计算工资奖金或评价项目好坏**。在[之四](http://blog.csdn.net/cheny_com/article/details/6713089)里边已经提到，必须在赚来钱的时候才能发奖金，它是由外部目标驱动的。 在产品开发中，往往收入与功能多少的关系不很直接甚至完全没有关系，但在一些直接由功能点报价的政府项目、外包项目里边，这个可以直接作为外部目标考核。   **本人正在参加CSDN博客之星评选，如果读完并喜欢这篇文章，欢迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) **** 点击下载免费的敏捷开发教材：《[火星人敏捷开发手册](http://blog.csdn.net/cheny_com/article/details/6616794)》