《用户故事与敏捷方法》：敏捷大师Mike Cohn的软件需求方法圣经，小型团队(项目)不可或缺的敏捷开发宝典，亚马逊五星级长销图书，敏捷社区重点推荐，结合精髓和实例，充分演绎用户故事的智慧。
在敏捷社区的详尽评审和热切期盼下， 《用户故事与敏捷方法》不负众望.为软件行业提供了一种节省时间和消除重复工作的需求管理方法.对开发更优秀的软件起着积极、高效的推动作用。
构建满足用户需求的软件，方法是从“用户故事”开始，即简明扼要、清楚明确地描述对实际用户有价值的功能。在《用户故事与敏捷方法》中.敏捷大师Mike cohn提供详尽的蓝图来指导我们如何编写用户故事.如何把它们应用于软件开发生命周期中。
《用户故事与敏捷方法》介绍了如何编写理想的用户故事，造成用户故事不理想的原因有哪些，如何在无法与用户交流的情况下有效地搜集用户故事.如何对已经写好的用户故事进行整理、排列优先级及在此基础上进行计划、管理和测试。
·专注于“用户故事”这一灵活、敏捷和实用的需求方法。
·强调如何用更短的时间开发更符合用户需求的软件应用。
·揭示如何在不能直接与用户交流的情况下搜集用户故事。
·诠释用户故事的优势，用户故事与用例、使用场景和传统需求方法的不同。
·精辟阐述如何围绕着用户故事进行全面的规划、进度、估算和测试。
·极限编程(Extreme Programming)，scrum或其他任何敏捷方法的伴侣。
采用XP和scrum等敏捷开发方法或其他软件开发方法的开发人员、测试人员，分析师和管理人员．可以从《用户故事与敏捷方法》获得有价值的信息，以更少的人员在更少的时间内开发出更符合用户需求的软件应用。
 

目录
第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本编程方面的书籍。（Mike也是《敏捷估计及估算》及Succeedingwith Agile两本重要敏捷著作的作者，并与其他两位敏捷泰斗Ken Schwaber和EstherDerbv一起创办了Scrum联盟。）

我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题（他们通常会被告知“我不关心你们怎么做，但请你们在6月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被减掉的功能。
至此我们已经了解到，我们不能完美地预测软件开发项目。当用户看到软件的早期版本时，他们会想出新的点子，从而改变他们的观点。由于软件的这种不可控性，大部分开发人员都会遇到众所周知的艰难时刻，估计需要多长时间才能完事儿。因为这些因素及其他一些因素，导致我们无法勾勒出一幅完美的PERT图①来展示项目中所有必须完成的事情。