Scrum Patterns: 梳理产品待办列表 (译)

关注

发布于: 2021 年 02 月 14 日

Bruce 有话说

Scrum Guide 中提到 Scrum 有 5 个 Event，他们分别是：Sprint Planning Meeting，Daily Meeting，Review Meeting， Retrospective Meeting 和 Sprint 本身。而梳理会(Refinement Meeting)并不是作为一个独立的事件在 Guide 中被提到。不过笔者一致认为，要让 Scrum 运行好梳理会是一个关键因素。那么为什么它如此重要呢？它主要是解决什么问题呢？今天我翻译的这篇文章，就是介绍梳理会的作用和如何进行它更有效。本文会涉及到的几个关键点总结如下：

为什么要延迟决策，而不是提前计划？
持续梳理 PBI 优先级的原因？
介绍一个简单工具来给带有依赖关系的 PBIs 排序。

注意：本译文内容略长，感兴趣的小伙伴请耐心阅读。

正文

市场波动改变了 PBIs 的相对价值。因此，Scrum 团队定期开会，以正确地排序、分解和评估产品 Backlog。你有一个产品 Backlog, Scrum 团队需要在 Sprint 计划会前考虑上述内容。

✥ ✥ ✥

敏捷企业必须能够快速响应以便能够利用机会来创造价值，同时应该避免过于超前的工作或计划。为了对市场机会做出快速反应，团队需要了解干系人的需求，并且所有的工作都必须排好队，以使手头有足够的项目可以继续地工作。产品负责人(PO)必须要通过沟通，明确即将开发的产品增量如何支撑愿景。PO 通过对产品增量的按顺序部署来满足高市场响应能力，并尽可能创造高价值。当机会来敲门的时候，人们要做好准备。在市场决策上可能存在“最后责任时刻”这么一说；它说的是你通过了一个决策，不过随着时间的推移和以此带来的环境的改变，都会让你的选择或者去执行这个决策的能力不复存在。

然而，推迟那些不会在很长时间内产生价值的工作也是很重要的。过早地在一个需要长周期交付的产品上投入工作，并且因为这些投入导致其他可行的产品错过主要的市场窗口，这带来机会成本是很高的。

更复杂的是，一些可交付成果对其他的条目有很强的依赖性。一些产品待办事项列表(PBI)可能建立在早期的产品增量之上;提前计划是很重要的，这样当大的市场机遇出现时，你就有了刚好合适的基础准备。这可能意味着您会更早地交付一些 PBI。尽管早期的版本可能会因为该条目产生较低的价值，但它可能会建立一个具有更大价值的产品增量。

随着时间的推移，团队对市场和依赖性有了更多的了解。然而，与此同时，组织内部的人做出开发和市场决策，或者市场本身朝着可能要求或引发对现有计划的改变的方向移动。每一个新的决定都是一个可能会限制未来产品和市场的可能性约束条件。例如，一个人可能会因为推迟在市场中引入某些特性而失去在市场中领先的机会。根据今天对团队和市场的理解，团队可以排序 PBIs 以获得最高的价值，但是明天可能会带来一个机会窗口，使用不同的 backlog 顺序可以创造更高的价值。团队通常很难提早就预见到这些问题。

因此:

Scrum 团队(特别是产品负责人和开发团队)应该经常开会，以正确地安排产品 Backlog，并将最近的大型 PBIs 分解为较小的 PBIs。开发团队应该维护其最终将实现的产品待办列表的最新估算(猪的估算——译者注：参考 Scrum 经典故事<鸡和猪的故事>)。

团队应该特别关注接近产品待办事项列表顶部的条目。要特别注意 PBIs 之间的依赖关系以及 PBIs 对外部市场因素(例如，假日销售季节)的依赖关系，以及何时有可用资源来建立 PBI(例如，交付所需的原始资料或者从供应商获得可用的技术实现)。Scrum 团队应该在 backlog 上注释每个条目的价值和工作量评估。

靠近待办事项列表顶部的 PBIs(接下来两到三个 Sprint 的条目)应该足够小，这样单个条目所需要的工作不会超过 Sprint 开发工作的 10%。

✥ ✥ ✥

条目细化包括详细的需求分析;在产品待办事项列表的结构中实现条目粒度梯度化;更新估计数字;重新排序项目，以反映它们之间的依赖关系或与 PBI 发布时间相关的约束;并且，通过更新产品待办事项列表，以反映任何对团队可用的新情况。

请记住，将团队聚集在一起细化 backlog 的主要目的是尽可能让团队开始思考如何实现预想的特性。

梳理也是一种学习的过程。无论是在潜意识中处理预想的需求，还是通过午餐时非正式地讨论即将到来的工作，对这些即将到来的功能的头脑活动将大大减少从愿景到设计的距离。

Isaac Asimov 提出，创造力在远离集体活动的孤独中开花，在结构化的专业环境之外的非正式愉快交流中开花。Steve Johnson 指出，“缓慢的直觉”是创造力的一个主要因素;Backlog 的细化和评估在团队成员的头脑中播下了点燃这个过程的种子。在条目部署之前就尝试看到它工作的样子，细化梳理的过程为这个思维过程的展开提供了时间。

在精益原则中一个比较好的简单排序技术是设计结构矩阵。让矩阵的每个坐标和 PBIs 对应，如果有彼此依赖就将字母”X”放入单元格：

然后对矩阵进行排序，使其成为左下角的对角矩阵。也就是说，你把延迟责任时刻提前——你从不推迟它们。这就是 Pre-XP 中提到的短语“最后的责任时刻”的原始含义。如果依赖项都被放在一个左下角的对角矩阵内，那么每一项都应该在它所依赖的条目之后。此外，将这些决策向前推进可以引导团队深入思考相关的工作条目，这将可能涌现出更多的需求，并提高对手头问题的洞察程度。时间的流逝并不能保证会出现任何新的见解：团队必须积极地将条目纳入设计和实现的思考，以便涌现出更多的需求。

用常识处理关联关系。如果不可能对矩阵进行排序，那么肯定存在循环依赖关系，团队应该对条目进行更详细的审查。在最坏的情况下，团队可能会将两个相互依赖的项合并成一个更大的项。

有了基本的依赖约束，对剩余的条目进行自由排序来优化应对市场变化和有价值的机会。了解开发团队在交付时对成本和项目将产生的预期价值的预测，您可以调整条目的顺序以优化他们对应的价值。仅仅改变一组给定条目的顺序通常就可以使实现的价值翻倍。

尽可能频繁的调整顺序，使每个队列中 PBIs(靠近 backlog 的顶部)符合 Ready 的定义。

以粒度梯度化的方式进行细化条目。如果时间允许-如果你有足够的信息做出负责任的决策，那么请专注于为即将到来的两到三个 sprint 细化梳理 PBIs。

在 Scrum 的早期，梳理活动发生在 Sprint 计划会期间。随着历史的发展，团队开始在 Sprint 计划会和每周一次的会议之间进行梳理工作，有时称为“周三下午的会议”或“产品 Backlog 改进会议”。在当代的 Scrum 实践中，通过简短的日常会议进一步传播工作是很常见的。每个团队都可以根据需要调整这类梳理活动的频率和持续时间，但是产品负责人与开发人员的会面时间一般不应超过工作时间的 10%。Scrum 团队应该提前安排所有这类活动：这不是产品负责人可以按需要求的工作。

在 Sprint 计划中，团队对 backlog 进行调整，不仅是为了追求最大的价值，也是出于对产品的自豪感。

更多关于估算的内容请看估算故事点部分的内容。

在 Scrum 指南中，Backlog 梳理并不是一个独立的事件。对于这一论点的支撑理由之一是说，Scrum 指南中没有任何东西可以超越当前的 Sprint。然而,这一观点是错误的,因为 Scrum 指南说,“在即将到来的 Sprint 中占据开发团队时间的产品待办事项必须是经过细化的,这样任何一个条目才能在合适的 Sprint 的时间盒内的‘完成’,” 同时 “冲刺评审的产出是一个可以放到下一次 Sprint 中的裁剪后的产品待办事项列表。” 一种更常见的解释是，梳理活动不需要有规律的定期举行，也不需要以“会议”的形式进行，而是给予 Scrum 团队以他们自由，按照他们认为最合适的方式进行即可。

在一定程度上，把未来的 Sprint 计划活动纳入到当前的 Sprint 中，是受到了 Takeuchi 和 Nonaka 在《哈佛商业评论》(Harvard Business Review)的经典文章中“B 型”生产的重叠的 Sprint 的启发。