（已有10条评价）基本信息
- 原书名：User Stories Applied: For Agile Software Development
- 原出版社： Addison-Wesley Professional
- 作者： (美)Mike Cohn
- 译者： 石永超 张博超
- 出版社：清华大学出版社
- ISBN：9787302223405
- 上架时间：2010-5-12
- 出版日期：2010 年4月
- 开本：16开
- 页码：220
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 综合
【插图】
编辑推荐
敏捷大师Mike Cohn的软件需求方法圣经
小型团队(项目)不可或缺的敏捷开发宝典
亚马逊五星级长销图书，敏捷社区重点推荐
结合精髓和实例，充分演绎用户故事的智慧
内容简介
作译者
Mike Cohn是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401(k)档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍。(译者注：Mike也是《敏捷估计及估算》及Succeeding with Agile两本重要敏捷著作的作者，并与其他两位敏捷泰斗Ken Schwaber和Esther Derby一起创办了Scrum联盟。)
目录
第I部分 起 步
第1章 概览 3
什么是用户故事？ 4
细节在哪里？ 5
“必须多长时间完成？” 6
客户团队 7
使用故事的过程是怎么样的？ 7
规划发布和迭代 9
什么是验收测试？ 11
为什么要变？ 12
小结 13
问题 14
第2章 编写故事 15
独立的 15
可讨论的 16
对用户或客户有价值的 18
可估计的 19
小的 20
分割故事 21
合并故事 23
第1章 概览 3
什么是用户故事？ 4
细节在哪里？ 5
“必须多长时间完成？” 6
客户团队 7
使用故事的过程是怎么样的？ 7
规划发布和迭代 9
什么是验收测试？ 11
为什么要变？ 12
小结 13
问题 14
第2章 编写故事 15
独立的 15
可讨论的 16
对用户或客户有价值的 18
可估计的 19
小的 20
分割故事 21
合并故事 23
译者序
译者简序：用敏捷的方式翻译敏捷经典
数年前，Mike Cohn写了这本User Stories Applied: For Agile Software Development，而我从2007年才真正开始接触敏捷，没想到在2009年我竟有机会能够参与翻译这本有关用户故事的经典著作，我感到十分的荣幸。
敏捷开发近些年在国内软件开发公司中十分流行，因为它为软件开发指引了一个方向。而用户故事是敏捷实践中一个十分重要的环节。它能帮助我们高效地收集客户真正的需求。软件开发都起始于需求收集与分析。如果一开始需求都弄错了，软件的成功也就无从谈起。同时，用户故事带来了一个十分重要的作用，即高效沟通，不论是开发团队与客户的沟通，还是团队内部成员之间的沟通。沟通使客户和团队成员都朝同一个方向前进，这意味着更少的错误，更少的浪费、风险和成本。用户故事还是敏捷计划与估算的重要基础。
我十分有幸能在Irdeto BSS进行敏捷开发。在这里，我们使用Scrum，结合XP进行开发。用户故事自然是不可或缺的。在这里，每个团队都有一个白板，上面贴有一些卡片。它们是这个Sprint团队计划完成的用户故事以及这些故事划分的任务。这些用户故事卡片概要描述了需求，形如“作为(角色)，我想要(功能)，以此(商业价值)”，有时上面还附着另一张卡片写着验收条件。在做计划和开发的时候，团队可以拿着这个用户故事讨论故事细节，故事如何才算完成，等等，正如Ron Jeffries所描述的3C：Card(卡片)，Conversation(交谈)和Confirmation(确认)。
用户故事从始至终贯穿于整个开发流程。首先产品负责人根据收集来的需求编写用户故事，放入产品Backlog中。在Sprint计划会议中，团队成员讨论其中的一些用户故事，细化故事细节，确定验收标准，使用Planning Poker(计划扑克)估算故事点。然后，将故事分成一些小的任务，并估算工作时间。最后，将故事放入Sprint Backlog中，并按优先级排序。Sprint开始时，故事卡片和任务卡片都放在白板的To Do栏，团队成员按故事的优先级挑选任务，将任务卡片挪到Doing栏。任务完成后，将任务卡片挪到Done栏。团队尽可能地先完成优先级高的故事。在故事开发的初始阶段，测试人员和产品负责人一起确认测试用例。故事的任务都完成后，产品负责人验收并确认故事已完成，将故事卡片挪到Done栏中。如此完成整个Sprint的所有故事。Sprint结束时，团队还要将完成的故事演示给利益相关人、其他产品负责人和团队等。这样，每个Sprint团队都会通过完成一系列的用户故事来向客户输出商业价值。
这次翻译我们一共四个人参与，我和石永超主要负责翻译，滕振宇和李国彪主要负责审核。前期的第一个月，我们几乎没有什么太大的进展。我们讨论过后，发现这次翻译其实是一个具有固定交付时间、固定范围(21章和两个附录)且依赖虚拟兼职开发团队的项目，包含开发(翻译)和测试(审核)等工作，何不用敏捷的方式来开展？于是，第二个月开始，我们使用敏捷的思想来指导翻译工作。我们首先把每一章当作一个用户故事，每个故事估算一个故事点(这个是我们做的不足的地方，一个故事点显然不能准确反映各章的不同篇幅)。我们以一个星期为一个迭代，用一份Excel文档作电子白板。每个周末固定时间用Skype开一次网上语音会议。如同Scrum的每日例会一样，大家回答三个问题：这个星期我做了什么，下个星期准备做什么，有什么困难。然后讨论大家遇到的一些翻译难点，统一一些术语的翻译。大家在完成每个星期的翻译工作的同时，必须及时简单地更新Excel中故事的状态。这样一来，每个人都能及时知道每一章的进度，哪一章可以审核，哪一章没有人翻译，可以任领。同时，Excel中还有燃尽图，告诉我们离目标还有多远，是否需要调整。如此，这份Excel文档就成为我们的另一个沟通工具。另外，我们还有十分重要的工具，如同我们的软件项目一样，对于项目中的所有文件(包括电子白板和术语表)，我们使用版本管理工具Subversion和持续集成工具CruiseControl。我们每次签入，持续集成工具都会立即发一封邮件通知大家有新的改动，邮件包含有签入的描述，这样可以提醒大家某一章翻译完了，应该审核，等等 。这样，从第二个月开始，我们的翻译工作就始终保持稳定的进度，团队通过更多更频繁的回馈不断学习成长，持续改善译稿和翻译过程，最终按时交付了翻译稿。
这次翻译成为我们软件开发之外的一次敏捷实践，获益良多。同样，我们也希望能够让更多的人了解敏捷，让更多从事软件开发的人和其他行业的人从中获益。翻译这本书也希望能为传播敏捷思想与方法尽一份力。让更多的人了解用户故事，使用用户故事，带来更多成功的项目。
在此感谢一起翻译的伙伴们：李国彪、滕振宇和石永超。感谢你们让我能够获得参与翻译此书的机会，我从中学习了很多很多，不仅仅是对用户故事更深入的了解，还有在这次翻译过程中对敏捷更全面、深刻的理解。
张博超
译者团队代表
2010年春于上海
数年前，Mike Cohn写了这本User Stories Applied: For Agile Software Development，而我从2007年才真正开始接触敏捷，没想到在2009年我竟有机会能够参与翻译这本有关用户故事的经典著作，我感到十分的荣幸。
敏捷开发近些年在国内软件开发公司中十分流行，因为它为软件开发指引了一个方向。而用户故事是敏捷实践中一个十分重要的环节。它能帮助我们高效地收集客户真正的需求。软件开发都起始于需求收集与分析。如果一开始需求都弄错了，软件的成功也就无从谈起。同时，用户故事带来了一个十分重要的作用，即高效沟通，不论是开发团队与客户的沟通，还是团队内部成员之间的沟通。沟通使客户和团队成员都朝同一个方向前进，这意味着更少的错误，更少的浪费、风险和成本。用户故事还是敏捷计划与估算的重要基础。
我十分有幸能在Irdeto BSS进行敏捷开发。在这里，我们使用Scrum，结合XP进行开发。用户故事自然是不可或缺的。在这里，每个团队都有一个白板，上面贴有一些卡片。它们是这个Sprint团队计划完成的用户故事以及这些故事划分的任务。这些用户故事卡片概要描述了需求，形如“作为(角色)，我想要(功能)，以此(商业价值)”，有时上面还附着另一张卡片写着验收条件。在做计划和开发的时候，团队可以拿着这个用户故事讨论故事细节，故事如何才算完成，等等，正如Ron Jeffries所描述的3C：Card(卡片)，Conversation(交谈)和Confirmation(确认)。
用户故事从始至终贯穿于整个开发流程。首先产品负责人根据收集来的需求编写用户故事，放入产品Backlog中。在Sprint计划会议中，团队成员讨论其中的一些用户故事，细化故事细节，确定验收标准，使用Planning Poker(计划扑克)估算故事点。然后，将故事分成一些小的任务，并估算工作时间。最后，将故事放入Sprint Backlog中，并按优先级排序。Sprint开始时，故事卡片和任务卡片都放在白板的To Do栏，团队成员按故事的优先级挑选任务，将任务卡片挪到Doing栏。任务完成后，将任务卡片挪到Done栏。团队尽可能地先完成优先级高的故事。在故事开发的初始阶段，测试人员和产品负责人一起确认测试用例。故事的任务都完成后，产品负责人验收并确认故事已完成，将故事卡片挪到Done栏中。如此完成整个Sprint的所有故事。Sprint结束时，团队还要将完成的故事演示给利益相关人、其他产品负责人和团队等。这样，每个Sprint团队都会通过完成一系列的用户故事来向客户输出商业价值。
这次翻译我们一共四个人参与，我和石永超主要负责翻译，滕振宇和李国彪主要负责审核。前期的第一个月，我们几乎没有什么太大的进展。我们讨论过后，发现这次翻译其实是一个具有固定交付时间、固定范围(21章和两个附录)且依赖虚拟兼职开发团队的项目，包含开发(翻译)和测试(审核)等工作，何不用敏捷的方式来开展？于是，第二个月开始，我们使用敏捷的思想来指导翻译工作。我们首先把每一章当作一个用户故事，每个故事估算一个故事点(这个是我们做的不足的地方，一个故事点显然不能准确反映各章的不同篇幅)。我们以一个星期为一个迭代，用一份Excel文档作电子白板。每个周末固定时间用Skype开一次网上语音会议。如同Scrum的每日例会一样，大家回答三个问题：这个星期我做了什么，下个星期准备做什么，有什么困难。然后讨论大家遇到的一些翻译难点，统一一些术语的翻译。大家在完成每个星期的翻译工作的同时，必须及时简单地更新Excel中故事的状态。这样一来，每个人都能及时知道每一章的进度，哪一章可以审核，哪一章没有人翻译，可以任领。同时，Excel中还有燃尽图，告诉我们离目标还有多远，是否需要调整。如此，这份Excel文档就成为我们的另一个沟通工具。另外，我们还有十分重要的工具，如同我们的软件项目一样，对于项目中的所有文件(包括电子白板和术语表)，我们使用版本管理工具Subversion和持续集成工具CruiseControl。我们每次签入，持续集成工具都会立即发一封邮件通知大家有新的改动，邮件包含有签入的描述，这样可以提醒大家某一章翻译完了，应该审核，等等 。这样，从第二个月开始，我们的翻译工作就始终保持稳定的进度，团队通过更多更频繁的回馈不断学习成长，持续改善译稿和翻译过程，最终按时交付了翻译稿。
这次翻译成为我们软件开发之外的一次敏捷实践，获益良多。同样，我们也希望能够让更多的人了解敏捷，让更多从事软件开发的人和其他行业的人从中获益。翻译这本书也希望能为传播敏捷思想与方法尽一份力。让更多的人了解用户故事，使用用户故事，带来更多成功的项目。
在此感谢一起翻译的伙伴们：李国彪、滕振宇和石永超。感谢你们让我能够获得参与翻译此书的机会，我从中学习了很多很多，不仅仅是对用户故事更深入的了解，还有在这次翻译过程中对敏捷更全面、深刻的理解。
张博超
译者团队代表
2010年春于上海
前言
在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则包含每章问题的答案。
我清楚我们成功的动因。但是我仍然有一种挥之不去、怅然若失的感觉，如果我们能写出长长的需求文档，我们可能会更成功。毕竟那是在我当时读到的书和文章里所描述的做法。如果成功的软件开发团队都在编写华丽的需求文档，看起来我们也应该这么做。但是我们从来没有时间做。我们的项目总是太重要，时间非常紧迫，以至于我们从一开始就没有时间做文档。
因为我们从来没有时间写长篇大论的漂亮的需求文档，所以便选定了一个可以和用户交谈的方法。我们不是把需求写下来，传来传去，并在时间不够用的时候还在商谈，而是和客户交谈。我们会在纸上画一些界面样例，有时做一些原型，我们经常开发一点就给潜在的用户展示我们开发了些什么。我们至少每月一次邀请一些典型用户，向他们演示我们开发的功能。我们贴近我们的用户，向用户展示我们一点一滴的进度，这样便在不知不觉中发现一个不需要漂亮的需求文档就可以成功的方法。
我还是觉得愧疚，觉得我们并没有按规范来做事。
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则包含每章问题的答案。
序言
Kent推荐序
你如何确定一个软件系统应该做什么？然后，你怎样和不同的人去沟通你的决定？本书就是研究这个复杂问题的。这个问题很难回答，因为不同的参与者有不同的需求。项目经理想跟踪进度，开发人员想实现系统，产品经理想要灵活性，测试人员想要度量，而用户想要一个可用的系统。在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续数月或者数年都保持这种平衡是很困难的事情。
与早期的种种方法(需求分析、用户实例和场景)一样，在这本书中，Mike Cohn探索的解决方案也是试图解决这个问题。是什么如此复杂？你写下想做的事情然后照着它做。日益出现的多个解决方案表明这个问题并不像最初那样简单，这些方案的不同在于你写下了什么，何时写的。
采用用户故事这一方法，是从写下两条信息开始的：每一个系统需要实现的目标和实现那个目标所需要的大致成本。这只需要几句话，却能给你其他方法没有给出的信息。遵循“最后责任时刻”(Last Responsible Moment)的原则，团队要等到开始实现软件特性前才写下特性的具体细节。
这个简单的时刻调换可以带来两个主要效果。首先，团队很容易在早期开发就开始实现最重要的特性，而那时其他特性还很模糊。当你加入新特性的时候，定义了每个特性行为细节的自动化测试可以保证此前的特性仍然正常工作。其次，在早期对特性进行成本考虑可以驱使我们在起始阶段就对软件特性排列优先级，而不是在最后为了赶上发布日期而惊慌地缩减功能。
Mike在用户故事方面积累的经验使得本书充满实用的建议，让用户故事可以在你们的开发团队里正常运转。祝愿你们有一个明确的、充满自信的开发过程。
Kent Beck
Three Rivers Institute
使用用户故事，不仅仅是为了快
如果去Amazon.com搜索“user story”这个关键字，你会惊奇地发现：User Stories Applied——这是唯一一本以用户故事为主题的书籍。随意翻开一页，你都可以从中发现有关用户故事乃至敏捷的真知灼见，无怪乎读者会称之为“用户故事圣经”。在“圣经”出现之前，我们又是如何应对需求的？
数年之前，每当我接手一个项目的时候，总会有几大本厚厚的文档扔在面前，不外乎需求规格说明、概要设计和详细设计。尤其是需求规格说明，拿起来翻开一看，那些格式化的语言就变成了世界上最好的催眠曲。读尚且如此，遑论写乎？人的大脑同时处理事物的能力是有限的，写这种正式的需求规格说明，既要思考内容是否表述客户的真实意图，还要想着符合公司对于格式、用词等等等等方面的要求，怎能不心生厌惧？更何况大脑里还总回响着一个问题：“这东西写出来，能有人认真看么？”在Wikipedia的User Story页面上，这样讲述使用用户故事的目的：以更快的速度、更少的消耗应对现实世界需求的快速变化。高速互联网时代，更是如此。你还在吭哧吭哧地写需求规格说明，竞争对手的系统很可能都已经上线试运行了。
使用用户故事，不仅仅是为了快。
从大脑认知的角度来看，正式的规约说明，主要以格式化的文字为表现形式。而我们的人脑对此是很难提起兴趣的。O’Reilly有一个Head First系列广为人知，并在市场上热卖，这套书就是在这方面做出了突破。在每一本Head First书籍前，都有同样几页图文并茂的说明，介绍我们大脑的认知方式。面对同样一个主题，只有通过多种不同方式、不同活动的刺激，大脑才能深刻理解并记忆。显然，单一的需求规格说明无法做到这一点。回过头来看用户故事，著名的极限编程创始人之一Ron Jeffries提出了“3C”原则：Card、Conversation和Confirmation。使用卡片记录用户故事，一方面可以隐藏低层细节，另一方面也方便各方人员在白板上将其移来摆去，以整体图形的方式将与客户需求有关的内容深深印在团队的脑海中，更不用说这样给项目规划带来的好处。对话，是为了促使团队与客户之间的沟通，让大家谈论需求，大声说出来，这种活动也调动了大脑的不同区域，让人们能把相关内容学得更快，记得更牢，同时还可促进团队和客户之间的沟通，加强人际联系，何乐而不为？用户故事的确认环节，则是以反复的方式，与用户确认某个具体使用场景中的关键细节，从而不会导致遗漏。
从软件开发的角度入手，使用用户故事，从用户角度出发描述功能，这让我们可以站在最终用户的立场考虑问题，避免程序员的自行其是。同时还能促使团队按功能特性实现需求，而不是按架构层次，这样可以降低系统开发进入后期出现整体风险的可能，带来更大的灵活性。
不过，我想指出的是：用户故事、规划会议等类似系列非技术实践，实施起来可能并不复杂，但是必须要结合TDD、持续集成、重构等技术实践，否则要想产生高质量的代码就是空谈，由此而完成的软件产品或是项目也必将成为沙滩上的城堡，连一个小小的浪头都无法抵挡，一瞬间即可坍塌。这两三年里，国内的敏捷声势一浪高过一浪，可大家更多讨论的也都是Scrum这个管理概念框架，如何减少技术债务、如何做好单元测试等方面的话题可谓寥寥。倘若写代码的基本功不扎实，长此以往，出现问题的时候，就会有人跳出来归罪于敏捷。我们作为软件开发从业人员，对此不可轻视。
回到本书，虽然它第一次正式出版是在6年之前，然而其中的内容却绝不过时。更值得指出的是，本书的译者团队本着快速迭代、频繁沟通的原则，以敏捷的方式完成了翻译，这个过程中，他们甚至还使用了持续集成！作为InfoQ中文站敏捷社区的首席编辑，我希望他们能尽快分享自己在“敏捷翻译”方面的经验，让更多的人将水平更高、质量更好的敏捷乃至技术内容介绍到国内，推动国内软件开发行业的进一步发展。
郑 柯
InfoQ中文站敏捷社区首席编辑
你如何确定一个软件系统应该做什么？然后，你怎样和不同的人去沟通你的决定？本书就是研究这个复杂问题的。这个问题很难回答，因为不同的参与者有不同的需求。项目经理想跟踪进度，开发人员想实现系统，产品经理想要灵活性，测试人员想要度量，而用户想要一个可用的系统。在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续数月或者数年都保持这种平衡是很困难的事情。
与早期的种种方法(需求分析、用户实例和场景)一样，在这本书中，Mike Cohn探索的解决方案也是试图解决这个问题。是什么如此复杂？你写下想做的事情然后照着它做。日益出现的多个解决方案表明这个问题并不像最初那样简单，这些方案的不同在于你写下了什么，何时写的。
采用用户故事这一方法，是从写下两条信息开始的：每一个系统需要实现的目标和实现那个目标所需要的大致成本。这只需要几句话，却能给你其他方法没有给出的信息。遵循“最后责任时刻”(Last Responsible Moment)的原则，团队要等到开始实现软件特性前才写下特性的具体细节。
这个简单的时刻调换可以带来两个主要效果。首先，团队很容易在早期开发就开始实现最重要的特性，而那时其他特性还很模糊。当你加入新特性的时候，定义了每个特性行为细节的自动化测试可以保证此前的特性仍然正常工作。其次，在早期对特性进行成本考虑可以驱使我们在起始阶段就对软件特性排列优先级，而不是在最后为了赶上发布日期而惊慌地缩减功能。
Mike在用户故事方面积累的经验使得本书充满实用的建议，让用户故事可以在你们的开发团队里正常运转。祝愿你们有一个明确的、充满自信的开发过程。
Kent Beck
Three Rivers Institute
使用用户故事，不仅仅是为了快
如果去Amazon.com搜索“user story”这个关键字，你会惊奇地发现：User Stories Applied——这是唯一一本以用户故事为主题的书籍。随意翻开一页，你都可以从中发现有关用户故事乃至敏捷的真知灼见，无怪乎读者会称之为“用户故事圣经”。在“圣经”出现之前，我们又是如何应对需求的？
数年之前，每当我接手一个项目的时候，总会有几大本厚厚的文档扔在面前，不外乎需求规格说明、概要设计和详细设计。尤其是需求规格说明，拿起来翻开一看，那些格式化的语言就变成了世界上最好的催眠曲。读尚且如此，遑论写乎？人的大脑同时处理事物的能力是有限的，写这种正式的需求规格说明，既要思考内容是否表述客户的真实意图，还要想着符合公司对于格式、用词等等等等方面的要求，怎能不心生厌惧？更何况大脑里还总回响着一个问题：“这东西写出来，能有人认真看么？”在Wikipedia的User Story页面上，这样讲述使用用户故事的目的：以更快的速度、更少的消耗应对现实世界需求的快速变化。高速互联网时代，更是如此。你还在吭哧吭哧地写需求规格说明，竞争对手的系统很可能都已经上线试运行了。
使用用户故事，不仅仅是为了快。
从大脑认知的角度来看，正式的规约说明，主要以格式化的文字为表现形式。而我们的人脑对此是很难提起兴趣的。O’Reilly有一个Head First系列广为人知，并在市场上热卖，这套书就是在这方面做出了突破。在每一本Head First书籍前，都有同样几页图文并茂的说明，介绍我们大脑的认知方式。面对同样一个主题，只有通过多种不同方式、不同活动的刺激，大脑才能深刻理解并记忆。显然，单一的需求规格说明无法做到这一点。回过头来看用户故事，著名的极限编程创始人之一Ron Jeffries提出了“3C”原则：Card、Conversation和Confirmation。使用卡片记录用户故事，一方面可以隐藏低层细节，另一方面也方便各方人员在白板上将其移来摆去，以整体图形的方式将与客户需求有关的内容深深印在团队的脑海中，更不用说这样给项目规划带来的好处。对话，是为了促使团队与客户之间的沟通，让大家谈论需求，大声说出来，这种活动也调动了大脑的不同区域，让人们能把相关内容学得更快，记得更牢，同时还可促进团队和客户之间的沟通，加强人际联系，何乐而不为？用户故事的确认环节，则是以反复的方式，与用户确认某个具体使用场景中的关键细节，从而不会导致遗漏。
从软件开发的角度入手，使用用户故事，从用户角度出发描述功能，这让我们可以站在最终用户的立场考虑问题，避免程序员的自行其是。同时还能促使团队按功能特性实现需求，而不是按架构层次，这样可以降低系统开发进入后期出现整体风险的可能，带来更大的灵活性。
不过，我想指出的是：用户故事、规划会议等类似系列非技术实践，实施起来可能并不复杂，但是必须要结合TDD、持续集成、重构等技术实践，否则要想产生高质量的代码就是空谈，由此而完成的软件产品或是项目也必将成为沙滩上的城堡，连一个小小的浪头都无法抵挡，一瞬间即可坍塌。这两三年里，国内的敏捷声势一浪高过一浪，可大家更多讨论的也都是Scrum这个管理概念框架，如何减少技术债务、如何做好单元测试等方面的话题可谓寥寥。倘若写代码的基本功不扎实，长此以往，出现问题的时候，就会有人跳出来归罪于敏捷。我们作为软件开发从业人员，对此不可轻视。
回到本书，虽然它第一次正式出版是在6年之前，然而其中的内容却绝不过时。更值得指出的是，本书的译者团队本着快速迭代、频繁沟通的原则，以敏捷的方式完成了翻译，这个过程中，他们甚至还使用了持续集成！作为InfoQ中文站敏捷社区的首席编辑，我希望他们能尽快分享自己在“敏捷翻译”方面的经验，让更多的人将水平更高、质量更好的敏捷乃至技术内容介绍到国内，推动国内软件开发行业的进一步发展。
郑 柯
InfoQ中文站敏捷社区首席编辑
媒体评论
我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题（他们通常会被告知“我不关心你们怎么做，但请你们在6月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被减掉的功能。 至此我们已经了解到，我们不能完美地预测软件开发项目。当用户看到软件的早期版本时，他们会想出新的点子，从而改变他们的观点。由于软件的这种不可控性，大部分开发人员都会遇到众所周知的艰难时刻，估计需要多长时间才能完事儿。因为这些因素及其他一些因素，导致我们无法勾勒出一幅完美的PERT图①来展示项目中所有必须完成的事情。 ……
书摘
插图：
我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题（他们通常会被告知“我不关心你们怎么做，但请你们在6月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被减掉的功能。
至此我们已经了解到，我们不能完美地预测软件开发项目。当用户看到软件的早期版本时，他们会想出新的点子，从而改变他们的观点。由于软件的这种不可控性，大部分开发人员都会遇到众所周知的艰难时刻，估计需要多长时间才能完事儿。因为这些因素及其他一些因素，导致我们无法勾勒出一幅完美的PERT图①来展示项目中所有必须完成的事情。
我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题（他们通常会被告知“我不关心你们怎么做，但请你们在6月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被减掉的功能。
至此我们已经了解到，我们不能完美地预测软件开发项目。当用户看到软件的早期版本时，他们会想出新的点子，从而改变他们的观点。由于软件的这种不可控性，大部分开发人员都会遇到众所周知的艰难时刻，估计需要多长时间才能完事儿。因为这些因素及其他一些因素，导致我们无法勾勒出一幅完美的PERT图①来展示项目中所有必须完成的事情。
