“价值/批量”式产品待办列表

太长不读版 本文主要针对“项目型”或敏捷转型初期的团队。传统的“堆栈式”产品待办列表强调按优先级排序，且栈顶的用户故事要拆分得足够细。但这种一维的可视化方法往往让经验不足的团队忽视产品价值，并错过拆分大型用户故事的时机。而用“价值/批量”式产品待办列表能让团队能轻松地识别需要拆分的高产品价值用户故事，提前将其拆分为小批量的用户故事，从而加快开发速度、提升代码质量、优化产品价值。

传统“堆栈式”产品待办列表的弊端

产品待办列表是团队在进行迭代式开发时经常使用的一种工具，来管理在未来迭代中将要实现的用户需求。出现在“产品待办列表”中的用户需求一般以“用户故事”为单位来组织。传统的“堆栈式”产品待办列表强调按用户故事的优先级排序，越靠近栈顶的用户故事优先级越高，且拆分得要足够细，以便让团队在下一个迭代开始时从中选取要开发的用户故事。如图所示。

Scrum迭代开发

对于“项目型”或敏捷转型初期缺乏经验的团队[1]，传统“堆栈式”产品待办列表主要有2个弊端：

• 传统“堆栈式”产品待办列表中所强调的“优先级”往往不能体现“产品价值”，而经常体现交付时间的先后顺序[2]，造成优先做的故事其实产品价值并不高。比如我曾辅导的一个团队，他们在进行用户故事优先级排序时，往往把领导规定的最近一个要交付的需求当作优先级最高的故事。当我问起其价值时，他们一脸茫然：“什么是价值？”
• 传统“堆栈式”产品待办列表主要对用户故事的“优先级”进行可视化，而缺乏对故事的产品价值和批量大小的二维关系的可视化，容易导致缺乏经验的团队忘记拆分大批量故事。这让我想起Jira中的列表式产品待办列表，虽然可以上下调整一个用户故事的优先级，但是用户故事的批量的可视化却做得很糟糕。

“价值/批量”式产品待办列表的价值

“价值/批量”式产品待办列表的价值主要有3个价值：

• 容易识别下个迭代要做的故事
• 容易识别需要拆分的高价值大故事
• 容易识别价值不高的故事

实施“价值/批量”式产品待办列表的方法

实施“价值/批量”式产品待办列表的方法主要有3个步骤：

1. 准备一个“价值/批量”式产品待办列表的白板 白板可以是实体的，也可以是电子的。如下图所示。

“价值/批量”式产品待办列表

1. 团队把用户故事贴在白板上并按相应的策略对待相应象限中的故事
2. 对于第一象限“产品价值高且能在1周内上线的小故事“，下个迭代就可以将其纳入Sprint迭代内待办列表来实现。但在此之前，应该持续检查其价值是否降低，一旦降低，就在白板上将其移入第四象限来暂时搁置。
3. 对于第二象限“产品价值高且批量大的故事”，需要将大故事逐步拆小，最终能拆到能在1周内上线的小故事，并将小故事移入第一象限。这里同样要持续检查这些大故事其价值是否降低，一旦降低，就可把这个大故事移入第三象限。
4. 对于第三象限“产品价值低且批量大的故事”，要持续检查其中是否有价值高的部分，并相应地拆分出价值高的故事来移入第二或第一象限。
5. 对于第四象限“产品价值低且能在1周内上线的小故事”，一定不要被“1周内”就能上线所诱惑，要“狠下心”将其暂时搁置，先做第一象限价值更高的小故事。同样此时要持续检查其价值是否提升，一旦提升，就将其移入第一象限。
6. 产品负责人和团队要持续检查板上故事的价值和批量 可以在每个迭代中期拆分下一个迭代的用户故事的“故事会”中做此事。

注意事项

• 不要把交付时间的先后顺序当作优先级。而应该把“产品价值”当作优先级。此处的“产品价值”就是产品交付后能为用户和企业所带来的成效。
• 把故事的批量尽量拆成能在1周内上线的粒度。注意是1周内”真正能测试完成且上线“的故事，而不是仅完成开发，却把相关的测试和上线放到后续的迭代完成。其原因是当后续迭代的测试发现了先前迭代的用户故事的缺陷，要找开发人员修复时，那时开发人员正忙着开发当前迭代的故事，思路已经“不在一个频道上”，要切回“旧频道”经常要花很久才能回忆当时的上下文，极大地浪费时间。此时最好的做法是减少批量，在同一个迭代内修复本迭代的缺陷，减少时间浪费。
  • 1周内能上线（隐含的意思是半个迭代周期开发，半个周期测试，并且做desk-check），就是要促使团队把故事大小尽量拆小。另外这里的“上线”包括“半成品上线”（即亚马逊所提出的Dark Launch，将“发布”与“部署”分离），即一个迭代做不完的特性，可以使用“特性开关”或“Expand/Contract模式”来让半成品代码在不破环已有功能的情况下持续小批量上线[3]。
  • 有时候故事之间会存在依赖关系。尽管拆故事时要尽量遵循INVEST原则，但是很难保证真的独立。有时发现有依赖关系，比如一个“高价值”的小故事a，依赖一个“低价值”的中故事b，这种情况怎么做“价值/批量”的待办列表？此时可以假设这两个故事可以分别在两个迭代内完成，那么可以先在迭代n做b故事并上线，但不让用户看到界面。然后在迭代n+1做a故事并上线，然后让用户能够看到a+b故事的界面。价值应该是用户最终用到产品后产生的，所以可以把b和a两个故事作为一个价值单元放到一起贴在图上第二象限，然后先把b移动到第一象限先做。两者的价值应该是一致的，但次序不同[4]。
  • 领导一般都会一次把要完成的需求的批量搞得很大，而其中必定有一部分比其他部分的“产品价值”更高，当然前提是需要有经验的产品负责人能识别“价值”。如果团队还没有这样的产品负责人，那么可以尝试用诸如“埋点”等方式，来度量所完成的特性是否是用户想用的，来反馈给领导。这样能促使领导下次提需求时，能考虑用户价值[5]。
• 产品负责人和团队要持续检查板上的故事的价值和批量，并随时做调整。可以在每个迭代的“故事会”中做此事。
• “价值/批量”产品待办列表可以在“用户故事地图”之后使用。两者不是相互替代关系，而是有先后次序的：“用户故事地图”是发散，而“价值/批量”象限是收敛。后者能补充前者缺乏“批量”这个重要纬度的不足[6]。

总结

“堆栈式”产品待办列表容易让人忽视产品价值，并忘记拆分大故事。而“价值/批量”式产品待办列表能解决这些问题，从而加快开发速度、提升代码质量、优化产品价值（具体原因参见“怪兽电力公司的翻硬币游戏”）。

1. 感谢我的同事然桑（肖然）提出的有关本文适用读者的反馈。 ↩
2. 这个时间一般是“河马”们定下来的，“河马”的英文是Hippo，在这里指High Paid Person's Opinion，即领导们的决策。 ↩
3. 感谢我的同事然桑（肖然）提出的有关“一个迭代内做不完”的反馈。 ↩
4. 感谢我的同事毛P（毛超）提出的有关“故事依赖”的反馈。 ↩
5. 感谢我的同事魔头（杨云）提出的有关“领导规定”的反馈。 ↩
6. 感谢我的同事传湘（刘传湘）提出的有关“用户故事地图”的反馈。 ↩