内容简介
作为敏捷社区的经典名作，《敏捷软件开发：用户故事实战》不负众望，为软件行业提供了一种高效的需求过程，通过用户故事来节省时间、消除重复工作和开发更优秀的软件。要想构建可以满足用户需求的软件，最好的方法是从“用户故事”开始，用简明扼要的语言清楚明确地描述对实际用户有价值的功能。在本书中，敏捷实干家提供了一个详尽的蓝图来指导读者如何编写用户故事，如何在软件开发生命周期中实际运用用户故事。
《敏捷软件开发：用户故事实战》共5部分21章，介绍了如何写出理想的用户故事，造成用户故事不理想的因素有哪些，如何在无法直接接触到用户的情况下有效搜集用户故事，如何对写好的用户故事进行整理、排优先级并在此基础上进行计划、管理和测试。
《敏捷软件开发：用户故事实战》适合采用XP、Scrum甚至其他自主敏捷方法的所有开发、测试、分析师和项目负责人阅读和参考，可以帮助他们以更少的人手在更短的时间内开发出更符合用户需求的产品或服务。
前 言
在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包含对各章结尾思考练习题的解答。
目 录
第I部分 开 始第1章 概述 3什么是用户故事？ 4细节在哪里？ 5“需要在多长时间内完成？” 7客户团队 7使用故事的过程是什么样的？ 8计划发布和迭代 9什么是验收测试？ 11为什么要改变？ 12小结 13思考练习题 13第2章 编写故事 15独立的 15可协商的 16对用户或客户有价值的 18可估算的 19小的 20拆分故事 20合并故事 22可测试的 23小结 24开发人员的责任 24客户的责任 24思考练习题 24第3章 用户角色建模 27用户角色 27角色建模步骤 29通过头脑风暴，创建初始的用户角色集合 29整理初始的角色集合 30聚合角色 31细化角色 32两个额外的技术 33用户画像 33极端人物 34如果有现场用户呢？ 34小结 35开发人员的责任 35客户的责任 35思考练习题 36第4章 收集故事 37引出和捕捉需求是不适用的 37一点儿就够用了，不是吗？ 38方法 39用户访谈 39问卷调查 41观察 41故事编写工作坊 42小结 44开发人员的责任 45客户的责任 45思考练习题 45第5章 与用户代理合作 47用户的经理 47开发经理 48销售人员 49领域专家 50营销团队 50前用户 50客户 51培训师和技术支持 52业务分析师或系统分析师 52如何与用户代理合作？ 52当用户存在但访问受限时 52当真的找不到用户时 53你能自己做吗？ 54建立客户团队 54小结 54开发人员的责任 55客户的责任 55思考练习题 55第6章 用户故事验收测试 57在编码之前编写测试 58客户定义测试 59测试是过程的一部分 59多少测试才算多？ 59集成测试框架 60测试的类型 61小结 62开发人员的责任 62客户的责任 62思考练习题 62第7章 好故事编写指南 63从目标故事开始 63纵切蛋糕 64编写封闭的故事 64约束卡片 65根据实现时间来确定故事规模 66不要过早涉及用户界面 66需求不止故事 67故事中包括用户角色 67为一个用户编写故事 68用主动语态 68客户编写 68不要给故事卡编号 68不要忘记目的 69小结 69思考练习题 69第II部分 估算和计划第8章 估算用户故事 73故事点 73团队估算 74估算 74三角测量 76使用故事点 77如果用结对编程呢？ 78“敲黑板” 79小结 79开发人员的责任 79客户的责任 79思考练习题 80第9章 发布计划 81我们希望什么时候发布？ 82希望在发布中包含哪些特性？ 82故事优先级排序 83混合优先级排序 84风险故事 84优先考虑基础设施需求 85选择迭代长度 86从故事点到预期工期 86初始速率 86猜测速率 87创建发布计划 87小结 88开发人员的责任 88客户的责任 89思考练习题 89第10章 迭代计划 91迭代计划概述 91讨论故事 92分解任务 92认领责任 94估算及确认 94小结 95开发人员的责任 96客户的责任 96思考练习题 96第11章 度量和监测速率 97度量速率 97计划速率和实际速率 99发布燃尽图 100迭代燃尽图 102小结 104开发人员的责任 104客户的责任 105思考练习题 105第III部分 经常讨论的话题第12章 用户故事不是什么 109用户故事不是IEEE 830 109用户故事不是用例 112用户故事不是场景 115小结 117思考练习题 117第13章 用户故事的优点 119口头沟通 119用户故事容易理解 121用户故事的大小适合于计划 122用户故事适合迭代开发 123故事鼓励推迟细节 124故事支持随机应变的开发 124用户故事鼓励参与式设计 125故事增强隐性知识 125用户故事的不足 126小结 126开发人员的责任 127客户的责任 127思考练习题 127第14章 用户故事的不良“气味” 129故事太小 129故事相互依赖 130镀金 130细节过多 131过早包含用户界面细节 131想得太远 132故事拆分太频繁 132客户很难对故事排列优先级 132客户不愿意写故事并对故事进行优先级排序 133小结 134开发人员的责任 134客户的责任 134思考练习题 134第15章 在Scrum项目中使用用户故事 135Scrum是迭代式和增量式的 135Scrum基础 136Scrum团队 137产品待办列表 137Sprint计划会议 138Sprint评审会议 140每日Scrum站会 140在Scrum项目中加入用户故事 142用户故事和产品待办列表 142Sprint计划会议中使用用户故事 142Sprint评审会议中使用用户故事 143用户故事和每日Scrum站会 143案例学习 143小结 144思考练习题 145第16章 其他主题 147处理非功能性需求 147纸质还是软件？ 148用户故事和用户界面 150保留故事 152用户故事描述bug 153小结 154开发人员的责任 154客户的责任 154思考练习题 155第IV部分 一个完整的项目案例第17章 用户角色 159项目 159识别客户 159识别一些初始角色 160聚类与细化 161角色建模 163增加用户画像 164第18章 故事 165Teresa的故事 165Ron船长的故事 168初级海员的故事 168非海员礼品购买者的故事 169报表查看者的故事 169一些管理员的故事 170结束 171第19章 估算故事 173第一个故事 174高级搜索 176评分和评价 177账号 177完成估算 178所有的估算 179第20章 计划发布 181估算速率 181对故事进行优先级排序 182完成的发布计划 183第21章 验收测试 185搜索的测试 185购物车的测试 186购买书籍 187用户账号 188管理 188测试约束 189最后一个故事 190第V部分 附 录附录A 极限编程概述 193附录B 各章思考练习题参考答案 203参考文献 217
