第一章 概览
»什么是用户故事？
用户故事描述了对用户、系统或者软件购买者有价值的功能。核心是有价值的。
用户故事包括以下三方面：
»细节在哪里？
用户故事分大小，很大不行，史诗级的用户故事，可以进一步拆分成小故事，特别小也不行，故事细节不如大家一起讨论。用户故事不用像需求文档一样扩充。
»必须多少时间完成？
记录用户期望，然后用测试验收的方式检查，是否已经完成。测试描述可以不完整，可以简短，可以随时添加，目的是让开发人员知道什么时候是结束。
有点类似老师在练习册上留作业，告诉你做到哪里，什么时间完成。
»客户团队
指所有的关系人。开发、测试、交互、产品经理、实际用户、客户等等。解决了这些人的所有问题，基本上，软件系统的问题就解决了。
»使用用户故事的过程是怎样的?
»规划发布和迭代
发布规划应该是项目时间和预计功能集合之间的平衡。
迭代规划应该是。。。？？？
计划需要考虑成本。迭代需要考虑研发速率，结合优先级进行迭代计划的安排。
»什么是验收测试？
测试也可以捕获项目预期，提前写好测试例子，进行测试，是可以跟开发同时进行的。
»为什么要变？
用户故事将重点从文档转移到了对话。
»小结
第二章 编写故事
好故事应该是独立的、可讨论的、对客户有价值的、可测试的、小的、可估计的，六点特征。invest
»独立的
好故事应该是减少依赖的，当遇到依赖性强的故事时，可以采取以下三种方法：
1.两个依赖的故事合并成一个独立的稍微大点的故事
2.用不同的方式切割
3.可以进行估计。当a比b先做的时候，估计一个a的工作天数，当a比b先做的时候，估计一个a的工作天数。
»可讨论的
故事是可以讨论的，故事是功能的简短描述，它不是具体的需求本身，会记录一些重要的需求细节，但是不是全部的。如何恰如其分的描述需求细节很重要。
把细节加入到故事是一条原则。
但是在需求讨论阶段，考虑太多细节问题，会导致一种错觉：故事卡反映了所有问题，不需要跟客户进一步讨论了
？？？？有疑问，再细化研究吧
»对用户或者用户有价值的
用户vs客户
注意：隐含测试细节的用例要和用户故事本身分开。尽量避免用户故事中出现用户界面、技术方面的定义。
用户故事不是承诺，是。。。
»可估计的
是对开发人员说的，估计一下故事的大小。
以下是会影响估计的
1.开发人员缺少领域知识：应该参与故事的讨论，对故事有大概的了解，不用对故事的细节了解很深。
2.开发人员缺少技术知识：可以实施极限编程里面的探针实验。
3.故事太大：需要继续分解；或者可以标记成占位符，有待讨论的大功能。
»小的
史诗级故事分为两种：复合故事、复杂故事。故事的大小取决于具体的团队。
复合故事：多个小故事凑在一起。分解这类故事可以采取多种方法。比如根据动作来区分，增删改查；也可以根据数据边界进行分解。
复杂故事：一般是不可以分割的。对于一些，因为 未知性导致的复杂故事，可以多次迭代进行分解。调研类的故事可以先放第一，不跟其他故事一起进行。
对于太小的故事，需要合并。比如缺陷类故事、调整界面颜色。。。
»可测试的
对于大多数故事都是可以测试的，不能测试的一般是非功能性需求；998%可测试的都在追求自动化测试。
»小结
第三章 用户角色建模
»用户角色
»角色建模的步骤
★通过头脑风暴，创建初始的用户角色集合
★整理最初的用户角色集合
★整合角色
★提炼角色
——--------------------------------------------------------------------------------------------------
»通过头脑风暴，创建初始的用户角色集合
注意：一个用户角色是一个用户
»整理最初的用户角色集合