前言

在20世纪90年代中期的大部分时间里，我都感到愧疚。我当时正在为一家公司工作，这家公司每年都会收购一家新公司。每次收购一家新公司，我都会被分派去负责打理他们的软件开发团队。收购的每个开发团队都带来了辉煌、美观、冗长的需求文档。我不可避免地感到愧疚，因为我自己的团队从来没有写出过如此优美的需求规格说明。但是，我的团队在生产软件方面一直比我们收购的团队成功得多。

我清楚我们成功的方法。然而，我总有一种难以名状的感觉，如果我们能写出大而冗长的需求文档，我们可能会更加成功。毕竟，那正是我当时正在阅读的书籍和文章中所描述的做法。如果成功的软件开发团队都在编写华丽的需求文档，那么看起来我们也应该这样做。但是，我们从来没有时间做。我们的项目总是太重要，需要我们尽快启动，以至于我们从一开始就没有时间来写文档。

因为我们从来没有时间写美观而冗长的需求文档，所以我们决定采用一种工作方式来与用户沟通。我们不是把需求写下来，让它们来回传递，并在时间不够用的时候还在谈判，而是和客户交谈。我们会在纸上绘制界面样例，有时候会创建原型，通常我们会写一些代码，然后向预期用户展示我们编写的内容。至少每月一次，我们会邀请一组具有代表性的用户，并向他们演示我们开发的功能。通过贴近用户并向他们演示小的增量进展，我们找到了一种方法来帮助我们在没有美观需求文档的情况下取得成功。

尽管如此，肯特·贝克（Kent Beck）仍然感到愧疚，认为我们没有按照我们应该的方式去做事。

1999年，肯特·贝克的革命性小册子《解析极限编程》出版发行。一夜之间，我所有的愧疚荡然无存。终于有人提出了开发人员和客户之间用讨论取代“写文档-商谈-再写文档”的模式。肯特阐明了很多事情，并带给我很多新的工作方法。但是，最重要的是，他证明了我从自己的实践中领悟到的是正确的。

大量的前期需求收集和文档可能在多方面导致项目失败。最常见的一种情况是需求文档本身成为软件开发的目标。需求文档只有在能够帮助实现交付某些软件的真正目标时才应该编写。

大量的前期需求收集和文档可能在多方面导致项目失败的第二种情况是书面语言的不准确性。我记得很多年前听到过一个小孩洗澡的故事。小孩的父亲已经在浴缸中放满了水，正准备帮助他的小孩进入水中。这个小孩大概两三岁，先把脚趾头伸入水中蘸了一下，然后迅速将脚趾移开，并告诉她的父亲“让它暖和一些”（make it warmer.）。父亲把手伸入水中，惊讶地发现水不是太冷，已经比他女儿习惯的温度更热了。

父亲思索了一下孩子的请求，意识到他们的沟通出现了问题，用相同的词语来表示不同的意思。孩子“让它暖和一些”的请求被任何成年人都解释为“调高水温”（increase the temperature）。然而，对于孩子来说，“让它变暖”意味着“让它接近我认为暖和的程度”。

文字，尤其是白纸黑字那样的，通过它来表达软件这样复杂东西的需求，是比较简单有限的载体。由于它们可能被误解，所以我们需要用开发人员、客户和用户之间频繁的对话来取代书面文字。用户故事为我们提供了这种方法，让我们写下来足够多我们不会遗忘的内容，并且我们可以估算和计划，同时还鼓励及时沟通。

读完本书的第I部分时，你将准备开始改变总是严格写下每一个需求最后细节的工作方式。读完本书的时候，你会知道在具体环境中实施故事驱动过程所有的必要信息。本书分为四个部分和两个附录。

第I部分“开始”，描述开始编写故事需要了解的一切。用户故事的目标之一是让人们说话而不是写作。第I部分的目标是尽快让你交谈。第1章概述了什么是用户故事以及如何使用故事。接下来的章节提供了编写用户故事，通过用户角色建模收集故事，在无法访问实际最终用户时编写故事以及测试用户故事的更多细节。第I部分的结尾部分提供了一些指导方针，可以用来改进用户故事。

第II部分“估算和计划”，有了一系列用户故事后，我们经常需要回答的第一件事是“需要花费多长时间来开发？”。第II部分介绍了如何使用故事点来估算故事，如何在3～6个月的时间范围内计划发布，如何更详细地计划随后的迭代，最后如何度量进度并评估项目是否按照既定的意愿进行。

第III部分“经常讨论的话题”，首先描述故事与用例，软件需求说明和交互设计场景等需求方案的不同之处。随后探讨用户故事的独特优点，如何判断出现问题的时间，如何调整敏捷过程Scrum以使用故事。最后一章着眼于各种小问题，例如是否在纸质卡片或者软件系统中编写故事以及如何处理非功能性需求。

第IV部分“一个完整的项目案例”，一个扩展的例子，旨在帮助归纳用户故事的所有内容。如果说开发人员可以通过故事更好地理解用户的需求，那么本部分的完整示例是非常重要的，这个示例将展示用户故事的各个方面及其结合方式。

第V部分“附录”，用户故事源于极限编程。阅读本书之前不需要熟悉极限编程。附录A提供了极限编程的简要介绍。附录B包含对各章结尾思考练习题的解答。