《敏捷软件开发：用户故事实战》
敏捷软件开发
用户故事实战
[美] 迈克·科恩（Mike Cohn） 著
王凌宇 译
推荐序
肯特·贝克（Kent Beck）
如何确定一个软件系统应该做什么？然后，怎样和相关的人沟通这个决定？本书研究了这个复杂的问题。这个问题很难，因为不同的相关人，各自的需求也不相同。项目经理想要跟踪进展，程序员想要实现这个系统，产品经理想要灵活性，测试人员想要度量，用户想要一个可用的系统。在这些充满冲突的观点中，想要达成一个每个人都支持的集体决定，并且维持数月或者数年的平衡都是很困难的事情。
迈克·科恩（Mike Cohn）在本书中探讨的解决方案，与以前解决这个问题的尝试方法，需求分析，用例和场景的目的是一样的。是什么如此复杂？你写下你想做的事，然后你照着做。解决方案的层出不穷，表明这个问题并不像看起来那么简单。这些解决方案的不同在于你写下了什么，何时写的。
用户故事通过两条信息来启动这个过程：每个系统需要实现的目标，以及实现这个目标所需要的大致成本。这只需要几句话，却能提供其他方法没有给出的信息。遵循“最后责任时刻”（last responsible moment）的原则，团队成员在实现特性之前，才将特性的大部分细节写下来。
这个简单的时刻转换有两个主要的效果。首先，团队可以很容易在开发早期就开始实现“最优”的特性，而那时其他特性仍然是模糊的。在添加新特性时，定义每个特性细节的自动化测试能够确保已实现的特性继续正常工作。其次，在早期对特性进行成本考虑时，可以鼓励从一开始就优先考虑特性的优先顺序，而不是最后为了满***付日期而忙乱地缩减功能。
迈克在用户故事方面的丰富经验使本书充满了实用的建议，让用户故事成为开发团队的利器吧。祝愿大家在做开发时能够更加明确、自信。
译者序
2001年，敏捷宣言诞生，现在敏捷方法已经在全世界范围内广泛应用。而早在1996年，极限编程就提出了“故事”（story）的概念，这是用户故事的起源。2004年，本书正式出版发行。书中对用户故事理论系统化的阐述，操作实例化的说明，实际应用中的价值呈现，使用户故事由单一实践上升至系统化的方法，本书也当之无愧成为用户故事方法的里程碑之作。虽然还存在一些不足，但是“用户故事”无疑已经成为精益敏捷方法的基石之一。
用户故事方法独有的价值，奠定了它在精益敏捷方法中的基石地位。
首先，用户故事实现了产品需求的敏捷化，进而将软件产品研发过程中的需求、开发、测试主要环节系统化的连接起来。需求模糊不清，变更频繁，做出的功能客户不认可已经成为产品团队普遍面临的痛点问题，怎样在有限的时间内及时交付给用户真正想要的产品，已经成为产品团队的梦想。但是在实现高效的开发之前，首先应该解决的是如何确保团队做的工作是正确的，用户故事覆盖了产品研发过程中的需求领域，对如何获取用户真实的需求并实现敏捷化提供了切实可行的解决方案。
通过有效的对话沟通和迭代式的细节完善等操作，用户故事实现了需求的敏捷化；通过优先级排序和故事点的应用，用户故事实现了需求与开发的连接；通过验收标准的持续明确，用户故事实现了需求与测试的连接。用户故事是一根线，它打破了传统管理中的职能墙，把需求、开发、测试环节进行了有机的连接和敏捷化的融合。
其次，用户故事方法弥补了目前业界通用的精益敏捷方法在产品需求领域的不足，是团队进行全价值链敏捷转型不可或缺的关键要素。
目前业界通用的精益敏捷方法，无论是敏捷Scrum，还是精益Kanban，甚至是规模化敏捷SAFe等，在需求领域，不管是简单的还是复杂分层级的需求描述，最后都会落在用户故事上。虽然精益敏捷基于实践持续演进，但是到目前为止，用户故事仍然是需求领域的核心方法。
第三，用户故事方法撬动了敏捷项目管理计划领域，促进了项目相关方之间的协同合作。
故事点是用户故事中独有的概念。故事点的使用，巧妙地让用户故事能够有效地进行计划，将产品需求与项目计划进行了有机的连接，并支持在项目执行过程中持续进行可协商的适应性调整。
用户故事更强调与用户之间进行口头对话和沟通。用户故事中的很多实践活动，用户代理、故事编写工作坊、估算故事、利用故事计划发布和迭代等，都强调客户、用户和整个项目团队的协同工作。用户故事在客户和项目团队之间搭建起真正的桥梁，促进了项目相关方能够向共同的目标协同努力。
可以说，用户故事给方兴未艾的敏捷项目管理领域贡献了特有的实践智慧。
第四，用户故事方法是组织进行业务敏捷转型不可或缺的工具。
市场商业环境纷繁复杂，用户需求模糊易变，产品交付周期日益缩短，企业组织面临的现状越来越严峻。怎样更好的应对这些现状？实现组织级业务层面的敏捷转型是企业应该优先考虑的方向之一。组织级业务敏捷转型需要企业高屋建瓴的进行规划，但是在落地实施层面更需要切实可操作的工具方法。
用户故事从用户价值的角度出发，在用户需求实现过程中时刻提示团队关注用户目标，并且将研发过程中需求、开发、测试主要环节进行了系统化的连接，能够最大限度地促进团队尽快及早向用户交付价值，从而满足用户真实的需求，适应市场的趋势，进而实现企业的商业目标。
用户故事方法就是从上到下贯通组织业务敏捷转型，并且可落地化操作的有效工具之一。
作为一名精益敏捷的践行者，我在多年推广的过程中意识到，理论只是理论而已，只有通过落地实操的方式给团队组织赋能，解决实际问题才能产生价值。可喜的是，在我们去实操之前，本书摆在我们面前，不仅从理论上，还从实操方面给出了大量的实例化案例来教会我们怎样使用用户故事，仔细品味这些案例，都会给大家带来有价值的参考。在后续的实施中，我相信用户故事会给大家带来惊喜。
最后，我把本书献给我的妻子王晓兰和我的儿子，在翻译的过程中，我的妻子正在辅导儿子学习英语，这使得我们家的翻译学习氛围更加浓厚，同时也激励我实现高质量的完成交付。由于妻子的辛劳付出和儿子的专心学习，使我能够心无旁骛地进行工作，反复琢磨词句，并最终将经典作品再次以全新的姿态呈现给各位读者朋友。
前 言
在20世纪90年代中期的大部分时间里，我都感到愧疚。我当时正在为一家公司工作，这家公司每年都会收购一家新公司。每次收购一家新公司，我都会被分派去负责打理他们的软件开发团队。收购的每个开发团队都带来了辉煌、美观、冗长的需求文档。我不可避免地感到愧疚，因为我自己的团队从来没有写出过如此优美的需求规格说明。但是，我的团队在生产软件方面一直比我们收购的团队成功得多。
我清楚我们成功的方法。然而，我总有一种难以名状的感觉，如果我们能写出大而冗长的需求文档，我们可能会更加成功。毕竟，那正是我当时正在阅读的书籍和文章中所描述的做法。如果成功的软件开发团队都在编写华丽的需求文档，那么看起来我们也应该这样做。但是，我们从来没有时间做。我们的项目总是太重要，需要我们尽快启动，以至于我们从一开始就没有时间来写文档。
因为我们从来没有时间写美观而冗长的需求文档，所以我们决定采用一种工作方式来与用户沟通。我们不是把需求写下来，让它们来回传递，并在时间不够用的时候还在谈判，而是和客户交谈。我们会在纸上绘制界面样例，有时候会创建原型，通常我们会写一些代码，然后向预期用户展示我们编写的内容。至少每月一次，我们会邀请一组具有代表性的用户，并向他们演示我们开发的功能。通过贴近用户并向他们演示小的增量进展，我们找到了一种方法来帮助我们在没有美观需求文档的情况下取得成功。
尽管如此，肯特·贝克（Kent Beck）仍然感到愧疚，认为我们没有按照我们应该的方式去做事。
1999年，肯特·贝克的革命性小册子《解析极限编程》出版发行。一夜之间，我所有的愧疚荡然无存。终于有人提出了开发人员和客户之间用讨论取代“写文档-商谈-再写文档”的模式。肯特阐明了很多事情，并带给我很多新的工作方法。但是，最重要的是，他证明了我从自己的实践中领悟到的是正确的。
大量的前期需求收集和文档可能在多方面导致项目失败。最常见的一种情况是需求文档本身成为软件开发的目标。需求文档只有在能够帮助实现交付某些软件的真正目标时才应该编写。
大量的前期需求收集和文档可能在多方面导致项目失败的第二种情况是书面语言的不准确性。我记得很多年前听到过一个小孩洗澡的故事。小孩的父亲已经在浴缸中放满了水，正准备帮助他的小孩进入水中。这个小孩大概两三岁，先把脚趾头伸入水中蘸了一下，然后迅速将脚趾移开，并告诉她的父亲“让它暖和一些”（make it warmer.）。父亲把手伸入水中，惊讶地发现水不是太冷，已经比他女儿习惯的温度更热了。
父亲思索了一下孩子的请求，意识到他们的沟通出现了问题，用相同的词语来表示不同的意思。孩子“让它暖和一些”的请求被任何成年人都解释为“调高水温”（increase the temperature）。然而，对于孩子来说，“让它变暖”意味着“让它接近我认为暖和的程度”。
文字，尤其是白纸黑字那样的，通过它来表达软件这样复杂东西的需求，是比较简单有限的载体。由于它们可能被误解，所以我们需要用开发人员、客户和用户之间频繁的对话来取代书面文字。用户故事为我们提供了这种方法，让我们写下来足够多我们不会遗忘的内容，并且我们可以估算和计划，同时还鼓励及时沟通。
读完本书的第I部分时，你将准备开始改变总是严格写下每一个需求最后细节的工作方式。读完本书的时候，你会知道在具体环境中实施故事驱动过程所有的必要信息。本书分为四个部分和两个附录。
l 第I部分“开始”，描述开始编写故事需要了解的一切。用户故事的目标之一是让人们说话而不是写作。第I部分的目标是尽快让你交谈。第1章概述了什么是用户故事以及如何使用故事。接下来的章节提供了编写用户故事，通过用户角色建模收集故事，在无法访问实际最终用户时编写故事以及测试用户故事的更多细节。第I部分的结尾部分提供了一些指导方针，可以用来改进用户故事。
l 第II部分“估算和计划”，有了一系列用户故事后，我们经常需要回答的第一件事是“需要花费多长时间来开发？”。第II部分介绍了如何使用故事点来估算故事，如何在3~6个月的时间范围内计划发布，如何更详细地计划随后的迭代，最后如何度量进度并评估项目是否按照既定的意愿进行。
l 第III部分“经常讨论的话题”，首先描述故事与用例，软件需求说明和交互设计场景等需求方案的不同之处。随后探讨用户故事的独特优点，如何判断出现问题的时间，如何调整敏捷过程Scrum以使用故事。最后一章着眼于各种小问题，例如是否在纸质卡片或者软件系统中编写故事以及如何处理非功能性需求。
l 第IV部分“一个完整的项目案例”，一个扩展的例子，旨在帮助归纳用户故事的所有内容。如果说开发人员可以通过故事更好地理解用户的需求，那么本部分的完整示例是非常重要的，这个示例将展示用户故事的各个方面及其结合方式。
l 第V部分“附录”，用户故事源于极限编程。阅读本书之前不需要熟悉极限编程。附录A提供了极限编程的简要介绍。附录B包含对各章结尾思考练习题的解答。
致 谢
本书受益于众多审阅者的评论。我特别感谢Marco Abis，Dave Astels，Steve Bannerman，Steve Berczuk，Lyn Bain，Dan Brown，Laura Cohn，Ron Crocker，Ward Cunningham，Rachel Davies，Robert Ellsworth，Doris Ford，John Gilman，Sven Gorts，Deb Hartmann，Chris Leslie，Chin Keong Ling，Phlip，Keith Ray，Michele Sliger，Jeff Tatelman，Anko Tijman[①]，Trond Wingård，Jason Yip和一些匿名的审阅者。
我衷心感谢本书正式的审阅者：荣恩（Ron Jeffries）、汤姆（Tom Poppendieck）和比尔（Bill Wake）。荣恩使我保持诚实和敏捷。汤姆使我察觉到之前没有考虑到的许多想法。比尔则使我保持正确的方向，并与我分享他的INVEST缩写词模型。我很骄傲能够和三位共事，他们当中任何一位提出来的建议都对完善本书做出了不可估量的贡献。
我还要感谢丽莎（Lisa Crispin）——《极限编程测试》的作者，她鼓励我写这本书，并告诉我她与Addison-Wesley出版社愉快的合作经历。没有她的鼓励，我将永远无法开始。
在过去的9年中，我所知道的大部分内容都与托德（Tod Golding）争论过。我们之间的共识远远超过彼此之间的争执。不管怎样，我从我们的争论中学到东西。多年来他所教我的一切，我都感激不尽。我和他讨论的内容极大充实了本书。
感谢阿历克斯（Alex Viggio）和XP Denver的所有人，让我有机会展示本书许多早期的想法。也感谢马克和J. B.（Mark Mosholder和J. B. Rainsberger），他们向我讲述了他们如何使用软件而不是卡片。感谢肯尼（Kenny Rubin）[②]，他与阿黛尔（Adele Goldberg）合作完成了Succeeding With Objects一书，他在书中所表现出来的自豪感使我在停笔数年后再次开始写作。
衷心感谢马克和Fast401k创始人丹（Dan Gutrich），他们全心全意地拥抱用户故事和Scrum。还要感谢Fast401k我的每一位同事，我们正在努力实现我们的目标——成为科罗拉多州最好的团队之一。
千言万语都无法表达我对家人的感激，因为有那么多的时间我无法陪伴他们。感谢我美丽的女儿和公主，萨凡娜和德兰妮（Savannah和Delaney）。特别感谢我美丽的妻子劳拉（Laura），因为我的繁忙，她得操很多心。
我对Addison-Wesley团队感激不尽。与保罗（Paul Petralia）的合作一直都非常愉快。米切尔（Michele Vincenti）一直推进事情。丽莎（Lisa Iarkowski）为我使用FrameMaker提供了宝贵的帮助。盖尔（Gail Cocker）润色了我的图表。尼克（Nick Radhuber）最后把所有一切整合在一起。
最后同时也是最重要的感言要献给肯特，感谢他的真知灼见和他的时间，感谢他把本书收入他的签名系列中。
目 录
第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项目中使用用户故事 135
Scrum是迭代式和增量式的 135
Scrum基础 136
Scrum团队 137
产品待办列表 137
Sprint计划会议 138
Sprint评审会议 140
每日Scrum站会 140
在Scrum项目中加入用户故事 142
用户故事和产品待办列表 142
Sprint计划会议中使用用户故事 142
Sprint评审会议中使用用户故事 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章 故事 165
Teresa的故事 165
Ron船长的故事 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
- 点赞
- 收藏
- 关注作者
评论（0）