Sprint Planning 的 Checkpoint
好的 Sprint Planning：
- 每個 ticket 有明確的 Acceptance Criteria（AC）——不是「完成登入功能」，而是「用戶可以用 email + 密碼登入；錯誤時顯示明確訊息；連續失敗 5 次鎖定 15 分鐘」
- Story point 不超過歷史 velocity 的 80%（留緩衝）
- 有 dependency 的 ticket 已確認對方 team 的時程
- Tech debt 和 bug 占 20-30%（不能全是新功能）
- 本次 sprint 的 goal 一句話說得出來
不健康的訊號：Sprint 結束時 50% 以上 ticket 被 carry over；每次 planning 都在問「這要幾點」而不是「這要解什麼問題」；ticket 沒有 AC 就開始做。
PR Review 的 Checkpoint
好的 PR：
- PR description 說明「做了什麼」和「為什麼這樣做」，不只是 commit list
- 單一 concern——不要把 refactor 和 feature 混在一起
- 有 test 或說明為什麼不需要
- 大 PR（>400 行）提前溝通或拆分
好的 Reviewer：
- 看「設計是否合理」，不只是 style（style 讓 linter 管）
- 提問而不是指令：「這裡用 X 是因為什麼考量？我在想 Y 會不會更好因為…」
- 分辨 blocker（必改）和 suggestion（可選）——明確標示
- 24 小時內給 review（不是等到有空才想到）
不健康的訊號：PR open 了三天沒人 review；review 只有「LGTM」沒有實質回饋；每個 PR 都有幾十個 style comment 但沒人看設計。
Retrospective 的 Checkpoint
Retro 的目的是「找到可以改的事，然後真的去改」——不是情緒宣洩，也不是例行公事的表演。
有效的 Retro：
- 上次 action item 的 follow-up：做了沒、有沒有效
- 具體的問題陳述：「deploy 流程太慢」→ 「每次 deploy 等 20 分鐘，一天 deploy 10 次，每週浪費 16 小時」
- 每個 action item 有 owner 和 deadline，不是「大家注意一下」
- Facilitator 和 team 分開——team lead 做 facilitator 會讓人不敢說
不健康的訊號：每次 retro 都說同樣的問題但什麼都沒變；action item 到下次 retro 都沒人追；只有正面 feedback，沒有問題被說出來。
On-call Rotation 的 Checkpoint
On-call 不應該是「某幾個人的永久宿命」，也不應該是「半夜每週都被吵」。
好的 On-call 安排：
- 輪值表公開，每人知道自己什麼時候值班
- 每個人上 on-call 前有 shadowing 期（先跟著有經驗的人）
- Alert 有 runbook：每個 alert 連到一份「發生了什麼、要怎麼處理、升級路徑」的文件
- Escalation path 清楚：處理不了的要找誰、找不到的要找誰
- On-call 交接有文件：這週有什麼未解決的問題、什麼事情要特別注意
不健康的訊號：on-call 每週有 5+ 次半夜叫醒；alert 沒有 runbook 要自己 google；一個人連續 on-call 好幾週；page 了但沒有 escalation 機制。
流程的原則
流程要服務工程師，不是控制工程師。 如果一個流程讓人花時間在填表單而不是解問題，這個流程需要被重新審視。
好的流程有三個特徵：清楚的期望（大家知道應該做什麼）、即時的回饋（做了有沒有用立刻知道）、低的維護成本（不需要有人不斷推動）。