5.2 交付对象模型
在我为其担任咨询顾问的很多团队里，大家常以功能或是模块作为交付对象的单位。这样的方式虽然在操作上感觉比较自然，因为大多数人都是以功能或模块为边界，自上而下地分解和理解一个系统，但从度量角度来讲，这种方式在粒度上就比较模糊。我在计划和评估会上经常看到一两百行代码的功能和三五千行的功能在同一个层面上讨论。即使拋开对功能和系统本身的熟悉程度、个人的经验和评估能力，这种方式在估算和度量的准确性上其实很成问题。这是由于我们在做判断的时候，经常会受到锚定偏见/基准点偏见（anchoring bias）的影响
，这种心理上的偏见很容易就把我们带到坑里去，而且很难仅靠小心谨慎来排除。
锚定偏见是心理上的一种经验性的或是启示性的作用，会对人们的评估结果造成影响。当我进了一个餐馆时，在菜单上看到大多数菜至少都是八九十元一份，更不消说那些几百元、数千元的海鲜了，这时偶尔看到个三四十元的菜，顿时觉得这个还挺便宜啊，其实就是个炒时蔬或是某个家常菜。人们通常会根据前一个数字来对后面的数字有个判断或是预期。在软件的工作量评估当中产生的结果就是，不管一个功能实际的大小如何，人们通常在估算的时候，倾向使结果靠近前面己经估算的功能的大小量级上。那么估算一组大小相差极大的功能，其结果就很容易受到这种偏见的影响。比如我们刚刚估算一个大约3000行代码的功能，后面马上要估算的一个功能比起前面一个小很多，我们通常倾向于至少估个800行或是至少500行，不会太情愿放个200行的数字。因此，为了能够更加系统地对度量的对象作出分析，我们需要对交付对象的粒度有个合理的定义。
为了能够找到合适的粒度，我们先需要寻找一个合适的方式来拆分度量的对象软件。敏捷开发提倡以端到端的方式划分交付的对象，期望每个划分出来的交付对象必须能够为软件的用户（不管用户是一个自然人还是另一个存在交互关系的系统）提供直接的价值，为此还提出了划分用户故事的INVEST原则（见右图），其中的V就指的是价值（Valuable）。在不同的软件开发流派当中，对端到端特性的描述术语有所不同。
Extreme Programming（极限编程）的实践者大多使用用户故事（User Story）描述客户需求。用户故事用简短的日常或业务语言来描述用户的行为和需要，关注的是“谁”，“要做什么”，“为什么”。Mike Cohn在他的《User Stories Applied: For Agile Software Development》中提到了用户故事的3个方面，如下所述。
●用于计划或是提醒的描述性记录（是工作量估算和任务划分的载体）。
●作为交流的载体，辅助对话者发掘相关生动细节。
●作为测试的载体，为测试传递和记录需求细节，并决定用户故事什么时候算是结束。
Unified Process在建模上给予相当多的关注，认为模型能够帮助人们理解并形成对问题的定义，并使解决方案具象化。从捕获需求的角度来讲，Unified Process选择用例建模（User Case M odeling）这样一个背景不同的人都能理解的方式，以期获得诸如用户、开发人员、客户、管理者等，更广泛的干系人的理解和共识。用例方法早先由Ivar Jacobson 在其著作《Object Oriented Software Engineering: A Use-Case-Driven Approach》里首先引入，而Alistair Cockburn的《Writing Effective Use Cases》一书则系统地展示了用例的实践方式。其所用的例子都很有借鉴意义，有很强的可操作性，为用例使用的推广起到了很大的作用，就连Extreme Programming的实践者在需要细化用户故事的时候，也经常会采纳用例的描述形式。
Scrum定义的Product Backlog是一个按优先级排序的需求列表，但却没有定义backlog里的需求是在什么样的粒度上，以什么形式描述，因此实践者一般都从其他流派借来了需求的发现、分析和描述方法。这其中用户故事在敏捷社区里被使用等似乎更加广泛一些，也有不少人倾向于使用Use Case的方法。
在《Agile Software Requirements》一书中，Dean Leffingwell尝试着梳理敏捷理念下的需求管理体系，使其能够适应不同规模、类型的开发场景。其中一个重要的做法是把软件开发组织处理的工作单元分成了4个层面：投资主题（Investment themes）-Epic-特性-用户故事。具体见图5-2。我们用前面的Big Bank的一个系统来介绍一下这几个层面的开发对象大概是个什么样子。
投资主题（Investment Themes）——一家企业可能在向市场提供多个产品或产品线，在这些产品组合上的投入程度是以企业的产品战略为前导的。企业通过计划一系列的投资主题来获得合适的产品布局，从而达成最终的战略目标，这个时候交付单位就是投资主题-Investment themes。
Big Bank决定在下一个阶段里，一个重要的投资主题是，通过其数字在线渠道，针对零售客户（就是像我们这样的普罗大众），提供业界最丰富、方便的理财服务。
Epic/特性——一个大规模系统的开发通常以项目或项目群的方式组织，多个团队会并行工作在一个敏捷发布火车上（Agile Release Train）。这个时候管理和度量的对象是PSI（Potentially Shippable Increments）可交付的增量，可交付的增量经常用特性或是Epic来代表。Epic一般指的是在比较高层面的描述，通常一两句话，可以被分解成一组相关的特性。
在Big Bank的一个Epic是贵金属投资下的黄金交易。在黄金交易有两个特性：即时交易、委托交易。
这个场景下，委托交易已经是一个最小的可交付的增量（PSI），如果再细分下去，比如分解成买入和卖出两个子特性，这两个子特性是没法独立交付的，因为用户没法接受只能买入或是只能卖出。
用户故事——在团队层面上，管理和度量的对象是团队Backlog中的故事列表。
在Big Bank的黄金委托交易里有两个用户故事，如下所述。
（1）委托买入：作为投资用户，我想要委托Big Bank在给定的时间內，如果黄金价格跌到一个给定数字的时候，能为我买入给定数量的黄金，为了能够以我预期的比当前价格更低的价格及时买入黄金。
（2）委托卖出：作为投资用户，我想要委托Big Bank在给定的时间內，如果黄金价格涨到一个给定数字的时候，能为我卖出给定数量的黄金，为了能够以我预期的比当前价格更高的价格及时卖出黄金。
图5-2 度量对象分解
除了明确各个层面的交付对象，另一个需要厘清的概念是什么代表了完成。