需求的优先级，在每个迭代前都要根据产品的现状，做个重新的排序。在这篇文章前，我先说下我们公司关于需求的几个定义：
上图是SAFe中关于需求大小的一些定义，我们公司还不是很大，所以目前还没有采用第三层的Capability，对需求的层级只做了Epic-Feature-Story三层划分。
《用户故事地图》一书也是按照三层结构，对需求做了Backbone-Feature-Story的划分。
这三层的划分怎么理解呢？我举个大家都比较熟悉的例子说明下吧：
比如我们要开发一个电商网站，电商网站一般都包含：
- 账号系统
- 商品系统
- 订单系统
- 会员系统
- 库存系统
- ……
这一级的需求，我们一般称作Epic/Backbone。
账号系统下面又会包含以下几个模块：
- 注册
- 登录
- 找回密码
- 详细资料
- ……
这一层级的需求，我们公司一般称作Feature。
详细资料下面又会包含以下几个功能：
- 完善基本资料
- 修改基本资料
- 绑定邮箱/手机号
- 设置密保问题
- ……
这一层级的功能，也就是可以直接拿来开发的需求，我们称作Story。
我在本文一开始说的：
需求的优先级，在每个迭代前都要根据产品的现状，做个重新的排序。
这个排序，主要针对的是Feature层面的排序，不是对Story或Epic的排序，因为Story粒度太细，Epic粒度又太粗了。
下面介绍具体的排序方法：
决定需求的优先级顺序有两种方法：定性评估法和定量计算法。定性评估法是通过评估影响需求排序的几个要素，为需求排出先后顺序;定量计算法是为影响排序的每个要素赋予一个数值，然后用公式计算出需求的唯一顺序。
3.1. 定性评估法
决定需求的优先级顺序有以下几个要素要考虑：
3.1.1. 延期成本
延期成本是当工作或里程碑延期交付所产生的财务成本。延期成本将价值和延期交付的时间合并起来。延期成本可能是创造的价值，也可能是经济损失。
若想知道一个产品、一个特性的延期成本，只需要问一个问题：“如果我们晚交付一个月的话，会给我们造成什么损失?”或者正向问法：”如果我们提前交付一个月的话，会给我们带来什么价值?“
上篇文章还在为产品优先级决策犯愁吗：教你服务级别分析方法介绍了延期成本，以及如何从延期成本的角度区分需求的服务级别。本文不再赘述。为需求排序，延期成本是首要考虑的因素。当延期成本无法区分出先后顺序的时候，比如：在很多时候，你会发现很多需求互相对比，它们的价值相当，时间上没有一定非要什么时候上线的期望，这时候，可以考虑下面的几个要素。
3.1.2. 实现成本
对于同等价值和时间要求的需求，团队通常会选择成本低、交付速度快的需求。因为越早完成，越早产生价值，并及早获得用户反馈，增加我们对用户的认知。
3.1.3. 风险和不确定性
风险和不确定是两个相互伴随的两个兄弟，但却是两个不同因素：不确定性可能蕴藏着风险，并不一定会带来风险，但是风险一定是带有不确定性。
如果需求具有不确定性，比如：在一定条件下这个需求会引爆市场，但是这个条件何时到来还不知道，那么一般采取的方法是推迟决策，同时密切跟踪市场动向。早做了也是浪费，晚做了就白做。
如果需求的实现有风险，比如：需求需要对已有代码模块的实现逻辑甚至架构有重大冲击，尽管这个需求价值很高， 团队往往会会喜欢推迟到以后再做，其实这是逃避风险的自然反应。现在不做，会继续堆积现有实现逻辑的代码，以后再做这个需求带来的冲击会更大。因此，对于这种有风险的需求，如果决定必须做，就要早做，直面风险。
3.1.4. 依赖
也许你知道用户故事的INVEST原则，INVEST其中的I(Independent)就是指的独立性，即：拆分用户故事尽量要避免相互依赖。但是依赖是不可能完全避免的。可以通过合并两个依赖的故事，或者重新拆分来避免依赖。但是即便这样，也无法完全避免依赖。
如果最后还是发生了故事A依赖于故事B，那么最好A和B错开一个迭代来实现，至少错开一周。尤其对于依赖的用户故事由其他团队交付的情况，进度不受自己团队控制，更需要错开节奏。如下图：
对每个需求就这4个要素都分析后，就可以排出优先级顺序。
3.2. 定量计算法
规模化敏捷框架SAFe(Scaled Agile Framework)提出了一种定量计算法来评估需求的优先级，称为WSJF(Weighted Shortest Job First: 加权最短作业优先)。
计算公式如下：
其中分母的工作规模部分大家比较熟悉，即估算的需求规模(故事点方法、理想时间方法等)。
分母部分的延期成本包括三个因子：
3.2.1. User and Business Value(用户和商业价值)
指的是对客户或商业的相对价值，比如：
用户更喜欢哪个?
对盈收有什么影响?
不做会产生什么潜在的负面影响?
3.2.2. Time Criticality(时间关键性)
指的是给用户的商业价值随着时间的推进如何变化。比如：
是否是固定交付日期类型的需求?
用户是否会愿意等待，还是会选择其他产品?
在某个时间窗口不上线的话，是否会影响用户的满意度?
3.2.3. Risk Reduction& Opportunity Enablement(减少风险或帮助获取新机会)
指的是除了上面的第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级需求，不适用于小颗粒的用户故事级需求，原因是用户故事通常很小，分母的几个因子不容易对比出差异。此外这种定量计算法在团队里应用过于沉重，因为需要对每个需求估算四个因子，不止是需求规模这一个因子，所有估算的耗时翻了四倍。
3.3. 操作提示
优先级是相对的，不是绝对的。只有将两个需求放在一起，你才能判断出哪个优先做，哪个靠后做。单独地说某个需求优先级高是没有意义的。
公式看着很诱人，貌似更科学，但是不要迷信。量化计算法评估出的优先级也只是参考。需求的排序不是完全用数学公式可以计算的，而是个理性评估加艺术直觉的快速决策过程。团队的交付节奏越密集、交付速度越快，花在排序上的时间就可以越少，因为即使排得不合理，或者不确定，下次发布马上就可以发布你排在后面的需求。
常见疑问：需要对整个Backlog排出唯一的先后顺序吗?
通过以上介绍的方法，足以对哪些需求排在整个Backlog的顶部做出区分。然后，对于排在Backlog顶部的当前版本的需求，以及最近一、两个迭代的需求排出唯一先后顺序，对于以后版本以及一、两个迭代以后的需求，不需要排出唯一的先后顺序，也没有足够的认知来排出。随着持续地发布产品，我们通过用户的反馈对需求的优先级认识会有变化。因此，过早排序也是一种浪费。
当然，比决定优先级更重要的是决定做与不做。
后记：关于SAFe和WSJF的截图，使用的都是SAFe官方培训的PPT文档，我暂时还不知道这些PPT可不可以随便分享，如有需要，可以留邮箱我单独发给你。
