故事

每个人都喜欢听故事，这也许是从小就养成的习惯。如果能够把需求分析工作变成听故事的过程，那该有多好。需求分析人员写出一个个优美的故事，开发人员边看故事，边实现故事。也许这就是XP的设计思路所在。用户故事，XP把需求变成了一个个故事，摒弃了枯燥无味的需求稳定。文档的作用是传递信息，如果失去这个意义，再优秀的文档也没有任何用处。但是，完整细致、厚达数十页的需求文档是否真的能够达到沟通的目标呢？对于大多数而言，恐怕看到文档的厚度就已经心生惧意了吧。好吧，我们通过很多的辅助手段，可以强制要求开发人员都投入大量的精力来研究、学习复杂的需求文档。但是这厚厚的需求文档真的能够完整的记录所有的需求吗？更糟糕的是，需求是会发生变化的，到时候如何维护这份需求文档呢？回想精益原则，我们可以判定，这种处理需求的方式一定会产生大量的浪费。将需求做的尽善尽美需要成本，项目组的人员熟悉需求需要成本，维护文档需求成本，解决不一致的问题也需要成本。那么，我们可以针对这几点做一个分析：

• 需求的文档是否要尽善尽美？需求文档的最大目标是将信息从业务人员传递给开发人员（当然也会存在其它的目的，例如作为合同的组成部分）。那么，文档是否完美和能否实现沟通效果并没有直接的关系。
• 开发人员怎么才能够快速理解需求？文档的制作融入了制作者的思想，因此他人理解总是需要一定的时间的。解决问题的思路有两个：一是提供标准通用的做法；二是简化文档，简单的东西总是要容易理解，但简单的东西并不等同于制作容易。
• 维护文档需要成本。不管如何，维护成本始终是无法避免的，关键在于，能否降低这部分的成本呢？维护成本和文档数量、复杂度成正比，因此文档的数量要尽可能的少、复杂度要降低。此外，减少维护的次数也是关键的因素之一，在讨论精益原则的时候我们说尽可能推迟决策就是这个意思。

针对以上的几点，XP提出了自己的实现思路－用户故事。用户故事简单，每个人都会写，每个人也都能理解，改变起来也很容易。但用户故事只是对系统功能的一个简单的描述，他并不能提供所有的需求内容，因此，在XP中，用户故事的实践需要现场客户的支持。用户故事之所以简单，是因为它只是开发人员和客户之间的一种契约，更详细的信息需要通过现场客户来获得支持。

从XP的观点来看，用户故事有这么几点作用：

• 客户自己描述、编写需求。对于任何一个需求来说，最理想的状态都是开发人员教授客户编写需求。最差的情况是开发人员代替客户编写需求。毫无疑问的，XP要求的就是最优秀的做法。客户要能够自己开发需求，前提条件是编写需求的技巧应该足够简单，能够很容易掌握，或是经过培训很容易掌握。用户故事就是这样一种简单的机制。
• 用户的观点。优秀的需求应该是站在用户的角度来思考问题，是用户能够利用系统完成什么，而不是系统自己完成。用户故事很好的达成了这一原则。因为用户故事是用户站在自己立场上编写，表现了用户对系统的期望和看法。
• 重视全局，而不是细节。需求有精度上的差别，软件开发初期最关键的，是建立一个高阶的需求概况，而不是立刻深入细节。对于XP来说，最主要的细节需求获取的方法是经过现场客户。现场客户随时提供对需求细节的指导。因此，用户故事的重点在于，尽可能全面的发现需求，以及，维持一个简单的需求列表。
• 评估的依据。用户编写的需求为软件的估算提供了依据。虽然这个依据是比较粗的，但随着项目的发展，开发速度的估算会越来越精确。在需求初期就进行适当的估算，其目的是让用户能够有一个比较直观的成本概念。这为用户制定需求实现的先后次序提供了指导。
• 用户自己的统筹安排。制定用户故事就像是上商场购物，虽然每件物品都是有用的，但是最后购买的次序和数量则要取决于钱包的厚度。在每一个用户故事具有了成本（即上一条中的估算）之后，用户就能够权衡实际成本和需要，并排定需求的座次。
• 迭代计划的输入。用户对用户故事的选择直接影响到迭代计划的制定，在第一个版本中，用户希望能够实现哪一些的需求（通过选择用户故事），经过估算，这些需求是不是能够在这个版本中实现，计划需要多长的时间。这些都是需求对迭代计划的影响。

故事的弊端

以上是一个银行的国际结算业务中款业务的例子。简短的叙述和非正式的形式体现了XP强调的简单原则。故事帮助开发人员和用户理顺流程的关系。在上述例子中，我们看到开发双方对流程仍然存在一定的疑虑（即括号中有问号的部分），但是这并不影响到用户故事的创作，因为这个版本的用户故事还会变化多次。但从这个简单的例子上来看，我们发现故事的形式仍然存在着一些不足：

故事的形式更容易被人接受，但是也有不规则的缺点。任意描述需求虽然节约了培训的成本，但是却造成了不一致性。不同的人对故事有着不同的理解，对需求也就有了不同的理解。需求故事虽然看起来很简单，但是要讲好一个需求故事绝对不是一件容易的事情。需求规约过于形式化和正式化，导致了需求规约难以使用，但是完全不要形式也不是一个好的做法。在形式和可用性之间保持平衡，是讲好需求故事的关键。

需求故事虽然容易阅读，但是却很难写得好。如何控制需求的描写精度，如何分解需求，如何组织，如何确定边界。但是XP并不关心这个问题，只要能够起到沟通的效果，怎么做都行。这种态度是否正确我们暂不去评价。但在实践中，由于缺乏系统的指导，一个新手往往需要花费很长的时间才能够学会故事的写法。

对于XP来说，需求的开发只有先后次序之分。而先后次序的制定由客户来负责。但是在实践中，识别出先后次序并不仅仅是客户的责任，开发人员同样需要提供需求优先级和风险的建议。这里有几点需求优先级的建议：

• 需求中包含了主要的设计，或是包含了大量的业务实体和典型的业务规则。对于这样具有系统代表性的需求，应该赋予较高的优先级。
• 需求中存在重大的技术风险，例如需求中包括了OCR开发包，而开发团队原先并没有相关的经验。
• 需求中包含了重要的业务流程，代表了本软件的主要设计思路。
• 需求具有代表性，并且难以估算，急需对需求进行试验性的评估，以获得较为精确的速度值。
• 需求的时间紧迫。

采用用例技术

用例技术保持了需求的简单原则，用例和形式和用户故事非常的相似，但是用例具有自己的格式，虽然这个格式也是可以任意定义的。用例的重点是表示系统的行为。我们看看上面的例子如何用用例来表示：

可以看到，用例表示的内容和用户故事并没有太大的差别，但用例比较强调格式。虽然不同的团队有不同的格式，但是在同一个团队中，尽可能使用相同和相似的格式（不同的用例可能需要不同的用例格式）基本流程中的每一个步骤都代表了业务人员和系统一次交互，流程非常的简单，但是已经覆盖了一个成功的流程。我们看到，流程的每一步都高度抽象的原因是该用例的层次是业务流程级别的。（业务流程级别也仅仅是一种约定，并不是标准）。利用层次的概念对用例进行精度的划分。在上面的例子中，低精度的用例主要的目标是把握系统的全貌。在RUP中，这种用例也被称为业务用例（Business Use Case）。在原先的用户故事中，对分支情况描述比较含糊，但采用了用例的这种描述形式，分支情况就一目了然了，和前面一样，分支情况的表述也有很多种的形式。

用例技术从提出到现在，已经有了大量的经验积累。在XP项目中采用用例技术并不是什么新鲜事。但在XP中应用用例也必须遵循XP的原则，以及精益编程的思路。所幸的是，这些思路是非常自然的，使用用例技术是完全可以实现的。本文并不打算详细的描述用例技术，如果要深入了解用例技术，有几本书是非常值得一看的（见附录）。

先把握系统的全貌：在做需求的时候，常常出现的一种情况是需求分析人员花费了很多的心思来精华、完善某个用例。对XP来说，这种做法并不推荐，而根据精益原则，这种行为存在浪费的可能性。我们对软件、对项目的认识是不断深入的。因此，我们在项目一开始就深入到需求、故事、或用例的细节，分析人员的能力可能很强，能够正确的捕捉到用户的实际需要。但是一个星期之后我们对需求的认识就有可能发生变化，也许是原先对用例范围的界定出现了问题，也许从另一个角度分析用例效果会更好，也许原先处理用例的思路不正确。不管如何，需求变化的可能性是非常大。用例越详细，发生变化的可能性就越大。这时候，原先花在精化用例上的时间就被浪费了。

因此，不要在一开始就精化需求，一开始的工作重点应该是放在尽可能全面的收集用例，了解整体的业务流程，分析主体业务流程等工作上。在获得了系统的全貌之后，你会发现你原先对系统的认识是不充分的，用例需要根据新的思路进行重新排列，用例的优先级需要调整，在UML图中，往往有一张系统的用例概览图，这张图所表示的就是系统行为的一个概述。

寻找优先级高的用例进行精化：我们在上文提到了需求优先级的判断，用例的优先级判断和需求的优先级判断相似。在讨论迭代的时候我们说过，前几次迭代的主要目的是要识别出项目风险。因此，寻找有代表性、优先级高的用例进行精化，能够帮助开发人员更快的理解领域知识，构建起初步的领域模型。

继续上面国际结算的例子，在完成总的用例图之后，我们发现，银行的业务非常的复杂，如果缺少领域专家，要在短时间内领会领域逻辑是非常困难的，同时，我们发现，汇款的业务在日常业务中所占的百分比是非常高的，而汇款业务涉及到了大多数的领域知识，而业务流程却相对简单。因此，我们决定，先把汇款的用例作为一个突破口，在完成了这个用例之后，我们的开发人员就会对业务领域有着比较深入的认识，也就能够进行更复杂的工作了：

注意到，在这个例子中我们对用例优先级的判定条件和上文的稍有不同，我们选择有代表性，但又相对简单的用例作为高优先级的用例。这样做是因为对业务领域比较陌生，一开始实现复杂的需求有很大的难度。所以，虽然我们提供了一些制定用例优先级的思路，但是实践的时候仍需要根据实际情况权衡。

迭代精化：用例的编写过程是一个对业务领域不断熟悉的过程。随着调研的深入，不断有新的问题显露出来，需要补充或修改原先的用例。这里有两种情况，一种是在同一个增量内，在对用例B精化的时候，发现用例A中忽略了一种情况，这时候我们就需要补充用例A。例如，我们在精化其它用例的时候，发现汇款用例中忽略了报表的需求，这样我们的工作又必须回到汇款用例上。这样的情况是非常普遍的，这就要求我们不要过分的修饰用例，不要把精力花在用例格式上，这样只会造成浪费。

第二种情况是在不同的增量中，这时候用例往往会加入新的需求、新的情境。我们如何去控制不同增量期间的迭代呢？一般来说，有两种方法，一种是对原有的用例进行增补，增补的部分用不同的颜色或标记。另一种方法是为用例建立版本，不同版本的用例对应于不同的增量周期。这样，对应对N个增量周期就有了n个不同版本的用例（n≤N）。不管是哪一种情况，都要求我们采用迭代的思路来处理用例。

形式不是最重要的：在团队中强制要求统一的用例书写格式是有意义的，但有的时候，这个意义并没有想象中的那么大。可以约定条件的编写形式、也可以约定层次的划分。但是过分的强制形式就没有什么意义了。