本文适合听过MPD上《敏捷开发需求管理：用户故事分类、颗粒度及组织结构》，或参加过《火星人敏捷开发培训》听过第一天下午课程的读者。

若您阅读过程中感觉缺少铺垫的信息，请先阅读：

 

敏捷开发绩效管理之六：敏捷开发生产率（中）（功能点分析，FPA，简化的功能点）

敏捷开发绩效管理之七：敏捷开发生产率（下）（简化功能点分析，NESMA，两级简化）

若需要更详细情况，请阅读：【在线研讨-现场文字】《敏捷开发用户故事分类与组织结构（一期-1）》2012-06-26

及一期其他所有文章。

与早期估算相关的两类用户故事

之前已经提到过，尽管用户故事规模、种类差异很大，但最终与项目开发规模直接相关的，是两大类。

第一类是文件故事（File Story），就是用户需要管理的业务数据。

比如一个人员管理系统，要管理用户/角色/权限这三个业务数据，那么就可以写下3个文件故事：用户，角色，权限。
如果不深究或来不及深究其中的细节（比如老板只拿回来一张纸上面写着这六个字，问“大约”多久可以完成），那么可以简单地这样估算：
1文件故事 = 40人天 = 2人月。（中国-政府行业软件生产率）
所以上述“人员管理系统”，需要6人月。
这可能和直观感觉大相径庭，“这么简单的事情，把需求告诉我，我一个下午就能做完。”
那么这6个人月包含什么呢？这个数据可以用来做什么？（亦即不可以用来做什么？）
使用文件故事做估算时的工作量包含
1. 需求分析/架构设计/编码/测试/部署（至初验款结帐），所包含范围的工作量大约是纯编码期的两倍略多
2. 需求模糊所需的讨论/测试/返工/修改缺陷/响应客户提出变更/乃至部署后提出的变更（在初验结账前），所包含的范围大约是“一次完成”的1～N倍。
4. 由于有多个人参与项目，所以由分工造成的文档/交流/沟通时间/修改别人Bug/人员离职时阅读别人的代码……等时间。
国内的20多个数据表明，若将团队控制在2人，生产率就能达到业界水平的2倍。但很可惜，“2人团队”一般需要至少一个业务和技术均过硬的高手参加，而除非一家公司1/2的人都具备这个素质，否则不可能全部变成2人团队。
5. 人员尽管定编在此项目中，但需要参加其他日常会议/领导前来打搅/紧急缺陷的修复/闲聊/上网……一切最终实际上会被填报在日志中的工时。某些时间看上去很不应该参与到生产率计算中（比如“闲聊/上网”），但因为永远不会有人单独填报“闲聊/上网”时间，所以它们实际上都被填报到日报中参加计算了；“领导前来打搅”的工作量，也不可能计算到其他项目中，所以也计算在人员所定编的项目中。
6. ……
这个数据可以用来做什么？
审视上面工作量的内容，会发现这个数据不是面向开发本身的，而是面向“成本”本身的，即若有任何工作量被计入成本（需要发工资或奖金的），而有没有其他项目可代为承担的，那么就计算到这个项目中。
所以，1文件故事 = 40人天 = 2人月这个计算方法，适合早期项目造价估算。
也就是企业只有提供2人月的成本，才能完成1个文件故事。
作为在项目初期想知道全貌的高层领导，“6个人月的成本才能从头到尾完成这3个文件故事”，要比“告诉我需求，我一下午就能开发出来”要有意义得多。

第二类是操作故事（Function Story），就是用户对业务数据进行的业务操作。

比如对一个人员管理系统，要管理用户，就要有增删改查等操作，这些操作都是业务语境中面向业务数据的，和我们平时说的数据操作不是一个东西。
FPA有一些方法，能根据业务操作估算出比仅仅知道业务数据时更准确的数据，但很可惜，这些操作的数量很难在项目早期估算出来，比如我问：除了增删改查，对“用户”还有哪些操作？在项目的初期，很难说的清楚。但实际工作的时候，就会发现落下了“批量操作”“冻结”这两个操作，而且，每次都只会落下而不会多估，反而不准确。
所以，在项目的初期，不要尝试用操作故事进行估算，而只使用文件故事。
不过，操作类故事可以被用于做生产率度量，因为在项目结束后，计数工作就不会有偏差了。这个，在日后会再谈。
火星人工具中，将来会推出利用用户故事度量生产率的功能，其前提之一是使用者利用火星人中对用户故事的定义进行描述。这一点在本文文初列出的研讨中描述。

非功能性需求造成的生产率波动

由于行业差异/质量要求/软件规模等，会造成生产率的差异，并非每个文件故事都要花费2个人月完成。
影响生产率的因素很多，按韩国的统计数据（韩国现在拥有全世界1/3的FPA专家），主要因素是应用领域差异，韩国的分类统计很细，简单说差异系数大约分别是：
1. OA/MIS类应用：1.0（即每文件故事 = 40 × 1.0人天，下同）
2. 科学计算类：1.4 （简单的财务软件/计算软件）
3. 实时控制类：1.7 （电信计费软件/生产管理软件）
4. 指挥管控类：2.2 （交通/核能/武器/航空等）
这些数字具体应用时并不准确，需要企业用自己的积累。
其他影响因素还包括质量要求、软件规模等，但影响率都只有0~20%左右，与应用领域相比不足为虑。

注：文件故事和操作故事及其英文File Story / Function Story，都是笔者自己临时起的名字，在国际上尚没有对用户故事绝对颗粒度进行讨论的先例。
文件故事得名于FPA中提到的内部逻辑文件（Internal Logical File），但与之对应的操作故事在FPA中被称为“交易”（Transaction，来自早期银行软件）过于难以理解，还是称之为操作故事（英文名Function Story则来自于我们日常所说的“功能性需求”）。
这种命名的混乱还会持续一段时间，取决于未来参与此话题讨论的结果。由于Agile和FPA都来自国外，很多讨论将照顾到国外的用语。
在此期间若看到以下中英文术语，他们大致是等同的：
业务数据 = 数据 = File = Internal Logical File （还有另外一种EIF） = File Story = Data = Data Story = FILE = DATA （后两者是火星人软件中的配置类型）
业务操作 = 操作 = 功能 = Transaction = EI/EO/EQ = Function = Function Story = Operation = Operation Story = FUNC = OPER （后两者是火星人软件中的配置类型）