scoping-and-handing-off-to-teams

面向 Initiative Shepherd 的第 4 阶段（范围界定与承诺）深度实践指南——在投入大量资源前的最终决策关口。Shepherd 将从带领工作转为支持负责执行的团队。交付物：高层架构计划、子 Epic、各团队交接会议、成本效益分析、领导层 go/no-go 汇报、运营优先级排序、产能分配，以及最终版 ADR。时间预算：2–4 周，Shepherd 投入 30–50 小时。本阶段在 bitwarden-delivery-tools 中组合使用 Skill(running-work-transitions)，对应 Work Transition Playbook 中发起方的准备和交接会议阶段。

首先要拒绝的反模式

首先要明确：拆分工作由团队负责，而不是 Shepherd。 此阶段最大的失败模式，就是 Shepherd 替团队编写用户故事。

漏斗文档明确指出：“交接后，组织一次团队拆分会议。由团队创建用户故事，而不是 Shepherd。” 团队没有编写的用户故事，团队就不会真正认同。这样一来，后续就会出现“我们落后于进度，因为用户故事不符合团队的实际工作方式”之类的问题，而且无法妥善补救。

坚守这一原则。你的职责是为每个团队提供充足的背景、范围和模式，让他们能妥善拆分工作，而不是替他们拆分。

你要产出什么

第 4 阶段会按大致顺序产出八项成果：高层架构计划、Jira 中的子 Epic、各团队交接会议、成本效益分析、已分配的 Initiative 优先级、供领导层做 go/no-go 决策的汇报、运营优先级排序与产能分配，以及最终版 ADR。下文将分别介绍每项成果。

高层架构计划

将 Confluence 页面放在 EN 空间的架构规划文件夹下，并使用“High-Level Architecture Planning”模板。漏斗文档规定了以下内容：

• 范围。 要变更什么——代码库、模块、文件。务必具体。此阶段的范围描述含糊，会导致实施期间重新界定范围。
• 方案。 如何推出变更，包括分阶段计划、迁移路径，以及迁移期间和之后旧模式的处理方式。
• 团队分工。 哪些团队负责哪些部分。尽可能做到每个 Epic 由一个团队负责。
• 依赖关系。 哪些事项必须先完成，哪些可以并行开展，以及团队之间可能出现的阻塞点。
• 风险缓解。 失败模式、回滚计划，以及触发暂停或调整方向的指标。
• 成功指标。 如何判断 Initiative 是否成功。现在就要定义这些指标——它们将成为实施完成后 3–6 个月评估影响的依据。
• 文档需求。 随着推出进展，必须创建或更新哪些内容（技术指南、迁移指南、ADR 更新、贡献指南变更、运行手册）。

每个团队的技术负责人都会在交接会议前阅读这份架构计划。请面向这位读者撰写。

Jira 中的子 Epic

在 BW 计划下创建 Epic，通常每个团队或主要模块一个。每个 Epic 包含：

• 概要。 简短具体（例如，“将浏览器扩展迁移到新的错误处理模式”）。
• 团队分配。 分配给团队，而非个人。
• 描述。 说明受影响的代码库区域、要采用的模式（链接到 PoC PR）、此 Epic 的预期结果、成功标准，以及团队需要了解的跨团队依赖项。
• 用于筛选的标签 / 组件（例如，initiative-typescript-migration）。之后，所有人的仪表板都会据此汇总进度。

funnel 文档中的 Epic 示例：

Epic： 将浏览器扩展迁移到新的错误处理模式 团队： 浏览器扩展团队 描述：

• 采用 PoC 中验证过的错误处理中间件模式（PR #1234）
• 应用于后台脚本、内容脚本和弹出窗口
• 必须保持现有的 Sentry 错误报告功能
• 成功标准： 所有扩展错误处理均遵循新模式，且没有回归问题

Epic 中不包含实施故事。这些故事由团队在自己的拆解会议中制定。

各团队交接会议

为每个团队安排一场 1 小时的交接会议。根据 funnel 文档，会议安排如下：

时间	内容
20 分钟	Shepherd 介绍：PoC 调查结果、架构计划中与该团队相关的部分
15 分钟	问答——团队针对方案提出澄清问题
15 分钟	团队讨论：对拆解方案的初步想法
10 分钟	后续步骤——团队承诺在特定日期前完成拆解

这也是发起方《工作交接手册》的第 2 阶段。funnel 文档明确引用了该手册；双方视角都适用。

会议前：

• 提前几个工作日发送架构计划和 PoC PR 链接。提前阅读材料的团队能提出更有针对性的问题。
• 确认团队的技术负责人和 EM 会出席。

会议中：

• 先说明原因（问题和 PoC 调查结果），再说明具体内容（架构计划中的相关部分）。相比规范说明，团队对背景的反应更好。
• 认真对待问题，尤其是揭示路线图冲突的问题。交接会议是讨论这些问题的合适场合，实施阶段则不适合。
• 结束前必须确定拆解完成日期。“我们会找时间做”会让 Epic 在待办事项中逐渐搁置。

会议后：

• 团队自行召开拆解会议（你不参加）。
• 团队的技术负责人将完成的拆解结果发给你。
• 你要检查其与计划愿景的一致性，而不是重写故事或事无巨细地管理。funnel 文档给出了这种提问方式：“看起来不错，但这里用的是回调，而不是 PoC 中的 async/await 模式——这是有意为之的吗？”

成本效益分析

记录在架构计划中。funnel 文档的分析框架如下：

• 成本： 各团队整体工作量（团队估算总和，加上你投入的 shepherd 时间和架构委员会时间）。
• 收益：
  • 定量： 减少的 Bug、节省的时间、性能提升、减少的值班告警。
  • 定性： 开发者体验、可维护性、一致性、安全状况、未来灵活性。
• 比较。 坦诚说明。如果收益主要是定性的，就如实说明——领导层可以据此权衡。如果没有定量依据却假装有，这会损害下一个计划的可信度。

倡议优先级

根据漏斗文档，与工程领导层协作，确定相对于其他倡议以及 Architecture / Engineering Operating Model 组合的优先级：

• Critical： 阻碍重要产品工作或带来重大风险——立即启动。
• High： 大幅提升使用体验或降低风险——安排在本季度内。
• Medium： 带来有意义的改进，可灵活安排——在 2 个季度内。
• Low： 有则更好，待有余力时再做——择机安排。

在 Jira 中更新 BW 倡议的优先级。

领导层汇报

在利益相关方同步会议上向工程领导层介绍计划。根据漏斗文档，内容包括：

• 问题回顾和解决方案。
• PoC 验证结果。
• 工作量估算和时间表（汇总各团队的拆分估算）。
• 成本效益分析。
• 风险评估。
• 倡议优先级。
• 资源需求——涉及哪些团队、需要多少产能、持续多长时间。

寻求明确的 go/no-go 决策。高管承诺意味着：“是的，我们会分配资源来完成这项倡议。”

运营优先级安排

这是漏斗文档明确区别于高管承诺的步骤。高管承诺表示“会做，但不一定何时做”。运营优先级安排表示“从这些日期开始，投入这么多产能”。

与工程领导层协调：

• 目标开始日期。 根据倡议优先级和其他团队承诺确定。
• 执行季度。
• 各个 Epic 相对于团队其他工作的优先级（产品路线图功能、其他倡议、缺陷、技术债务）。

工程领导层与团队负责人和 EM 协作，以便：

• 传达这项倡议的重要性和时间表。
• 分配产能（例如，“接下来的 3 个冲刺中，将 15% 的冲刺产能用于此项工作”）。
• 调整团队路线图。
• 如果团队任务过多，解决冲突。
• 将 Epic 按适当的优先级加入团队待办事项列表。

此步骤的产出（根据漏斗文档）：

• 明确的时间表（例如，“2026 年 Q2 开始实施，预计 2026 年 Q3 完成”）。
• 每个参与团队都了解需要分配产能。
• 在 Jira 中为各团队待办事项列表中的 Epic 设置优先级。
• 团队确认该工作已列入其路线图。

漏斗文档明确指出了这种失败模式：有高管承诺但未进行运营优先级安排的倡议，会无限期地停滞在待办事项列表中。未完成运营优先级安排前，不要进入实施阶段。

最终确定 ADR

• 如果 ADR 状态尚未设为“Accepted”，则更新状态。
• 添加实施时间表和最终范围。
• 包括开始日期和预计完成日期。

更新 BW 倡议

在范围界定阶段（参见 基于想法的倡议）：

• Priority 字段： 设置为领导层最终确定的优先级。
• 子 Epic： 在 Jira 中创建为该倡议的子项，每个团队或模块创建一个。
• 评论： 记录高管承诺——谁批准了、分配了多少产能、商定了什么时间表。这是可审计的承诺记录。
• 描述： 在描述中或通过评论链接高层架构计划。
• ARCH idea 状态： 更新为“4️⃣ Scoping & Commitment”。

退出标准

根据漏斗文档：

• 交付物： 高层架构计划；创建范围和方案明确的史诗；各团队已完成故事拆分和估算；汇总团队估算，形成总体时间表和工作量；确定计划优先级；完成成本效益分析；获得高管承诺；在团队待办列表中为史诗排序，并明确时间表和产能分配。
• 决策者： 工程副总裁 / CTO，并与利益相关方达成一致。
• 可能的决策： 进入实施阶段 / 重新确定范围（缩小范围、重新估算）/ 暂缓（时间冲突，安排到未来季度）/ 拒绝。

漏斗文档列出的五项关键成功因素：

1. 工程领导层必须明确表示“是，我们要做这件事”。
2. 必须为团队分配产能，并明确开始和结束日期。
3. 根据产能和依赖关系制定的时间表必须切实可行。
4. 必须在团队待办列表中为史诗排序，让团队知道何时将故事纳入冲刺。
5. 故事拆分必须由团队负责。

本阶段交接给阶段 5 的内容

进入实施阶段时（通过 Skill(coordinating-implementation-across-teams)），《工作交接手册》的支持期阶段即开始。发起方指南——哪些事情该找你帮忙，哪些不该——见 Skill(running-work-transitions)。在实施阶段启动前阅读；接收团队阅读的也是这份手册。

常见错误

• 替团队编写故事。 前面已经提过；这里再次强调，因为这是常见的失败模式。
• 把高管承诺当作范围界定阶段的终点。 没有实际的优先级安排，高管承诺就只是空谈。
• 接受被提前结束的交接会议。 交接会议是提出棘手问题的场合。会议时间少于 1 小时，意味着有些话没有说出来。
• 夸大成本效益分析。 工程领导层会看穿，下一项计划还会为失去的信誉付出代价。
• 跳过架构计划中的“文档需求”部分。 这样一来，文档只能等到最后才写，而那时模式已经出现偏差。
• 未经团队认可就汇总团队估算。 如果团队给出估算时自己都不认同，也不会按这个估算交付。

参考资料

• 软件计划漏斗 §4 — 阶段说明、交接会议结构和实际优先级安排的权威资料。
• 工作交接手册 — 交接流程的权威资料；本阶段对应阶段 1–2 的发起方。
• 基于创意的计划 — 如何在范围界定过程中更新 BW Initiative。
• 架构 / 工程运作模式 — 计划组合如何与其他架构工作进行优先级排序。
• 相关资料：总体手册见 Skill(shepherding-an-initiative)；发起方交接机制见 bitwarden-delivery-tools 中的 Skill(running-work-transitions)；范围界定阶段的后续内容见 Skill(coordinating-implementation-across-teams)。