第一章 概论
用户故事与敏捷方法 Mike Cohn
用户故事：3C（Card卡片、Conversation交流、Confirmation确认）
#Card：描述用户故事只记录对用户有价值的功能，与用户无关或者用户不关心的功能不需要写上去
故事很大的时候称为史诗故事（如：“求职者可以在网站上搜索工作”），可以将史诗故事分成更多的小故事，当有一个故事可以覆盖到每一个细节的时候我们可以停止分解，具体细节问题可以交由开发团队和用户进行讨论。
如：“用户可以查看搜索结果中每个工作的信息”这个故事就没有必要继续分解成“用户可以查看工作描述”、“用户可以查看薪水范围”、“用户可以查看工作地点”
在纸质卡片记录用户故事时，可以在卡片背面记录用户的期望用于作为测试故事的提示，测试描述的灵活度应该很高，用于传递用户故事的额外信息，便于开发人员理解用户的期望，当这些期望都被实现的时候，当前用户故事算是完成了

个人理解：相较于传统开发项目的流程，使用用户故事加大了用户在开发过程中的参与程度

组建客户团队来编写用户故事并确定故事优先级：客户团队应该由确保软件满足用户需求的所有人。包括测试人员、产品经理、实际用户、交互设计师

在用户故事编写会上编写完用户故事集合以后，客户团队和开发人员确定迭代长度（个人理解为一个周期，一周---四周的时间，完整的项目开发需要多个周期），每一轮迭***人员可以做多少事情称为速率。
对于用户故事集合，会将其分为很多堆，每一堆（一定数量的用户故事）代表一轮迭代，在正式开始进行开发以后，根据团队的实际开发速率对每一堆用户故事的数量进行调整，比如，当前一堆的开发难度较低，提前完成开发任务，可以将下一轮迭代的用户故事提到当前迭代，反之亦然。

发布规划：指确定项目时间表和预期功能集合之间达到平衡（项目进度推进与项目完成度应该相匹配）。
#确定故事优先级：在确定故事优先级的时候需要考虑（大部分用户客户对特定特性的渴望程度、小部分重要用户客户对特定特性的渴望程度、故事之间的关系）当客户团队与开发人员出现优先级确定矛盾时，最终应该以客户组织利益最大化的原则。同时在排列故事优先级时应考虑故事成本，故事的故事成本由开发人员给出，用故事点来进行描述。
迭代规划：涉及选择迭代包含的故事（每一个迭代应该实现的具体功能）
#确定故事优先级以后，开始为开发计划中的迭代分配故事，首先由开发人员给出一个预计速率，然后客户团队把故事分配到迭代中，每个迭代的故事点不能超过事先预期的速率。同时在迭代分配故事的过程中，可以在迭代临时跳过一个大故事，放入一个小故事以满足迭代中的故事点不会超过预期速率；除了该方法以外还可以将大故事分解为两个小故事。

验收测试：用来验证实现的用户故事是否符合团队的期望。

相比较于需求文档和用例，用户故事的优势有哪些：
#用户故事强调人与人的交流而不是书面形式的沟通
#用户故事可以同时被你和开发人员理解
#用户故事的大小适合做计划
#用户故事有利于进行迭***
#用户故事鼓励推迟考虑细节，直到你非常清楚的了解自己的需求

推迟细节很重要，对于一些最终需要但是当前并不重要的特性，可以先写下一个史诗故事占位，然后进行提炼，逐渐抛弃史诗故事用更小的更具体的故事替代它

问题：
1.用户故事包含哪三部分？
#3C：Card、Conversation、Confirmation
2.客户团队由哪些人组成？
#客户团队由产品经理、实际用户、测试人员以及交互设计师组成（为何没有开发人员）
3.以下哪些不是好的用户故事？为什么？
a.用户可以在 Windows XP 和 Linux 上运行系统
b.所有绘图和图表将用第三方类库完成
c.用户可以最多撤销50步操作
d.软件将于6月30日发布
e.软件将使用Java编写
f.用户可以从下拉列表框里选择她的国籍
g.系统将使用Log4J把所有错误信息记录到一个文件中
h.如果用户15分钟内没有保存文档，系统将提示用户进行保存
i.用户可以选择“导出到XML”特性
j.用户可以导出数据到XML文件
#判断一个用户故事的好坏，卡片只记录对用户有价值的功能，所以我认为b、d、e、g是不好的用户故事
4.需求对话相较于需求文档有哪些优势？
#需求对话可以不断的明确具体需求
（使用文档意味着需求是精确的，但这是文档无法保证的。用户故事用卡片来作为对话的提醒，避免了需求非常精确的假象。把东西记录下来并不能保证用户得到他们真正想要的，充其量也只是得到了记录下来的那些东西。频繁的沟通，特别是开发过程中讨论功能，可以让开发人员和客户之间加强相互的理解）
5.为何在故事卡的背面写测试描述？
#便于开发人员理解用户期望，当用户期望都被满足时，当前用户故事算是完成了
（在卡片背面写测试描述对于客户是沟通故事的期望和假设的非常好的方法）