交接是指需求離開 BA 負責人並進入 UX、Dev 和 QA 手中的時刻。如果交接不明確，衝刺將付出以下代價：
- Dev根據自己的理解建構。
- QA 編寫缺乏業務規則的測試案例。
- 漂亮的使用者體驗流程設計，但政策錯誤。
- 利害關係人拒絕 UAT，因為「這不是正確的想法」。
一次好的交接不是一次閱讀。良好的切換是結構化的對齊。
1. 切換什麼時候發生？
在敏捷中，交接通常發生在細化時或衝刺計畫之前。在計畫驅動的專案中，交接發生在 SRS 設定基準之後。
在以下情況下您需要切換：
——故事即將進入衝刺。
- SRS部分已經完全成熟。
- 使用者體驗設計開始。
- QA 開始編寫測試案例。
- 有重大需求變動。
- 具有重要的整合或 NFR。
2. 誰該參加？
最低：
- 文學士
- 產品所有者或企業主
- 開發人員/技術主管
- 品質保證
需要時：
- 使用者體驗設計師
- 建築師
- 資料工程師
- 安全/合規性
- 營運/支持
如非必要，請勿擁擠。但不缺決策者。
3. 移交清單
交接前，BA 準備：
- 問題與商業價值。
- 範圍與範圍外。
- 使用者故事或 SRS 部分。
- 驗收標準。
- 業務規則。
- 線框或流程（如果有 UI）。
- API/資料影響。
- 相關 NFR。
- 邊緣情況。
- 依賴關係。
- 開放式問題。
- 簽名或決定關閉。
如果缺少太多物品，您不應該交出。讓我們回到發現/改進。
4. 三個朋友的議程 45 分鐘
三個好友通常是 BA、Dev 和 QA，一起審查故事。如果需要，可以新增 PO/UX。
0-5 phút: BA nhắc lại business value và scope
5-15 phút: Review flow chính và acceptance criteria
15-25 phút: Dev hỏi về API/data/NFR/dependency
25-35 phút: QA chuyển AC thành test scenarios, hỏi edge cases
35-40 phút: Chốt open questions, owner, deadline
40-45 phút: Quyết định story Ready hay chưa
會話結束時的輸出：
- 故事準備好/未準備好。
- 未決問題清單。
- 測試草稿場景。
- 更新需要在SRS/story完成。
5. 將AC轉換為測試場景的範例
故事：
作為客戶，我想重新安排我的預約，以便在我的計劃發生變化時可以選擇另一個可用時間。
交流電：
Given khách có lịch hẹn ở trạng thái Confirmed
When khách chọn đổi lịch sang slot còn trống trước giờ hẹn ít nhất 4 tiếng
Then hệ thống cập nhật lịch hẹn sang slot mới
And gửi email xác nhận lịch mới
測試場景：
| 身分證 | 場景 | 預計 |
|---|---|---|
| TC-001 | 提前 4 小時更改至可用時段 | 成功，郵件已發送 |
| TC-002 | 更改為已預訂的時段 | 錯誤訊息：插槽不再可用 |
| TC-003 | 還剩不到 4 小時時重新排程 | 不允許更改、顯示策略 |
| TC-004 | 電子郵件服務錯誤 | 行事曆仍在更新，電子郵件重試/日誌 |
| TC-005 | 使用者不是日曆的擁有者 | 403 或未經授權的訊息 |
這就是 BA 不僅幫助 QA 測試快樂之路的方式。
6.開放問題日誌
並非所有問題都會立即解決。但懸而未決的問題是必須有一個所有者。
模板：
| 身分證 | 問題 | 影響 | 業主 | 到期 | 狀態 |
|---|---|---|---|---|---|
| OQ-01 | 白天的行程可以更改嗎？ | 業務規則、UI、AC | 客戶服務主管 | 2026-05-12 | 開啟 |
| OQ-02 | 失敗的電子郵件會阻止預訂嗎？ | 錯誤處理 | 技術主管 | 2026-05-12 | 開啟 |
規則：如果懸而未決的問題是一個障礙，故事就無法進入衝刺。
7. UX 交接
使用者體驗需求：
- 主要角色。
- 使用者的目標。
- 主要流程。
- 錯誤/空/載入狀態。
- 業務規則影響使用者介面。
- 需要顯示內容。
- 可訪問性/本地化要求。
BA 不會設計 UI 而取代 UX，但 BA 必須確保 UX 理解業務約束。
8. 開發移交
開發人員需要：
- 功能性行為。
- 資料模型或現場影響。
- API互動。
- 權限模型。
- 錯誤處理。
- NFR。
- 依賴性。
- 功能標誌或推出限制。
BA 不只是說「進行預訂畫面」。 BA需要明確說明「顯示哪個槽位、重疊規則、時區、狀態、審核日誌」。
9. 品質檢查移交
品質檢查需求：
- 驗收標準。
- 業務規則。
- 測試數據。
- 角色/權限矩陣。
- UAT場景。
- 回歸範圍。
- 已知風險。
如果 QA 不理解業務規則，測試通過仍然可能是錯誤的。
10. 完整的切換包範例
功能：客戶重新安排諮詢預約。
| 部分 | 移交內容 |
|---|---|
| 商業價值 | 當客戶需要重新安排時間時減少客戶服務電話，但仍能保護顧問的工作進度。 |
| 範圍 | 客戶可以在預約時間前至少 4 小時在線重新預約。 |
| 超出範圍 | 更改行程少於 4 小時、更換顧問到不同領域、更改小組行程。 |
| 業務規則 | BR-001：只能更改所有者管理員。 BR-002：僅在預約狀態 = 已確認時才變更。 BR-003：僅在預約時間前 >= 4 小時變更。 |
| 使用者體驗筆記 | 如果更改成功，將顯示新的確認碼；如果因斷電而失敗，顯示熱線電話。 |
| API/資料 | PATCH /appointments/{id}/reschedule，請求包括 new_slot_id, reason, idempotency_key。 |
| NFR | 2秒內回應p95；寫入稽核日誌old_slot/new_slot。 |
測試場景矩陣：
| 場景 | 測試資料 | 預期結果 |
|---|---|---|
| 改為 4 小時前可用的時段 | 預約已確認，24 小時後開始 | 狀態仍為已確認，舊插槽重新開放，新插槽已鎖定。 |
| 4小時內兌換 | 預約於 3 小時 30 分開始 | 請勿更改時間表或顯示熱線電話。 |
| 換到剛才放置的插槽 | new_slot_id 不可用 | 不要重新安排，建議另一個時段。 |
| 使用者更改其他人的約會 | Appointment_id 不是使用者的一部分 | 返回403，寫入安全事件。 |
| 因雙擊提交兩次 | 相同的 idempotency_key | 只有一次重新排程。 |
開放式問題：
| 身分證 | 問題 | 業主 | 截止日期 |
|---|---|---|---|
| OQ-001 | 重新安排發送簡訊還是僅發送電子郵件？ | 行銷 | 2026-05-10 |
| OQ-002 | 顧問可以拒絕更改的時間表嗎？ | 營運主管 | 2026-05-10 |
| OQ-003 | 顧客多次換房是否會缺席？ | 銷售經理 | 2026-05-11 |
11. 常見錯誤
錯誤 1：透過發送 Confluence 連結進行切換
連結不會取代對齊。對於重要的需求，有必要使用清單進行即時或非同步審查。
錯誤2：沒有儘早邀請QA
當 QA 遲到時，邊緣情況就會晚發現。邀請 QA 進行細化，以幫助減少缺陷。
錯誤3：不記錄決定
會議很好，但沒有決策日誌，幾天後每個人的記憶都不一樣了。
參考來源
- Scrum 指南 2020： https://scrumguides.org/scrum-guide.html
- IIBA BABOK 指引： https://www.iiba.org/standards-and-resources/babok/
結論
切換不是單向切換。交接是 BA、PO、Dev、QA 和相關角色之間的共同澄清會議。當交接良好時，衝刺提出的問題更少，QA 測試更仔細，UAT 的意外更少，利害關係人更信任 BA。