[Day08] 团队系统设计 - 规画系统

在 Scrum Guide 中其实并没有明确地提到所谓的「精链会议」( Refinement) ，因此在社群中对「精链会议」和 「计画会议」( Planning) 讨论没少过。也正是这种模糊的美，造就了许多团队的迷糊。我经历过的团队，起初都是把有关使用者故事的讨论，放在 Planning 会议中。在会议中的活动包含：

• 审阅 UI / UX 规格
• RD 们讨论实作细节
• 估点
• 给出 Sprint 产出的承诺 ( Commitment)

乍看之下，都很合理，但实际执行起来，每个团队都遇到了同样的问题：

• UI / UX 有问题时，设计师会在 Sprint 开跑後才能给出定稿，导至 RD 开发排程受影响
• 对於还没有掌握度的技术， RD 们容易进入发散式的讨论，进而估出非常大的故事点数
• 所有 RD 对故事进行估点，然後讨论点数差异。而不同领域的 RD ，对自己不熟悉的实作进行估点，跟掷骰子没什麽两样。

而这样的 Planning 会议开下来，最糟的情况，可以开一整天。即使投资了大量的时间，却因为未定的细节太多，RD 无法给出承诺，导至能交付的项目少得可怜。在这个 Planning 的结构中，张力-舒缓系统随处可见。因此，我们需要一个新的结构/系统：
一个协助开发者可以高效产出的规画系统

系统方块图如下：

在这个系统中，我明确的把 Refinement 从 Planning 中抽离，形成一个独立的活动。这个概念来自「开脑 CSM」课程。 Daniel 老师是这样论述：

「Refinement 是 Scrum 团队的远光灯，团队在 Refinement 中应针对「未来」即将进行开发的 User Story 进行讨论，而不该把讨论放在一个已开跑的 Sprint。」

「提前讨论的好处在於，PO/PM 与设计师有时间针对未周全的设计进行修改，工程师也可以针对掌握度不足的技术进行前置研究。」

「提前的时间以不超过 2 Sprint 为原则，隔太久，大家都忘了在 Refine 什麽。」

根据我的实务经验，将 Refinement 提前进行，确实可以让工程师在开发过程中，有明确的开发方向，并减少因规格不明或技术掌握度问题带来的阻碍，因此可以推论开发效率也获得提升。

至於如何提出效率提升的量化指标，我采用问卷评分方式，针对 30 个 Scrum 团队成员进行调查，题目为：

对於转型前/後的开发流程，1 - 10 分你各会给予几分？

结果如下图：

这个调查显示转型前的团队评分偏低，间接说明团队存在不小的内部张力。而经过调整之後，对於开发流程的满意度明显是往好的方向移动。

我提出的系统肯定不是完美的，但这里的重点是：与团队对话。透过有结构的对话，可以知道团队的感受，并且也搜集团队的意见，再注入系统中，我们终究可以打造出最合适个别团队的开发系统。有关问题设计与提问技巧，留到後面一些再与大家分享。

接下来的文章，我们将逐步拆解规画系统，以及每个环节的实践方法，我们明天见！