前    言

　　在20世纪90年代中期，我一直感到非常愧疚。那时我在为一家公司工作，这家公司每年都会收购一家公司。每次收购一家公司后，我就会被派去负责他们的软件开发部门。收购的每个软件开发部门都有华丽而厚重的需求文档。我当然会感到愧疚，因为我自己的部门从没有做过这样漂亮的需求说明。然而，我的部门在生产软件方面远比我们收购的部门要成功得多。

　　我清楚我们成功的动因。但是我仍然有一种挥之不去、怅然若失的感觉，如果我们能写出长长的需求文档，我们可能会更成功。毕竟那是在我当时读到的书和文章里所描述的做法。如果成功的软件开发团队都在编写华丽的需求文档，看起来我们也应该这么做。但是我们从来没有时间做。我们的项目总是太重要，时间非常紧迫，以至于我们从一开始就没有时间做文档。

　　因为我们从来没有时间写长篇大论的漂亮的需求文档，所以便选定了一个可以和用户交谈的方法。我们不是把需求写下来，传来传去，并在时间不够用的时候还在商谈，而是和客户交谈。我们会在纸上画一些界面样例，有时做一些原型，我们经常开发一点就给潜在的用户展示我们开发了些什么。我们至少每月一次邀请一些典型用户，向他们演示我们开发的功能。我们贴近我们的用户，向用户展示我们一点一滴的进度，这样便在不知不觉中发现一个不需要漂亮的需求文档就可以成功的方法。

　　我还是觉得愧疚，觉得我们并没有按规范来做事。

　　1999年，Kent Beck出版了一本革命性的书《解析极限编程——拥抱变化》。一夜之间，我的这份愧疚烟消云散。终于有人旗帜鲜明地提出开发人员和客户之间用交谈取代“写文档——商谈——再写文档”。Kent阐明了许多事情，带给我许多有用的方法。但最重要的是，他证明我在实践中领悟到的是正确的。

　　大量预先的需求收集和文档会以很多方式导致项目失败。最常见的是需求文档变成软件开发的目的。应当只在对交付软件有用时才写需求文档。

　　大量预先的需求收集和文档导致项目失败的另一个方式是记录语言的不准确性。我记得许多年前听到过的一个小孩洗澡的故事。小孩的父亲在浴缸中放满了水，帮助孩子进入水中。小孩子大概只有两三岁，她先用脚趾头试了下水温，告诉父亲说“水要暖点”(make it warmer)。父亲把手放入水中，惊奇地发现，水并不冷，水已经比他女儿习惯的水温更热了。

　　父亲思考了一下孩子的要求，发现他们的沟通出现了问题，相同的词代表不同的意思。孩子的要求“水要暖点”对任何大人的理解都和“提高水温”是一样的。然而对孩子而言，“水要暖点”意思却是“让水温更接近我认为的暖的温度”。

　　语句，尤其是写在书面上的时候，对于表达像软件这么复杂的需求是比较有限的。由于它们可能被误解，所以需要与开发人员、客户和用户频繁沟通。用户故事提供了一个方法，让我们可以写下我们不会遗忘且我们可以估算和计划的，同时还鼓励沟通。

　　读完本书第I部分后，你即可改变以前总是严谨地记录下每个需求细节的方式。读完本书，你将知道在实现故事驱动流程的所有必要信息。本书由4部分和两个附录组成。

　　第I部分“起步”  描述用户故事编写须知。用户故事的目的之一是让大家交谈而不是写。第I部分的目的是让你尽快开始交谈。第1章概要介绍什么是用户故事，如何使用故事。接下来9章详细介绍编写用户故事，通过用户角色建模收集故事，在不能直接访问真实的最终用户时编写故事，测试用户故事。第I部分结束时，用一章的篇幅介绍用户故事改进指南。

　　第II部分“估算和计划”  有了一系列用户故事后，首先要做的是回答“要花多长时间来开发？”第II部分的各章全面介绍如何用故事点估算故事，如何做一个3～6个月的发布计划，具体如何为即将到来的一轮迭代做计划，如何测量进度和评估项目是否如期进行。

　　第III部分“经常讨论的话题”  第III部分开始讲述故事与用例，软件需求说明和交互设计场景之间的区别。紧接着的各章介绍用户故事特有的优势，如何发现错误，如何在敏捷过程Scrum中使用故事。第III部分的最后一章研究了一些小问题，例如故事写在纸质卡片上还是记录在软件系统中，如何处理非功能性需求。

　　第IV部分“一个完整的实例”  用一个扩充的实例做一个综述。如果我们认为开发人员能通过故事充分理解用户的需求，那么用一个扩展的案例展示用户故事的所有方面来总结本书是非常重要的。

　　第V部分“附录”  用户故事源自极限编程。虽然读本书不需要熟悉极限编程，不过，附录A仍然大致介绍了极限编程。附录B则包含每章问题的答案。