最近在参与一个棘手项目，居然直接参与到需求阶段了。 虽然，目标是架构师不过，分析师的活看来也是要会的。网上找到一篇(好像也是唯一一篇)讲述use stories的文章。拿来借鉴一下吧。。。。

出处：Extreme Programming 论坛
作者：light

胡乱说说，里面肯定存在着不少的错误，还请高手指正。

Use Stories就是系统要实现的功能。它表述起来非常的简单，一个Use Stories只需要几句话就可以写完。之所以这样是因为用户需求的细节是非常易变的，而其高层描述却是相对稳定的。所以我们可以通过使用Use Stories的方法来从高层确定需要开发的内容，这些单纯的Use Story相当于系统中可能的点，而由我们通过与用户交流所得到的所有Use Stories则构成了一个面，它就是整个系统所需要实现的功能。

深入思考上面这段话的含义就会发现Use Stories在整个项目的初始分析阶段起的作用只是一个占位附。他告诉我们这样功能在实作的时候应该要实现，但是具体需要实现什么，怎么实现则是在迭代 过程中的分析阶段所需要的事情。所以在写Use Stories的时候请切记，一定要简单概括，不可明确描述实现细节方面的问题。

说到这里就不能不说一下Use Story与Use Case的关系，我个人认为Use Story是一个更高层的分析阶段，它的抽象层次非常的高，如前面所说，它是一个占位符，而在具体对一个Use Story进行分析的时候则可以使用Use Case分析技术，将一个Use Story分解成为若干个Use Case。当然上面这段描述的前提是需要开发的系统足够的大Use Story对相对较大，一个Use Story可以折分一系列Use Case。但是如果项目的规则相对较小，那么可以直接使用Use Case来取代Use Story，这个在开发的时候需要灵活的掌握，不可死板追求到底用Use Story还是Use Case。

Use Story中除了包含对功能的简单描述之外，还可以酌情加入对异常情况的描述。虽然在具体分析一个Use Story的时候还需要将其异常情况进行详细的列出，但是在撰写Use Story的时候还是有必要的尽可能的将它们列出，其原因在于，对异常情况的描述可以帮助我们发现一些在正常情况下无法体现出来的Use Story之间的关系。这对我们撰写Use Story的描述部分是有一定的帮助的，另外也可以在这个初始阶段提出一些问题，然后等待进入具体迭代的分析阶段时再进行解答。

Use Story内的描述只是开发者系统的一个最初步认识，所以以后开发者在实际开发时参考这些Use Story时一定要持着一种怀疑态度，再重复一次Use Story只是对高层系统一部分的抽象度非常高的描述。用户在具体开发的时候应该维护一份Use Story列表，如果在实际开发一个Use Story（或者这个Use Story所对应的某一个Use Case）的时候，遇到了对其它Use Story有影响的问题应该在这份Use Story列表当中标出。以便我们在这些受影响功能进行分析的时候可以尽量多的认识到这些影响它的问题。 

用户在对Use Stories进行优先级的排序后，这个顺序虽然不是在未来完成整个系统的过程中实现Use Story的顺序（因为需求是易变的），然而一般情况下这个Use Stories的优先级排序，却决定了第一次 迭代的开发内容。优先级高的Use Story应该先完成，这是直面风险的一种方式，按照XP的描述来看， 用户认为优先级越高的Use Story所存在商业价值就越大，当然其风险和不确定性也就越大，所以我们应该先实现它。

在用户确定了第一次迭代过程中所需要开发 的Use Stories后，那么我们就可以将这些Use Stories分解成相应的任务了，注意，用户虽然为第一次迭代选择了相应的Use Sotries，但是这些Use Stories却未必会在第一次迭代当中完成，因为正如前面所说Use Stories的作用只是一个占位符，我们通过Use Stories所了解的系统功能只是极为抽象的内容，单凭这些内容我们是无法估算出完成一个认识所需要的具体时间的，所以在决定开发一个Use Story的时候需要对这个Use Story进行进一步的分析，将这个Use Story拆解成若干个任务。折解的目的是Use Story所被折解成的任务将都是可以进行开发时间评估的（大小基本可知），只有这样的任务开发人员实际工作起来才会感觉到心里有数，一个Use Story所表示的抽象范围比较广，可以先将这个Use Story折解成若干个Use Case或者更小的Use Story（再强调一次，Use Case要比Use Story的抽象极别低），然后再将具体的Use Case折解成具体可以进行评估的任务。而如果我们对一个任务无法进行评估的话，那么可能就说明我们任务还有细分的余地，我们可以将它拆解成更小的任务 （当然这里有一种情况是由于团队内的开发人员都不清楚任务所涉及到的专业知识，所以造成无法对任务的工作时间进行评估，在这种情况下，可能就需要一个此领 域的专家帮忙了，或者如果没有这样条件的话，那么开发团队在经过对这种专业知识的短时间学习后再对任务进行评估？，或者重新评估使用此技术所付出的代价是 否可以在一定的成本范围之内）。

在对Use Story进行拆解的过程当中经常会遇到的一个问题就是可以从进一步的分析过程当中得到一些浅在的Use Story或者Use Case。可以将这些Use Story或者Use Case加入到列表，然后评估其是否有必要被加入到本次迭代，如果有的话，那么一并进行分析，如果没有的话，那么将其安排到其它的迭代中来完成。

在拆解任务的过程中，我们应该保持对核心 问题的注意力，举个例子来说，比如说我们要处理一个发送信息到指定用户的Use Case，这个Use Case核心的问题就是将信息成功的发送到指定用户处，而在拆解这个Use Case的时候我们发现校验收件人用户是否有效的操作也是一个相对比较复杂且工作量比较大的工作，因为它涉及到与帐号系统的配合工作。在这个时候我们所采 取的策略就应该是将用户校验操作视为完成整个发送信息过程操作当中的非核心步骤，不需要对这个问题太过纠缠。在分析的时候只需要把它当做一步操作，而在实 做的时候也只需要定义一个用户校验的接口，然后使用Mock对象的技术来满足发送邮件时对用户校验系统的需求即可。

另外在拆解任务的过程当中还应该注意的一 点是，不应该让我们所能够承受的复杂度和负载度超标，比如说当我们发现从一个Use Story分解出来的Use Case复杂的足以让我们不能够一次对付他们的时候就应该明智的将对Use Story的分析改成对某一个或者某几个特定Use Case的分析。只有使用客中化整为零，各个击破的策略才能够使我们在面对大型软件的时候保持我们的控制力。 
 
Archie的评价  2004.10.07 
虽然不能准确的对故事进行估算，但是还是要进行估算的，而且团队的速度也是用故事的度量单位来衡量，而不是任务。
要进行估算就要对故事进行比较详细的了解，要和客户进行大量的沟通，了解到什么程度呢？能进行估算了为止。