User Story

 

User Story在敏捷项目中是项目范围的基本单位。在项目中，每个User Story是从稍多于一行的描述逐步精细到一套验收标准的。User Story是把需求分解为有优先级的，可测试的，可评估的小工件的有效机制。

好的方面：一个User Story是在商业价值的上下文中写出的，该价值体现为一个可以供终端用户使用的系统功能。编写它们的标准方式为——As insert user I need to insert feature so that insert business value。
User Story最初只有一两行，包含了足够的细节来测试，并提供了评估和优先级。附加的细节将在该故事得到交付的迭代之前增加进来。每个User Story的大小应该使它能够在一个迭代之内完成。

---------------------------------------------------------------------------------------------------

 

User Story 在敏捷开发过程中的应用

 

2009-03-04 作者：苏小补丁 来源：苏小补丁的空间

http://www.uml.org.cn/SoftWareProcess/200903041.asp

 

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 由以下三点组成：

• 用来制定计划和作为提醒的一段书面描述
• 用来充实story的细节的谈话
• 测试用例，用来表达和记录细节并且能够在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（用户可以查找职位）”是一件事情，而能否只靠这个作为指导就开始编码和测试却是另外一件事情。因为，细节在哪里呢？类似于下边的这些问题怎么办呢？

• What values can users search on? State? City? Job title? Keywords?（用户查询的条件是什么？州？城市？职位？关键字？）
• Does the user have to be a member of the site?（用户必须是网站的注册用户吗？）
• Can search parameters be saved?（可以保存查询条件么？）
• What information is displayed for matching jobs?（查询页面上应该显示哪些信息呢？）
• 许多类似的细节可以当作另外的stories来描述。实际上，多做几个stories 比做一个很大的stories要好。例如整个的BigMoneyJobs 网站可以用这两个stories来描述：
• A user can search for a job（用户可以找工作）
• A company can post job openings（公司可以发布职位空缺（好机会））

很明显，这两个stories太大了，大到没有太大用处.，在第二章“编写故事”中，完整的阐述了故事大小的问题。从一、两个开发人员花费半天或者两个星期来编写和测试一个story开始，是一个不错的起点。 公平一些来讲（Liberally interpreted），上边的两个stories简单的概括了BigMoneyJobs网站的大部分功能，，每一个大概要花费程序员多于一周的时间。

当一个故事太大的时候，他通常会被作为一个Epic（译者注：此词本意为史诗级的，我没有找到合适的汉语词汇表达，就是大的故事集的意思）提出.Epics可以被分割成两个或更多个小故事。例如，这个Epic“A user can search for a job（用户可以找工作）”就可以被分割成这些Stories。

• A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted.（用户可以通过地区, 薪水, 职位, 单位名称, 和职位发布日期 来搜索）
• A user can view information about each job that is matched by a search.（用户可以查看搜索出来的每个职位的详细信息）
• 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”是非常适度和实用的。我们不需要再去把它进一步的像这样去拆分：
• A user can view a job descrīption.（用户可以查看职位描述）
• A user can view a job's salary range.（用户可以查看职位薪水）
• 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。这个是太理想的情况，所以，我们创建一个客户团队，这个团队里包括那些可以保证软件达到最终用户需求的那些人。这就意味着这个客户团队包括测试人员、管理人员、用户和交互设计人员。

 

---------------------------------------------------------------------------------------------------------

In computer programming auser story is one or more sentences in the everyday or business language of theend user that captures what the user wants to achieve. User stories are used withAgile software development methodologies for the basis of what features that can be implemented. Each user story is limited, and should fit on a small paper note/card to ensure that it does not grow too large. The user stories should be written by or for the customers of a software project and are their main instrument to influence the development of the software. User stories could also be written by developers to express non-functional requirements (security, performance, quality, etc.). ^[1]

User stories are a quick way of handling customer requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.

A user story is an informal statement of the requirement as long as the correspondence ofacceptance testing procedures is lacking. Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled. Some formalization finally happens when the developer accepts the user story and the acceptance procedure as a work specific order.

Contents

[hide]

• 1Creating user stories
• 2Examples
• 3Usage
• 4Benefits
• 5Limitations
• 6User stories and use cases
• 7See also
• 8References
• 9External links

 Creating user stories

When the time has come for creating user stories, one of the developers gets together with a customer representative. The customer is responsible for formulating the user stories. The developer may use a series of questions to get the customer going, such as asking if some particular functionality is desired, but must be careful not to dominate the idea creation process.

As the customer conceives the user stories, they are written down on a note card (e.g. 3x5 inches or 8x13 cm) with a name and a description which the customer has formulated. If the developer and customer find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory often using theINVEST guidelines from theScrum project management framework. However, it is stressed inExtreme Programming (XP) that user stories are not to be definite once they have been written down. Requirements tend to change during the development period, which is handled by not carving them in stone.

User stories generally follow the following template:

"As a <role>, I want <goal/desire> so that <benefit>"

but the shorter version is commonly used as well:

"As a <role>, I want <goal/desire>"

Examples

As a user, I want to search for my customers by their first and last names.

As a non-administrative user, I want to modify my own schedules but not the schedules of other users.

As a mobile application tester, I want to test my test cases and report results to my management.

Starting ApplicationThe application begins by bringing up the last document the user was working with.

As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save.

Closing ApplicationUpon closing the application, the user is prompted to save (when ANYTHING has changed in datasince the last save!).

alternatively...

As a user closing the application,I want to be prompted to save anything that has changed since the last saveso that I can preserve useful work and discard erroneous work.

The consultant will enter expenses on an expense form. The consultant will enter itemson the form like expense type, description, amount, and any comments regarding the expense.At any time the consultant can do any of the following options.(1) Once this is completed the consultant will “Submit”. If the expense is under fifty (<50),the expense will go directly to the system for processes.(2) In the event the consultant has not finished entering the expense, the consultant maywant to “Save for later”. This instance should then be displayed on a list (queue) forconsultant with the status of “Incomplete”.(3) In the event the consultant decides to clear the data and close the form the consultantwill “Cancel and exit”.  This  instance will not be saved anywhere.

 Usage

As a central part of many agile development methodologies, such as in XP's planning game, user stories define what is to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers.

When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written.

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.

Benefits

XP and other agile methodologies favour face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:

• Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
• Allowing developer and the client representative to discuss requirements throughout the project lifetime
• Needing very little maintenance
• Only being considered at the time of use
• Maintaining a close customer contact
• Allowing projects to be broken into small increments
• Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
• Making it easier to estimate development effort
• Require close customer contact throughout the project so that the most valued parts of the software get implemented.

 Limitations

Some of the limitations of user stories in agile methodologies:

• They can be difficult to scale to large projects.
• They are regarded as conversation starters.

User stories and use cases

While user stories, use cases andusage scenarios all serve the purpose to capture specific user requirements in terms of interactions between the user and the system, there are major differences between them.

User StoriesUse Cases

• Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.
• Can be accompanied by Acceptance Testing procedures for clarification of behavior where stories appear ambiguous.

• Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.^[2]
• May be delivered in a stand-alone document.

See also

• Acceptance testing
• Extreme Programming
• Requirement
• Scrum
• Use case
• Agile software development
• INVEST mnemonic

References

• Daniel H. Steinberg and Daniel W. Palmer: Extreme Software Engineering, Pearson Education, Inc.,ISBN 0-13-047381-2
• Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5
• Mike Cohn: Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5

1. ^ Davies, Rachel. "Non-Functional Requirements: Do User Stories Really Help?".http://www.methodsandtools.com/archive/archive.php?id=113. Retrieved 12 May 2011.
2. ^ Advantages of User Stories for Requirements

External links

• Definition of User Stories at extremeprogramming.org
• Definition of User Story at c2.com
• User Stories in Action