1--敏捷--用户故事的好处

参考http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements

极限编程引入了用户故事的形式来表达需求，它是功能的简短描述，对软件用户和客户都很有价值。下面是一个典型的用户故事（工作发布和搜索站点）：

• 用户能够发布简历到网站
• 用户能够搜索工作
• 公司能够发布职位空缺
• 用户能够限制哪些公司可以查看她的简历 

但是用户故事不仅仅只是这些文字小片段。各个用户故事包含三个方面：

1. 故事的描述，用于计划和作为一个提醒
2. 详谈故事，以使故事细节具体化
3. 测试，确认故事已经完成

为什么使用故事

因为故事展示出用例或者传统需求方法的一些相同特征，故事区别于这些早期的需求技术就变得非常重要。这些差异使得故事具有很多的优势：

用户故事强调口头交流。字面语言经常是含糊的，无法保证客户和开发者以相同的方式理解。有时我们认为文字是准确的，但是实际上不是。

对计划有益

故事的另一个益处是使项目计划能够被容易的使用。每个用户故事都进行了困难程度和时间上的估计。另一方面，用例通常太大以致于难以给出有用的估计。故事一般在

敏捷项目中的单个迭代实现，而用例一般会分成若干次迭代。

用户故事鼓励延迟收集详细

一个初始化的目标级的故事，可以被更加详细的多个故事替代。

用户故事不是用例

用户故事更多的与统一过程相关联。一个用例是描述系统与一个或者多个作用者之间的交互，作用者可以是用户也可以是另一个系统。

用户故事与用例最明显的差异就是范围。两个都用来传递商业价值，但是我们限定故事的大小，例如不超过10天的开发周期，以便用于开发计划。

用户故事与用例的另一区别是完成的级别。故事相当于用例成功的场景，故事测试相当于用例扩展。

还有一个区别是用例和故事存在的时间，用例 是长期工件。故事通常只在故事迭代中存在。

用例更倾向于包含用户接口的细节。有几个原因，用例导致大量的文档，以致没有其它地方来放接口需求。用例更早关注软件实现而不是商业目标。

来自http://www.diybl.com/course/3_program/gcs/20090318/163248.html

在最近的咨询过程中，经常有客户问到“用户故事和用例是什么关系？”、“用户故事是不是取代了用例？”、“什么时候用用例、什么时候用用户故事？”、“特性和用例是什么关系？”。以下把我的想法整理了一下，首先先驳斥一些观点吧：

 

错误观点１：用户故事会取代用例；

如Ｍａｒｔｉｎ在他的博客中所说的，用户故事和用例都是组织需求的方式，只是目的不同而已，用例的目的是为了把需求描述清楚，而用户故事的目的是把需求分解成可用于迭代计划的单元（http://martinfowler.com/bliki/UseCasesAndStories.html）；

错误观点２：用例是不敏捷的；

其实，在写作用例的过程中，用户也可以根据需要将用例写到不同的详细程度（如概要级），所以，用例技术也是可以用到敏捷项目中的；

 

那么用例和用户故事是什么关系呢？或者说如何从用例导出用户故事呢？用例是许多个（可能是几百个）场景的抽象；用例是用基本流和备选流组合的方式来高效地描述这些场景（可能有几十个流），所以一个流可能对应多个场景（如在下图中备选流１就对应了场景Ｂ和Ｄ），而场景实际上是流的排列。

 

 

用户故事会包含一个或多个场景，也可能是一个场景的某些步骤，所以应该说在大多数情况下，一个用例会包含许多个用户故事。

 

在ＩＪＩ的方法论当中，我们引入了另外一个概念叫用例模块，用例模块对应一个或几个流所代表的场景（功能需求）以及相关的非功能需求，用例模块还应该包含验证上述需求的测试用例。用户故事和用例模块基本上是在一个抽象层次的，或者是，用例模块是一种从用例分解到用户故事的方式。