接触了解用户故事到现在，近十个月了，一直没用这种方法进行完整的实践，趁着这两天休假，将前期了解的知识整理一下。

敏捷与极限编程

对于敏捷的粗浅了解仅有一些概念性的东西和最近一段时间的实践。敏捷强调递增与迭代，在迭代中完善细节。

敏捷宣言

个人和交流重于过程和工具

正在运行的软件本身重于复杂的文档

与客户的沟通和交流重于使用合同约束客户

对变化的快速响应重于跟随计划

极限编程

12个实践

短交付周期：2周左右，通常1-3周，不超过4周

计划游戏：发布计划和迭代计划。

重构：不断关注重构。

测试：测试驱动开发，测试-编码-测试-编码。

结对编程

持续一致的速度

团队代码所有权

编码标准

简单设计

隐喻

持续集成

现场客户：产品、测试、开发团队及时沟通。

极限编程价值

沟通：面对面沟通

简单：最简单可行的方式

反馈：重视反馈，越快越好

勇气：重视勇气

关键原则

快速反馈

假设简单

增量变化

拥抱变化

高品质质量

用户故事

概览

用户故事包括：描述、对话和注释。必须是：独立的、有价值的、可讨论的、可估计的、可测试的、规模合理的（小的）。史诗故事包括复合故事和复杂故事，根据具体情况对用户故事进行分割和合并。

描述是对用户故事的简单书面描述，它是主动的。

对话用来提醒客户团队和开发亟待讨论的问题，不需要记录太多细节。

注释主要包括验收测试用例。测试用例在开发前已经由产品和测试完成。

故事需要所有团队成员经过多轮的讨论，才不断完善。

优秀用户故事准则

考虑每一个用户角色，从目标故事（高层次故事）开始衍生

切蛋糕原则：每个故事具有某种程度的完整性

编写封闭的故事，有明确的范围边界

卡片约束

根据时间来确定故事规模和精确度

不要过早涉及用户界面

有些需求并不是故事，可以使用其他的形式表达某些需求

故事里包括用户角色

一个用户故事只为一个角色编写

以主动语态编写

由客户编写

不需要编号，增加无谓的流程

有序号，表示优先顺序

故事卡用来提醒客户和开发的对话讨论，要简洁，尽量只有切人点提醒，不加入太多的细节

角色建模

列出角色（角色卡）

整理角色

提炼角色

角色特征（角色卡）

构造虚拟人物

简单分析极端人物

搜集故事

故事作坊：头脑风暴（记录而不评价故事，重在数量而非质量）；简单原型（类似简单页面结构和功能的结合体），及时抛弃简单原型。

用户访谈：了解怎么使用开放式和背景无关的提问。

观察用户

问卷调查

验收测试

开发之前写测试用例：客户定义测试，开发会定义一些其他测试。测试用例编写的时机包括：讨论需要记录明确的细节时；写代码之前作为一项任务；开发过程中或之后发现新的测试时。

产品和测试共同编写详细的测试，产品带来目标，测试带来怀疑的心态

开发团队会为很多详细的用例写单元测试，客户不负责定义所有可能的测试，应该更专注于那些向开发团队说明故事意图的测试

测试类型

集成测试

交互测试

可用性测试

性能测试

压力测试

注意：测试的是缺陷，而不是覆盖率；高度合作的团队心态：不应该推卸责任，而应该是我们共同负责；理清测试重点。

故事点估算

开发和客户团队参与，以团队估算

每个开发人员估算，经过多轮估算得出估算值

三角测量：比较故事的故事点；列出所有故事的故事点，按故事点排列比较

使用故事点：史诗故事不需要与拆分后的故事点数值相同

制定发布计划

莫斯科原则MoSCoW

必须有的（基本功能）

应该有的（重要但短期内有替代解决方案的功能）

可以有的（没时间就不考虑的）

这次不会有（客户期望拥有但同时承认需要在后续发布中实现的功能）

方法

根据用户的广泛性和重要性、故事之间的关系、时间等制定优先级

制定优先级前应该先估算故事点

价值优先or风险优先

根据架构需要安排优先级

确定迭代周期时间长度

从故事点到预计工期

初始速率：历史速率or进行一轮迭代试试or猜猜猜

开发人员帮助排列优先级，提供信息，在基础性需求、架构需求与其他需求之间取得权衡

产品故事有顺序编号

制定迭代计划

讨论故事：开发人员没有必要理解故事所有的细节；客户克制，不要改变优先级

从故事中分解任务

某些任务不需要在每个版本的故事中都列出（以前的迭代中了解或全局的规范）

开发人员承担每个任务的职责

接受任务后，开发人员单独估计任务

测量并监控速率

根据已完成的故事测量速率，不急于调整，在多轮迭代有稳定速率后调整发布计划

几个图

计划速率和实际速率（故事点-迭代次数）

计划故事点和实际故事点（累计故事点-迭代次数）

迭代燃尽图（剩余故事点数-迭代次数）

每日燃尽图（剩余小时数-天）反应剩余工作量：开发人员剩余工作时间可调整，但应该在开始尽可能合理评估；可以增加新的必须的任务

用户故事不良征兆

故事太小

故事互相依赖

开发人员镀金

故事中包含太多细节

故事中太早出现用户界面

想得太远

故事划分太过频繁（故事太大，一轮迭代难以完成；故事包括高优先级和低优先级的子故事）

很难为故事排优先级（故事太大；不具有直接商业价值的用户故事）

用户故事与用户界面 （敏捷版以使用为中心的设计）

用户角色建模

捕捞高层次的用户故事

排列故事优先级

精炼高优先级和中等优先级的故事

对故事整理分组

建立书面的原型

精炼该原型

开发

客户团队

开发团队