[Day14] 团队系统设计 - 重塑 Planning 会议

本篇文章来介绍「规画系统」(Planning System) 中的：Planning 会议。我相信熟悉 Scrum 的朋友对 Planning 的内含与执行方式都不陌生，我尽量减少己知资讯的重覆，而是聚焦高效率 Planning 会议的实践方式。

回顾规画系统方块图，细心的各位也许会发现与之前稍有不同。在这里我更明确的定义了 Refinement 的系统输出为「产品待办清单」( Product Backlog ) 上「合格」的待实作 User Story，我对「合格」定义：进行过「细颗粒执行项目」拆分与「点数」评估。而 Planning 的系统输出为 Sprint 待办清单。

Planning 会议中要进行的活动就是：

从 Product Backlog 中，挑选下个 Sprint 中团队可以消化的工程项目，放进 Sprint Backlog

之前的文章提到过，很多团队会在 Planning 会议中，一并进行 User Story 的讨论与估点，造成时间冗长；这个问题在我提出的系统中，已经消除，Planning 的会议效率已预期可大幅提升。此时关注的重点在於「实作项目挑选」以及「团队实作量能」。

实作项目挑选

PO 根据商业价值判断，定义 Product Backlog 的优先顺序後，在 Planning 会议中，PO 向团队解释验证与商业目标，以及期望团队可以交付的 User Story 有哪些。由於此时的 User Story 都已经带有点数，且根据 123 估点法，PO 已经可以事先估算团队在 Sprint 中的实作量能，可以拉几个 User Story 进 Planning 就可以大概估算。例如一个假想的圑队组成如下：

• Backend : 2 人
• Android : 1 人
• iOS : 1 人

一个 Sprint 的周期为 2 周，则团队理想实作量能为：

• Backend : 2 人 x 10 days x 3 pt/day = 60 pts
• Android : 1 人 x 10 days x 3 pt/day = 30 pts
• iOS : 1 人 x 10 days x 3 pt/day = 30 pts

但团队开发，绝不可能每个人 30 点排满满，因为每个 Sprint 都会有预期 (会议，公司活动，国定假日等)或非预期 (特休，插件，天灾等) 的事件，可能影响开发。PO 可以根据经验，将开发量能给与权重。假设权重为 0.8 ，则调整後的实作量能成为：

• Backend : 2 人 x 10 days x 3 pt/day x 0.8 = 48 pts
• Android : 1 人 x 10 days x 3 pt/day x 0.8 = 24 pts
• iOS : 1 人 x 10 days x 3 pt/day x 0.8 = 24 pts

以下图的估点为例：

三个领域的 RD 都有充份的量能可以开发这个 Story，此时 PO 可以轻松的判断，是不是还可以把另一个 User Story 先放进 Planning 会议。或是把时间交给技术主管，进行一些别的开发活动。

团队实作量能

上面提到的实作量能，是 PO 的估算值，而实际状况就是在 Planning 会议中，由 RD 自行回报。例如下述的状况：

• Backend RD 在 Sprint 中，计画性的请 3 天特休
• 当前的 Sprint ，有 1 天国定假日
• iOS RD 会请 1 天特休

因此在会议中，可以重新对齐团队开发量能如下：

• Backend : ((1 人 x (10 - 4) days x 3 pt/day) + (1 人 x (10 - 1) days x 3 pt/day )) x 0.8 = 36 pts
• Android : 1 人 x (10 - 1) days x 3 pt/day x 0.8 ~= 22 pts
• iOS : (1 人 x (10 - 1 -1) days x 3 pt/day) x 0.8 ~= 19 pts

接下来，就让 RD 自行挑选工程项目 (Task)，此时的精神为 RD 的承诺。PO、Scrum Master、工程主管不干预 RD 自主性。

最後， PO 可以从 Planning 的结果，得知 User Story 是否都可以在 Sprint 中完成交付。根据经验，我带过最大的 Scrum 团队 (20 人)，曾经在 40 分钟内完成 Planning ，并且领域团队可以向所有人简报他们预计完成的项目，对齐期望。

这里会有一个常见的衍伸性问题：

如果 Sprint 无法将完整的 User Story 完成该怎麽办？ 这不就违反 Scrum 精神了吗？ 要删减 User Story 还是延长 Sprint 时间？ 这个疑问，我留待之後的文章专门解答。

下一篇我们来聊聊「规画系统」的最後一环：开发系统。明天见！