具体描述
《用户故事与敏捷方法》详细介绍了用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。
《用户故事与敏捷方法》对于软件开发人员、测试人员、需求分析师和管理者，具有实际的指导意义和重要的参考价值。
作者简介
Mike Cohn是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401(k)档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍
目录信息
第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
· · · · · · (收起)
读后感
这本书我先看了一遍英文版（那时中文版还没上市），又读了两遍中文版。 书写的很清楚，把用户故事的来龙去脉解释的非常清楚，如何写，如何用，和其他需求编写方式有什么区别等等都写的很到位。翻译的也不错。 总之，值得多读几遍
2001年，敏捷宣言诞生,现在敏捷方法已经在全世界范围内广泛应用。而早在1996年，极限编程就提出了“故事（story）”的概念，这是用户故事的起源。2004年，Mike Cohn《 User Stories Applied: For Agile Software Development》一书正式发表。书中对用户故事理论系统化的阐述，...
• 极限编程5原则： ○ 快速反馈 Rapid Feedback ○ 假设简单Assuming Simplicity ○ 增量变化 incremental change ○ 拥抱变化 embrace change ○ 高品质产品 doing Quality work • 极限编程涉及以下实践 ○ Small release ○ The planning game ○ Re...
Business Analyst首选的入门教科书。 我读得很快，因为太想快点入门。 我想的，这种书，常读常新，以后带着经验重读，应该会更有感触。 更个人的主观看法，要是在现在这个阶段做新产品，前期应该很多东西，都可以「借鉴」吧。 更多书评，可以查看我的个人站点
用户评价
当我翻开这本书的时候，我并没有抱太大的期望，想着可能就是市面上众多讲解敏捷的陈词滥调。然而，令我惊喜的是，这本书以一种极其独特且引人入胜的方式，将用户故事的艺术与敏捷的哲学巧妙地融合在一起。作者的叙述风格非常具有感染力，仿佛在娓娓道来一个激动人心的故事，而不是在枯燥地讲解理论。他并没有回避敏捷转型过程中可能遇到的各种挑战和困境，反而提供了许多切实可行的解决方案和应对策略。我特别喜欢书中关于“共情”的部分，它强调了理解用户需求的关键在于站在用户的角度思考问题，而用户故事正是实现这一目标的最有效工具。书中对“验收标准”的讲解也让我受益匪浅，清晰的验收标准是确保团队对需求理解一致、避免返工的关键。这本书不仅提供了理论框架，更重要的是，它给了我一种思维方式的转变，让我更加注重价值交付和持续改进。我已经开始尝试在我的团队中实践书中的一些方法，并看到了明显的积极变化。
这本书绝对是我近年来阅读过最令人振奋的实践指南之一。它深入浅出地阐释了如何将抽象的用户故事转化为切实可行的开发任务，并且将敏捷方法论的精髓融入到实际的项目管理流程中。我尤其欣赏作者对于“为什么”的反复强调，不仅仅是教你“怎么做”，而是让你理解“为什么这样做”能够带来更好的结果。书中通过大量的真实案例，生动地展示了在需求不确定、变化频繁的环境下，如何通过迭代和反馈来不断优化产品。我记得其中一个案例，关于一个初创公司如何利用用户故事和看板来快速验证市场需求，避免了巨额的开发成本和时间的浪费，这让我深受启发。作者在解读各种敏捷实践，如Scrum、Kanban时，并没有生搬硬套，而是强调了它们的核心原则以及在不同团队和项目中的灵活应用。这本书的语言非常亲切，即使是初次接触敏捷方法的人也能很快理解。它不仅仅是一本书，更像是一位经验丰富的导师，在你进行敏捷转型过程中，随时提供指引和建议。我已经被它所蕴含的逻辑和实践的有效性深深吸引，迫不及待地想将书中的知识应用到我自己的工作中。
我必须承认，一开始我有些怀疑这本书的实用性，毕竟敏捷方法和用户故事在业界已经讨论了很久。但读完之后，我发现这本书的价值在于它提供了一种更加深刻、更加人性化的理解。作者并没有止步于讲解“工具”和“技术”，而是深入探讨了如何构建一个能够持续交付高质量产品的文化。书中关于“反馈循环”的强调，让我深刻理解了为什么在敏捷开发中，持续的沟通和协作如此重要。它就像是一张精心绘制的地图，指引我如何在错综复杂的敏捷世界中找到方向。我特别喜欢书中关于“定义完成”（Definition of Done）的章节，它为我提供了一个清晰的衡量标准，确保团队交付的产品真正达到了预期的质量。这本书不仅提升了我对敏捷方法论的理解，更重要的是，它激发了我对如何创造更好产品的热情。这本书的语言简洁明了，结构清晰，即使是第一次接触敏捷的读者，也能快速领会其精髓。
毫不夸张地说，这本书已经成为了我案头的必备参考。它并没有提供一套放之四海而皆准的“灵丹妙药”，而是提供了一种强大的思考工具箱，帮助我根据具体情况来选择和应用最适合的方法。我尤其欣赏作者在解释敏捷原则时的严谨和深入，他能够将“透明”、“检视”和“适应”这些核心概念，通过生动的故事和具体的实践，转化为可执行的操作。书中关于“故事地图”的讲解，为我提供了一个全新的视角来可视化产品路线图，并帮助团队理解不同用户故事之间的关联和优先级。我发现，通过将用户故事与敏捷的迭代周期相结合，我们能够更有效地管理范围蔓延，并快速响应市场的变化。这本书的价值在于，它不仅仅教授了“做什么”，更重要的是教会了“如何思考”。它鼓励我不断质疑和改进现有的流程，而不是盲目地遵循某个固定的框架。
这本书给我带来了意想不到的思维冲击，它让我重新审视了产品开发过程中“人”的重要性。作者用一种非常细腻且富有洞察力的方式，描绘了用户故事如何成为连接开发者和用户的桥梁，如何让团队成员真正理解他们正在为谁构建产品，以及为什么构建。这种对用户价值的极致追求，贯穿了整本书的始终。我被作者对于“史诗”、“特性”、“用户故事”和“任务”之间层级关系的清晰划分所折服，这种结构化的思考方式，极大地提高了需求的梳理和管理效率。同时，书中关于敏捷估算和规划的章节，也打破了我以往的一些固有观念。作者强调的“相对估算”和“基于价值的优先级排序”，让我看到了在不确定性中进行有效预测的可能性。我特别欣赏书中关于“持续集成”和“持续交付”的实践建议，它们是实现敏捷交付的基石。这本书不仅仅是一本技术手册，更是一本关于如何构建高效、协作、以用户为中心的产品团队的哲学指南。
看看就行了，其实很多时候对第一线的用处不是特别大。但是引起的思考和进一步研究是很好的
简洁、实用。
简洁、实用。
入门人员还是很值得看看的
这是讲敏捷实战的书，里面例子很丰富。可惜在我们团队一落地实践，效果就摔成了渣。
