[Day10] 团队系统设计 - Refinement 会议

在之前的文章中提到过，在 Planning 中进行 Refine 容易造成开会时间冗长，造成讨论缺乏效率的问题。那麽，把 Refine 从 Planning 中独立出来，难道就不会变成一个冗长的 Refinement 吗？ 本篇就来聊聊，高效率 Refinement 会议的具体实践方式。
回顾我们的「规画系统」图， Refinement 是其中的一个子系统：

Refinement 系统的产出为具有以下特性的 User Story：

• 内含经过 PO，设计师以及开发团队确认过的 UI/UX 规格
• 经过开发团队确认的验收条件 (Accept Criteria)
• 根据工程实务，将 User Story 拆分成细颗粒度的执行项目 ( Tasks )
• 针对执行项目进行点数估计

为了优化「效率」，我将 Refinement 拆成「线上」(online) 与「线下」(offline)：

线上 Refinement

时间：1 小时 (务必坚守)

流程：

• PO 说明对用户的价值，验证目标 ( 5 - 10 mins)
• 设计师解释设计，与使用者流程 (10 - 15 mins)
• RD (Backend, Mobile, Web, Native) 与 QA 依据领域专业，分组针对 User Story，UI/UX 进行审阅，并整理问题 ( 10 - 15 mins)
• PO 与设计师回答开发端的提问；可以立即做出判断的回答，可以直接决断；也常发生开发团队提出了很棒的建设性问题，PO/设计师需要时间思考，就回到线下进行。( 10 - 15 mins)
• 根据 User Story 复杂度的不同，若仍有充足的时间进行下一个 Refinement，刚重覆上述动作，直到会议时间结束。

线下 Refinement

时间：无限制，由团队成员自行规画时间进行，所需时间计入工作时间

流程：

• Scrum Master 与团队约定最晚应完成时间。
• PO 与设计师针对线上会议未回答的问题进行思考与补强。
• 在线上 Refinement 中已取得的资讯，让团队回到各自舒适的场域进行思考。并根据领域专业，分别切分成细颗粒的执行项目 (Tasks)。例如：UI 设计，商业逻辑设计，API 设计，基础架构设计…等。
• 对执行项目进行估点。(估点方式的探讨，留待下一篇文章细聊)

透过每个流程的时间限制，让团队在集体会议中可以聚焦讨论。而线下活动则是让开发团队可以在安静的环境，并确保其心理安全 (规画属工作的一部分，计入工时) 的条件下，得到优质的 Refinement 结果。

Scrum 行事历

至於， Refinement 会议的时间如何规画，我用假想 Scrum 团队的行事历来作说明，请见下图。

这个团队的开发周期是 2 周，每个 Sprint 的第 1 天进行 Planning ，而可以拉进 Planning 的工作项目，是透过前两周的 Refinement 得到。这里可能会衍生的另一个疑问题，这样做，团队的前一个 Sprint 不就被打扰了吗？ 这个问题，我留到介绍 Planning 的时候再释疑。

下一篇文章，我会来补本篇留下的坑，介绍一种变型的估点实践方法。明天见！