内容简介

Mike Cohn是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401(k)档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍

作品目录

第I部分 起步
第1章 概览 3
什么是用户故事？ 4
细节在哪里？ 5
“必须多长时间完成？” 6
客户团队 7
使用故事的过程是怎么样的？ 7
规划发布和迭代 9
什么是验收测试？ 11
为什么要变？ 12
小结 13
问题 14
第2章 编写故事 15
独立的 15
可讨论的 16
对用户或客户有价值的 18
可估计的 19
小的 20
分割故事 21
合并故事 23
可测试的 23
小结 24
开发人员职责 25
客户团队职责 25
问题 25
第3章 用户角色建模 27
用户角色 27
角色建模的步骤 28
通过头脑风暴，列出初始的用户
角色集合 29
整理最初的角色集合 30
整合角色 31
提炼角色 32
两个额外的技术 33
虚构人物 33
极端人物 34
如果有现场用户该如何？ 35
小结 35
开发人员职责 35
客户职责 35
问题 36
第4章 搜集故事 37
引出和捕捉是不合用的 37
够用就行，不是吗？ 38
方法 38
用户访谈 39
问卷调查 41
观察 41
故事编写工作坊 42
小结 45
开发人员职责 45
客户职责 45
问题 46
第5章 与用户代理合作 47
用户的经理 47
开发经理 48
销售人员 49
领域专家 49
市场营销团队 50
以前的用户 50
客户 51
培训师和技术支持 52
业务分析师或系统分析师 52
与用户代理合作时，做些什么？ 52
能接触到用户但访问受限时 52
实在不能接触到用户时 53
可以自己来吗？ 54
设立客户团队 54
小结 55
开发人员职责 55
客户团队职责 56
问题 56
第6章 用户故事验收测试 57
在写代码之前写测试 58
客户定义测试 59
测试是过程的一部分 59
多少测试才算多？ 59
集成测试框架 60
测试类型 61
小结 62
开发人员职责 62
客户职责 62
问题 62
第7章 优秀用户故事准则 63
从目标故事开始 63
切蛋糕 63
编写封闭的故事 64
卡片约束 65
根据实现时间来确定故事规模 65
不要过早涉及用户界面 66
有些需求并不是故事 67
在故事里包括用户角色 67
只为一个用户编写 68
以主动语态编写 68
由客户编写 68
向故事卡编号说“不” 68
不要忘记意图 69
小结 69
问题 70
第II部分 估算和计划
第8章 估算用户故事 73
故事点 73
以团队估算 74
估算 74
三角测量 75
使用故事点 76
如果用结对编程呢？ 77
一些提醒 78
小结 79
开发人员职责 79
客户职责 79
问题 79
第9章 发布计划 81
我们想在什么时候发布 81
希望在发布中包含哪些功能？ 82
排列故事优先级 82
混合优先级 84
高风险故事 84
根据架构需要安排优先级 85
选择迭代长度 86
从故事点到预计工期 86
初始速率 87
猜测速率 87
创建发布计划 88
小结 88
开发人员职责 89
客户职责 89
问题 89
第10章 迭代计划 91
迭代计划概览 91
讨论故事 91
分解任务 92
准则 93
承担职责 94
估算并确认 94
小结 95
开发人员职责 96
客户职责 96
问题 96
第11章 测量并监控速率 97
测量速率 97
计划速率和实际速率 98
迭代燃尽图 100
迭代中的燃尽图 102
小结 104
开发人员职责 105
客户职责 105
问题 105
第III部分 经常讨论的话题
第12章 故事不是什么 109
用户故事不是IEEE 830 109
用户故事不是用例 112
用户故事不是场景 115
小结 117
问题 118
第13章 用户故事的优势 119
口头沟通 119
用户故事容易理解 121
用户故事的大小适合做计划 122
用户故事适合于迭代开发 123
用户故事鼓励延迟细节 124
用户故事支持随机应变的开发 124
用户故事鼓励参与性设计 125
用户故事传播隐性知识 126
用户故事的不足 126
小结 127
开发人员职责 127
客户职责 128
问题 128
第14章 用户故事不良症兆一览 129
故事太小 129
故事互相依赖 129
镀金 130
细节太多 131
过早考虑用户界面细节 131
想得太远 132
故事划分太过频繁 132
客户很难为故事安排优先级 132
客户不愿意写用户故事，也不愿意
为故事安排优先级 133
小结 134
开发人员职责 134
客户职责 134
问题 134
第15章 Scrum与用户故事 135
Scrum是迭代和递增的 135
Scrum基础 136
Scrum团队 137
产品Backlog 137
Sprint计划会议 138
Sprint评审会议 140
每日Scrum简会 140
在Scrum中使用用户故事 142
Scrum和产品Backlog 142
在Sprint计划会议中使用
用户故事 142
在Sprint评审会议中使用
用户故事 143
在每日Scrum简会中使用
用户故事 143
一个案例 143
小结 144
问题 145
第16章 其他话题 147
处理非功能性需求 147
纸质还是软件? 148
用户故事和用户界面 150
保留故事 152
缺陷的用户故事 154
小结 154
开发人员职责 155
客户职责 155
问题 155
第IV部分 一个完整的实例
第17章 用户角色 159
项目 159
定义客户 159
定义一些角色雏形 160
整合与提炼 161
角色建模 162
添加虚构人物 164
第18章 一些用户故事 165
Teresa的故事 165
Ron船长的故事 168
“初级航海者”的故事 168
“不出海的礼物购买者”的故事 169
“报表查阅者”的故事 169
“管理员”的一些故事 170
收尾 171
第19章 估算故事 173
第一个故事 174
高级搜索 176
评分和评论 177
账户 177
完成估算 178
所有估算 179
第20章 发布计划 181
估算速率 181
给故事安排优先级 181
最终的发布计划 182
第21章 验收测试 185
搜索测试 185
购物车测试 186
购买书 187
用户账户 187
管理 188
测试限制条件 189
最后一个故事 190
第V部分 附录
附录A 极限编程概览 193
附录B 参考答案 203
· · · · · ·

作者简介

Mike Cohn是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401(k)档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍

精彩摘录

第1章概览什么是用户故事用户故事描述了对用户、系统或软件购买者有价值的功能。其包括：1.一份书面的故事描述，用来做计划和作为提示。2.有关故事的对话，用于具体化故事细节。3.测试，用于表达和编档故事细节且可用于确定故事何时完成。使用故事的过程是怎么样的？编写用户故事的过程最好从考虑系统的用户类别开始。应由客户团队而不是开发人员来编写用户故事，尽量不要出现技术术语。排列优先级时需要考虑下面几点：1.大部分用户和客户对特定特性的渴望程度。2.小部分重要用户和客户对特定特性的渴望程度。3.故事之间的互补或依赖关系。规划发布和迭代在许多故事的优先级上，开发人员可能与客户团队意见相左。他们可能基于技术风险或由于某个故事是其他故事的互补故事，而建议改变故事的优先级。客户端团队应该倾听他们的观点，但是随后排列故事优先级时，应该坚持客户组织利益最大化的原则。小结故事卡是故事的可见部分，但客户团队和开发人员关于故事的对话更重要。客户团队包括那些确保软件符合潜在用户需求的人，可以包括测试人员、产品经理、实际用户和交互设计师。

——引自章节：第1章概览

第6章用户故事验收测试验收测试可以记录客户提出的一些假设，也提供了确认故事是否被完整实现的基本原则。在写代码之前写测试考虑每个故事，然后问类似下面的一些问题：1.关于这个故事，程序员还需要知道什么？2.对怎么实现这个故事，我的想法是什么？3.有没有一些特殊情况会使这个故事有不一样的行为？4.这个故事在什么情况会出错？客户定义测试客户可以和程序员与测试人员合作创建测试，但不要完全依赖程序员与测试人员，客户至少应该详细的指出一些测试，用以验证故事的实现是正确的。测试是过程的一部分一般情况下，产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识；测试人员则带来怀疑的心态。多少测试才算多？只要这些测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试。同时，一个优秀的开发团队会为很多详细的用例写单元测试。集成测试框架客户在每轮迭代时都执行以往迭代的所有测试时非常重要的，且递增的测试工作量要求开发团队应该自动化部分或全部验收测试。集成测试框架http://fit.c2.com自动化验收测试工具：http://fitnesse.org测试类型在敏捷项目中，测试的目的是发现并消除缺陷，所以没有必要追求100%的代码覆盖率或测试所有的边界条件。我们运用我们的直觉、知识和过去的经验来指导测试。开发人员职责1.若团队觉得有需要，则负责实现自动化验收测试。2.开始开发一个新的故事时，负责考虑更多的验收测试。3.负责为代码作单元测试，使验收测试就不必顾及故事的每个细节。客户职责1.负责编写验收测试。2.负责执行验收测试。

——引自章节：第6章用户故事验收测试