PCA 架構之旅 03 — 撰寫 User Stories
Persona 告訴你「是誰」，User Story 告訴你「他要做什麼、成功長什麼樣」。這是從人轉到系統功能的橋樑。
很多人把 User Story 當成敏捷開發才有的東西，以為只有 PM 要寫。但在 PCA 架構設計裡，user story 是你後面寫 SLO、拆微服務、設計 API 的依據。少了它，每一步都只能用猜的。
這是 PCA 架構之旅 的第三步。上一篇 02 · User Personas。
為什麼這一步重要
在 PCA case study 題目中怎麼出現
PCA 考題常常這樣描述：「業務希望使用者在 2 秒內看到首頁」「資料分析師每天早上需要前一天的銷售報表」。這些其實就是 user story，只是沒寫成標準格式。考試會要你根據這些敘述挑對的服務跟 SLO 值，看錯就會把 RPO 當成 RTO、把 P50 當成 P99。
考生常見錯誤
- User Story 寫得太技術：「系統要用 Pub/Sub 接收訊息」，這是解法，不是故事。
- 沒有驗收條件（acceptance criteria）：沒寫「成功長怎樣」，後面設計 SLO 就沒得依據。
- 一個 story 包山包海：「使用者可以購物」太大了，要拆成「瀏覽」「加入購物車」「結帳」這幾個獨立故事。
核心概念
一個合格的 User Story 有三個部分：
| 要素 | 說明 | 範例 |
|---|---|---|
| 角色（Role） | 哪個 persona | 身為一般消費者阿元 |
| 目的（Goal） | 要做什麼、為什麼 | 我要能在 2 秒內看到商品列表 |
| 驗收條件（Acceptance Criteria） | 可驗證的條件 | P95 首頁載入 < 2s、空庫存商品仍顯示 |
標準格式：「身為 <角色>，我想要 <目的>，以便 <好處>。」，加上一組 Given/When/Then 驗收條件。
Given/When/Then 是 BDD（Behavior Driven Development）的描述法：給定某個前置狀態、當使用者做某動作、會得到某結果。
思考框架
寫 user story 時問自己：
- 這個故事的成功能用數字量化嗎？ 不能量化的就還不是 user story，只是願望。
- 這個故事會跨幾個服務？ 跨太多代表還沒切乾淨，要先拆。
- 如果這個故事失敗，誰會痛？ 對應回 persona，驗證影響範圍。
- 這個故事是 happy path 還是 edge case？ 兩種都要寫，不然架構會漏掉異常處理。
- 有沒有非功能性故事？ 不只是「我想做什麼」，也包括「我不能等超過 5 秒」「我不想看到 500 錯誤」。
走一遍範例 — 登雲書店
針對每個 persona 寫 2–3 個核心 user story：
消費者阿元
故事 3.1 · 瀏覽暢銷榜
身為一般消費者阿元，我想要在首頁看到即時暢銷榜，以便快速決定要買什麼。
驗收條件：
- Given 我是未登入訪客，When 我打開首頁，Then P95 在 1.5 秒內看到 Top 10。
- 暢銷榜更新延遲不超過 15 分鐘。
- 區域故障時暢銷榜仍可顯示（可接受降級為前一次快照）。
故事 3.2 · 下單結帳
身為一般消費者阿元，我想要用 Apple Pay 一鍵結帳，以便不用每次輸入信用卡。
驗收條件：
- 結帳流程從按鈕到完成不超過 6 秒（P95）。
- 結帳 API 可用性 99.99%。
- 付款失敗時金流不會重複扣款（idempotent）。
- 所有交易紀錄符合 PCI DSS 4.0.1 稽核需求。
電子書訂閱者小葵
故事 3.3 · 同步閱讀進度
身為訂閱者小葵，我想要換裝置時自動跳到上次看到的頁面，以便通勤跟在家看可以順順接著讀。
驗收條件：
- 換裝置後 10 秒內看到最新進度。
- 同一本書在兩台裝置同時閱讀時，以最後一次 sync 為準。
- 離線時可繼續閱讀，重新上線後 30 秒內同步。
書商合作夥伴天下出版
故事 3.4 · 每日批次上傳庫存
身為書商合作夥伴，我想要透過 SFTP 上傳 CSV 並在 email 收到處理結果，以便知道價格是否成功更新。
驗收條件：
- 單筆 CSV 最大 200MB，處理時間 < 30 分鐘。
- 失敗時 email 包含失敗列號與原因。
- 庫存更新對消費者端可見的延遲 < 10 分鐘。
內部營運分析師 Marcus
故事 3.5 · 查詢昨日銷售
身為分析師 Marcus，我想要用 SQL 直接查昨日所有訂單，以便製作每週行銷報表。
驗收條件：
- 資料新鮮度 D+1（前一日 6am 前完成 ETL）。
- 查詢 1 億筆訂單聚合不超過 30 秒。
- 僅能看到去識別化後的會員 ID。
這 5 個故事，後面每個服務的 SLO 跟 API 行為就靠它們定。
常見陷阱
- 把技術方案寫進故事：User Story 是 what，不是 how。「我要用 Memorystore 快取」是 how，不該出現。
- 驗收條件寫得模糊：「要快」「要穩」不是驗收條件，要有具體的百分位數與時間。
- 只寫正向故事：沒寫「付款失敗怎麼辦」「庫存同步失敗怎麼辦」，後面的錯誤處理就會漏設計。
延伸閱讀
- Google Cloud Architecture Framework — Define Reliability Requirements — 官方建議從使用者期望開始定義可靠度。
- SRE Book — Chapter 4 Service Level Objectives — 把 user story 轉成 SLI/SLO 的標準作法。
- Atlassian — User Story Examples — 結構與範例參考。
下一步：user story 有了驗收條件，就能正式定義 SLO 與 SLI，把期望轉成可監控的指標。
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 3 填入你的 case study，邊寫邊內化。