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

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

《User Stories Applied: For Agile Software Development》

http://space.flash8.net/space/?610884/viewspace-370260.html

suy_98@hotmail.com (苏小补丁)

敏捷开发已经越来越受到人们的关注，User Story 作为敏捷需求分析的一种重要工具

和方法，也越来越受到敏捷开发团队的重视，但是市面上关于 User Story 的资料目前较少，

而且多为英文资料，所以将我自己读的这本《User Stories Applied: For Agile Software

Development》翻译如下。

Pages:

Translator：Yan Su，Peng Zhou

敏捷开发团队的彻底审查和努力实践证实了 User Stories 应用提供了一种节省时间、

减少重复工作、并且能够做出更好的软件需求过程。

构造满足客户需求的软件的最好方法就是从简短的、清晰的、扼要的并且对最终用户

有价值的 User Stories 开始。，在这本书中，Mike Cohn 提供了一种如何编写 User Stories 以

及如何在软件开发生命周期中运用它们的详尽蓝图。

你将会学习到，怎样编写一个好的 User Story，而怎样又会导致一个坏的 User Story 产

生呢？你还将会学习即使在你无法和客户交谈的情况下，仍能获取到 User Stories 的实用方

u 同客户中的管理者、培训人员、销售人员和其他代理商等一起工作

u 编写可测试的 User Stories。

u 根据 User Stories 来划分优先级，制定计划，估算成本

u 章尾问题和练习

User Stories 应用对于使用任何敏捷开发方法的软件开发人员、测试人员、分析人员和

管理者都是极其有价值的。

序

90 年代中期，大多数时间我都觉得很有罪过感。我所在的公司每年都会并购一家新公

司。每次并购以后，我都被指派去运作那个公司的开发团队。每一个并购的开发团队都会

开始的时候有任何延迟。

因为我们没有时间去写一个漂亮、很长的需求文档，我们采用和我们的客户讨论这种

工作方式，而不是把他们写下来，自前而后互相传递，然后讨论，我们只交谈。我们在纸

上画一些界面，有时候我们会做些原型，还经常编写一小段代码，并把我们编写的东西展

示给目的用户。我们去经常找一些有代表性的客户，并把我们真正编写的东西给他们看，

通常至少每月一次。通过和我们的客户呆在一起并给他们看我们每一小块的工作进程。我

们找到了一种不需要写那些漂亮的需求文档也能成功的方法。

但是，我仍然有罪恶感，我们没有按照我们应该按照的那种方式去做。

1999 年，Kent Beck 发表了一本具有革命意义的小书“Extreme Programming Explained:

Embrace Change”，一夜之间，我所有的罪恶感消失了，书中有一种说法，说开发人员和客

前听过的一个关于小孩洗澡的故事，爸爸倒好了洗澡水，帮助他的小孩儿洗澡，这个两三

岁的孩子，刚把脚趾头放到水里，就迅速的收了回来，然后跟他的爸爸说“再暖和点

（make it warmer）”。爸爸把手放到水里，惊奇的发现，水不但不冷，而且已经比她女儿洗

澡用的热多了。

当他想了一会儿他儿子的要求以后，他意识到他们缺乏交流，他们使用同一个词错误

的表达了不同的意思，小孩所说的“再暖和点儿”通常被大人们理解为“提高水的温度”。但是，

对小孩儿来说，“更暖和点儿”的意思是“把水温调到更接近于他所认为的暖和”（译者注：水

温应该更低一点儿）。

词，尤其是书面词语，当他来表示像软件这么复杂的需求的时候是非常单薄的。为了

避免对书面词语的曲解，我们需要用开发人员和客户之间频繁的交谈来替代书面词语。

整个过程。本书包括四部分和两个附录。

第一部分：从这里开始—对于你开始编写 story 之前所要了解的所有事情做了一个描

写 Stories 的细节，通过用户模型来收集 Stories，当你无法接触到真正用户的时候怎样编写

Stories。第一部分以一些能改善你的 User Stories 的指导结束。

第二部分：估算和计划—当我们具备了一些 Stories 的时候，我们最常问的就是“我们

需要多长时间来开发”？第二部分揭示了如何通过故事点来评估 Story，如何计划一个跨度

3~6 个月的发布计划，如何更细节的计划接下来的迭代计划，最后，如何去衡量进度以及

衡量这个项目是否按你的预期进行。

第三部分：经常讨论的主题—第三部分通过描述 User Stories 和一些其他的需求分析

方法的区别，例如 User Case、软件需求规格说明书和交互设计场景的区别开始，接下来的

一节阐述了 User Stories 在发现错误和适应敏捷开发方面的优势，最后一章来讨论一些小问

题，例如：Stories 应该写在纸上还是记录在软件系统里，怎样处理没用的需求等等。

第四部分：举例—一个包含了前面所讲述的所有内容的例子。如果我们要求开发人员

能够通过 story 最好的理解用户需求，那么在这本书中增加一个展示 user stories 所有方面的

例子是很重要的。

第五部分：附录—User stories 由极限编程产生。虽然阅读这本书之前，你不需要对极

限编程很熟悉，但是附录 A 仍然为你提供了极限编程的简要描述。附录 B 为你提供了本书

第一部分我们将快速浏览什么是 user stories 以及如何使用，然后将阐述如何编写 User

Stories；如何通过系统用户模型来定义 Stories；当客户自己本身无法前来的时候，如何同

那些能够充当客户角色的人一起工作；如何来编写测试用例，来证明你的 Stories 已经被成

功编写的细节，最后将阐述几条编写好的 Story 的指导建议。

则是技术团队。

如果任何一方控制了沟通，那么项目注定会失败。如果业务一方控制，则会要求功能

和日期，而不太担心开发人员是否能全部完成或者开发人员是否明白他们的真正要求；如

果开发人员控制了沟通，技术术语会代替业务语言，开发人员也失去了通过倾听来了解客

感情因素和原则问题就变成了双方共同的问题。.当资源分配完全倾向一方的时候，项目就

会失败。如果开发人员全权负责（无论怎样都必须在 7 月份之前全部做完），他们可能会

因为一些附加的功能而牺牲质量，或者只实现部分功能，或者独自制定本该客户或用户参

与制定的大量的决定。当客户和用户方全权负责，项目前期就会出现一个漫长的讨论过程，

在这个过程中越来越多的功能被从项目中删除，当软件被交付的时候，甚至实现的功能比

删掉的功能少。

我们已经知道了我们不能够完美的预言一个软件开发项目。当用户看到软件的初版时，

他们会产生一些新的想法，改变一些他们原有的想法，由于软件的不可把握性，开发人员

进行时间估算变得非常困难。由于种种原因，我们无法罗列一个完整的 PERT 图表来显示

我们在项目里所必须完成的全部工作。

那么，怎么办？

我们经常通过手头已经掌握的资料来做决定，会好过在项目初期就做出所有的决定。

我们把做决定分散到整个项目过程中。为了做到这一点，我们要确认已经有一个尽早尽多

获得相关的资料的程序。User Stories 由此而生。

1.1.1User Story 是什么？

l 用来制定计划和作为提醒的一段书面描述

l 用来充实 story 的细节的谈话

l 测试用例，用来表达和记录细节并且能够在 story 实现的时候对进行验证

因为 User Story 的描述是通过传统的手写记录在卡片上，所以 Ron Jeffies 给这三个方

面起了很好的名字，Card（卡片），Conversation（会话），和 Confirmation（确认）。卡

片是 story 最可见的表现形式，但是他不是最重要的。Rachel Davies 已经说过，卡片“重现

客户需求场景好于记录它们”。思考 User Stories 的完美方法是：card 包含 story 的正文，通

过会话得出细节，并记录在测试用例中。

· 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 是因为用户根本就不关心使用

哪种编程语言。但是，如果这是一个应用程序接口，用户（他本身就是个程序员）写下

程序如何连接到数据库的技术细节。

也许，你已经读了这些 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 比做一个很

l A user can search for a job（用户可以找工作）

l A company can post job openings（公司可以发布职位空缺（好机会））

很明显，这两个 stories 太大了，大到没有太大用处.，在第二章“编写故事”中，完整的

阐述了故事大小的问题。从一、两个开发人员花费半天或者两个星期来编写和测试一个

story 开始，是一个不错的起点。公平一些来讲（Liberally interpreted），上边的两个

stories 简单的概括了 BigMoneyJobs 网站的大部分功能，，每一个大概要花费程序员多于一

周的时间。

当一个故事太大的时候，他通常会被作为一个 Epic（译者注：此词本意为史诗级的，

分割成这些 Stories。

l A user can search for jobs by attributes like location, salary range, job title, company

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.（用户可以查看工作地点）