三個月導入路線圖（統整版V2）

2026-02-23
統整初稿-v2

三個月導入路線圖（統整版V2）

本文件為統整初稿 V1 的升級版本，整合 Integration Expert 整合決策報告中的全部架構調整。V2 與 V1 最大的差異在於：成熟度路徑新增 Level 3.5（String Freeze 先行），Month 2 加入去污名化 Workshop 和 QA 批次視窗機制，Month 3 正式啟用 Hotfix SOP。

設計哲學：文化轉變需要有序的衝擊劑量。V1 在 Month 2 同時引入 Feature Freeze 設定和掉車 SOP，文化衝擊集中，V2 透過分層設計（String Freeze → 掉車預演 → Feature Freeze → Hotfix）讓每個月有一個主要的文化升級點。

相關文件：04-環境建置指南（統整版V2） | 05-團隊導入策略（統整版V2）

成熟度路徑總覽

V2 的成熟度設計新增了 Level 3.5 這個中間站，讓從「沒有截止日文化」到「完整 Feature Freeze 文化」的轉型更有緩衝：

成熟度描述達成時機核心機制
Level 2（現況）版本有日期但可以延誤，沒有截止點文化導入前—
Level 3（Month 1）Linear 環境建立，全員加入，基礎 Automation 運作Month 1 Week 3Android ALPHA 驗證 + Testing Notes Template
Level 3.5（Month 1 末）String Freeze 試水：第一次讓「截止點是死的」變成真實體驗Month 1 Week 4String Freeze 第一次執行
Level 4（Month 2）掉車 SOP 第一次執行，去污名化 Workshop 完成，QA 批次視窗啟動Month 2 Week 2-3掉車 SOP + QA 批次視窗
Level 5（Month 3）完整 Feature Freeze 文化，Hotfix SOP 正式運作Month 3Hotfix SOP + 第三次掉車自動執行

為什麼需要 Level 3.5（String Freeze 先行）

String Freeze 和 Feature Freeze 的核心差異：

面向String Freeze（Level 3.5）Feature Freeze（Level 4-5）
影響範圍所有 UI 文字和 Copy所有功能的增刪
情緒衝擊低（翻譯晚了很好理解）高（功能掉車涉及 RD 個人感受）
破壞性幾乎為零（文字調整不影響功能）中高（功能掉車影響版本內容）
文化建立目的讓全員體驗「有截止點且不可延伸」讓全員體驗「列車不等人」

String Freeze 之所以作為試水，是因為它能在幾乎沒有衝突的情況下建立「截止點是死的」這個最基本的文化認知。當 MKT 知道文字在某日之後不能改，他們必須在截止日前完成文案確認——這個體驗本身就是 Feature Freeze 文化的預演。

三個月總覽

Month 1（建立基礎 + String Freeze 試水）
  ├── Level 3 目標：Linear 環境所有 P0 項目完成
  ├── Android ALPHA 驗證：確認自動通知機制可靠
  ├── Testing Notes Template：建立填寫規範，全員理解
  ├── DORA 基線：7 個指標全部測量現況
  ├── Feature Freeze 概念宣告：為 Month 2 文化轉變預熱
  ├── Firebase Crashlytics Alert 設定（Month 1 末）
  └── Level 3.5 目標：String Freeze 第一次試水（Week 4）

Month 2（文化轉變：掉車 SOP + QA 批次視窗）
  ├── 去污名化 Workshop（Week 1）：60分鐘，在真實掉車前去除心理障礙
  ├── Feature Freeze 第一次執行（Week 1-2 設定）
  ├── 掉車 SOP 首次實際執行（Week 2-3）
  ├── QA 批次視窗啟動（Week 1）：週二 + 週四 PM 固定 QA 時段
  ├── String Freeze 第一次完整執行（以 Month 2 某版本為試驗對象）
  └── Testing Notes 填寫率追蹤：目標 > 80%

Month 3（指標達標 + Hotfix SOP 正式運作）
  ├── Hotfix SOP 正式培訓（Week 1）
  ├── QA / Shawn 全面接入 Linear
  ├── 第一次完整「列車準時發車」（含掉車 + 準時提交）
  ├── 掉車自動化（第 3 次起不需 RM + PO 逐次確認）
  └── DORA + 消費者 App 7 個指標首次完整評估

時間軸

Week:  W1   W2   W3   W4   W5   W6   W7   W8   W9  W10  W11  W12
       ────────────────────────────────────────────────────────────
M1:    ████████████████████
       ↑    ↑    ↑    ↑
   Template DORA ALPHA String
   建立   基線  驗證  Freeze
                      試水

M2:              ████████████████████
                 ↑    ↑    ↑    ↑
              Workshop Freeze 掉車  QA批次
              去污名化 執行   SOP   視窗

M3:                        ████████████████████
                           ↑    ↑    ↑    ↑
                        Hotfix  QA  列車   指標
                        SOP    全接 準時   評估

Month 1：建立基礎 + String Freeze 試水

月度目標

  1. 完成 Linear 環境所有 P0 項目
  2. 驗證 Android ALPHA 自動通知機制
  3. 建立 Testing Notes Template 並制定填寫規範
  4. 完成 DORA 基線 + 消費者 App 3 個特有指標的現況測量
  5. 向全員宣告 Feature Freeze 概念，為 Month 2 預熱
  6. 在 Month 1 末完成 Firebase Crashlytics Alert 設定（低成本高保護）
  7. 執行 String Freeze 第一次試水（Level 3.5 里程碑）

現況繼承清單

項目狀態Month 1 動作
Workspace + Team（REL）設定完成繼承，無需重做
Workflow States（11 個）完成評估是否加入 Waiting for Others（M2 試行）
Labels完成新增 [Hotfix] Label（紅色）
GitHub Integration完成驗證 branchPattern 設定（P0 優先）
Slack Integration完成驗證 ALPHA 通知觸發；建立 release-hotfix Channel
Projects（版本容器）待建立P0
Issue Templates（含 Testing Notes）待建立P0
Automation Rules待建立P0
邀請全員加入 Workspace待執行P0

任務清單

M1-01：branchPattern 設定與驗收測試（最優先 P0）

負責人：David

重要：branchPattern 是所有 Automation 的前提條件，必須在其他 Automation 設定之前完成，並通過驗收測試。

完成條件：

期限：Month 1 Week 1（第一個執行的任務）

M1-02：Projects 建立與版本容器設定

負責人：David

完成條件：

String Freeze Milestone 說明：在 V2 中，每個版本 Project 都應設定 String Freeze Milestone，時間點通常在 Feature Freeze 前 7-10 天。String Freeze 代表所有 UI 文字和 Copy 的最後截止日，MKT 的翻譯工作必須在此日期前確認所有文案。

期限：Month 1 Week 1

M1-03：Issue Template 建立（含 Testing Notes）

負責人：David（建置）+ Sherridy（定義填寫規範）

完成條件：建立三個 Template（詳細格式見 04-環境建置指南（統整版V2））：

  1. 新功能規劃（PO 使用）—— 含 Testing Notes 欄位，PO 在 Planning 必填初始版本
  2. QA 測項（Sub-issue 使用）
  3. Bug 修復（Ready for Fix 時使用）

全員 Slack 公告：在 #forest-release 發布 Template 用途與填寫責任分工說明

期限：Month 1 Week 1（P0，必須在 M1-04 前完成）

M1-04：Android ALPHA 機制驗證

負責人：David + Tolyn（Android RD）

背景：Android Ready for Test 的自動 QA 通知依賴版本號含 -ALPHA。此機制不可因導入而中斷，必須在 Month 1 驗證其可靠性。必須連續 2 次成功觸發才算驗證通過。

完成條件：

依賴項：M1-01（branchPattern 已驗收通過）

期限：Month 1 Week 2

M1-05：DORA 基線 + 消費者 App 指標現況測量

負責人：David + Sherridy

完成條件：以下 7 個指標均有現況測量數據：

DORA 4 個指標：

  1. Lead Time：過去 3 個版本，功能從進入 Planning 到版本 Released 的平均天數
  2. Deployment Frequency：過去 6 個月，iOS / Android 各發布了幾次版本
  3. Change Failure Rate：過去 6 個月，緊急修復版本數 / 總發布次數
  4. MTTR：過去 3 個重大 Bug，從最早發現記錄到修復完成的時間

消費者 App 3 個特有指標： 5. Testing Notes 填寫率：過去 3 個版本 Issues 中有測試注意事項記錄的比例（預期基線：0%） 6. 版本延誤頻率：過去 3 個版本，幾次版本發布比預定日期晚超過 3 天？ 7. Crash-free Session Rate 現況：Firebase Crashlytics 查詢 iOS / Android 當前基線數字

記錄格式：建立一份 Linear Project Comment 記錄各指標現況數字與測量方法

期限：Month 1 Week 2

M1-06：Feature Freeze 概念宣告 + Hotfix 環境建立

負責人：David（環境建立）+ Sherridy（公告）

兩個子任務：

子任務 A：Feature Freeze 概念宣告

子任務 B：Hotfix 環境預建（為 Month 3 正式使用預先準備）

依賴項：M1-03（Template 建立後才宣告，顯示準備充分）

期限：Month 1 Week 3

M1-07：Automation Rules 建立

負責人：David

完成條件：建立 Automation 1-7（詳細設定見 04-環境建置指南（統整版V2））：

Automation說明技術可行性
#1 iOS Ready for Test 通知狀態改為 Ready for Test + Label iOS → Slack 通知✅ Linear 原生
#2 Android Ready for Test 通知同上 + Label Android✅ Linear 原生
#3 Server/Web Ready for Test 通知同上 + Label Server/Web✅ Linear 原生
#4 Released 時間戳記錄狀態改為 Released → Comment + Webhook✅ Linear 原生（DORA 部分需 n8n）
#5 Testing Notes 提醒（降級版）狀態改為 In Development → 無條件發 Comment✅ 降級後可行（無法判斷 Description 是否空白）
#6 Ready for Test 個別確認狀態改為 Ready for Test → Comment 提醒 QA✅ Linear 原生
#7 Ready for Fix 通知狀態改為 Ready for Fix → Slack + DM✅ Linear 原生

重要說明（Automation 5 降級）：

Feature Freeze 提醒注意事項：

期限：Month 1 Week 3-4

M1-08：Firebase Crashlytics Alert 設定（新增至 Month 1）

負責人：David（設定）+ Shawn（確認可接收通知）

為什麼前移至 Month 1：Firebase Crashlytics Alert 的配置成本低（設定約 1-2 小時），但一旦上線就能即時保護發布安全。V1 將此設定放在 Month 3，意味著整個導入期的前兩個月沒有自動 Crash 監控保護。

完成條件：

MTTR 計時說明：MTTR 從 Firebase Alert 觸發時開始計算，時間戳以 Slack 通知的時間為準。

期限：Month 1 Week 4

M1-09：String Freeze 第一次試水（Level 3.5 里程碑）

負責人：Sherridy（決策）+ MKT 負責人（執行）

這是 V2 最重要的新增任務，也是 Level 3.5 的核心。

背景設計邏輯：String Freeze 是讓全員在低衝突情境下體驗「截止點是死的」這個文化的機制。它的違反成本說明：

完成條件：

文化里程碑意義：第一次 String Freeze 的成功執行，代表 Forest App 正式進入 Level 3.5——全員已有「截止點存在且不可任意延伸」的體驗。

期限：Month 1 Week 4（配合版本 Cycle 時程）

Month 1 成功指標

指標目標值驗收方式
Linear 環境所有 P0 項目完成100%Checklist 全勾
branchPattern 驗收測試通過通過驗收測試記錄
Testing Notes Template 上線完成至少 1 個真實功能 Issue 使用新 Template
Android ALPHA 驗證通過連續 2 次成功觸發[ALPHA-Verified] Label 標記
DORA + 消費者 App 7 個指標均有基線數據7/7測量記錄文件
Feature Freeze 概念宣告全員確認理解Slack 回覆記錄
Firebase Crashlytics Alert 設定完成完成Alert 觸發測試通過
[Hotfix] Label + release-hotfix Channel 建立完成環境確認
String Freeze 第一次試水（Level 3.5）完成MKT 確認 + RM 公告記錄

Month 1 末文化里程碑

Month 2：文化轉變（掉車 SOP + QA 批次視窗）

月度目標

  1. 執行去污名化 Workshop（Week 1）：60 分鐘，在真實掉車前去除心理障礙
  2. 所有 RD 開始全面使用 Linear 追蹤開發中 Issue
  3. 第一次 Feature Freeze 正式設定與執行
  4. 掉車 SOP 首次實際執行
  5. QA 批次視窗機制啟動（Week 1）：Fei Chen + Jimmy 設定固定 QA 工作節奏
  6. String Freeze 第一次完整執行（以某個 Month 2 版本為試驗對象）
  7. Testing Notes 填寫率追蹤正式開始，目標 > 80%

重要設計說明：為什麼 Workshop 移至 Month 2 Week 1

V1 版本的「掉車預演會議」設計在 Month 1 Week 4 執行。V2 的調整理由如下：

任務清單

M2-01：去污名化 Workshop（V2 新增，Level 4 前置）

負責人：David（主持）+ Sherridy（主要參與者）+ RD Lead Ezou + QA Fei Chen

時機：Month 2 Week 1，Feature Freeze 第一次設定的同一週

形式：60 分鐘 Workshop（建議結合 Planning 會議進行，避免佔用額外時間）

完整議程：

[0-10 分鐘] 角色演練——理解對方的壓力點
  形式：RM（Sherridy）扮演 RD，RD（Ezou）扮演 RM
  劇本：
    「RM」（Sherridy 扮演）：「我的功能還差 2 天，可以等我嗎？」
    「RD」（Ezou 扮演）：「這個版本已經有 3 個功能準時了，等你的話
                       那 3 個功能的 QA 時間就被壓縮了。」
  討論：互相說出扮演對方時感受到的壓力

[10-30 分鐘] 掉車情境模擬
  從 SOP 的第 1 步走到第 5 步：
  Step 1：Feature Freeze 前 3 天，David 列出 In Development Issue 清單
  Step 2：Sherridy 詢問 RD（Ezou）：「FOR-XXX 能在 Freeze 前完成嗎？」
  Step 3：Ezou 誠實回答：「不確定，可能需要多 2 天」
  Step 4：Sherridy 宣布掉車決定 + 說明心理安全聲明
  Step 5：David 在 Linear 執行移動操作 + 公告

  全員確認：「我知道我在這個流程中要做什麼」

[30-40 分鐘] 心理安全宣言（RM 公開承諾）
  Sherridy 公開說明：
  「掉車不計入個人績效，只計入版本學習。

  我承諾：
  1. 第一次掉車的原因永遠是流程問題，不是個人問題
  2. 掉車後被掉車 RD 的下一班時程會在 24 小時內確認
  3. 如果掉車決定讓你感到委屈，你可以直接找我討論
  4. 我會在 Slack 公告時說明決策邏輯，不是只發結果」

  David 在 Linear 建立「版本學習記錄」格式預覽

[40-60 分鐘] 掉車記錄格式預覽
  讓所有人看到「掉車記錄長什麼樣」：
  - Linear Issue Comment 的記錄格式
  - Slack 公告的格式
  - 掉車功能在下一班 Project 中的狀態

  重點：讓大家知道「掉車不是消失，是轉移」

  Q&A：收集所有顧慮，David 記錄並承諾在 Freeze 前回應

完成條件：

期限：Month 2 Week 1（Feature Freeze 第一次執行前必須完成）

M2-02：QA 批次視窗機制啟動（V2 新增）

負責人：Fei Chen + Jimmy（設計工作節奏）+ David（Linear 視圖設定）

背景：個別 Issue 觸發（Issue 完成 → 立即 Ready for Test）是 V1 已確認的正確設計。但純粹個別觸發模式下，Fei Chen 和 Jimmy 會面臨高頻 context switching——每收到一個 Ready for Test 通知就要停下來切換。V2 加入批次視窗機制解決這個問題。

設計原則：

具體設計：

批次視窗時間（建議，Fei Chen + Jimmy 可依實際節奏調整）：
  週二 PM 14:00-18:00
  週四 PM 14:00-18:00

在批次視窗外收到 Ready for Test 通知的處理：
  → Issue 出現在 QA 待測 Queue 中
  → 下一個批次視窗統一處理
  → Fei Chen 不需要立即切換（除非 Issue 有 [Priority: Urgent] Label）

例外（可以在批次視窗外立即測試）：
  → Issue 有 [Priority: Urgent] Label（需 RM 手動加）
  → 接近 Feature Freeze 的 Issue（RM 評估後加 Urgent Label）

Linear 視圖設定（詳細步驟見 04-環境建置指南（統整版V2））：

David 在 Linear 建立「QA 待測 Queue」Custom View：

向 RD 的說明（培訓素材）：

「你的功能 Ready for Test 後，為什麼不立刻被測試？」

「QA 使用批次視窗機制來保護他們的認知資源。你的 Issue 已進入 QA 的待測 Queue，會在下個批次視窗（週二或週四下午）開始測試。如果你的 Issue 接近 Feature Freeze 或有緊急需求，請通知 Sherridy 加上 Urgent Label，可以插隊到批次視窗外即時測試。」

完成條件：

期限：Month 2 Week 1 設定；Week 2 開始正式執行

M2-03：Feature Freeze 第一次正式設定

負責人：Sherridy（決策）+ David（Linear 操作）

完成條件：

Step 1 — Planning 完成後 24 小時內：

Step 2 — 在 Linear 設定 Milestones：

Step 3 — 同步設定 Google Calendar 提醒（Feature Freeze 48h 提醒替代方案）：

Step 4 — 公告 Freeze 日期：

掉車保守模式說明（V2 精確化）：

期限：Month 2 Week 1

M2-04：掉車 SOP 首次實際執行

負責人：Sherridy（決策）+ David（Linear 操作）

背景：M2-01 去污名化 Workshop 是心理準備，M2-04 是真實執行。在 Feature Freeze 前掃描中，刻意選擇一個影響最小的功能（非核心、非承諾），走一次完整的掉車 SOP。

完整掉車 SOP（5 步驟）：

Step 1：風險識別（Feature Freeze 前 3 天）
  David 查詢 Linear，列出本版本中仍在 In Development / Planning 的 Issue
  → 整理清單呈報 Sherridy

Step 2：RD 誠實評估
  Sherridy 詢問相關 RD：「FOR-XXX 能在 Freeze 前完成嗎？」
  RD 在 Issue Comment 記錄評估（非只在 Slack）

Step 3：RM + PO 確認掉車（保守模式，前兩次執行）
  Sherridy 在 Issue Comment 記錄：
  「決定：FOR-XXX 掉車，移至 v5.x+1.x
   原因：RD 評估 Feature Freeze 前無法完成
   決定時間：[日期]
   批准：Sherridy」
  David 在 Linear 執行操作：將 Issue 移出當前 Project，加入下一個 Project
  為 Issue 加上 [Dropped] Label（通用 Label，不建版本特定 Label）
  在 Issue Comment 補充：「掉車自 v5.x.x，預計列入 v5.x+1.x」

Step 4：文件化公告
  Sherridy 在 <span class="tag">forest-release</span> 發布公告（心理安全宣言格式）：
  「[功能名稱] 這次掉車，不是因為 RD 表現不好。
   功能掉車是列車準時的代價，而準時的列車讓用戶信任我們。
   [功能名稱] 已排入下一班（v5.x+1.x），不是被取消。
   感謝 [RD 姓名] 誠實地評估了完成時間。」

Step 5：回顧（掉車後 1 週）
  在週會討論：
  - 掉車決定是否及時？
  - 被掉車功能在下一班進展如何？
  - 去污名化 Workshop 的效果如何？有什麼需要調整？

Dropped Label 設計說明（V2 修正）：

完成條件：至少 1 個 Issue 走完完整的 5 步驟，所有步驟均有 Linear 記錄

期限：Month 2 Week 2-3（隨 Feature Freeze 執行自然發生）

M2-05：String Freeze 完整執行

負責人：Sherridy（決策）+ MKT（翻譯確認）

背景：Month 1 Week 4 的 String Freeze 是試水（讓大家知道機制存在），Month 2 的 String Freeze 是完整執行（MKT 翻譯工作已依 String Freeze 日期計劃）。

完成條件：

期限：Month 2 Week 2-3（配合版本 Cycle）

M2-06：Testing Notes 填寫率追蹤啟動

負責人：David（每週追蹤）+ Sherridy / Shawn（填寫責任）

完成條件：

三方確認機制說明（V2 更名）：

目標：Month 2 結束時，新建 Issue 的 Testing Notes 填寫率 > 80%

期限：Month 2 Week 1 開始，全月持續

Month 2 成功指標

指標目標值驗收方式
去污名化 Workshop 完成1 次會議記錄 + 全員 Slack 回覆
QA 批次視窗機制啟動完成Linear 視圖設定 + QA 確認使用
Feature Freeze 第一次成功設定與執行1 次Linear Milestone + Slack 公告記錄
掉車 SOP 首次完整走完至少 1 個 Issue5 步驟均有 Linear 記錄
String Freeze 完整執行1 次MKT 確認 + 無未申請 Exception
Testing Notes 填寫率> 80%（新建 Issue）每週追蹤數據
RD 使用 Linear 追蹤開發中 Issue 比例> 80%Linear 活躍用戶統計
PR Template 含 Testing Notes 確認欄位已建立Ezou 確認

Month 2 末文化里程碑

Month 3：指標達標 + Hotfix SOP 正式運作

月度目標

  1. Hotfix SOP 正式培訓（Week 1）：讓全員知道緊急通道如何運作
  2. QA（Fei Chen / Jimmy）和 Shawn 全面接入 Linear
  3. 第一次完整「列車準時發車」（含功能掉車 + 版本準時提交）
  4. 掉車自動化（第 3 次起不需 RM + PO 逐次確認）
  5. DORA 4 個 + 消費者 App 3 個指標首次完整評估
  6. Feature Freeze 提醒升級（評估從 Google Calendar 升級到 n8n 自動化）

任務清單

M3-01：Hotfix SOP 正式培訓（V2 新增，Week 1）

負責人：David（主持）+ Sherridy + Ezou

背景：Hotfix SOP 是 Release Train 文化中的「緊急超車道」。沒有設計好的超車道，每次緊急情況都會變成特例討論，消耗 RM 的信任資本。Month 1 已建立 Hotfix 基礎環境（Label + Channel），Month 3 Week 1 進行正式培訓，讓全員知道觸發條件和各自責任。

Hotfix SOP 完整設計（30 分鐘培訓）：

[Hotfix 觸發條件]
  PO 判定為 P0 Bug（David 或 Ezou，兩人其一即可）

  PO 判定 P0 Bug 的主要參考指標：
  - Crash-free session rate < 99.0%（Firebase Crashlytics）
  - 付費功能（訂閱購買、Forest 幣）出現中斷報告
  - 影響 > 10% 用戶的核心功能失效（例：計時器不啟動、通知完全失效）

[授權人]
  PO（David 或 Ezou，兩人其一即可，不需要兩人都同意，確保緊急時決策速度）

[Hotfix 執行 5 步驟]
  Step 1：Firebase Alert 觸發 → MTTR 計時開始
    → 自動推送到 Slack <span class="tag">release-monitor</span>
    → RM 識別觸發情況，通知 PO

  Step 2：PO 判定並授權 Hotfix
    → PO（David 或 Ezou）確認觸發情況，判定是否為 P0 Bug
    → PO 在 Slack 發出 Hotfix 啟動通知（文字記錄，作為授權依據）
    → RM 接收通知，開始協調後續執行流程

  Step 2b：建立 Hotfix Issue
    → Issue Title：[Hotfix] [問題描述]
    → 加 Label：[Hotfix]（紅色）
    → Priority：Urgent（Automation 自動設定）
    → Assignee：最資深 RD（由 Ezou 指派）
    → 建立獨立 Hotfix Cycle：命名「Hotfix-[版本號]-[日期]」（如 Hotfix-v5.8.1-2026-03-15）

  Step 3：快速修復
    → RD 建立 Hotfix 分支（命名：hotfix/vX.X.X，從 main 切出）
    → 修復完成後，PR 直接合併到 Main Branch（不需等 Feature Freeze）
    → 只需 RD Lead（Ezou）代碼審查，不需要 PO Review

  Step 4：QA 快速回歸測試
    → 目標：2 小時內完成
    → 測試範圍：核心功能（計時器/種樹）+ Hotfix 相關功能
    → 使用 [Priority: Urgent] Label，可在 QA 批次視窗外即時處理

  Step 5：發版
    → RM 決定 Patch Release（如 v5.8.1）或 Minor Release
    → Shawn 送審：
      - Android：Google Play 分級發布（通常 2-4 小時審核）
      - iOS：App Store 審核（通常 24-48 小時；緊急情況可申請 Expedited Review 縮短至數小時）
    → 發版後在 <span class="tag">release-hotfix</span> 公告
    → 在 Hotfix Issue Comment 記錄 MTTR：
      「MTTR：從 Firebase Alert [時間戳] 到 App Store 發版 [時間戳] = [X 小時]」

[Android vs iOS Hotfix 差異]
  Android：Google Play 的分級發布更新，通常 2-4 小時審核
  iOS：App Store 審核通常 24-48 小時
       緊急情況：申請 Expedited Review（在 App Store Connect 送審說明中說明緊急原因）
       短期緩解（未完全 Hotfix 前）：若有 Feature Flag，可使用 Server-side Kill Switch

[Hotfix 文化說明]
  Hotfix 是例外通道，不是常規流程。
  使用頻率過高（月 > 2 次）是需要改善測試流程的信號，而非調整 Hotfix SOP。

完成條件：

期限：Month 3 Week 1

M3-02：全員培訓（Week 1-3 分批執行）

負責人：David（主持）

Week 1：Shawn + Sherridy 深度培訓（含 Hotfix SOP）

培訓內容：
  1. Phased Release 監控操作（Shawn 主要新增責任）
  2. Firebase Crashlytics 查看方式（Shawn）
  3. Hotfix SOP 實際演練（Shawn 作為送審人的角色）
  4. App Store Expedited Review 申請流程（Shawn）
  5. 掉車 SOP 回顧 + 掉車自動化說明（第 3 次起不需確認）
  6. Cycle 回顧指標格式（Sherridy + Shawn 共同確認）

Week 2：QA 培訓（Fei Chen + Jimmy）

培訓內容：
  1. 三方確認機制完整說明（PO + RD + QA 三方，非雙向強制）
  2. QA 批次視窗進階操作（如何處理 Urgent Label 插隊）
  3. Hotfix 快速回歸測試的範圍界定（核心功能 + Hotfix 相關功能）
  4. iOS vs Android 版本確認差異
  5. 回測計數格式：「[回測 N] 問題描述」Comment 格式

Week 3：翻譯 Gate + 發布流程

培訓內容：
  1. Feature Freeze + String Freeze 完整操作說明（兩個截止點的關係）
  2. Phased Release 監控 SOP（全員理解，Shawn 主責）
  3. Firebase Alert → Slack 通知的自動化機制說明
  4. n8n Feature Freeze 提醒升級評估（若技術條件允許）

期限：Month 3 Week 1-3

M3-03：掉車自動化確認（第 3 次起自動執行）

負責人：Sherridy（決策）+ David（記錄）

背景：V2 的精確化設計——「第 3 次掉車起自動執行」取代 V1 模糊的「第 3-5 次後評估」。

確認流程（Month 2 Sprint Review 中執行）：

如果 Month 2 Sprint Review 中決定延長保守期：

期限：Month 3 Week 1（確認 Month 2 Sprint Review 的決定）

M3-04：第一次完整「列車準時發車」

負責人：Sherridy（Feature Freeze 決策）+ Shawn（送審）+ David（協調）

這是 V2 統整版的核心文化里程碑。

成功的 5 個條件：

  1. String Freeze 日期按時執行（沒有因文字調整壓力延後）
  2. Feature Freeze 日期按時執行（沒有因功能壓力推後）
  3. 至少有 1 個 Issue 掉車，且掉車決定在 Freeze 前完成（非臨時決定）
  4. 版本在預定日期提交 App Store / Google Play（沒有延誤超過 3 天）
  5. Crash-free Session Rate 在 Phased Release 7 天期間維持 > 98.5%（沒有觸發 Hotfix）

完成後的公告格式：

「v5.x.x 準時發車！

本次版本功能：[功能列表]
掉車功能：[Issue 編號 + 名稱]（已排入 v5.x+1.x）
String Freeze 執行：[日期] ✅
Feature Freeze 執行：[日期] ✅
提交時間：[日期]（預定時間 ✅）
Crash-free rate（Day 7）：XX%（目標 > 98.5% ✅）

這是 Forest App 第一次真正執行「列車不等人」。
感謝每一位的配合。

下一班列車（v5.x+1.x）的 String Freeze：[日期]
下一班列車的 Feature Freeze：[日期]」

期限：Month 3 Week 3-4（配合版本發布節奏）

M3-05：Feature Freeze 提醒升級評估（n8n 方案）

負責人：David（技術評估）

背景：Month 1-2 使用 Google Calendar 手動提醒（替代方案 B）。Month 3 評估是否升級到 n8n 定時查詢（替代方案 A）。

評估條件：

n8n 方案設計（如選擇升級）：

n8n Cron Job 設定：
  執行頻率：每天 09:00（台北時間）
  查詢：Linear API → 找出 48 小時內即將到來的 Milestone
  判斷：Milestone 名稱包含「Feature Freeze」
  動作：發 Slack 訊息到 <span class="tag">product-release</span>

Slack 訊息格式：
  「📌 Feature Freeze 提前警告（自動通知）
   Project：[版本名]
   Feature Freeze 日期：[日期]（還有 2 天）

   以下 Issue 尚未 Ready for Test：[Issue 清單]

   請 @sherridy 確認：
   ① 這些功能預計在 Freeze 前完成？
   ② 或需要啟動掉車 SOP？」

期限：Month 3 Week 2（評估）；若決定升級，Week 3 完成設定

M3-06：DORA + 消費者 App 7 個指標首次完整評估

負責人：Sherridy（主持）+ David（數據收集）

完成條件：完成以下指標的 M3 實際數值，並與 M1 基線對比：

指標M1 基線M3 目標M3 實際達標？
Lead Time[待測]≤ 4 週
Deployment Frequency[待測]每 2 週一版本
Change Failure Rate[待測]< 15%
MTTR（Firebase Alert 起算）[待測]< 3 天
Crash-free Session Rate[待測]> 98.5%
Testing Notes 填寫率0%> 90%
版本準時發車率[待測]第 1 次成功

期限：Month 3 Week 4

Month 3 成功指標

指標目標值驗收方式
Hotfix SOP 培訓完成全員知道角色和觸發條件培訓記錄
所有角色每週 Linear 登入率> 80%Linear 活躍用戶統計
DORA Lead Time≤ 4 週M3-06 指標評估
DORA Change Failure Rate< 15%M3-06 指標評估
DORA MTTR< 3 天Firebase + Linear 記錄
Crash-free Session Rate> 98.5%Firebase Crashlytics
Testing Notes 填寫率> 90%每週追蹤數據
第一次完整列車準時發車1 次成功M3-04 完成條件
掉車自動化確認（第 3 次起）已確認Sprint Review 記錄

Month 3 末文化里程碑

7 個成功指標追蹤總覽

指標類型開始追蹤Month 2 目標Month 3 目標
Lead TimeDORAM1 基線不惡化≤ 4 週
Deployment FrequencyDORAM1 基線維持節奏每 2 週一版本
Change Failure RateDORAM1 基線不惡化< 15%
MTTR（Firebase Alert 起算）DORAM1 末起建立計算起點< 3 天
Crash-free Session Rate消費者 AppM1 末基線> 98.5%> 98.5%
Testing Notes 填寫率消費者 AppM2 起追蹤> 80%> 90%
版本準時發車率消費者 AppM3 起—第 1 次成功

角色責任矩陣

任務DavidSherridyShawnEzouFei ChenJimmyRD
Linear 環境建置主責審核—協助———
Feature Freeze 決策操作主責意見意見———
String Freeze 決策紀錄主責MKT 協調————
掉車 SOP 執行操作決策意見意見——評估
去污名化 Workshop主持承諾—扮演參與—參與
QA 批次視窗視圖設定例外批准——主責主責了解
Hotfix SOP 執行協調授權送審授權快速回歸—修復
DORA 指標追蹤數據收集主持回顧—————
Firebase 監控設定知情日常監控備援授權———

回退計劃

以下任何一個條件觸發時，啟動回退討論（David + Sherridy 決策）：

觸發條件回退動作
DORA 任一指標惡化 > 20%（對比 M1 基線）停止擴展，召開 30 分鐘緊急診斷會議
Android ALPHA 通知連續失效 > 2 次暫停 Android Automation，回到手動通知，調查 CI/CD 設定
Crash Rate 在 Phased Release 超過 1.5%啟動 Hotfix SOP；若 Hotfix 無法快速完成，考慮暫停 Phased Release
Testing Notes 填寫率連續 2 個 Cycle < 60%召開說明會，評估 PR Template 是否有效
去污名化 Workshop 後仍有嚴重掉車文化阻力暫停強制掉車，回到「軟性 Feature Freeze」（記錄但不強制移除 Issue）
QA 批次視窗造成 Issue 積壓（待測 Queue > 10 個）Sherridy 評估是否增加批次頻率或臨時增加 Urgent 處理

消費者 App 業界參照里程碑

業界參照對應 Forest App 里程碑所在月份
Duolingo：String Freeze 文化String Freeze 試水成功M1 末
Todoist：Feature Freeze 首次執行Feature Freeze 第一次執行M2 W1-2
Duolingo：去污名化設計（掉車不等於失敗）去污名化 WorkshopM2 W1
Headspace：Hotfix SOP 正式化Hotfix SOP 培訓M3 W1
Todoist：批次 QA 窗口QA 批次視窗機制M2 W1
Duolingo：Release Train 完整運作第一次列車準時發車M3 W3-4

相關文件：04-環境建置指南（統整版V2） | 05-團隊導入策略（統整版V2）

linear 路線圖 統整版V2 ReleaseTrain 掉車SOP 測試注意事項 DORA StringFreeze HotfixSOP QA批次視窗