需求排序还在拍脑袋?WSJF来帮你

在SAFe的敏捷发布火车的工作优先级梳理中使用了WSJF的方法,这篇短文希望能把这种“加权最短优先”(Weighted Shortest Job First,自己翻译的,不知道有没有表达到位)的方法做一个介绍。不限制在SAFe的框架中,所有在推动持续交付的软件开发中都能应用作为优先级的指导原则。

需求排序还在拍脑袋?WSJF来帮你_第1张图片
需求怎么排序?

调度算法问题,在IT相关的各个领域都是核心问题的;在软件开发的需求管理领域,哪些工作需要先做,哪些工作要排在后面,这同样一直是个让大家感到很有争议的话题。如果只是简单地说重要的工作要先做,虽然这个原则大家很容易达到一致,但这个非常的没有可操作性,遇到具体的案例时就很容易出现没有办法判断的情况。所以我们不仅要有指导的原则,更需要有一个可以量化的方式,使我们能更容易对顺序排列的结果达成一致。

Weighted Shortest Job First

在计算机操作系统领域,有一个“最短作业优先”(Shortest Job First)的调度算法,让执行最短的任务先被调度到,加快作业的疏散速度,这可以极大的缓解紧张的内存资源,提高计算性能。WSJF就是在这个原理上的扩展。

WSJF的算法只需要两个参数:这个任务的权重(重要性)这个任务持续的时长

WSJF分数=任务权重 / 任务时长

把任务权重除以任务需要持续的时长,结果就是WSJF的分数,分数越大,则这个任务就越需要放在前面,反之放在后面。

估算任务时长

相对来说这两个参数中,任务的持续时长是比较好估算的,这个时长往往代表的任务的复杂程度(不考虑和其他任务的依赖),对于估算方法可以参考我以前的文章守破离的轮回-敏捷估算。

估算任务权重

重点是怎么估算任务的权重,也就是任务的重要性。

用Cost of Delay来描述任务的权重

给出一个任务的权重是一个复杂且有争议的课题,但在产品开发领域,知名专家Don Reinertsen 给出了一个衡量方式:

if you only quantify one thing, quantify the Cost of Delay.

不同的人,从不同的角度,对同一件事情会得出不同的重要程度理解,这里我们推荐使用Cost of Delay, 即“延期成本“来代表任务的权重。

在英文中称为Cost of Delay Divided by Duration,简称CD3

Cost of delay又该怎么确定

一般我们认为延期成本由3个因素组成:

  1. 基于用户的商业价值
  • 我们的用户是不是真的非常想要这个?这个对我们业务的收入有什么影响?如果延误我们会收到什么样的惩罚和其他影响?
  1. 时机关键性
  • 这个有确定的deadline吗?用户会为此等待我们还是会转移到其他的解决方案上去?有其他关键里程碑会被我们的延期影响吗?
  1. 降低风险/增加机会的可能性
  • 这个能帮助我们降低未来发布的风险吗?它能帮助我们开启新业务领域的机会吗?

不管怎么样,我们的组织如果处在持续交付的状态,并且我们的需求池列表中有足够多的任务供选择,所以我们不需要纠结于每一个参数的精确值是否正确,我们只需要使用相对值的方式比较不同的任务,就像使用估算扑克那样。

Cost of Delay = 商业价值 + 时机关键性 + 减低风险或增加机会的可能性

WSJF效果图例

基于Cost of delay的WSJF算法本质上就是让延期成本高,花费时间短的任务先被调度,从而降低整个系统的延期成本,下图是一个基于A、B、C三个任务的示例图,上半部分是一个正面的列子,下半部分是一个反面的例子。

需求排序还在拍脑袋?WSJF来帮你_第2张图片
从经济的角度理解WSJF的意义的示例

我的理解

虽然WSJF提供了一套来确定需求列队顺序的算法,但是在实际工作中我们不需要关注是不是每个任务都能算出一个确定的值,进而进行排序。更重要的是我们需要理解这套算法背后的原理,并且当遇到争论和解释不清的时候可以利用这个算法帮助我们梳理自己的思路,尽快让大家找到共识。

你可能感兴趣的:(需求排序还在拍脑袋?WSJF来帮你)