保持产品Backlog的“深度”

FYIRH

* d2 L4 R' Z" h" T/ w- W6 C

随着第一版MMR发布后，团队对产品研发工作越来越明确。产品需具备的功能，会随时被添加到产品的Backlog里。Backlog的来源如下：

• 商业模式（精益画布）；
• 产品愿景；
• 用户画像；
• 产品路线图；
• 客户或用户的反馈；
• 团队自己发现的需求。
  : }. R) x; _9 ?6 _/ \
  

Backlog需要满足以下属性，如果用英文表述，可简写为“DEEP”。

/ q5 F8 h+ ?& p; M: x' m% D  P1 \

1.D（DetailedAppropriately）：适度详细

如图8-13所示，在Backlog里，需求的优先级越高，描述得越细致；需求的优先级越低，描述得越粗糙。优先级排在最高的需求，其描述细致到足以马上启动开发进程。

5 a0 k, Z7 ?( w

图8-13Backlog条目是适度详细的

6 ^  q/ f7 E, z9 M: G$ i3 i

2.E（Estimated）：估算好的

团队不需要对Backlog里的每个需求都做出估算，但是一定要对下一个版本以及下一个迭代的需求做出估算。估算的意义如下。

( p0 j& G) V+ v$ I, @

• 判断需求的规模。团队需要对超过一个迭代规模的需求做拆分，在拆分需求的过程中，团队可能会发现之前没有想到的需求场景。
• 做版本计划。如果团队不对需求做出估算，就无法判断版本什么时候交付。
• 做迭代计划。如果团队不对需求做出估算，就无法判断每个迭代周期装载多少新的需求。
  # H2 ]; R' L, ^
  

) ]+ F0 r" I# D! ]) L+ Y/ |0 O; ]. q

3.E（Emergent）：涌现的

; r0 K( k! |/ A2 p! Q7 N

团队不得不接受这样的现实，即需求不是一开始被写进Backlog里的时候，团队就能完全清楚的，而是随着时间的演进，通过逐渐增多的用户和市场的反馈，使团队获得更多的认知后而逐渐明晰的。此外，即使在当下被认为是明确的需求，将来也可能产生变化。在当今VUCA[时代，唯一不变的就是变化。

  \- L! v& U6 l; A+ D

4.P（Prioritized）：排好优先级的

团队在产品需求分析中要弄清楚需求的优先级；团队在版本需求分析中要分清楚MustHave需求、ShouldHave需求和CouldHave需求。但是这还不够，团队在做迭代计划的时候，需要将纳入迭代的需求排出唯一一个先后顺序，团队按照这个先后顺序认领需求开发，如图8-14所示。

2 r% j3 J; ?" c, ~1 N

图8-14需求优先级排序示意图

7 p' L! G8 v1 }9 \; u& M7 H8 D

在很多敏捷团队的Backlog里，需求优先级并没有被标识出来，而是存放在了产品负责人的脑袋里，但这并不代表需求没有优先级。当我问及团队为什么没有标识的时候，产品负责人说：“大家都知道，没必要标识。”而当我问及研发工程师的时候，对此，他们表示不清楚，只是知道这些需求需要做。

为什么需要通过显性标识让全员对需求的优先级有明确的理解呢？因为团队成员是自己认领需求后开展开发或测试工作的，如果没有清晰的优先级标识，大家只能靠口头来沟通优先级，而口头沟通无法确保每个人对信息的准确掌握。另外，对于不知道优先级信息的团队成员来说，他们一般会喜欢认领那些容易实现的需求，而这会导致真正高价值的需求被排在后面。

, H) `( q9 \; j0 f" [6 U