第 65 个主题,共 91 个· 软件工程与数字化交付

WSJF与CD3

CD3(延迟成本除以时长)与WSJF(加权最短任务优先)是按价值密度来排定工作优先级的规则:即每消耗一单位稀缺产能,能消除多少延迟成本。在共享且固定的产能约束下,按CD3从高到低排序,在数学上正是使总延迟成本最小化的最优排序方式。

为何重要

每一份积压任务清单,本质上都是一个配给问题:众多有价值的条目,却只有一条流水线。健康经济学用成本效果排行榜解决了医疗预算领域的同一个问题:按每英镑获得的健康价值对干预措施排序,从榜首开始资助,直到预算耗尽为止。CD3正是交付产能领域中完全相同的逻辑:每单位受约束资源的效益,按排名顺序获得资助。把排序做对,等于白捡的钱——同样的工作,同样的产能,却能带来更低的总延迟成本。

计算方法

CD3  = 延迟成本(£/周) / 时长(周)      —— 使用真实货币单位(Black Swan Farming方法)

WSJF = (用户-业务价值 + 时间紧迫性 + 风险降低/机会赋能)
       / 任务规模                        —— SAFe框架的相对尺度代理指标,
                                          采用修正版斐波那契打分

使用真实货币单位(延迟成本)的CD3,在严格意义上强于WSJF那种无量纲的分数——WSJF之于CD3,正如多准则打分之于完整的成本效用分析:在无法进行货币化时可用,但在分数缺乏锚点时容易被操纵。

实例演算

三个功能,一个团队:

功能   延迟成本(£/周)   时长    CD3
A         30,000       10周     3,000
B         12,000       2周      6,000
C         5,000        1周      5,000

按CD3排序:B、C、A。与"延迟成本最大者优先"(A、B、C)的排序相比较总延迟成本:

CD3排序  (B,C,A):A等待3周,C等待2周 → 30,000×3 + 5,000×2  = £10万延迟成本
延迟成本排序 (A,B,C):B等待10周,C等待12周 → 12,000×10 + 5,000×12 = £18万

同样的功能,同样的团队——仅仅是排序方式的不同,就节省了£80,000。其直觉在于:小而紧急的条目应优先处理,因为它们能以低廉的代价释放各自的延迟成本;而大条目短暂等待所损失的价值相对较小。

与软件工程的联系

对于医疗软件的投资组合而言,应以本书所教授的单位来量化延迟成本:QALY/周 × 阈值,再加上运营层面的£/周,这样一来,积压任务清单就能与医疗系统对其所购买的其他一切事物的排序方式直接相通、可以比较。两点实践要点:(1) 时长指的是占用约束瓶颈的日历时间,而非投入的工作量——一个耗时2周、但只需要瓶颈团队投入2天的条目,实际代价比看起来要低(参见下游资源优化);(2) 医院在按紧迫程度加权的吞吐量排定手术室名单时,其实隐含地运行着同一条规则——临床优先级分类,本质上就是按严重程度加权的CD3(参见QALY缺口与严重程度调整因子)。

陷阱

  • WSJF打分表演:无量纲的斐波那契数字讨论,最终往往取决于谁的嗓门最大;至少应将积压清单最顶端的条目锚定在真实的延迟成本上。
  • 时长操纵:通过拆分条目来虚抬CD3排名——如果拆分后各部分确实能独立交付价值,这是合理的;如果不能,这就是造假。
  • 忽视紧迫性剖面:截止日期形态的延迟成本(监管日期)会打破恒定速率的假设;应先按截止日期的可行性排定这类条目,再对其余条目使用CD3。
  • 重新排序造成的震荡:CD3适用于承诺阶段的排序决策,而非对已在进行中的工作进行日常重新洗牌(关于在制品数量,参见流动指标)。

来源