当我第一次听到敏捷的时候，看名知意，敏捷即快速。听闻些许公司用敏捷开发，心里曾想，莫不是用什么高效率的开发方式来开发称为敏捷开发。
众所周知，IEEE830需求(瀑布式需求)。但是用户故事与IEEEE830需求的区别是什么呢？
IEEEE830需求声明关心解决方案的特征，用户故事关心用户目标。IEEEE830需求鼓励团队在写代码之前完成所有的需求声明，而不是像用户故事那样使用迭代的方式。写需求声明需要花费很大的精力来确保文字表达了正确的意思；用户故事鼓励通过口头的交流澄清细节。
一.用户故事
1.初始化
用户故事必须要了解的一个就是用户故事卡。
由于用户故事的描述信息都是以传统的手写方式写在直至卡片上，所以Ron Jeffries对这三个方面起了一个非常好的以相同的英文字母开头的名字：
卡片（Card）：用户需求
对话（Conversion）：开发根据卡片同客户讨论用户需求的细节
确认（Confirm）：确认用户需求
2.卡片
一个优秀的用户故事卡应该保证有以下几个特征：
- 独立的：每一个故事卡是一个很小的需求，卡与卡之间（需求与需求之间）没有关系连接，保证卡是独立的
- 可以讨论的：一个卡里面的内容可以与客户进行交流，才是一个好的卡，不能交流的卡完全丧失了敏捷故事卡存在的意义
- 对用户或者客户有价值的：记住对用户有价值的东西，才能避免多做很多没有价值的事
- 可以估计的：可以估计这张卡完成的时间
- 小的：史诗级别的卡（特别大的需求卡），就如同需求文档一般，这将会变得毫无意义，丧失了敏捷开发的特点
- 可以测试的：成功通过了测试表示开发人员实现了这个故事卡。
3.对话
用户故事卡是作为对话的前提，避免了需求过于精确的假象，如果是需求文档，做的最好的无非就是完成了需求文档上面所有的精确的需求，然而，对话可以完成文档背后的需求。
4.确认
测试，用于表达和编档故事细节并且可以确定用户故事什么时候能够完成。
5.意图
故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论的，既然是一个提醒，那么就要保持它的简介性。假如需要的细节，以便联想到继续对话的切入点，但不要在故事卡上面加入太多的细节并以此取代对话。
总结：编写用户故事卡就是在一个卡上正面写上最好一句话就可以描述完成的小需求，不要写太多的细节，细节自己和客户讨论（因为卡上面写上过多的细节会让人过于关注细节而忘记讨论才是正事）；卡的背面则可以写上这个故事卡所需要的测试。
二.用户角色建模
1.初始化
在很多项目中，需求分析人员只是从一个角度写用户故事，这样往往容易疏忽一些需求故事，因为故事针对的并不是系统的一般用户。
我们将通过用户角色，角色建模，角色映射和虚拟人物，模拟出更多的用户，编写更多不同角度细节的故事，来开发更好的软件。
2.为什么需要用户角色建模
因为大部分项目小组只考虑到了单一的用户类型，这样会导致软件疏忽原本需要的一些用户的模型。
为了避免从单一用户的角度编写所有故事，要识别与软件交互的不同用户角色。通过每个用户角色定义的相关的特征，可以更加清楚地看到不同角色之间的不同点。
对于有些用户而言，用代表人物来描述会很有帮助。虚构人物是假想出来的用户角色代表。他们有名字，有照片，还有足够的相关的细节，因为对项目成员来说，很真实。
对于有些应用程序而言，极端人物可能有助于搜集原本被遗漏的故事。
总结：角色建模就是不光要考虑到最普通大众的需求，还要考虑到其他一些不同类型用户的需求。
三.搜集故事
1.初始化
如何和用户一起工作，如何通过与他们沟通来发现故事。为什么一定需要沟通：因为需求就像鱼一样，会成长，也可能会死亡。
2.用户访谈
只需问用户“你们需要什么是不够的“，因为大部分用户不太善于理解，更难以表达他们的真实需求。
仅仅因为有些问题是由用户提出的就认为只有用户才有资格提出解决方案，这种观点是不对的。
3.搜索需求
通过开放式的，与背景无关的提问更容易获得有用的答案，例如：”高速我你想怎么搜索工作“，就胜于”你要通过什么职位名称来搜索工作“。
我们可以通过用户访谈，观察用户，问卷调查和举办故事编写工作坊来发现有用的用户故事。
总结：面对用户故事卡，如何与客户交流来搜索到更有用的信息需求。
四.与客户代理合作
1.初始化
我们可能期望与不同的用户进行接触，这些用户代表来产品的不同角度，当我们无法接触到他们时，就代表我们需要求助于用户的代理（user proxy），他们自己可能不是用户，但他们在项目里面代表着用户。
2.可能的用户代理
- 用户的经理
- 开发经理
- 销售人员
- 市场营销团队
- 以前的用户
- 客户
- 领域专家
- 培训师和技术支持
- 业务分析师或者系统分析师
总结：因为不可能接触到所有的用户，只好委托一下用户代理来帮助我们更好地了解到用户的真实意图来写用户故事。
五.用户故事验收测试
1.初始化
验收测试提供了确认故事是否被完整实现的基本标准。
2.测试的两步流程
- 将测试要点记录在故事卡的背面，任何时候发现新的测试都可以记录在故事卡的背面。
- 将测试要点编程全面的侧首，这些测试可以用来演示故事已经正确，完整的实现了。
总结：验收测试就是写在用户故事卡背面的测试，在编写功能代码之前写下来的测试，当功能代码编写完毕，通过了之前写的测试，那么验收测试也算是完成了。
六.估算用户故事
1.初始化
估算这个故事卡，需要多长的时间才能够完成。
2.估算
估算的目的是知道整个项目的工作量，所以最后我们总是要将估算换成时间。
3.故事点
故事点没有特别准确的定义，完全根据团队而定。有的团队认为一个故事点为一个理想周的工作，有的团队则把一个故事点作为故事复杂度的测量。
4.正确地使用故事点
- 你的团队的故事点和我的团队的故事点事不一样的。你的团队估算的故事有三个故事点，而我的团队则估算的是5个故事点。
- 一个故事（可能是一个史诗故事）分解成一些小故事，这些小故事估算的总和不需要与开始那个史诗故事估算的故事点相同。
- 故事点好似故事复杂度，工作量或者工期的相对估算。
- 故事点应该由团队估算。
总结：估算故事点就是估计这个需求需要完成的时间。
七.发布计划
1.初始化
大部分软件以2-6个月为一个发布周期，这是最好的。
2.什么时候发布
可迭代的，由故事驱动的过程使我们很容易确定一个日期，确定在指定日期里交付哪些哪些功能却比较困难。
3.优先级
对于一个项目来说，应该先做最有风险的事，还是先做最有的价值的事？
敏捷方法旗帜鲜明地支持先做最有价值的部分。
4.迭代长度
短迭代允许项目更加频繁地作出调整，项目进度也更加透明；但是每一轮迭代会有少许额外开销。加入不确定迭代长度，请选择迭代短的而不是迭代长的，使用长迭代更加容易犯错。
5.初始速率
执行一轮迭代以获取初始速率事一个很好的方法。但很多时候，这个方法并不可行。
所以可以考虑使用历史值或者猜测。
总结：分好了需求的优先级，估计好了初始速率，计算好了迭代的长度，大概确定好了发布日期，所做的这一系列的便是发布计划。一个发布计划中可能有多轮迭代。
八.迭代计划
1.初始化
利用发布计划，我们可以将粗粒的故事分配到发布中的多轮迭代。
在开始一轮迭代之前，再做更精细的进一步的计划也非常的重要。
2.迭代计划会议
整个团队会举行一个迭代计划会议为下一轮的迭代做计划。
迭代计划会议的内容：
- 讨论故事
- 从故事中分解故事
- 开发人员成段每个任务的职责
- 讨论所有的故事，并且接受了所有的任务后，开发人员单独估计他们所承担的任务，以确保他们不会做出过于乐观的承诺。
总结：迭代会议就是分解任务，开发人员选择自己要做的任务。
总结
用户故事与敏捷方法其实就是抛弃了瀑布式的需求文档，选择了轻巧的故事卡，通过建立与用户长时间的需求交流，模拟了不同类型的用户的想法，来完成相对精确需求的代码编写，验收测试的完成也代表了故事卡的完成。
通过迭代计划以及发布计划来规划了一次发布的几轮迭代，一轮的迭代会议是对下一轮迭代的进一步的计划：故事的拆分，故事的优先级，迭代的时间速率，开发人员对故事卡的自我选择。
