用户故事与敏捷方法

这本书的英文名是《User Stories Applied : For Agile Software Development》，是一本将敏捷开发（XP）的思想与流程应用到需求管理工作的小册子。
用户故事是一种管理需求的方法，以便开发人员、客户团队、客户以及用户共同配合开发出高质量产品。

用户故事的特征：

1. 独立的；
2. 可讨论的；
3. 对用户或客户有价值的；
4. 可估计的；
5. 小的，注意区分“复合故事”与“复杂故事”的区别；
6. 可测试的

用户故事不是“场景”，主要区别在于“范围与细节”，场景包含更多的细节，同时涵盖多个故事。

用户故事的优势：

1. 强调口头沟通；
2. 容易理解；
3. 适合做计划；
4. 适合迭代开发；
5. 鼓励延迟细节；
6. 支持随机应变的开发；
7. 鼓励参与性设计；
8. 传播隐性知识。

来自前辈的箴言：

1. 用户以及客户通常不能准确的知道自己的实际需求；
2. 即便开发者知道所有的需求，很多需求细节只能随着他们的开发进展变得清晰；
3. 就算假设所有的细节可以在前面弄清楚，人们也没有能力理解这么多细节；
4. 就算我们真的能理解所有的细节，产品和项目也会经常变更；
5. 人非圣贤，孰能无过。

需求最重要的两个问题：

1. 用户是谁？
2. 他们的诉求是什么？

所以本书围绕“用户角色”和“优秀故事”着力进行了介绍：

1. 用户角色。初始角色 -> 整合角色 -> 提炼角色。两个额外的技术：虚拟人物，极端人物。确定真正的用户，注意区分客户与用户，排除用户经理、开发经理与市场人员这种干扰项，如果希望软件是可用的，就要与未来的用户交流。
2. 优秀故事：够用就行，写尽可能多的故事，在较高层面讨论、不要陷入细节，尽量让客户编写故事，故事需要围绕单个用户，同时符合故事的特征（见上文）。

不良故事的症兆：

1. 故事太小；
2. 相互依赖；
3. 额外实现；
4. 细节太多；
5. 过早考虑界面；
6. 频繁划分；
7. 难以排序；
8. 客户甩锅。

客户定义测试，测试是开发过程的一部分，而不是在编码完成后要做的事。

排列优先级的莫斯科（MoSCow）规则：

·必须有的（Must have）；
·应该有的（Should have）；
·可以有（Could have）
·这次不会有（Won't have this time）。

优先级需要考虑的因素：重要性、成本、风险、架构，如果有冲突，就以客户的优先级为准。

以故事为需求单元，从故事分解出任务，然后在团队内分配职责，同时测试并监控速率。

XP 的 12 个实践：

1. 短交付周期（small releases）；
2. 计划游戏（the planning game）；
3. 重构（refactoring）；
4. 测试（testing）；
5. 结对编程（pair programing）；
6. 持续一致的速度（sustainable pace）；
7. 团队代码所有权（team code ownership）；
8. 编码标准（coding standard）；
9. 简单设计（simple design）；
10. 隐喻（metaphor）；
11. 持续集成（continuous integration）；
12. 现场客户（on-site customer）；

XP 提倡的 4 大价值：

1. 沟通（Communication）；
2. 简单（Simplicity）；
3. 反馈（Feedback）；
4. 勇气（Courage）。

XP 的五项基本原则；

1. 快速反馈（rapid feedback）；
2. 假设简单（assuming simplicity）；
3. 增量变化（incremental change）；
4. 拥抱变化（embrace change）；
5. 高品质的产品（doing quality work）。

PS:产品经理最喜欢其中“拥抱变化”这条了。

XP 团队特质：

1. 向客户提供快速反馈，并从反馈中学习；
2. 喜欢简单，并总是试图在转移到更复杂的解决方案前，先做简单的解决方案；
3. 通过小的、增量的变化提高软件质量；
4. 拥抱变化，知道自己是真正地善于包容和适应；
5. 坚决主张软件应该始终展示出最高的质量工艺。