如果你只能量化一件事，那就量化延迟成本吧。
—— Don Reinersten
Weighted Shortest Job First
Weighted Shortest Job First (WSJF) 是一个用于对工作（如Features, Capabilities, Epics）进行优先级排序，以使经济效益最大化的模型。在SAFe中，WSJF的估算方式是用延迟成本(Cost of Delay, CoD) 除以工作规模。
在基于流的系统中，持续更新优先级能提供最大化的经济效益。在这样基于流的环境下，提供最佳结果的是对工作的排序，而不是理论上单项工作的投资回报率。
为此，SAFe提供了WSJF方法，通过计算相对的延迟成本(CoD) 和工作规模（指代工期）来为Backlog进行优先级排序。Backlog的优先级根据相对的用户和业务价值，时间因素，风险降低和机会获取，以及相对规模来进行持续更新。WSJF还方便的自动忽略了沉没成本，这是精益经济学的一个基本原则。
WSJF详解
Reinertsen 阐述了一个复杂的模型，叫做WSJF，以基于精益产品开发的经济学原理来为Job进行优先级排序[2]。WSJF的计算方式，是将延迟成本(CoD) 除以工期(Duration)。CoD是指在一段时间内延迟或不做某项工作，所造成的经济损失。例如，一个潜在的功能每月预期能够产生十万美元的价值，那么如果延迟三个月，总的延迟成本就是三十万美元。
在最短的时间内提供最大价值（或CoD）的工作，能够带来最佳的经济回报。如同在SAFe中所运用的，WSJF模型还支持产品开发流程的一些其他原则，包括：
- 采取经济视角
- 忽略沉没成本
- 持续进行财务选择
- 使用决策规则来进行去中心化决策
- 如果你只能量化一件事，那就量化延迟成本吧
图1展示了正确运用Reinersten的WSJF模型带来的影响。蓝色阴影部分展示了每个情况下的总延迟成本。采用WSJF带来了最佳的经济效益，且影响系数非常之大。
（注：如图1所示，Reinertsen[2]采用了实际货币价值作为延迟成本及估算工期，而SAFe中则采用修改后的斐波那契数列进行相对估算，本文稍后将进行介绍。）
图片
图1 应用WSJF算法提供了最佳的整体经济效益
估算延时成本
在SAFe中，“工作(Jobs)”是指存在于各个Backlog中的Features, Capabilities, 和Epics。然而，确定还未实施的工作的延迟成本可能较有挑战，SAFe采用了一个CoD替代指标，估算与Backlog中其他工作的相对规模。CoD主要由以下三个部分组成：
- 用户业务价值 —— 对于客户或业务的相对价值是多少？我们的用户是否更偏好这个功能？对于业务收入有什么影响？如果延迟会有怎样的潜在负面影响？
- 时间紧迫性 —— 用户/业务价值如何随时间衰减？是否有固定的截止期限？用户会等待我们还是转向其他解决方案？关键路径上是否有受此影响的里程碑？对当前用户满意度有怎样的影响？
- 降低风险/获取机会的价值 —— 这对于我们的业务还有哪些好处？是否会降低此次或未来交付的风险？我们将收到的信息是否有价值？这个功能是否会促成其他的业务机会？
团队使用和“估算扑克”中相同的修改过的斐波那契数列来对Backlog item做相对估算，于是（相对的）延迟成本CoD的计算公式如下：
图2 计算相对延迟成本
估算工作时长
公式中的下一个元素，即WSJF中的分母，是工作持续时间。这也很难确定，特别是在早期，还没有决定由谁来做，或有多少产能可分配时。幸运的是，工作规模是一个很好的可以代替工作时长的元素。（如果我是唯一的修剪草坪的人，前院的大小是后院的三倍，那么修剪前院就需要花费三倍的时间。）使用工作规模，我们有一个直观的计算方式，来通过WSJF比较工作，如图3所示。
图3 相对WSJF的计算公式
于是我们就可以用一个简单的表格来对工作（在这个例子中是三个Feature）进行比较，如图4。
图4 用于计算WSJF的表格
和故事估算类似，采用修改后的斐波那契数列来进行估算，是由于它能更好的反映出随着规模增大时，估算范围的不确定性。采用图4中的表格进行计算时，团队要针对CoD中的三个因素以及工作时长，分别将每个Feature与其他Feature进行相对估算。每次针对其中一列，将最小的那一项设置为基准值“1”，再将其他项与它进行相对估算。最后再将CoD除以工作规模，得出的WSJF值最大的那项工作，就是接下来要做的最重要的工作项。
这个模型鼓励将大件的工作拆分成多个较小的工作项，来与其他的小规模工作竞争。否则，重要的大工作可能永远无法完成。但这只是敏捷的工作。由于实施是增量式的，当一项持续的工作在竞争中排名不理想时，就会被其他选择出的工作所替代。
SAFe的WSJF模型还有另一个优势，那就是团队并不需要确切的知道CoD各组成部分的绝对价值，而是将Backlog中的工作项针对各因素进行相互对比。最后，由于更新的估算仅包含剩余工作的规模，频繁的重新调整优先级意味着系统将自动忽略沉没成本。
使用工作规模代替工作时长
虽然我们使用工作规模来代替工作时长，但规模并不总是一个好的替代。考虑以下两个场景：
如果具备专业技能使一项规模更大且价值更高的工作能够在更短的时间内完成，则它可以被选择，因为能在更短的时间内提供更大的价值。（如果有三个人能来修剪我的前院大草坪，而我自己修剪后院，则这些工作所花费的时间相当，产生的价值却不同。）
一项小工作也许需要稀缺资源，或对其他工作有依赖，也可能比其他大工作花费更多的时间。
这种情况下，可以对优先级的结果做相应调整。但我们很少需要担心这两种例外场景，大多数情况下，快速的WSJF相对估算是足够的。由于在基于流的系统中，选择中的小错误并不致命，因为下一个重要工作很快就会上升到Backlog的顶端。
使用工作成本代替Epic时长
当工作成本的估算结果已知时，它也许比工作规模的估算结果更适合作为WSJF的分母。这些成本通常在投资组合看板的后期，当精益可行性分析完成后才得知。当要选择实施这些较大规模的工作时，则需要采用工作成本的估算结果作为代替，或更理想的是采用工作时长的估算结果，来进行更加精化的WSJF计算。
当工作成本的估算结果作为WSJF的分母时，可以通过将Epic的成本标准化来简化公式计算。具体做法是，给估算出的最小成本Epic一个基数“1.0”，然后将后续Epic的成本除以这个最小的成本估算值（如1.5/0.5=3.0），如图5所示。
图5 采用标准化成本作为WSJF的分母
（注：如果你能对CoD进行很好的货币估算，则用它作为所有被进行优先级排序的Epic的分母；同样的，如果你能得到很好的工作时长估算，就用它来取代替代变量。）
扩展阅读
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
原文地址：wsjf
关于译者
Scrum中文网翻译组
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。
Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
