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

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

第一类是文件故事（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 （后两者是火星人软件中的配置类型）

转载于:https://blog.51cto.com/cheny/1101574