User Story 概览—承上启下的重要一环

软件开发是一个从捕获客户需求到编码实现的过程。在我们传统的印象中，需求是厚厚的软件规格说明书，实现则是无穷无尽的bug产生器。需求是在实现之前写好的，客户签字确认的。实现是程序员拿着需求不断猜测这该怎么做，那该怎么做的重新发现的过程。在需求与实现之间横亘着一个巨大的鸿沟，做需求的人和写代码的人总是互相推诿责任，到最后客户总是得不到自己想要的功能。

敏捷软件开发方法有一整套实践，来促进客户与开发团队之间的交流与反馈。而User Story则是这些实践中比较具有启发意义的一个主要实践，我认为它是承上启下的重要一环。因为在其上，它是具体用户角色完成具体目标的过程组成部分。而在其下，它是编写验收标准（Acceptance Criteria）的具体上下文。它就像一条锁链一样，在需求与实现之间架起了一座危桥。

之所以称之为危桥，是因为一旦人们把User Story当做软件规格说明书一类的文档来看待的话，User Story很快就不能反映客户的需求，同时也无法指导实现的开发。我们必须要把它当做危桥一样来对待，经常去重新评估实现难度，根据给客户带来的价值排优先级。当发现它所覆盖的内容不再准确或者过时了的时候，对于危桥我们就不用犹豫，该炸掉重来就炸掉重来。

不严格地说，敏捷开发从需求到实现的单向流程（反馈的路径未包括其中）大概是这样的：

这个过程没有暗示任何瀑布式的开发风格，其实这个过程是反复的，不断有反馈回顾。画出这么一个流程性的图只是为了表明User Story是如何承上启下的。

要知道它是如何承上启下，还是要知道它自身是什么样的。明确的答案是：User Story应该Small（小规模），Testable（可测试），Valuable（有价值）。

Valuable是说User Story能够给利益相关人员提供明确的商业价值。往往表现为满足了用户某方面的预期。

Testable是说User Story可以给验收标准提供明确的上下文。也就是说这个User Story能够对程序的外部行为产生影响，比如界面，日志文件等用户看得见摸得着的东西。

Small是说User Story应该足够小，在商业过程中也就一步或者相关联的几步。小的目的是更好地符合迭代式开发的风格，能够在一个迭代内完成。

这三个特性直接支撑了敏捷开发的一些核心价值：给客户提供价值（对应valuable），保证质量（对应testable）和快速响应变化（small）。

User Story与传统的Use Case有一些不同。某些Use Case的书籍中提倡写出不同层次的Use Case，有High Level的，有Medium Level的，也有Low Level的。从某种程度上来说，High Level相当于Goal，Medium Level相当于User Story，而Low Level相当于Acceptance Criteria。但是由于Use Case的写法缺乏统一的习惯和明确的指导。初学者在写Use Case的时候往往缺乏明确的目标，无法有效地把需求与实现贯穿起来。

因此，若把需求到实现看做从天空到湖底的话，User Story就恰好浮在水面上。可以说User Story是文档能够达到的最细节的层次，若在往下就陷入了实现的细节之中，与具体实现方式相关而且经常变动，维护起来非常困难。更重要的是，写出那样的细节文档又不能执行，无法给客户带来价值，只是对代码的无味重复。

这里只是概览了User Story在整个开发过程中的位置和作用，以及其自身的的一些属性和它能提供的价值。具体使用User Story去实践敏捷开发可以参阅我同事李默所写的敏捷需求分析一文。他在文中以一个业务分析师的角度讲述了如何把User Story用在敏捷需求分析的过程中去。