現有流程深度分析（統整版V2）

2026-02-23
統整初稿-v2

現有流程深度分析（統整版V2）

本文件在統整初稿 V1 的 13 節點框架基礎上進行深度升級。每個節點採用統一的五維格式：背後目的（為什麼這個節點存在）→ 演化軌跡（V1/V2/V3 三版如何認識這個節點）→ V2 設計決策（最終採用的設計和理由）→ 技術可行性說明（哪些靠工具，哪些靠人工紀律）→ 執行風險（最容易出錯的地方）。

V2 新增節點 14（Hotfix 緊急超車道），這是三個版本的共同盲點，在 V2 首次完整設計。

業界對標採雙層次：消費者 App（Duolingo / Todoist / Headspace）為主要對標，大型科技公司（Google / Meta / Spotify）為哲學方向參考。

流程全景（V2 版：含 Hotfix 超車道）

Planning（PO + RM 定義功能）
    │   測試注意事項欄位建立（PO 初始填寫）
    │   PR Template 確認欄位（V2 新增，RD 開發中補充）
    │
    ├──────────────────────────────────┐
    ▼                                  ▼
節點 2：RM 決定版本號              節點 3：QA 展測項（草稿）
（加入 Linear Project）            （Planning 後立即開始）
    │                              （參考測試注意事項）
    └────────────┬─────────────────────┘
                 ▼
         節點 4：In Development（RD 開發）
                 │  RD 補充「測試注意事項」（開發中）
                 │  PR Template：Testing Notes 確認欄位（V2 新增）
                 │  ⚠ 各 Issue 完成時間不同，非同步觸發
                 ▼
         節點 5：Test Requested（個別 Issue 觸發，非 Milestone）
                 │  iOS：Comment 標準模板（M1-2 過渡）
                 │  Android：-ALPHA 版本號機制（全自動）
                 │  → 進入 QA 等待池（V2 新增）
                 ▼
         節點 6：Testing（QA 批次視窗集中處理）（V2 升級）
                 │  三方確認機制：PO + RD + QA
                 │
         ┌───────┴───────┐
         ▼               ▼
   節點 7：測試報告    節點 8：Fix Required（V2 命名優化）
   （QA Passed）           │
         │            （RD 修復）
         └───────┬───────┘
                 ▼
    節點 7b：翻譯 Gate（AND Gate）
                 │
                 ▼
         節點 9：Build Requested（V2 命名優化）
                 ▼
         節點 10：Release Scheduled（V2 命名優化）
                 ▼
         節點 11：Release（Phased Rollout）
                 ▼
         節點 12：Rolling → Monitoring（V2 新增）
                 ▼
         節點 13：Released ✅ → Monitoring Complete（V2 新增）

<mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark>====
[緊急通道，獨立於正常流程]
節點 14：Hotfix 緊急超車道（V2 全新節點）
  Firebase Alert → Hotfix Issue → Hotfix Branch → 精簡 Review
  → QA 快速回歸 → Expedited Review → Hotfix Released
  MTTR 計時：Firebase Alert 觸發 → Hotfix Released
<mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark>====

14 個節點深度解析

節點 1：Planning

背後目的

功能開發的正式起點。確保所有下游角色（RD / QA / PD / MKT）在功能開始前拿到足夠的上下文，避免「開始做了才發現沒有設計稿」的情況。Planning 節點也是「測試注意事項」欄位的誕生點——這是貫穿整個流程的核心品質機制。

演化軌跡

V2 設計決策

Issue Template 必填欄位（含 V2 更新）：

## 功能基本資訊
1. 功能名稱
2. 平台（iOS / Android / Server / Web — 代表工程師職能標籤）
3. 負責工程師
4. Figma 設計連結（必填，無則填「TBD + 預計日期」）

## 測試注意事項（Testing Notes）
> 此欄位由 PO 在 Planning 初始填寫，RD 在開發中補充技術邊界。
> QA 在展測項時和 Test Requested 時都需要讀取並確認。

**重點觀測項目**（PO 填寫，Planning 必填）：
- 哪些使用情境需要特別覆蓋？
- 有哪些邊界條件（boundary cases）？
- 哪些裝置或系統版本有特殊行為？

**技術邊界**（RD 在 In Development 補充）：
- （RD 開發中補充）

**平台差異**（RD 在 In Development 補充）：
- iOS：
- Android：

**已知限制**（RD 補充，不需當 Bug 回報的情況）：
- （如有請補充）

## 其他
6. 埋點清單（若有）
7. 多國翻譯需求（Needs Translation：Y / N）

技術可行性說明

Testing Notes 初始填寫是 Issue Template 的結構性設計，Linear 原生支援。填寫品質靠人工紀律，無法工具強制。Automation 5（降級版）在 Issue 進入 In Development 時無條件發 Comment 提醒（不判斷是否已填），確保提醒機制不依賴工具讀取 Description 內容。

執行風險

最高風險：PO 在 Planning 填寫的 Testing Notes 品質不足（填了但是空洞，比沒填更危險）。緩解：每月 RM 抽查 5 個 Issue 的填寫品質，不只看填寫率，更看內容深度。

業界對標

Duolingo 要求功能在 Sprint Planning 前確認 QA 接受標準；Todoist RFC 模型讓 QA 在 Planning 就標記測試風險；Headspace 在 Planning 確認翻譯字串需求（String Freeze 計劃）。

節點 2：RM 決定版本號與列車週期

背後目的

版本列車的控制中樞。RM 統一分配版本號，建立可預測的發布節奏，避免某個版本塞進太多功能，防止 QA 資源過度集中在特定時間點。版本號是所有後續 Automation 和 DORA 計算的基礎欄位。

演化軌跡

V2 設計決策

時序依賴：節點 2（版本號）和節點 3（QA 展測項）並行觸發，不是順序關係。QA 在 Planning 完成後立即開始建草稿，不等版本號確認。

Feature Freeze Milestone 設定：

操作路徑：
  Linear → Project → [版本 Project] → Milestones → 新增 Milestone

填寫內容：
  名稱：Feature Freeze
  日期：[Cycle 結束前 7 天]
  描述：此日期後不再接受新 Issue 加入此版本。
       掉車的 Issue 移至下一個 Project 或 Backlog。

設定時機：
  每個 Cycle 的 Planning 會議結束後立即設定

Feature Freeze 前 48 小時提醒（工具外補充機制）：

Linear 原生 Automation 沒有「距 Milestone 日期 N 天」的 Trigger，這是確認的技術限制。V2 採用以下替代方案（依團隊現有工具選擇）：

Freeze 後加入新 Issue 的三方確認流程：

三方確認流程（缺一不可）：
  確認方 1：RM（Sherridy）— 評估對版本時程的影響
  確認方 2：PO（Shawn）— 確認業務優先級
  確認方 3：受影響 RD — 確認工時與技術可行性

三方均同意後：
  RM 手動將 Issue 加入 Project
  在 Issue Comment 記錄：「Post-Freeze 特例：已獲 RM/PO/RD 三方確認（[日期]）」

技術可行性說明

Feature Freeze Milestone 的建立：Linear 原生支援。Freeze 前 48 小時提醒：Linear 原生不支援，需要 n8n 或 Calendar 外部補充（這是「工具外補充機制」，文件中應明確標注）。

執行風險

最高風險：Feature Freeze 提醒機制未配置，導致 Freeze 到來前沒有任何預警。緩解：Month 1 末確認方案 A 或 B 的配置完成，作為 Month 2 Feature Freeze 啟用的前提條件。

業界對標

Duolingo 有固定 Release Cut Day，不等人；Apple 的審核週期使得行動 App 的版本號是必要約束；Spotify 的 Release Train 讓版本邊界成為整個 Squad 的共識。

節點 3：QA 展測項（兩階段品質閘）

背後目的

測試準備前置化。讓 QA 在功能開發期間就準備好測試項目，避免「功能開發完交過來，QA 才開始想要測什麼」的情況，同時透過 QA 在 Planning 階段閱讀 Issue，提前發現設計問題。

演化軌跡

V2 設計決策

兩階段品質閘（核心設計）：

第一階段：QA 展測項（Planning 後立即）
  輸入：功能描述 + Testing Notes（PO 視角）
  產出：Sub-issue 測項（草稿）

  品質門：Testing Notes 是否有初始填寫？
    → 若空白：在 Issue Comment 留言提醒（不阻塞，繼續建測項）
    → 若有：根據 PO 視角建立測項

第二階段：Test Requested 後再次讀取（測試前）
  輸入：收到 Test Requested 通知後，重新讀取測試注意事項
  目的：RD 在開發中可能已更新此欄位
    → 若有新增內容：補充對應的測項 Sub-issue
    → Android：確認版本號含 -ALPHA
    → 確認完成後才開始執行測試

兩個視角結合的核心價值：

技術可行性說明

展測項本身是 QA 的手動工作，Linear Sub-issues 提供結構，但測項內容需要 QA 自行建立。Automation 6（Test Requested 個別確認 Comment）會在 Issue 進入 Test Requested 時自動提醒 QA 執行第二階段讀取，這部分是 Linear 原生可行的。

執行風險

最高風險：QA 在第一階段建了測項後，第二階段忘記讀取 RD 補充的技術邊界，導致測試遺漏。緩解：Automation 6 的 Comment 提醒，以及 QA 的標準回覆格式（確認已讀取第二階段）。

業界對標

Duolingo QA 在 Sprint 第一天就建立測試計劃；Todoist Developer-owned QA 讓 RD 的技術視角直接影響測試範圍（對應第二階段的 RD 補充）。

節點 4：In Development

背後目的

開發核心節點。確保功能通過兩道 Review 後才能進入測試。同時，這是「Testing Notes 三方確認機制」中 RD 責任最集中的節點——RD 在開發過程中發現的技術邊界，必須補充到 Issue Description 的 Testing Notes 欄位，而不只是留在 PR Description。

演化軌跡

V2 設計決策

Testing Notes 三方確認機制的 RD 環節：

V1 的「雙向強制」設計只覆蓋了 PO（填寫）和 QA（讀取），遺漏了 RD 這個最脆弱的中間環節。V2 的解決方案不是在 Linear Issue 狀態轉移時阻止（Linear 技術上不支援條件式狀態轉換），而是在 PR Review 這個已有流程強制點的節點插入確認：

PR Template 新增欄位（需 Ezou 確認可行性）：

## Testing Notes 確認（RD 填寫）

- [ ] 已確認 Linear Issue 的測試注意事項中「技術邊界」欄位：
  - [ ] Y：已在開發中補充新的技術邊界或邊界條件
  - [ ] N/A：此 PR 無新的技術邊界需要補充

## PR Impact Scope（供 QA 回歸測試判斷）
受影響的模組 / 畫面：
- （請列出，供 QA 判斷是否需要回歸測試已通過的相關功能）

RD 補充 Testing Notes 的典型範例：

技術邊界類：
  - 「API 超時時，UI 應顯示 X 狀態，不是 Loading 狀態」
  - 「第一次啟動 vs 重啟後的行為不同，需分別驗證」
  - 「UserDefaults key 更名了（A → B），舊版升級後有 migration 邏輯」

邊界條件類：
  - 「任務名稱超過 100 字的 truncation 行為」
  - 「網路離線時的 Offline Mode 處理邏輯」

平台差異類（顯性化）：
  iOS：「iOS 16 以下不支援此 API，有 fallback 邏輯」
  Android：「Android 12 以上需要額外的通知權限確認 Dialog」

操作原則：補充到 Issue 欄位（QA 的參考點），不只補充到 PR Description（Reviewer 的參考點）。

Automation 5（降級版）——無條件提醒：

當 Issue 進入 In Development 時，Automation 無條件發 Comment 提醒（不判斷 Description 是否為空，因為 Linear 技術上無法讀取 Description 內容）。

Trigger：Issue 狀態改為 In Development
Action：在 Issue 新增 Comment：
「PO / RD 請確認：此 Issue 的測試注意事項是否已填寫？
 若已填寫請忽略此提醒；
 若尚未填寫，請在 In Development 期間完成補充。
 （此提醒為無條件發送，由 Automation 5 觸發）」

重要說明：V1 和 V3 原始文件中描述的「Description 中 Testing Notes 區塊為空時才觸發」是技術上不可行的設計。V2 修正為無條件觸發，無論是否已填都會發 Comment，由 PO / RD 自行確認後忽略或補充。

技術可行性說明

執行風險

最高風險：RD 在 PR Template 的 Testing Notes 確認欄位勾選「Y」但實際上沒有補充 Linear Issue（形式主義）。緩解：QA 在第二階段讀取時若發現技術邊界欄位仍為空但 PR Template 顯示 Y，在 Issue Comment 記錄差異，RM 每月抽查。

業界對標

Duolingo 工程師在開發中更新 Ticket 的 QA Notes，Bug 率降低 30%；Meta 要求 branch 壽命短、PR 夠小讓 Reviewer 在 30 分鐘內理解。

節點 5：Test Requested（V2 命名優化）

背後目的

正式通知 QA 可以開始測試，提供測試所需的一切資訊：版本號、測試版本連結（TestFlight / APK）、測試報告連結。V2 命名優化：Ready for Test → Test Requested（避免與 Build Requested、Release Scheduled 等「Ready for」命名混淆）。

演化軌跡

V2 設計決策

iOS vs Android 通知可靠性差異（V2 顯性化核心）：

不假裝 iOS 和 Android 的通知機制是一樣的——它們的可靠性從根本上就不同。統整版選擇顯性化這個差異，並為每個平台設計最適合的機制：

面向AndroidiOS
觸發機制CI/CD 自動，-ALPHA 版本號標記RD 手動（M1-2）/ Webhook 評估（M3）
通知可靠性高（工具觸發）中（人工觸發，有忘記風險）
版本確認方式QA 確認版本號含 -ALPHAQA 確認 TestFlight Build 號與通知一致
補償機制版本號標記自動防錯Linear Issue Comment 標準模板（可追溯）

Android 機制（高可靠性，維持現有設計）：

Android Ready for Test 觸發流程：
  1. RD 合併 PR 到 staging/android-* 分支
  2. CI/CD 自動 Build，產生 ALPHA 版本號：
     格式：{版本號}-ALPHA{編號}（例：5.8.0-ALPHA1）
  3. 版本號包含 -ALPHA 的 Build 自動觸發通知給 QA
  4. Linear Issue 狀態自動更新為 Test Requested
  5. QA 確認版本號含 -ALPHA → 確認是正確的測試版本

QA 確認點：
  收到通知但版本號沒有 -ALPHA？
  → 可能是 Automation 設定問題，通知 David 確認

iOS 機制（過渡期設計，依賴人工但有標準化）：

iOS Test Requested 觸發流程（M1-M2）：
  1. iOS RD 合併 PR 到 staging/ios-* 分支
  2. Linear 根據 branchPattern 自動改 Issue 狀態為 Test Requested
  3. RD 在 Linear Issue 新增 Comment（使用固定模板）：

「📱 iOS Test Requested
 TestFlight Build：[Build 號]（若已上傳）
 測試環境：staging
 技術注意事項：[簡述 PR 中的關鍵改動，若有影響測試的部分]
 請確認 Testing Notes 後開始測試
 預計可測試時間：[現在 / 今天下午 / 明天]」

  4. Automation 1 自動發送 Slack 通知到 <span class="tag">forest_ios_testcenter</span>

注意：步驟 3 是 M1-M2 的過渡機制，依賴 RD 習慣。
     iOS RD 在每次合併 PR 後需立即完成此步驟，不可延遲。
     如果忘記，QA 在等待池中無法確認是否有新版本待測。

iOS 短期補償機制的核心邏輯：不是讓 iOS 靠記憶，而是讓記錄有跡可循。Linear Issue Comment 作為標準化記錄點，即使 RD 延遲補充，QA 也知道去哪裡查確認狀態。這比 Slack 手動通知更可追溯。

QA 等待池設計（V2 全新）：

Issues 進入 Test Requested 後，自動出現在 QA 的「待測 Queue」Linear 視圖，進入等待池，在固定批次時間集中處理（詳見節點 6）。

技術可行性說明

執行風險

最高風險：iOS RD 忘記在 Linear Issue 新增 Comment，QA 在等待池中看到 Issue 進入 Test Requested 但不知道是否有可測試的版本。緩解：iOS 的 Automation 1 在 Test Requested 時的 Slack 通知，同時提醒 RD 確認 Comment 已補充。

業界對標

Duolingo 使用 Firebase App Distribution + TestFlight，測試版本有明確 -rc.N 後綴；Todoist 使用 TestFlight（iOS）+ Firebase App Distribution（Android），測試版本有 -beta 後綴。

節點 6：Testing（V2 升級：QA 批次視窗 + 三方確認）

背後目的

核心品質關卡。QA 按照預先準備的測項（Sub-issues）逐一驗證功能行為，依據測試注意事項執行三方確認讀取（PO 初填 + RD 補充 + QA 執行），發現的問題在 Issue Comments 集中記錄。

演化軌跡

V2 設計決策

QA 批次視窗機制（V2 核心新增）：

個別 Issue 觸發（繼承 V1 正確設計）+ 批次視窗處理（V2 新增）的組合：

QA 等待池（Test Requested 後自動）：
  → Issues 進入 Test Requested，出現在「待測 Queue」Linear 視圖
  → Filter：Status = Test Requested，按 Priority 排序
  → Fei Chen 和 Jimmy 看到等待池，按批次時間規劃工作

批次視窗（每週 2 次）：
  → 建議時段：週二下午 + 週四下午
  → 實際時段由 Fei Chen 和 Jimmy 根據工作節奏確認
  → 視窗期間集中處理等待池中的所有 Test Requested Issues

緊急插單例外：
  → RM 在 Linear Issue 加 [Priority: Urgent] 標記
  → [Hotfix] Issue 自動為緊急等級（不等批次視窗）
  → RM 通知 QA（Slack DM），說明緊急原因
  → QA 優先處理，不等下個批次視窗

為什麼設計批次視窗：Fei Chen 和 Jimmy 兩人，每次 context switching 的成本約 15-20 分鐘（從當前工作切換到新的測試，需要重新建立測試上下文）。在單個 Cycle 中可能有 6-10 個 Issues 陸續進入 Test Requested，如果每個都立即觸發，每天可能有 3-5 次不計劃的工作中斷。批次視窗把中斷集中到固定時間，讓 QA 在非視窗期間可以進行不被打斷的深度測試。

Testing Notes 三方確認機制（V2 命名更新）：

從「雙向強制（PO + QA）」更名為「三方確認機制（PO + RD + QA）」，並明確說明依賴關係：

三方確認機制：
  PO（Planning 階段）：填寫 Testing Notes 初始版本（重點觀測項目）
  RD（In Development 階段）：補充技術邊界和平台差異
  QA（Testing 階段）：雙重讀取（展測項時 + Test Requested 時）

重要聲明：
  此機制依賴人工紀律，非工具強制。
  Linear 無法阻止 QA 跳過 Comment 直接改狀態。
  Linear 無法判斷 Description 是否已填寫完整。
  執行保障靠：Automation Comment 提醒 + PR Template 確認欄位 + RM 每週 Review 抽查。

QA Testing 執行流程（V2 版）：

收到等待池通知，批次視窗開始：
  Step 1：確認 build 版本
          → Android：確認版本號含 -ALPHA
          → iOS：確認 TestFlight Build 號與 Comment 模板一致

  Step 2：打開 Issue，重新閱讀測試注意事項（三方確認）
          → PO 初填部分（功能用戶需求視角）
          → RD 補充部分（技術邊界和平台差異）
          → 對比第一階段建立的測項，補充缺少的測試場景

  Step 3：執行 Sub-issue 測項（Fei Chen：E2E；Jimmy：Integration）

  Step 4：在 Testing Notes 相關的 Automation Comment 下方回覆確認：
「✅ 已確認 Testing Notes
 閱讀時間：[日期]
 Testing Notes 版本：PO [日期] 初始版 + RD [日期] 補充版
 發現的額外測試需求：[有/無]
 開始測試時間：[日期]」

  Step 5：發現 Bug 時，在 Issue Comment 記錄（不在 Slack Thread）：
「[Bug] 功能名稱 - 問題描述
 重現步驟：...
 期望行為：...
 實際行為：...
 測試環境：iOS XX / Android XX」

  Step 6：完成後更新 Sub-issue 狀態

回歸測試決策（V2 新增）：

新 ALPHA 版本發出時（有新的合併 PR），QA 需要判斷是否需要對已通過的 Issue 進行回歸測試。判斷依據：RD PR 的 Impact Scope 欄位（PR Template 中的新增欄位）。

回歸測試決策流程：
  新 ALPHA 版本發出
    → QA 查看新 PR 的 Impact Scope 欄位
    → 若 Impact Scope 包含已通過功能的相關模組：進行局部回歸測試
    → 若 Impact Scope 不影響已通過功能：不需要回歸，繼續處理等待池

技術可行性說明

執行風險

最高風險：批次視窗機制初期 RD 不理解「為什麼我的功能 Ready 了但 QA 沒有立刻測」，引發不滿。緩解：Month 2 導入前，RM 向全體 RD 說明批次視窗機制的設計邏輯（保護 QA 認知資源，不是讓 RD 等待更久），並明確說明緊急插單機制。

業界對標

Duolingo 每個 Sprint 有固定的 Regression Suite；Todoist 的「Developer-owned QA」哲學（QA 是品質文化建立者，不是最後守門人）；Headspace 使用批次化測試窗口，避免 QA 頻繁切換上下文。

節點 7：測試報告與翻譯確認

背後目的

以版本為單位正式記錄測試結果，同時確認多國翻譯內容是否正確。翻譯不是真正卡住流程的節點，而是「確認翻譯內容是否正確」的確認步驟；沒有翻譯需求的 Issue 完全不受此步驟影響。翻譯確認是整個流程中最容易被忽略的跨部門依賴點——翻譯工作由 MKT 負責，不在工程師的日常視野中，容易在版本末期才發現翻譯需要確認。

演化軌跡

V2 設計決策

Waiting for Translation 改為 Label 組合的理由：

「Waiting for Translation」State 只對有翻譯需求的功能有意義，在全體 Issue 的狀態選擇器中出現造成視覺噪音。改為 Label 組合更靈活，且降低 State 數量（從 12 降至 11），減少操作選錯的機率。

新的翻譯 Gate 邏輯：

String Freeze 與翻譯 Gate 的關係：

String Freeze（Month 1 末試水）是「翻譯字串截止日期」的正式化：

測試報告工具遷移策略（逐月）：

M1：Bug 追蹤在 Linear
  → Bug 從 Notion 的 Test Issue 資料庫遷移到 Linear Issue Comments
  → 測試報告主體仍在 Notion（QA 熟悉格式，不強制改變）

M2：Bug 記錄在 Linear Comment
  → 正式以 Linear Issue Comment 作為 Bug 討論的主要場所
  → Notion 測試報告繼續存在，Linear 提供 Bug 追蹤的結構化記錄

M3：評估 Notion 遷移
  → 由 David + QA 共同評估測試報告是否從 Notion 遷移至 Linear Project Document
  → 尊重 QA 的工作流偏好，不強制

技術可行性說明

執行風險

最高風險：翻譯 Gate 的跨部門依賴——MKT 不在 Linear 中，沒有主動通知機制（Automation 發 Slack，但 MKT 是否看到）。緩解：Automation 8 的 Slack 通知明確 @MKT 負責人；RM 在每週 Cycle Review 時掃描有 [Needs Translation] Label 但無 [Translation Confirmed] 的 Issue。

業界對標

Duolingo 的 String Freeze——Release Cut Day 前幾天，所有翻譯字串必須凍結；Todoist 使用 Weblate 平台，翻譯工作流完全整合進 CI；Headspace 使用 Phrase 工具，翻譯完成是 Feature Flag 開啟的前置條件。

節點 8：Fix Required（V2 命名優化）

背後目的

明確標記「此功能有問題需要修復」，觸發通知 RD 並進入修復循環。修復後回到 Test Requested，進行回測。V2 命名優化：Ready for Fix → Fix Required（更直接表達當前狀態，而非下一步動作）。

演化軌跡

V2 設計決策

掉車 SOP 去污名化設計（V2 強化重點）：

在 Fix Required 節點，RM 每週三掃描所有 In Development 和 Fix Required 的 Issue，評估哪些有掉車風險。在第一次實際掉車前，必須先進行「掉車預演」：

掉車預演（Month 2，第一次真實掉車前）：
  Step 1：RM 主持角色扮演會議（約 30 分鐘）
  Step 2：以真實的「風險功能」為案例，全員演練掉車對話
  Step 3：明確宣告：「第一次掉車，RM 和 PO 會一起面對，不是 RD 單獨承擔」
  Step 4：在 Linear Cycle Description 預設掉車記錄格式

掉車 SOP 5 步驟（V2 去污名化強化版）：

Step 1：RM 識別風險 Issue（每週三 Cycle 中段）
  → 掃描所有 In Development 或 Fix Required 的 Issue
  → 評估：到 Feature Freeze 還有 N 天，哪些 Issue 明顯來不及？
  → 在 Issue 加 Label：[At Risk]
  → 在 Issue 新增 Comment（語氣重要！）：
「RM 評估：此 Issue 有掉車風險。
 距 Feature Freeze 還有 [N] 天。
 @[RD] 請評估：可以在 Freeze 前完成嗎？
 若無法，我們會一起啟動掉車流程，這不是問題。」

Step 2：RD 評估回覆（等待 24 小時內）
  → 能完成：「預計 [日期] 完成，請繼續安排。」
  → 無法完成：「預計最快 [日期] 才能完成，原因是 [說明]。」

Step 3：確認掉車（RM + PO 共同決定，RD 不需要「批准」）
  若 RD 評估無法在 Freeze 前完成：
    1. 移除 [At Risk] Label，加 [Dropped] Label（通用，不含版本號）
    2. 在 Issue Comment 記錄：
       「掉車決定：此功能移至 [下一個版本]
        決定時間：[日期]
        原因：[說明]
        決策人：RM [姓名] + PO [姓名]」
    3. 把 Issue 從當前版本 Project 移到下一個版本 Project
    4. Issue 狀態改為 Planning（重新進入下一個 Cycle 規劃）

Step 4：版本照常發車（不等掉車的 Issue）
  → 在 <span class="tag">forest-release</span> 發通知：
「📋 版本調整：[功能名] 移至 [下一版本]，[當前版本] 如期發車。
 掉車原因已記錄在 Issue REL-XXX。
 @channel 不影響當前版本的任何其他 Issue。」

Step 5：Retrospective（Cycle 結束後，去污名化格式）
  在 Linear Cycle Description 記錄（公開）：
「本次掉車原因：[說明]
 下一版規劃：[移至哪個版本，預計完成時間]
 學習點：[Planning 估計、技術依賴、需求變更等哪個環節可以改善]」

  Retrospective 固定議程：
  「本次版本的掉車 Issue 列表 + 每個的學習點」
  討論方向：流程問題（為什麼估計不準確？有沒有技術依賴事先沒有識別到？）
  不討論：「[某人] 為什麼做這麼慢」

保守模式退出條件（V2 明確化）：

前 2 次掉車（Month 2）：RM + PO 逐次確認（保守模式）
  → 讓整個團隊習慣流程，且每次都有人工確認學習

第 3 次起（Month 3）：自動掉車，事後通知（Duolingo 模式）
  → RM 執行掉車操作，不需再與 PO 開會確認
  → 在 <span class="tag">forest-release</span> 廣播結果

退出確認時間點：Month 2 Sprint Review
  → David 主持確認：前 2 次掉車執行後，文化是否已接受？
  → 若是：從第 3 次起啟用自動模式
  → 若否：延長保守模式，在 Month 3 Sprint Review 再次確認

Label 系統（V2 修正版）：

[At Risk]        — 有掉車風險，正在評估中
[Dropped]        — 已確認掉車（通用 Label，不含版本號）
                   版本號記錄在 Issue Comment
[Post-Freeze Exception] — Freeze 後特例加入，已三方確認

重要變更：V1 設計的 [Dropped from vX.X.X] 版本特定 Label，長期會累積大量只用一次的 Label，違背 Label 管理的可持續性。V2 改為通用 [Dropped] Label + Issue Comment 記錄（「掉車自 v5.8.0，預計列入 v5.9.0」）。

回測計數機制（V2 優化）：

Label 設定：
  Re-test-1 — 第一次回測
  Re-test-2 — 第二次回測
  Re-test-3 — 第三次回測（此時觸發 Automation）

Automation 12（V2 優化版）觸發邏輯：
  Trigger：Issue 狀態改為 Fix Required + 已有 Re-test-2 Label
  Action：Slack 通知 <span class="tag">forest-release</span>：
「⚠️ 回測警告：{Issue 標題} 即將進行第三次回測
 Issue：{URL}
 @Sherridy @Shawn 請確認是否需要特別介入或調整驗收標準」

QA 回測 Comment 格式：
「[回測 N] 問題描述
 問題狀態：[已修復確認 / 仍有問題 / 新問題]
 測試環境：iOS XX / Android XX」

技術可行性說明

執行風險

最高風險：第一次真實掉車時，RD 的情緒反應。緩解：預演會議（在真實掉車前）；RM 的 Step 1 Comment 語氣設計（「這不是問題」）；Retrospective 聚焦流程而非個人。

業界對標

Spotify Squad 模式明確規定：未完成的功能在 Feature Freeze 當天自動移至下一班，流程自動執行；Duolingo 第一次實施 Feature Freeze 時引發文化衝突，最終嚴格執行的選擇有其代價，Forest App 通過預演降低代價。

節點 9：Build Requested（V2 命名優化）

背後目的

測試通過且翻譯確認後，正式授權 RD 包正式版本（Production Build）。V2 命名優化：Ready for Release Build → Build Requested（一致的動詞命名規範，語意更清晰）。

演化軌跡

V2 設計決策

AND Gate 觸發條件（V2 更新）：

技術可行性說明

Label Gate Automation：Linear 原生支援，Automation 9 的 Trigger 邏輯調整後完全可行。

執行風險

最高風險：Translation Confirmed Label 由誰加？目前設計是 RM 代理 MKT 確認後手動加。若 RM 忘記，功能卡在 QA Passed 無法推進。緩解：Automation 8 的 Slack 通知提醒 MKT，RM 每週掃描有 [Needs Translation] 無 [Translation Confirmed] 的 Issue。

節點 10：Release Scheduled（V2 命名優化）

背後目的

正式版本已包好，等待 Shawn 提交商店審核。V2 命名優化：Ready for Release → Release Scheduled（更精確表達「發布已排程，等待執行」的狀態）。

演化軌跡

V2 設計決策

Linear Automation 在狀態變更為 Release Scheduled 時自動 Slack 通知 Shawn，包含：平台（iOS / Android）、版本號、一鍵跳轉 Linear Project。

備援機制：Shawn 缺席時的替代人（Month 3 前確認），作為文件記錄的必要事項，不可留白。

技術可行性說明

完全可行，Automation Action 為 Slack 通知。

執行風險

Shawn 單點風險。緩解：Month 3 前確認替代人。

節點 11-12：Release / Rolling / Monitoring（V2 新增 Monitoring 狀態）

背後目的

正式提交商店審核，審核通過後進行分階段發布（Phased Release），在全量發布前監控品質指標。V2 新增 Monitoring 狀態，讓 Phased Release 期間的監控期在 Linear 中可見。

演化軌跡

V2 設計決策

Monitoring 狀態設計：

Released（初次）→ Monitoring（Phased Release 期間）→ Monitoring Complete（100% 推送後）

Monitoring 期間：
  Shawn 每日 5 分鐘確認 Firebase Crashlytics Dashboard
  目標指標：Crash-free session rate > 99.5%

  如果 Crash Rate > 0.5%（早期容差）或 > 0.1%（Month 3 後嚴格閾值）：
  → 立即在 <span class="tag">release-monitor</span> 通知 David + Sherridy
  → 在 Linear Project Comment 記錄異常
  → 評估是否啟動 Hotfix 流程（見節點 14）
  → 評估是否暫停 Phased Release

Monitoring Complete 觸發條件：
  iOS：7 天 Phased Release 完成
  Android：100% Rollout 完成（10% → 50% → 100%）

Phased Release 啟用確認：

Month 1 Week 1 清單中加入「確認 iOS App Store Phased Release 和 Android Google Play Staged Rollout 的啟用狀態」，由 Shawn 確認並在 Linear 對應的設定 Issue 中記錄。這是前置確認，不是假設已啟用。

Crash Rate 監控三層設計（V2 新增）：

Layer 1（自動）：Firebase Crashlytics Alert 觸發 Slack <span class="tag">release-monitor</span>
  → Crash-free rate < 99.0%（初期閾值，3 個月後依數據調整）
  → David 和 Sherridy 都在 <span class="tag">release-monitor</span> 接收

Layer 2（人工主責）：Shawn 在 Phased Release 期間每天 5 分鐘確認 Dashboard
  → 主動監控，不等 Alert

Layer 3（人工備援）：Shawn 缺席時，David 授權備援機制啟動
  → Firebase Alert 的 Slack 通知確保 David 也在接收
  → David 主動確認 Crashlytics Dashboard

技術可行性說明

執行風險

最高風險：Firebase Alert 未配置，在發版後沒有自動監控，Crash Rate 升高後無人察覺。緩解：Firebase Alert 設定從 Month 3 前移至 Month 1 末（配置成本低但保護價值高）。

業界對標

Duolingo Phased Release 7 天，崩潰率 > 0.5% 自動暫停；Todoist App Store Phased Release（1% → 2% → 5% → 10% → 20% → 50% → 100%）；Headspace Google Play Staged Rollout（10% → 50% → 100%），有監控期。

節點 13：Released / Monitoring Complete

背後目的

版本全量發布完成，Monitoring Complete。記錄 DORA 指標，觸發版本回顧（Retrospective）。

演化軌跡

V2 設計決策

DORA 指標定義（V2 明確版）：

Lead Time（從功能建立到發布的時間）：
  計算起點：Issue 建立時間（Planning 狀態）
  計算終點：Monitoring Complete（全量發布）
  目標：≤ 4 週

Change Failure Rate：
  定義：Released 後 72 小時內觸發 Hotfix 的版本比例
  目標：< 15%

MTTR（Mean Time To Restore）：
  計算起點：Firebase Alert 觸發時（精確時間戳）
  計算終點：Hotfix 版本 Monitoring Complete
  目標：< 3 天

Deployment Frequency：
  定義：每月 Monitoring Complete 次數（含 Hotfix）
  目標：持平或提升（以品質優先，不以頻率本身為目標）

Release Notes 流程（V2 新增）：

責任人：Shawn（技術摘要）+ PD（Tiffany / Zi，審閱用戶溝通語氣）
時機：Feature Freeze 後確定 Issue 清單，同步開始撰寫
格式：按功能分類（新功能 / Bug 修復 / 改善），語氣對用戶友好
存放：Release Notes 草稿存在對應 Milestone 的 Linear Project Description
Month 3 評估：n8n 自動生成草稿（從 Issue 清單生成 Markdown 模板）

技術可行性說明

執行風險

最高風險：MTTR 計算起點不一致（有人從人工發現計算，有人從 Alert 計算）。緩解：V2 明確裁決 Firebase Alert 時間戳為唯一起點，在所有文件中統一說明。

節點 14：Hotfix 緊急超車道（V2 全新節點）

背後目的

Release Train 的安全閥設計。一個沒有緊急通道的 Release Train 系統，在第一次緊急事故時必然失控。Hotfix SOP 讓緊急情況有序處理，不打斷正常 Cycle 的節奏。

為什麼這是獨立節點而非正常流程的一部分

Hotfix 不是正常 Release 流程的例外處理，而是一條平行的緊急通道：

這些特徵讓 Hotfix 成為正常流程「旁邊」的一條平行道，而非其中一個節點。

演化軌跡

V2 設計決策

觸發條件：PO 判定為 P0 Bug

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

PO 在判斷是否為 P0 Bug 時，主要參考以下指標：

參考指標具體數值 / 定義資料來源
Crash 率異常Crash-free rate < 99.0%（iOS 或 Android）Firebase Crashlytics Alert 自動推送
付費功能中斷訂閱購買、Forest 幣功能出現中斷Slack user-feedback 或 App Store 評論
核心功能失效影響 > 10% 用戶的核心功能失效（例：計時器不啟動、通知完全失效）人工判斷

最終是否啟動 Hotfix，由 PO（David 或 Ezou）判定。RM 負責協調後續執行流程。

Hotfix 執行流程（完整版）：

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 接收通知，在 Linear 建立 Hotfix Issue：
    · Label：[Hotfix]
    · 版本號在 Comment 記錄（如 v5.8.1）
    · 建立獨立 Hotfix Cycle（命名：Hotfix v5.8.1）

Step 3：RD 在 Hotfix 分支修復
  → 分支命名：hotfix/vX.X.X（從 main 切出）
  → 精簡 Review：
    · 不需要 PO Review（跳過功能行為確認）
    · 只需 RD Lead（Ezou）代碼審查（Code Review，確認修復邏輯正確）
    · 審查重點：修復是否完整、是否引入新的問題

Step 4：QA 快速回歸測試
  → 立即插入批次視窗（不等下個批次時間）
  → [Hotfix] Issue 自動為緊急等級，不受批次視窗限制
  → 測試範圍：
    · 修復的 Bug 場景（必測）
    · 相關核心功能的快速回歸（選測，根據 Impact Scope 判斷）
    · 不執行完整 Regression Suite（時間不允許）

Step 5：發版
  iOS：
    → Shawn 在 App Store Connect 送審，選擇 Expedited Review
    → Expedited Review 申請說明填寫緊急原因（Crash Rate / 付費功能中斷）
    → Apple 通常在 24 小時內審核完成
  Android：
    → 緊急發布，同時在 Google Play Console 申請 Fast Track Review
    → Google Play 通常在 24-48 小時內審核完成

  Hotfix Released → MTTR 計時結束
  → 在 Linear Hotfix Issue Comment 記錄：
「MTTR：X 小時 Y 分鐘
 Firebase Alert 時間：[時間]
 Hotfix Released 時間：[時間]」

Step 6：Monitoring（繼續監控，確認 Crash Rate 恢復）
  → 確認 Crash-free rate 恢復到 > 99.0%
  → Shawn 繼續每日 5 分鐘確認 Dashboard

Step 7：Retrospective（下次 Sprint Retrospective）
  → 討論 Hotfix 根因
  → 這個問題在測試流程的哪個環節可以提前發現？
  → 加入對應的測試覆蓋（補充 Testing Notes 或建立新的測試案例）

Android vs iOS Hotfix 流程差異：

面向AndroidiOS
分支機制hotfix/vX.X.X（從 main 切出）同左
審核時間Google Play Fast Track：24-48 小時App Store Expedited Review：約 24 小時
特殊機制可以使用 Google Play 緊急降級（回到上一版）App Store 沒有即時降級功能
Crash 定義Crash-free session rate < 99.0%（Firebase）同左
測試機制-ALPHA 機制驗證 Hotfix 包TestFlight 分發 Hotfix 包

Hotfix 在 Linear 中的設計：

[Hotfix] Label：
  → 在 Label 系統建立（Month 1 Week 1 設定）
  → Hotfix Issue 必須加此 Label

Hotfix Cycle：
  → 獨立建立，命名：Hotfix vX.X.X
  → 不合併進正常版本 Cycle（確保 Hotfix 的追蹤和正常 Release 不混淆）
  → Cycle 結束時間：Hotfix Released 後

MTTR 記錄：
  → 在 Hotfix Issue Comment 記錄（MTTR：X 小時 Y 分鐘）
  → 每次 Hotfix 的 MTTR 記錄作為 DORA Change Failure Rate 計算依據

Retrospective 記錄：
  → 在 Hotfix Cycle Description 記錄根因和學習點

技術可行性說明

執行風險

最高風險：Hotfix 觸發條件被誤用（普通 Bug 走 Hotfix），導致每月 Hotfix 次數過多，降低 Hotfix 的緊急感。緩解：PO 授權判定制度（需要 David 或 Ezou 任一判定為 P0 Bug），RM 定期報告 Hotfix 頻率；月 > 2 次觸發測試流程改善討論。

業界對標

Duolingo：嚴格的 Hotfix 觸發條件（Crash Gate 觸發），App Store Expedited Review + 自動化工具；Todoist：Fastlane Hotfix Lane，工具自動化 Hotfix 分支和打包；Headspace：因為 React Native，使用 CodePush（Forest App 不適用）。

跨節點隱性依賴分析（V2 版）

Planning（PO 三方確認起點）
    │
    │   Testing Notes 建立（PO 初填）
    │        ↓ 兩條並行路徑
    ├──→ RM 版本號 + Feature Freeze 日期（外部工具提醒）
    │        ↓
    └──→ QA 展測項（草稿，立即開始）
              ↓ RM 確認後合併
         正式測試報告
              ↓
         In Development（PR Template：RD 確認欄位）
              │ RD 補充 Testing Notes（技術邊界）
              ↓
         Test Requested（個別 Issue 觸發）
              │ iOS：標準 Comment 模板（過渡）
              │ Android：-ALPHA 自動觸發（高可靠）
              │ → 進入 QA 等待池
              ↓
         Testing（批次視窗集中處理）
              │ 三方確認機制（PO + RD + QA）
              │
         ┌────┴────┐
         ▼         ▼
    QA Passed  Fix Required（回測計數 Re-test-N）
         │
    翻譯 Gate（Label Gate：[Translation Confirmed]）
         │         ↑ MKT 跨部門依賴
         ▼
    Build Requested → Release Scheduled → Monitoring → Monitoring Complete
         │
    Firebase Alert → MTTR 計算起點（也是 PO 判定 P0 Bug 的重要參考指標）

<mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark>====
Hotfix 通道（獨立，非正常流程節點）：
Firebase Alert → Hotfix Issue → hotfix/vX.X.X → QA 快速回歸 → Expedited Review → Hotfix Released
MTTR：Firebase Alert 觸發 → Hotfix Released
<mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark><mark>=</mark>====

重要時序依賴清單（V2 版）：

依賴關係類型說明
Planning → QA 展測項前置（非阻塞）QA 展測項立即開始，不等版本號
RM 版本號 → 草稿合併前置（阻塞）草稿需要版本號才能合併為正式報告
展測項 → Testing兩階段品質閘第一階段建測項，第二階段 Test Requested 後再次讀取
In Development → Test Requested個別觸發每個 Issue 獨立觸發，不等 Project 其他 Issue
Test Requested → TestingQA 等待池 → 批次視窗等待池等待，批次視窗集中處理（緊急例外）
QA Passed + [Translation Confirmed] → Build RequestedAND Gate兩條件同時滿足才進入 Build Requested
Released → MTTR 計算觸發Firebase Alert 觸發為 MTTR 起算點
Firebase Alert → Hotfix（可選）緊急通道滿足觸發條件才啟動，非必然

十一大痛點對照表（V2 版）

排名痛點統整 V1 識別V2 新增/升級解法
1Slack Thread 討論散亂Linear Issue Comments維持，並加強 Bug 記錄格式化
2iOS 手動通知，格式不一過渡期標準格式標準 Comment 模板（不靠 Slack，在 Linear Issue 留記錄）
3翻譯 Gate 無主動提醒Linear Automation + Freeze DateWaiting for Translation 從 State 改為 Label，更靈活
4RM 無「待分配」提醒Feature Freeze SOPFeature Freeze 外部工具提醒（n8n / Calendar）明確配置
5測試報告手動合併逐月遷移策略M3 評估遷移（QA 自行決定）
6修復循環次數無追蹤Re-test Label + AutomationAutomation 12 觸發邏輯優化（狀態 + Label 組合）
7Shawn 送審單點風險替代人 M3 前確認維持，M3 前必須確認
8跨平台流程不一致顯性化設計iOS 標準 Comment 模板明確化
9無 Crash Rate 監控責任Shawn 日常監控三層監控設計（自動 + 主責 + 備援）+ Firebase Alert 前移至 M1 末
10「列車等人」文化Feature Freeze + 掉車 SOP去污名化 Retrospective 格式 + 保守模式明確退出條件
11無 Hotfix SOP（V2 新識別）無完整 Hotfix 緊急超車道設計（節點 14）

必須在新系統中保留的元素（V2 版）

  1. 版本號作為核心屬性：所有功能必須綁定版本號，不可讓每個 RD 自行填寫
  2. RM 集中管理版本分配：Sherridy 是版本節奏的守護者
  3. 測試準備前置（QA 展測項）：Planning 完成即可開始，不等版本號確認
  4. 兩階段品質閘：展測項（Planning 後）+ Testing 前再次讀取測試注意事項
  5. Testing Notes 三方責任：PO 建立 → RD 補充（PR Template 確認）→ QA 雙重讀取
  6. 翻譯 Gate（AND Gate）：Label Gate 取代 State，確保翻譯確認不遺漏
  7. 個別 Issue 觸發 Test Requested：不等 Project Milestone，進入 QA 等待池
  8. QA 批次視窗：保護 QA 認知資源，緊急例外有明確機制
  9. Android ALPHA 版本號機制：版本號識別確保通知正確觸發
  10. Hotfix 緊急超車道：嚴格觸發條件 + 明確授權人 + 精簡流程，Release Train 的安全閥
  11. Crash Rate 監控三層設計：Firebase Alert 自動 → Shawn 主責 → David 備援
  12. DORA 指標自動記錄：MTTR 從 Firebase Alert 起算，確保數字可信

相關文件：00-導入計劃總覽（統整版V2） | 02-Linear功能對應分析（統整版V2）

linear 流程分析 統整版v2 消費者App dora 測試注意事項 ReleaseTrain HotfixSOP QA批次視窗 統整初稿-v2