第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人天，就要做拆分，或者拆分后可以分给多个开发人员进行并行开发，提高效率。
估算时使用故事点可以做到尽量客观，有一个估算标准可以参照。