1 从这里开始
第一部分我们将快速浏览什么是user stories以及如何使用，然后将阐述如何编写User Stories；如何通过系统用户模型来定义Stories；当客户自己本身无法前来的时候，如何同那些能够充当客户角色的人一起工作；如何来编写测试用例，来证明你的Stories已经被成功编写的细节，最后将阐述几条编写好的Story的指导建议。
当你学完这部分之后，你就可以定义、编写、测试你的Stories，同时你应该准备去看如何通过User Stories去进行评估和计划，也就是第二部分的内容。
1.1 概述
软件需求是一个沟通的问题，想得到（或者使用，或者出售）新软件的人，必须和软件的生产者进行沟通。项目的成功与否，依赖于从不同的人那里得到的信息：一方面是客户、用户、分析人员、领域专家以及其他从业务或者组织角度来看待软件的人；另一方面则是技术团队。
如果任何一方控制了沟通，那么项目注定会失败。如果业务一方控制，则会要求功能和日期，而不太担心开发人员是否能全部完成或者开发人员是否明白他们的真正要求；如果开发人员控制了沟通，技术术语会代替业务语言，开发人员也失去了通过倾听来了解客户真正需求的机会。
我们需要一种方法让大家一起合作，以至于沟通不会被单方控制，并且资源分配中的感情因素和原则问题就变成了双方共同的问题。.当资源分配完全倾向一方的时候，项目就会失败。如果开发人员全权负责（无论怎样都必须在7月 份之前全部做完），他们可能会因为一些附加的功能而牺牲质量，或者只实现部分功能，或者独自制定本该客户或用户参与制定的大量的决定。当客户和用户方全权 负责，项目前期就会出现一个漫长的讨论过程，在这个过程中越来越多的功能被从项目中删除，当软件被交付的时候，甚至实现的功能比删掉的功能少。
我们已经知道了我们不能够完美的预言一个软件开发项目。当用户看到软件的初版时，他们会产生一些新的想法，改变一些他们原有的想法，由于软件的不可把握性，开发人员进行时间估算变得非常困难。由于种种原因，我们无法罗列一个完整的PERT图表来显示我们在项目里所必须完成的全部工作。
那么，怎么办？
我们经常通过手头已经掌握的资料来做决定，会好过在项目初期就做出所有的决定。我们把做决定分散到整个项目过程中。为了做到这一点，我们要确认已经有一个尽早尽多获得相关的资料的程序。User Stories 由此而生。
1.1.1 User Story 是什么？
User story是对软件的用户或买主有价值的功能点的描述。User stories 由以下三点组成：
l 用来制定计划和作为提醒的一段书面描述
l 用来充实story的细节的谈话
l 测试用例，用来表达和记录细节并且能够在story实现的时候对进行验证
因为User Story的描述是通过传统的手写记录在卡片上，所以Ron Jeffies给这三个方面起了很好的名字，Card（卡片），Conversation（会话），和Confirmation（确认）。卡片是story最可见的表现形式，但是他不是最重要的。Rachel Davies 已经说过，卡片“重现客户需求场景好于记录它们”。思考User Stories的完美方法是：card 包含story的正文，通过会话得出细节，并记录在测试用例中。
User story 的例子，请参见Story Card 1.1
Story Card 1.1 是一个写在卡片上的初期的User Story
（用户可以在网站上发布简历）
为了保持一致，贯穿剩下的这本书的例子大多都是为BigMoneyJobs 网站而设计的。其他的例子故事可能包括：
· A user can search for jobs（用户可以查找职位）
· A company can post new job openings（公司可以发布新的职位）
· A user can limit who can see her resume（用户可以限制那些人可以查看他的简历）
因为user stories 描述了对客户来说有价值的功能点，所以对这个系统来说下边的例子就不是好的user stories。
· The software will be written in C++.（软件应该用C++来编写）
· The program will connect to the database through a connection pool（软件应该通过连接池来连接到数据库）.
第一个例子对BigMoneyJobs来说不是个好的user story是因为用户根本就不关心使用哪种编程语言。但是，如果这是一个应用程序接口，用户（他本身就是个程序员）写下“The software will be written in C++（软件应该用C++来编写）”就会很好。
第二个story在这种情况下也不是个好的user story ，因为系统的使用者并不关心应用程序如何连接到数据库的技术细节。
也许，你已经读了这些stories 并且很惊讶地说，“等等，使用一个连接池是我这个系统的一个需求” 如果这样的话，请一定要清楚，编写stories的关键点在于让客户认可他们的价值，我们将在第二部分“编写story”里看到一些关于编写Story方面的例子。
1.1.2 细节在哪呢？
说 “A user can search for jobs（用户可以查找职位）”是一件事情，而能否只靠这个作为指导就开始编码和测试却是另外一件事情。因为，细节在哪里呢？类似于下边的这些问题怎么办呢？
l What values can users search on? State? City? Job title? Keywords?（用户查询的条件是什么？州？城市？职位？关键字？）
l Does the user have to be a member of the site?（用户必须是网站的注册用户吗？）
l Can search parameters be saved?（可以保存查询条件么？）
l What information is displayed for matching jobs?（查询页面上应该显示哪些信息呢？）
许多类似的细节可以当作另外的stories来描述。实际上，多做几个stories 比做一个很大的stories要好。例如整个的BigMoneyJobs 网站可以用这两个stories来描述：
l A user can search for a job（用户可以找工作）
l A company can post job openings（公司可以发布职位空缺（好机会））
很明显，这两个stories太大了，大到没有太大用处.，在第二章“编写故事”中，完整的阐述了故事大小的问题。从一、两个开发人员花费半天或者两个星期来编写和测试一个story开始，是一个不错的起点。 公平一些来讲（Liberally interpreted），上边的两个stories简单的概括了BigMoneyJobs网站的大部分功能，，每一个大概要花费程序员多于一周的时间。
当一个故事太大的时候，他通常会被作为一个Epic（译者注：此词本意为史诗级的，我没有找到合适的汉语词汇表达，就是大的故事集的意思）提出.Epics可以被分割成两个或更多个小故事。例如，这个Epic“A user can search for a job（用户可以找工作）”就可以被分割成这些Stories。
l A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted.（用户可以通过地区, 薪水, 职位, 单位名称, 和职位发布日期 来搜索）
l A user can view information about each job that is matched by a search.（用户可以查看搜索出来的每个职位的详细信息）
l A user can view detailed information about a company that has posted a job.（用户可以查看发布职位空缺信息公司的详细信息）
但是，当我们的story能够涵盖所有的细节时，我们就不再去分割story了。例如，故事“A user can view information about each job that is matched by a search”是非常适度和实用的。我们不需要再去把它进一步的像这样去拆分：
l A user can view a job descrīption.（用户可以查看职位描述）
l A user can view a job's salary range.（用户可以查看职位薪水）
l A user can view the location of a job.（用户可以查看工作地点）
总的来说，user story 不需要用专业的需求文档格式夸张的描述成下面这个样子。
| 4.6) | A user can view information about each job that is matched by a search. |
| | 4.6.1) | A user can view the job descrīption. |
| | 4.6.2) | A user can view a job's salary range. |
| | 4.6.3) | A user can view the location of a job. |
比坐在这里把这些细节写成stories更好的方法就是开发团队和客户来一起讨论这些细节。就是说，当这些细节比较重要的时候，就把他拿出来讨论。讨论后，在卡片上添加一些注释是没有错的，就像Story Card 1.2.一样。可是，重点是会话，而不是story card上的笔迹。不管是开发人员还是客户都能够在3个月后还指着卡片说“看，我那时候是这么说的”。Stories并不承担法律责任。我们将看到，协议通过可以证明某个story被正确实现的测试用例来记录。
Story Card 1.2. A story card with a note.
1.1.3 故事应该有多长呢？
当我上中学文化课时候，每当我们被指定去写一篇论文，我总是问“论文必须写多长呢？”老师是不喜欢这个问题的，但是我仍然认为这个问题是必要的，因为它告诉我老师期望的是什么。这个问题同样也是了解项目用户需求很重要的一点。这些要求最好以可测试的形势被捕获。
如果你使用的是纸质的笔记卡片，你可以把卡片翻过来，把需求写到背面。这些记录下来的要求提醒怎样测试这个story，就像Story Card 1.3所显示的那样。如果你使用的是电子系统，它应该有一个地方可以让你加进一些可测试性的提醒。
Story Card 1.3. The back of a story card holds reminders about how to test the story.
测试描述是简短和不完备的，测试用例可以随时添加或者删除。目的是涵盖Story的附加信息，以便开发人员知道Story什么时候就算完成了。就像老师的要求对我来说很有用，我可以知道什么时候我写的关于Moby Dick的东西算完成了。它对于开发人员来了解什么时候完成了客户需求一样有用。
1.1.4 客户团队
对于一个理想的项目来说，我们会有一个专门的系统最终用户，他为开发人员区分工作的优先级，并回答他们的问题，编写所有的Stories。这个是太理想的情况，所以，我们创建一个客户团队，这个团队里包括那些可以保证软件达到最终用户需求的那些人。这就意味着这个客户团队包括测试人员、管理人员、用户和交互设计人员。