## 建議閱讀路徑

如果你是 CEO ，只有 30 分鐘：

1. 本文件（已完成）
2. 03-三個月導入路線圖（統整版V2）（了解執行時程）
3. 09-業界基準研究總覽（統整版V2）（了解業界對標背景）

如果你要深入理解設計邏輯： → 00-導入計劃總覽（統整版V2） → 01-現有流程深度分析（統整版V2） → 02-Linear功能對應分析（統整版V2）

如果你是執行者（David / Sherridy）： → 04-環境建置指南（統整版V2） → 06-角色視角指南（統整版V2） → 07-功能案例走查（統整版V2）

用途：向 CEO（David）說明 Linear 導入計劃的整體方向、預期成果、執行時程與各文件分工 閱讀時間：約 10 分鐘 完整文件：詳見本頁各文件連結

一句話說明這件事

把 Forest App 的 Issue 追蹤與發布流程從 Notion + Slack 口頭協調，遷移到 Linear， 並在三個月內建立可量測的 Release Train 文化——包含 Feature Freeze、掉車 SOP、Hotfix 緊急超車道，以及 DORA 品質指標追蹤。

為什麼要做這件事？

Forest App 目前的版本管理在實際運作上表現穩定（沒有因等人而延遲發車的情況），但缺乏正式的制度保障：

導入後會達到什麼？

DORA 四項指標目標（Month 3）

消費者 App 特有指標

三個月執行路線圖

Month 1：建立基礎                    Month 2：文化轉變                    Month 3：指標達標
─────────────────────────────────────────────────────────────────────────────────────
Linear 環境建置                      去污名化 Workshop（掉車演練）          Hotfix SOP 正式培訓
Issue Template 建立                  掉車 SOP 首次實際執行                  第一次列車準時發車
Automation 設定（13 條）             QA 批次視窗正式啟動                    Crash Gate 上線
PR Template 更新                     String Freeze → Level 4 升級            DORA 基線 vs 目標對比
Firebase Alert 設定                  DORA 指標首次量測                      掉車自動化（第 3 次起）
Level 3.5：String Freeze 試水
─────────────────────────────────────────────────────────────────────────────────────
成熟度 Level 3 → Level 3.5          Level 3.5 → Level 4                  Level 4 → Level 5（目標）

關鍵里程碑：

• M1 W1：branchPattern 設定並驗收（前置條件，最優先）
• M1 末：String Freeze 首次試水（建立「截止點是死的」文化認知）
• M2 W1：去污名化 Workshop（讓全員在安全環境預演掉車）
• M2 末：第一次真實掉車執行
• M3：Hotfix SOP 培訓 + 第一次列車準時發車（成熟度里程碑）

Release Tracker：Linear 如何運作版本追蹤流程

版本結構：四個層級

Linear 用四個層級組織每一個版本的工作：

Project（版本）
  └── Cycle（列車週期）
        └── Milestone（6 個關鍵節點）
              └── Issue（每個功能 / Bug / 優化）
                    └── Sub-issue（QA 測項）

6 個 Milestone 時間表（以 v5.8.0 為例）：

Day 1  ── Sprint Planning 完成（Issue 分配、Testing Notes 初版）
Day 16 ── Feature Freeze（不接受新 Issue，列車關門）
Day 17 ── First ALPHA 發出（Android，QA 開始測試）
Day 19 ── All QA Passed
Day 21 ── Release Candidate（iOS TestFlight + Android APK 就緒）
Day 23 ── Released（App Store + Google Play 上線）

Issue 的一生：從 Planning 到 Released

每個功能 Issue 流經 11 個 Workflow State，對應發布流程的每個節點：

Planning → Backlog → In Development → Test Requested
    → Testing → Fix Required（有 Bug 回測）
    → QA Passed → Build Requested → Release Scheduled → Released
    → Monitoring Complete

關鍵轉換點說明：

翻譯確認（非 blocking）：Issue 加 [Needs Translation] Label 後進入確認步驟；無此 Label 則直接跳過，進入 Build Requested。

掉車：Feature Freeze 前發現功能無法如期完成，RM 將 Issue 移出版本 Project、加 [Dropped] Label、移入下一版本，並在 #forest-release 發去污名化公告。

RM 如何用 Linear 追蹤版本健康

Sherridy 的每週固定動作：

週三（每週）— 掉車風險掃描（30 分鐘）

打開當前版本 Project → Board View
→ 過濾出 Planning / In Development 的 Issue
→ 評估距 Feature Freeze 天數 vs 開發進度
→ 高風險 Issue（Freeze < 5 天仍在開發中）私訊 RD 確認
→ 掉車決定記錄在 Issue Comment

每個 Cycle 結束後 — DORA 指標回顧（15 分鐘）

7 個追蹤指標：
  ① Lead Time（Planning → Released，目標 ≤ 4 週）
  ② Deployment Frequency（目標每 2 週發版）
  ③ Change Failure Rate（Hotfix 次數 / 總發布，目標 < 15%）
  ④ MTTR（Firebase Alert → Hotfix Released，目標 < 3 天）
  ⑤ Testing Notes 填寫率（目標 > 90%）
  ⑥ 掉車次數 vs 版本延誤次數（掉車健康，延誤不健康）
  ⑦ Crash-free session rate（目標 > 99.0%）
記錄位置：Linear Project Comment

Hotfix：平行緊急通道

Hotfix 不進入正常版本 Cycle，而是開一條獨立的緊急通道：

Firebase Alert 觸發
    ↓
PO（David 或 Ezou）判定為 P0 Bug，授權啟動
    ↓
RM（Sherridy）建立獨立 Hotfix Cycle（命名：Hotfix v5.8.1）
    ↓
RD 快速修復 → QA 2 小時核心回歸測試
    ↓
Shawn 申請 App Store Expedited Review（24-48 小時）
    ↓
Released，MTTR 計時結束（Firebase Alert → 此刻）

Hotfix Cycle 的整個過程都在 Linear 獨立追蹤，MTTR 從 Firebase Alert 時間戳自動起算，不依賴人工發現時間，確保數字客觀可信。

三個核心設計亮點（V2 新增）

1. Hotfix 緊急超車道

解決什麼：緊急 Bug 發生時不再需要臨時討論，有明確的 SOP 可依循。

觸發：PO（David 或 Ezou）判定為 P0 Bug
授權：PO 其一即可，不需要兩人都同意（確保決策速度）
執行：RM 協調 → RD 快速修復 → QA 2 小時回歸測試 → Expedited Review 發版
MTTR 計時：從 Firebase Alert 時間戳起算（客觀、不依賴人工發現）

2. String Freeze 先行（Level 3.5）

解決什麼：直接進入完整 Feature Freeze 文化衝擊太大。String Freeze 是最低情緒阻力的起點。

只影響翻譯字串的修改，不影響功能開發
讓全團隊第一次體驗「截止點是死的」
為 Month 2 的掉車 SOP 演練做好心理準備

3. Testing Notes 三方確認機制

解決什麼：QA 測試依據不一致，測試品質依賴個人判斷。

PO：Planning 時初填功能定義
RD：開發中補充技術邊界（在 PR Template 確認）
QA：展測項時 + Test Requested 時雙重讀取
最脆弱環節：RD（靠 PR Template Checklist 補強，非工具強制）

角色分工一覽

授權設計說明：Hotfix 授權為 PO 職責（David 或 Ezou），RM 負責協調執行，兩者明確分工。P0 Bug 的判定由 PO 一人即可決策，不需要兩人共識，確保緊急情況下的決策速度。

業界對標位置

Duolingo 建立完整 Feature Freeze + Hotfix 文化耗時數年；三個月達到 Level 5 需要全團隊紀律配合，成功的關鍵是文化轉變，而非工具設定。

需要 CEO 關注的三件事

✅ 不需要 CEO 決策（已設計好）

• Linear 環境建置方式
• Automation 規則設定
• QA 批次視窗時段
• Issue Template 欄位設計

🟡 可能需要 CEO 確認（導入過程）

• 第一次掉車：M2 期間 RM 會刻意選影響最小的功能執行掉車演練，建議 David 公開表態支持（去污名化關鍵）
• Hotfix 授權啟動：P0 Bug 判定由 David 或 Ezou 任一即可，請確認此授權機制符合預期
• DORA 指標確認：Lead Time ≤ 4 週、CFR < 15%、MTTR < 3 天，是否為 Team 共識目標

🔴 回退觸發條件（如導入出問題）

以下任一情況發生時，考慮暫停或調整導入計劃：

• DORA 指標連續兩週惡化 > 20%
• Testing Notes 填寫率 M2 末仍 < 50%
• 掉車引發明顯團隊文化衝突且 Workshop 後未改善
• Crash Rate 異常上升（Firebase Alert 連續觸發）

11 份文件索引

文件版本：統整初稿 V2 | 最後更新：2026-02-19 | 撰寫：Linear 導入計劃工作小組