（书摘：用户故事与敏捷方法）第十二章 故事不是什么

（从本章开始，我们将进入本书的第三部分，首先把注意力集中于用户故事与其他需求方法的区别，包括需求规格文档，场景已经用例。然后阐述用户故事相较于这些方法的优势。）

 

为了帮助我们更好地理解用户故事是什么，首先应了解它们不是什么，这一点很重要。本章会解释故事如何区别于其他三种常见的需求方法：用例(use case)，IEEE830软件需求规格(software requirements specification)和交互设计场景(interaction design scenario)。

 

用户故事不是IEEE830

• 需求文档乏味，容易出错，而且非常费时
• 根据需求文档编写代码，我们的目标是需求列表，而不是满足了用户的目标。
• IEEE830样式的需求已经使许多项目误入歧途，因为它们侧重于关注需求的检查清单，而不是用户的目标。需求清单不会像故事那样给读者一个对于产品的整体理解。
• 用户故事与IEEE830样式需求规格的最后一个不同在于，对于后者而言，在写下所有需求前，每个需求的成本是不可见的。
  典型的情况是，一个或几个分析师花两三个月时间编写出冗长的需求文档。随后把文档交付给程序员。这时程序员告诉分析师，完成项目需要24个月，而不是分析师所希望的6个月。在这种情况下，分析师在编写团队没有时间开发的四分之三的文档上浪费了很多时间，而且在开发人员，分析师和客户之间反复讨论需要在有限的时间内先开发哪些功能上会浪费更多的时间。每个故事都会有一个估算。客户知道团队的速率，也知道每个故事的点数。编写完足够填满所有迭代的故事后，她知道自己的任务已经完成了。

用户故事不是用例

 

用例最初由Ivar Jacobsen(1992)采用。用例是对于系统之间以及一个或多个用户之间交互的一般性描述，使用者要么是用户，要么是另外的系统。

 

用例中可以包括主要成功场景和扩展部分。主要成功场景是用例成功路径的描述。扩展部分则定义了其他路径。通常情况下，扩展部分用于错误处理。

• 故事与用例之间最明显的区别是它们的范围。两者的大小都以交付商业价值为目标，但故事的范围更小，因为我们对它们的大小有限制，以便于安排工作。
• 用户故事和用例的不同还在于它们的完整性。James Grenning注意到故事卡上的文本加上验收测试基本相当于用例。Grenning的意思是故事对应于用例的主要成功场景，而故事测试对于应于用例扩展。
• 用例和故事之间另一个更重要的区别是它们的寿命。只要产品在开发或维护，用例常常作为永久性的”工件“持续存在。另一方面，故事不会超过包含它们的迭代。
• 另外的区别是用例比较容易包括用户界面的细节。
• 用例和故事的目的不同。用例目的是记录客户和开发之间的协议。而编写故事是为了更方便发布计划和迭代计划，并且它充当着用户具体需求对话的占位符。
• 用例一般写成分析活动的结果。用户故事则写成注释，用以启动分析谈话。

用户故事不是场景

场景是用户与计算机交互的详细描述。交互设计场景和用例场景是不同的。事实上，交互设计场景通常比用例更大或更全面。

场景示例：

Maria正在考虑转行。自从辉煌的互联网时代泡沫开始，她一直在BigTechCo担任测试工程师。由于她原先是一所高中的数学老师，Maria觉得假如回到学校教书，自己可能会更快乐。Maria去访问BigMoneyJobs.com网站。她用一个用户名和口令创建了一个新账户。接着她创建了自己的简历。她希望在爱达荷州找一份数学教师的工作，但她偏向于靠近Coeur d'Alene，这是她现在工作的地方。根据她的搜索条件，Maria找到了少数几个符合条件的工作机会。她最感兴趣的是北岸学校，一所地处Boise的私立高中。Maria在Boise有个朋友叫Jessica，她觉得Jessica应该认识北岸学校的人。Maria输入Jessica的电子邮件地址，加上一段注释询问她是否认识学校的人，然后转发给Jessica这份工作的链接。第二天早上，Maria收到一封来自Jessica的电邮，Jessica说自己并不认识这个学校的人，但她知道这个学校，它有良好的声誉。Maria点击按钮将自己的简历提交给北岸学校。

Carroll（2000）说场景包括以下特征元素：

• 应用环境(setting)
• 使用者(actor)
• 目标或目的(goals or objective)
• 行动和事件(actions and event)

用户故事和场景的主要区别是范围和细节。场景包含更多细节，他们的范围通常包含多个故事。

尽管场景往往包含更多的细节，它（像故事一样）也是鼓励通过讨论获得更多的细节。