用户故事与敏捷方法第一章

第1章 概览

软件需求是一个沟通问题。需要新软件的人(使用或销售软件的人)必须与开发新软件的人进行交流。一个项目的成功，依赖于很多不同的信息，这些信息来自各有不同的人员：一方是客户和用户，有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人；另一方是技术团队。

一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。如果业务方把持绝对地位，他们就会关注软件功能和交付日期，却很少关注开发人员是否能够同时满足这两个目标，或者开发人员是否确切地了解需求。如果开发人员把持绝对地位，技术术语就会代替业务语言，从而导致开发人员无法倾听业务方的实际需求。

我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题(他们通常会被告知"我不关心你们怎么做，但请你们在6月份之前完成")，他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被减掉的功能。

至此我们已经了解到，我们不能完美地预测软件开发项目。当用户看到软件的早期版本时，他们会想出新的点子，从而改变他们的观点。由于软件的这种不可控性，大部分开发人员都会遇到众所周知的艰难时刻，估计需要多长时间才能完事儿。因为这些因素及其他一些因素，导致我们无法勾勒出一幅完美的PERT图 来展示项目中所有必须完成的事情。

那么，我们该怎么办？

一般情况下，我们根据手头的信息来做决策。我们经常这么干。不要在项目开始时就做一套包罗万象的决策，我们要把各个决策分散在项目过程中。为此，我们要确保有一个获取信息的过程，越早越好，越频繁越好。用户故事由此应运而生。

什么是用户故事？

用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三方面组成。

一份书面的故事描述，用来做计划和作为提示。

有关故事的对话，用于具体化故事细节。

测试，用于表达和编档故事细节且可用于确定故事何时完成。

由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面起了一个非常好的以相同英文字母开头的名字：卡片(Card)、对话(Conversation)和确认(Confirmation)。卡片可能是用户故事最明显的表现，但它并不是最重要的。Rachel Davies(2001)说过"卡片代表客户需求而不是记录需求"。这是对用户故事的最佳诠释：卡片包含故事的文字描述，然而需求细节要在"对话"中获得，并在"确认"部分得以记录。

故事卡1.1是一个用户故事的例子，这张故事卡来自假想的职位发布和搜索网站BigMoneyJobs。

故事卡1.1 写在卡片上的用户故事雏形

用户可以在网站上发布简历。

出于一致性考虑，本书其余部分的很多例子都将使用BigMoneyJobs网站作为例子。其他BigMoneyJobs示例故事可能包括下面几个。

用户可以搜索职位。

公司可以发布新职位。

用户可以限制浏览其简历的人。

因为用户故事代表对用户有价值的功能，所以下面的例子对于这个系统来说就不是理想的用户故事。

这个软件将用C++语言来编写。

程序将通过连接池连接到数据库。

第一个例子对BigMoneyJobs来说不是一个理想的用户故事，因为它的用户不需要关心系统是用什么语言编写的。然而，如果这是一个应用程序编程接口(Application Programming Interface，API)，那么系统的用户(她自己也是程序员)写下"这个软件将用C++编写"的用户故事则比较恰当。

第二个用户故事例子在此案例中也不是一个很好的用户故事，因为系统用户没有必要关心应用程序如何连接数据库之类的技术细节。

读完这些故事后，你可能会马上觉得"但是，等等--在我的系统中，使用连接池是需求之一！"如果这样，请停一下，关键在于故事应该以对客户有价值的方式写下来。还有很多其他方法来表示对用户有价值的故事。第2章将提供相关例子。