作者简介

迈克•科恩（Mike Cohn）
敏捷联盟联合创始人&Scrum联盟联合创始人及理事会主席，CST（Scrum认证讲师），Mountain Goat Software创始人兼总裁。迈克从1984年开始编程，1988年开始管理软件项目，1995年开始做自己的一个Scrum项目，从此一发不可收，成为Scrum的忠实拥趸和积极的倡导者。他熟悉很多硬件和软件环境，尤其擅长于指导组织采用和改进敏捷过程和技术的应用，帮助他们打造高绩效的软件开发企业。他服务过很多公司，从新创公司到财富40强都有，比如加拿大游戏制作公司Bioware、一资本Capital One、艺电Electronic Arts、谷歌，高月工作室High Moon Studios、财捷Intuit、JDA软件，律商联讯Lexis Nexis、航空航天公司洛克希德马丁Lockheed Martin、微软、尼尔森媒体调研、培生教育、飞利浦电器、旅游公司Sabre、西门子、升阳微系统、德州仪器、特纳广播公司TBS、人力资源软件开发商Ultimate Software和雅虎。

译者简介

王凌宇
精益敏捷践行者，PMI-ACP，PMP。历任高级项目经理、研发经理、项目群经理、产品经理、敏捷教练等职位，现任上市公司PMO敏捷教练和研发管理专家。
教练指导过多个产品团队实现敏捷转型，成效显著。对于精益敏捷方法的推广应用，项目管理以及PMO的建设运营具有丰富的实践经验。参与译著有《SAFe 4.0精粹：运用规模化敏捷框架实现精益软件与系统工程》。

作为敏捷社区的经典名作，《敏捷软件开发：用户故事实战》不负众望，为软件行业提供了一种高效的需求过程，通过用户故事来节省时间、消除重复工作和开发更优秀的软件。要想构建可以满足用户需求的软件，好的方法是从“用户故事”开始，用简明扼要的语言清楚明确地描述对实际用户有价值的功能。在本书中，敏捷实干家提供了一个详尽的蓝图来指导读者如何编写用户故事，如何在软件开发生命周期中实际运用用户故事。
《敏捷软件开发：用户故事实战》共5部分21章，介绍了如何写出理想的用户故事，造成用户故事不理想的因素有哪些，如何在无法直接接触到用户的情况下有效搜集用户故事，如何对写好的用户故事进行整理、排优先级并在此基础上进行计划、管理和测试。
《敏捷软件开发：用户故事实战》适合采用XP、Scrum甚至其他自主敏捷方法的所有开发、测试、分析师和项目负责人阅读和参考，可以帮助他们以更少的人手在更短的时间内开发出更符合用户需求的产品或服务。

第2章  编写故事
在这一章里，我们将介绍如何编写故事。为了创建好的故事，我们需要关注六个特征。一个好的故事应该具备以下特征（INVEST）：
独立的（Independent）
可协商的（Negotiable）
对用户或客户有价值的（Valuable to users or customers）
可估算的（Estimatable）
小的（Small）
可测试的（Testable）
《极限编程》（Extreme Programming Explored）和《重构实践手册》（Refactoring Workbook）的作者比尔•威克（Bill Wake）建议用单词首写字母缩写INVEST指代这六个特征（Wake 2003a）。
独立的
我们应该尽量避免故事之间相互依赖。故事间的相互依赖会导致优先级排序和计划出现问题。例如，假设客户选定了一个高优先级的故事，而这个故事却依赖于一个低优先级的故事，这样就会产生问题。
故事间的相互依赖也会使估算变得更加困难。例如，假设我们在BigMoneyJobs网站上工作，需要编写故事：公司如何为在网站上发布职位进行付费。我们可以写出如下这些：
1.公司可以用Visa信用卡对发布职位进行付费。
2.公司可以用万事达信用卡对发布职位进行付费。
3.公司可以用美国运通卡对发布职位进行付费。
假设开发人员估算需要3天的时间来支持第一种信用卡（不管它是哪种），然后给第二种和第三种各分别需要1天。对于像这些有相互高依赖关系的故事，你不知道如何对每个故事进行估算—哪个故事应该给3天的估算？
当故事间出现这种依赖时，有两种应对方法可以避免。
将相互依赖的故事合并成一个更大但独立的故事。
寻找一种不同的方式来拆分故事。
将不同种类的信用卡合并成一个独立的大故事（“公司可以使用信用卡对发布职位进行付费”）是不错的，因为合并后的故事只需要5天时间。如果合并后的故事花费的时间要比这长得多，通常一个更好的方法是找一个不同的维度来拆分故事。如果对这些拆分后故事的估算时间更长，那么另一种拆分方法如下：
1.客户可以用一种信用卡支付。
2.客户可以用另外两种信用卡支付。
如果你不想将这些故事合并在一起，并且无法找到一个很好的方法来拆分它们，那么你还可以采用简单的方法，即在故事卡上放两个估算值：较高的估算值给二者之间必须在前面完成的故事，较低的估算值给后面接着要完成的故事。
可协商的
故事是可协商的，它们不是签署好的书面合同或者是软件必须实现的需求。故事卡是对功能的简短描述，其细节是在客户和开发团队之间的对话中协商产生的。因为故事卡本身并不是详细的需求，而是用来提示客户和开发团队进行对话的，所以它们不需要包括所有相关的细节。然而，在编写故事的时候，如果一些重要的细节是已知的，那么就应该把它们包括在故事卡的注释中，如故事卡2.1所示。挑战在于如何掌握包含“足够”的细节。

公司可以用信用卡支付发布职位的费用。
注释：接受Visa信用卡、万事达信用卡和美国运通卡。考虑美国发现卡。
故事卡2.1  一个注释了额外细节的故事卡
 
故事卡 2.1是一个不错的故事卡，因为它提供了适量的信息供开发人员和客户讨论。当一个开发人员开始编码实现这个故事时，故事卡会提示她必须支持三种主卡（Visa信用卡、万事达信用卡和美国运通卡），同时她也可以询问客户是否已经决定接受美国发现卡。卡片上的注释可以帮助开发人员和客户恢复之前中断的对话。理想的情况下，不管是原来对话的开发人员和客户，还是其他的开发人员和客户，对话都应该能够恢复。把细节加入故事时，应该以此为指导原则。
另一方面，让我们思考一个带有太多注释的故事，如故事卡2.2所示。这个故事有太多的细节（“收集卡片的过期月份和日期”），还结合了一个单独的故事（“系统可以存储一个卡号供将来备用”）。

公司可以用信用卡支付发布职位的费用。
注释：接受Visa信用卡、万事达信用卡和美国运通卡。考虑美国发现卡。当支付金额超过100美元时，需要提供卡背面的ID号。系统可以根据卡号的前两位数字识别客户使用的是何种类型的信用卡。系统可以存储卡号以备将来使用。收集信用卡的过期月份和日期。
故事卡2.2  细节过多的故事卡

处理故事卡2.2这样的故事是非常困难的。大多数读者在阅读这种故事时，会错误地关注本不应该关注的细节。然而，在许多情况下，过早指定细节只会产生更多的工作。例如，如果两个开发人员讨论和估算一个简单的故事“公司可以用信用卡支付发布职位的费用”，开发人员知道他们的讨论有点抽象，他们不会误以为他们的讨论是明确的，或者他们的估算是准确的，因为缺少太多的细节。然而，如果向故事卡中添加更多类似故事卡2.2中的细节，关于这个故事的讨论就有可能变得更加具体和真实。但这可能会导致错误的判断：故事卡反映了所有的细节，没有必要再与客户进一步讨论这个故事了。
如果我们把故事卡看作是开发人员和客户进行对话的一种提示，那么故事卡中包含如下信息就是很有价值的。
用来提示保持开发人员和客户对话的一两句话。
在整个对话期间待解决问题的注释。
已经通过对话确定的细节将变成测试。如果使用纸质故事卡，我们可以在故事卡背面注明测试内容，如果使用电子系统，可以标注在合适的地方。故事卡2.3和故事卡2.4展示了故事卡2.2中的过多细节如何变成测试，用于提示对话的注释可以留存在故事卡正面。这样，故事卡的正面包含故事本身和关于相关问题的注释，而卡片的背面则包含用于验证故事是否像预期的那样，以测试形式体现的故事细节。

公司可以用信用卡支付发布职位的费用。
注释：我们需要接受美国发现卡吗？
UI注释：不需要专门的字段来输入信用卡类型（可以从信用卡号的前两位来获得该信息）
故事卡2.3  修正后的故事卡正面（只有故事和需要讨论的问题）

目    录
第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项目中使用用户故事    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