第3章 用户角色建模：

用户角色是一组属性的集合，这些属性刻画了一群人的特征以及这群人与系统可能的交互。

用户建模步骤：

l头脑风暴，列出初始的用户角色集合。

l整理最初的角色集合

l整合角色

l提炼角色

一个用户角色是一个用户：已确认的角色代表的是单一用户。

尽量坚持一个原则：用户角色定义的是人，而不是其他外部系统。

角色特征是关于同属这一类的用户的事实或有用信息。

虚构人物是假想的用户角色代表。创建虚构人物需要的不只是在用户角色上加一个名字，其描述应当是十分充分的。要注意，应事先做好充分的市场和目标用户群调查，要确保虚构人物能够真正代表产品的目标用户。

考虑极端人物很可能会让你编写出原本可能遗漏的故事。

第4章 搜集故事

创建故事最有用的一些方法：

l用户访谈：

选择正确的受访者，开发人员也要积极寻找问题解决方案

开放式问题和背景无关的问题

l问卷调查：不适合作为拖网捕获新故事的主要方法。

l观察

l故事编写工作坊：在较高的层次上讨论

画原型，深度优先，扔掉原型

维护一个代办事项列表

重点放在数量上而不是质量上

不要为每个故事都陷入长时间的讨论中

不要在整个过程中评价某个故事的好或坏

第6章 用户故事验收测试

测试两步流程：

1、将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面。

2、将测试要点变成全面的测试，用来演示故事已正确、完整地实现。

在写代码之前写测试

客户定义测试

测试是过程的一部分。产品经理和测试人员共同负责列出详细的测试。

客户应该更专注于那些能向开发团队说明故事意图的测试

集成测试框架FIT

测试的是缺陷而不是覆盖率

12月27日 小组分享会：

Groom需求讨论，明确需求(小而多次，可拉多个人。类似于产品内部的会，产出用户故事)->P规划会，明确需求细节->S站会->S演示会，按版本开（PO给高层做演示，展示成果）->R回顾会

R评审会，按迭代开(研发给PO演示，集体评审，“我没做错”)

Q：为什么要使用用户故事这种模式？

A:强制站在用户的角度来看待需求，有独立价值，方便快速交付。

可以立刻测试，提高效率

用户故事编写需要听取技术团队的意见

Story划分先基于经验，然后明确关键点与技术难点进行调整。Story要尽量小，满足一个sprint能够完成。

用户故事是渐进明细的。

理论上是客户写用户故事，要贴近用户

第5章与用户代理合作

尽可能接触真正的业务场景，尽可能接近真实的最终用户。要充分与实际用户进行沟通，确保真正理解用户的意图。

第7章 优秀用户故事准则

要学会“切蛋糕”，分割成贯穿应用程序所有层面的故事。

编写封闭故事，能让用户使用后觉得她完成了某个任务

不要过早涉及用户界面

有些需求用非故事的形式表达也是可以的

不必编写故事卡号

用户故事不能取代与用户的对话

第8章 估算用户故事

无论什么时候获得有关故事的新信息，都允许我们改变之前的想法?

这里面强调的核心是避免浪费。与其做出来的是废品，还不如直接就不做了。

估算故事时，一定要考虑完成这个故事需要做的所有事！

点数要合理，而不是绝对精确。

需要对估算做三角测量。将故事卡根据他们的大小贴在墙上是个三角测量的好方法。

估算方式要前后一致。

精度随故事大小增加而降低。可以使用斐波那契数列。

注意：

团队之间的估算值没有可比性。

小故事的估算值总和没必要一定等于史诗故事的估算值。

任务的估算值总和没必要一定等于所属故事的估算值。

不需要纠结什么加一起一致不一致的问题，必然不一致。还是要清晰背后的每个元素的目的，Epic估算的目的是排年度或季度计划（一般不估算）。Story估算是为了排发版和迭代计划。对于任务来说如果是Story的任务那么没必要估算。

第9-11章

排列故事优先级的方法：

1、MoSCoW规则：

必须有的

应该有的

可以有的

这次不会有

这一规则的问题是，有可能会倾向于全部为必须有的，基于这个可能会改变故事的优先级排序。

2、COD

采用一种模型，从多个维度来衡量故事优先级：价值、紧急程度、研发成本、风险等。

分解任务需要灵活掌握：如果是很简单的故事就没有必要再拆分，如果比较复杂，比如需要5人天，就要做拆分，或者拆分后可以分给多个开发人员进行并行开发，提高效率。

估算时使用故事点可以做到尽量客观，有一个估算标准可以参照。