1. 用例，用户故事和特性的区别
需求阶段是软件工程中的一个重要阶段，里面涉及到需求收集分析，需求管理，需求开发，系统工程，易用性和交互设计，界面，业务领域知识，非功能性需求等多方面的内容。在面向对象的需求分析中我们通常采用用例分析的方法进行，在RUP核心三要素中第一位的就是用例驱动。 在《Use Case Modeling》一书中的定义是，用例代表了系统为其用角（Actors）所做的有价值的事情。用例不是功能（functions），也不是特性（features），它们不能被分解。每个用例都有一个名字和一段简述。用例的详细描述本质上是一些叙述（stories），说明了用户如何使用系统来完成他们认为重要的事情，以及系统做了些什么来满足这些需要。 张洵对用例的定义是一种粒度刚刚好，反映了用户的真实目的（目标），并记录了为达到此目的（目标），用户与系统或多个干系者之间如何开展协作，从事了哪些动态交互行为的软件需求（表现形式）。 首先用例是描述功能性需求，而在描述过程中所涉及到的三要素就是人(Actor)和系统边界，交互和动态行为。在需求分析中我们另外强调了输入输出，而在用例中对输入输出的描述是融入在基本流和扩展流的描述中。在敏捷方法中我们一般采用用户故事卡(User Story Card)，用户故事卡对交互过程的描述可能并不会很详细，但是更加强调了用户驱动，强调了用户场景，而这也是用例偏弱的地方。我们做任何需求都必须要清楚的知道是什么样的用户和业务场景下驱动出了该需求。
2. 用户故事(User Story)相关术语介绍
工作中遇到很多同事问到用户故事的相关概念，而且基本是每新来一个同事就要解释一遍，这里做个总结，希望以后不要再做这个重复性的工作了。😹
INVEST是用户故事的书写标准，具体每个字母的含义如下：
一个用户故事对于另一个用户故事应该是尽可能独立的。为什么呢？因为传统的需求描述方式（功能模块、用例等等）由于个体较大，彼此之间依赖较多，导致输入到开发阶段时开发工程师不太容易计划他们的工作，从而导致的开发延期的现象就变成大家习以为常了。而独立性较好的故事能够独立交付，从这一点，用户故事就充分的考虑到了需求与开发的敏捷化连接问题。
那要如何才能做到用户故事之间的独立性呢？通常，可以通过组合用户故事或者分割用户故事来减少依赖性。
大家对所有之前达成的一致在新的变化发生情况下，协商后达成新的一致，从而推动系统的研发进展。
上面是比较书面的解释，我的理解是这样的：
用户故事可协商的地方，在于验收标准（AC），同样一个手机号+验证码的注册功能，我们既可以写成如下的验收标准（以下只是举例，真实的验收标准建议参照Given-When-Then的格式编写）：
如果按照这个验收标准来做，一个注册功能可能就要开发一周左右，但是早期我们为了快速进行后续的开发，可以暂时降低我们验收标准：
这样就能迅速完成注册的功能，继续后续的开发了。
这就是我理解的用户故事的“可协商的”概念。
协商去掉的这些验收标准，不是说以后都不做了，而是暂时为了完成整个MVP，就先牺牲掉了，这些细节还可以在后续的迭代里再加上。
每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。
书写用户故事的三段论：
作为（XX角色），我想（XX功能），从而（实现XX价值）
最后一句话，就是在强调价值的重要性。
开发者需要去估计一个用户故事以便对故事进行规划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
一个好的故事应该在工作量上短小，描述具有代表性，而且不超过3人天（或者3故事点）的工作量。超过这个范围的用户故事，将会在划分范围和估计时出现很多错误。
一个用户故事是可测试的并用来确认完成，记住，我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。
小结
一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立，详情应该便于开发者和用户进行沟通，应该对用户有价值，应该对于开发者来说尽可能的清晰以便进行估计，应该短小，通过预定义测试用例的使用确保它是可以测试的。
3C是收集用户故事的有效手段，具体每个C的含义如下：
用卡片（Card）来简要描述故事。
与Proct Owner（或客户）交谈（Conversation）来明确细节。
验收评审，确认（Confirmation）被正确完成。
DEEP原则是用来梳理Proct Backlog的，改概念最早在 Mike Cohn 的《Succeeding with Agile》一书中提到。
接下来的1~2个Sprint中要完成的用户故事，需要足够的详细。而不着急开发的，则不必太详细。
Proct Backlog中的需求都要是经过估算的，只不过靠后（优先级低）的PBI没有充分理解（也不必），因此其估算也不如靠前（优先级高）的PBI估算精确。
Proct Backlog不是静止的。随着了解的深入，Proct Backlog中的用户故事会增加、减少、删除、拆分或重新排优先级。
Proct Backlog应该根据由上至下按照条目的价值从高到低排序。团队应根据优先级进行开发，从而使正在开发的产品或系统价值实现最大化。
规模化敏捷框架 SAFe (Scaled Agile Framework)提出了一种定量计算法来评估需求的优先级，称为WSJF(Weighted Shortest Job First: 加权最短作业优先)。
计算公式如下：
其中分母的工作规模部分大家比较熟悉，即估算的需求规模(故事点方法、理想时间方法等)。
分母部分的延期成本包括三个因子：
指的是对客户或商业的相对价值，比如：
用户更喜欢哪个?
对盈收有什么影响?
不做会产生什么潜在的负面影响?
指的是给用户的商业价值随着时间的推进如何变化。比如：
是否是固定交付日期类型的需求?
用户是否会愿意等待，还是会选择其他产品?
在某个时间窗口不上线的话，是否会影响用户的满意度?
指的是除了上面的第1个和第2因子需要考虑因素之外，这个需求还能为业务带来哪些价值, 比如：
是否降低产品以后交付某些必要特性的风险?
是否会学到我们不知道的知识或信息?
是否会带来新的商业机会?
这样拆解后，WSJF的公式细化为：
如何操作呢?将所有特性列成表，如下：
对这个表中WSJF公式中的每个因子，采用与用户故事的故事点相对估算类似的方法做估算。比如，对于工作规模这一项，选择一个工作规模最小的特性作为基准，它的工作规模设为1（ 注意：WSJF公式中的每一项，都要选中一个特性作为相对估点的1 ），其他特性的工作规模与之相对比, 采用 近似斐波那契数列 1, 2,3, 5, 8,13, 20…为单位。如果特性A是基准特性的3倍，那么特性A的工作规模就是3。
为WSJF公式分子的其他因子做同样的相对估算法，即找到一个因子最小的基准特性，然后其他特性与之相比较，从而得到相应因子的估算数值。
就每一个特性，将WSJF的每个因子做相对估算后，就可以计算出每个特性的WSJF，这样你就得到了量化的需求排序。
常见疑惑：WSJF适用于所有需求的排序吗?
不是的。在 SAFe 里，WSJF可以适用于大粒度的Epic和Feature级需求，不适用于小颗粒的用户故事级需求，原因是用户故事通常很小，分母的几个因子不容易对比出差异。此外这种定量计算法在团队里应用过于沉重，因为需要对每个需求估算四个因子，不止是需求规模这一个因子，所有估算的耗时翻了四倍。
MoSCoW法则是用来排定用户故事优先级顺序的一种定性方法。
具体这个缩写的含义是什么，具体怎么用，可以参考这篇文章： 如何利用MoSCoW法则排定Sprint Backlog的优先级
SMART是用来将用户故事拆分为任务时的指导原则。
任务必须是具体的。
任务必须是可以衡量的。
任务必须是可以达成的。
任务与最终目标是要相关的。
任务必须具有明确的截止期限。
3. 用户故事与敏捷方法
故事的好处
软件开发是渐进明细的过程，充满挑战。软件需求是被识别为最常见的痛苦根源。如何定义需求，冗长的文档已经不被阅读者接受，简单、精准、一目了然的格式一致的用户故事越来越被接受。当掌握刚刚足够的信息就继续前行，按需及时开展，通过交谈获取所需要的细节。从用户角度出发描述功能，让我们站在最终用户立场考虑问题，避免开发者自行其是。
方便沟通和传递，只有一句话或者简短描述就能知道用户诉求，比任何长篇大论漂亮的需求文档好太多。更多的细节在交谈中获取，强调频繁的沟通和反馈。
用户故事的组成
用户故事描述了对用户，系统或者软件购买方有价值的功能。一般由以下三个方面组成：
1，一份书面的故事描述，用来做计划和提示
2，有关故事的对话，用于具体话的故事细节
3，测试场景或者举例，用于表达故事细节且可用于确定故事何时完成。
一般故事写在卡片上，正面描述，反面是验收测试场景，另外可以在空白处加上优先级，以及谈话中讨论的细节提醒。
如果一个故事太大（史诗故事Epic)，那么需要再细分为更小的故事，直到每一个故事能覆盖到每一个细节，每一个细节之间都不能有重复，避免冲突和减少依赖。
使用故事的过程
过去是瀑布，强调文档编写完再设计，所有细节设计完成后进入开发，开发完成后进入测试。如果使用故事则玩不通，因为故事强调沟通，最需要的是客户和用户在项目中全程参与，需要在项目中随时可以找到可沟通的人，得到正确和真实的反馈。
让用户编写故事
软件客户和用户应该在编写用户故事时承担活跃的角色，客户参与写用户故事有两个好处，首先那个故事必须使用业务语言写，而不是使用技术语言，这样团队可以排列故事优先级；其次作为产品的构想者和使用者，用户和客户应该最清楚和适合描述产品的行为！
优秀的用户故事准则
目标故事：了解使用软件的目的，通过目标衍生故事。例如找工作是一个目标，那么可以拆分为搜索工作，编写简历，投递简历，申请工作等……
切蛋糕方法：面临一个大的故事，采用纵向切蛋糕的方法拆分更小的故事，每个故事都提供某种完整的end to end（闭环） 的功能。例如“求职者可以发布简历”这个故事拆分“求职者可以提交简历，简历包括名字，地址和教育背景这样的基本信息；求职者可以提交简历，简历包括雇主想看到的所有信息。
在编写故事时，更倾向编写一整块完整蛋糕那样功能完整的故事。
编写封闭的故事
一个封闭的故事是指随着一个有意义的目标的实现而结束的故事，让用户觉得使用后能完成某个任务。而不是开放性，比如管理简历就是个开放性的故事；而保存简历，删除简历，更改简历的信息，就是封闭式的故事。好处在于每个故事都是一个闭环，用户会有一定程度成就感。
卡片约束
任何必须遵守而不需要直接实现的故事，设定为约束。如“系统必须要支持最大50个并发用户的峰值”。约束卡片不需要估算，也不会被安排到迭代中，可以作为其他可能关联故事实现时候的提醒。
不要过早的涉及用户界面
项目早期应该对系统设计还没有一个深入设计，很多需求都只是一个构想，如果过早的设计用户界面，那么会将用户界面细节陷入故事。软件设计是个渐进明细的过程，请不要违背这个过程。例如，如果项目刚开始就设计一个“用户可以在搜索界面上从日期部件上选择日期”，那么其实对于开发人员来说是比较困难去开发的，因为在早期软件可能还没有设计搜索和日期相关的功能，尽量不要因为过早设计页面左右了真实需求。 软件只有在越来越完整的时候，并且从全新的功能转向修改或扩展现有功能的时候。
在故事中包括用户角色
如果项目已经识别了角色，那么请在故事中使用已经识别的角色。这样可以让用户在开发人员脑子里保持着最重要的位置。例如不要写“用户可以发布简历”，应该描述为“求职者可以发布简历”。这样开发者会联想到实际的，真切的用户，开发出满足用户需求的软件。
只为一个用户编写
当故事只为单一用户编写时，故事的可读性通常是最强的。如“求职者可以删除简历”，应该描述成“求职者可以删除他自己的简历”。从单个用户角度思考问题，会让故事更清晰。
故事发布计划
Must have 必须有(基本功能)
Should have 应该有(很重要但是短期内有可替代解决方法的功能)如果项目时间没有约束，应该有的功能应该是强制性的
Could have 可以有(如果没时间，可以在发布中不考虑的功能)
Won’t have this time 这次不会有(客户期望有，但是承认需要在后续发布中实现的功能)
排列优先级
用户对故事进行优先级排序，一般会从广泛性和重要性开来判断。
如果用户的优先级和开发人员实现的顺序不一样时，应该客户说了算。在确定优先级时，应该先对故事进行估算，这样用户可能重新调整优先级，根据估算大小，评估发布顺序让价值最大化。
迭代计划
讲解故事，澄清问题，优先级排序，任务拆分，任务认领，评估任务是否能完成。
拆分任务
1 实现故事的开发人员一般不是一个人
2 故事拆分为开发人员的待办事项(to do list)时团队透明，团队集体智慧有助于不容易遗忘
3 拆分任务的同时也是一个即时设计短脉冲的过程，这个过程类似瀑布过程的前期设计阶段
4 团队成员自愿认领和执行任务
5 团队围绕共同目标执行迭代，在迭代后期如果有人任务无法完成，团队其他人应用于承担，避免有人任务完成，还有人的任务列表还有待处理的情况。。
用户故事的优势
强调口头沟通，人人都可以理解用户故事，用户故事大小适合做计划和迭代开发。
用户故事鼓励延迟细节，并根据沟通适应随机应变。鼓励参与性设计和传播阴性知识。此部分难以理解，目前我们仍然使用prd记录和描述用户需求，尽可能记录清楚用户诉求自己可能场景和用例。此处和书上描述避免使用过详细的记录相悖论。我们因为部门墙的存在，用户可能没办法和研发团队频繁交流，且反馈环拉的很长。我们产品经理就处于与用户沟通和设计产品的角色，所以大家还是希望产品能将沟通记录和结果记录清晰。
用户故事促使我们重视口头交流，提供迅速的反馈周期，促使对需求的理解。用户故事范围比用户用例(IEEE830 定义的软件需求包括用户用例和场景)场景
4. 我们常说的用户故事是什么
1，用户故事的概念
概念这种东西我喜欢说文解字的方式去理解和阐述。用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户和用户需求的简短描述。
2，用户故事的三要素
用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。
一个完整的用户故事包含三个要素：
（1）角色（who）：谁要使用这个
（2）活动（what）：要完成什么活动
（3）价值（value）：为什么要这么做，这么做能带来什么价值
3，3C原则
用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
卡片的正面书写故事的描述，格式为：作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。
（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确保各方对故事的理解正确。
（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。
4，INVEST原则
好的用户故事除了格式规范，要素完整外，还应该遵循INVEST原则：Idependent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimatable（可评估）；Small（小的）；Testable（可测试的）。
（1）Idependent（独立的）
要尽可能的让一个用户故事独立于其他的用户故事。用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。
（2）Negotiable（可协商的）
一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。
（3）Valuable（有价值的）
每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。
（4）Estimatable（可评估）
计划会议里面一个很重要的环节，那就是故事点的估计。实际上就是对要开发的User Story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量），重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事。让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）
（5）Small（小的）
一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
（6）Testable（可测试的）
一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
5，三个准则
用户故事在遵循了INVEST原则后，基本就是一个好的用户故事了。再重点分析三个准则，帮助在产出用户故事时更好地符合原则。三个准则是：一个用户、完整价值、不依赖
（1）一个用户
只包含一个用户，因为多个用户常常有细微的差别。一般是典型的用户，常常有共同的某类需求。
（2）完整价值
完整地交付一个客户价值。一个完整的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标。
（3）不依赖
依赖性的三种常见类型是：重叠、顺序和包含。总体上来说，故事之间功能点相互重叠是需要避免的；顺序关系是现实存在，在多数情况下可以通过一些手段解决；包含关系对复杂系统是有帮助的，对排定发布和迭代计划的影响需要注意。
1.重叠依赖
重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。
解决方式：
将重叠部分单独剥离出来做为独立的用户故事
合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中
使用Scrum开发模式
2.顺序依赖
顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。顺序依赖通常是无害的，而且有一些方式可以减轻这种依赖。从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的。但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。
解决方式：
一个迭代内的用户故事尽量做到没有内在依赖。
保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前面迭代故事的单向依赖（前向依赖）。
剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。
3.包含依赖
包含依赖是指在组织用户故事时使用有层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。
解决方式：
用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划
特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去
遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。