結論先講
專案追蹤的目的不是抓偷懶的人，是早期偵測問題。當燃盡圖開始走平、Cycle Time 開始變長、WIP 開始堆積，就是該介入的時候——不要等到 Sprint 最後一天才發現做不完。而且不同對象要看不同指標：給老闆看進度和風險，自己團隊看流程效率。
Burndown Chart：最經典但最容易被誤讀
怎麼看
X 軸是 Sprint 天數，Y 軸是剩餘工作量（SP 或 task 數）。理想線是一條從左上到右下的直線。
SP
30 |\
| \ ← 理想線
| \
20 | \ * *
| \ * ← 實際線
| *
10 | *
| *
| * *
0 |________*____
1 2 3 4 5 6 7 8 9 10
Sprint 天數
常見模式及含義
| 模式 | 圖形 | 原因 | 行動 |
|---|---|---|---|
| 理想型 | 實際線貼近理想線 | 估算準確、執行順利 | 保持 |
| 晚期趕工型 | 前半段平坦，後半段急降 | 前期卡住或太晚開工 | 檢查依賴和阻塞 |
| 平坦線 | 中間一段完全水平 | 團隊被其他事佔用或卡住 | 立刻確認阻塞原因 |
| 階梯型 | 大塊大塊往下跳 | Ticket 太大，完成一個就掉一大段 | 把 ticket 拆更小 |
| 反彈型 | 突然往上升 | 中途加了新 ticket | 記錄 scope change |
Burndown 的盲點
Burndown 看不到 scope change。如果 Sprint 開始是 30 SP，中途加了 10 SP 又完成了 10 SP，burndown 還是顯示 30 SP——看起來沒進度，其實做了 10 SP 的事。
這就是為什麼你還需要 Burnup Chart。
Burnup Chart：scope change 的照妖鏡
怎麼看
Burnup Chart 有兩條線：
- 完成線（從 0 往上升）：已完成的工作量
- 範圍線（從初始值開始，可能往上升）：總工作量
SP
50 | ___________ ← 範圍線
| ___/
40 | ___/
| ___/
30 | ___/
| / ___________* ← 完成線
20 | ___/
| ___/
10 |___/
|
0 |________________________
1 2 3 4 5 6 7 8 9 10
為什麼 Burnup 比 Burndown 好
| 場景 | Burndown | Burnup |
|---|---|---|
| 範圍沒變，進度正常 | 看得出來 | 看得出來 |
| 範圍增加，但也完成更多 | 看起來沒進度 | 兩條線都在升，看得出範圍膨脹 |
| 範圍沒變，進度落後 | 看得出來 | 完成線跟範圍線差距越來越大 |
給利害關係人看 Burnup 而不是 Burndown——他們可以清楚看到「是進度慢了」還是「是範圍增加了」。
Cycle Time 和 Lead Time
定義
| 指標 | 起點 | 終點 | 衡量什麼 |
|---|---|---|---|
| Lead Time | 需求提出 | 上線 | 客戶等待的總時間 |
| Cycle Time | 開始開發 | 開發完成 | 團隊的實際工作效率 |
需求提出 ──── 開始開發 ──── 開發完成 ──── 上線
|←─── Lead Time ──────────────────────→|
|←── Cycle Time ──→|
為什麼 Cycle Time 比 Velocity 更有用
Velocity 告訴你「團隊一個 Sprint 做了多少」，但不告訴你「一個 ticket 從開始到結束要多久」。
Cycle Time 能幫你發現：
- 某類型的 ticket 特別慢：例如跨團隊的 ticket cycle time 是內部的 3 倍
- 流程瓶頸：如果 code review 階段平均等 2 天，那就是瓶頸
- 趨勢：cycle time 逐月增長代表流程在退化
怎麼用
追蹤每個 ticket 的 cycle time，算平均值和 P85（85% 的 ticket 在這個時間內完成）。
| 月份 | 平均 Cycle Time | P85 |
|---|---|---|
| 1 月 | 3.2 天 | 5 天 |
| 2 月 | 3.5 天 | 6 天 |
| 3 月 | 4.1 天 | 8 天 |
Cycle time 在惡化——需要找原因。可能是 ticket 變大了、review 變慢了、或是依賴變多了。
Velocity：正確用法 vs 錯誤用法
正確用法
- 用來預測未來 Sprint 能完成多少工作
- 用趨勢來觀察團隊效率的變化
- 用穩定度來評估估算的成熟度
錯誤用法
- 當 KPI 來逼團隊（「為什麼這個 Sprint velocity 降了？」）
- 跨團隊比較（A 團隊 velocity 40、B 團隊 30，不代表 A 比 B 好）
- 當個人績效指標
Velocity 看趨勢，不看單點
| Sprint | Velocity | 解讀 |
|---|---|---|
| 1 | 20 | 新團隊，還在磨合 |
| 2 | 18 | 有人請假 |
| 3 | 24 | 開始穩定 |
| 4 | 25 | |
| 5 | 23 | |
| 6 | 15 | ← 突降！需要調查 |
Sprint 6 突然降到 15，可能原因：有人離職、大量插單、技術問題。Velocity 是溫度計，不是目標。
Cumulative Flow Diagram（CFD）
CFD 是 Kanban 團隊的最佳朋友。
怎麼看
X 軸是時間，Y 軸是 ticket 數量，用堆疊面積圖顯示每個狀態的 ticket 數量。
tickets
50 | ╱╱╱╱╱╱╱╱ Done
| ╱╱╱╱╱╱╱╱
40 | ╱╱╱╱╱╱╱╱ ────── In Review
| ╱╱╱╱╱╱╱╱ ────────
30 |╱╱╱╱╱╱╱╱ ────────── In Progress
|╱╱╱╱╱╱ ────────────
20 |╱╱╱╱ ────────────── To Do
|╱╱ ────────────────
10 |────────────────────
|
0 |________________________
Week 1 Week 2 Week 3 Week 4
CFD 能看出什麼
| 現象 | 代表的意義 |
|---|---|
| 各色帶均勻展開 | 流動順暢 |
| In Progress 帶越來越寬 | WIP 太多，工作卡住了 |
| In Review 帶突然變寬 | Review 變成瓶頸 |
| To Do 帶快速變寬 | 進來的需求比完成的快 |
| Done 帶的斜率變緩 | 交付速度在下降 |
工具比較
| 工具 | Burndown | Burnup | CFD | Cycle Time | 價格（每人/月） | 適合 |
|---|---|---|---|---|---|---|
| Jira | 內建 | 需插件 | 需插件 | 需插件 | $8.15 起 | 大團隊、企業 |
| Linear | 內建 | 內建 | 內建 | 內建 | $8 起 | 工程團隊 |
| GitHub Projects | 需手動 | 無 | 無 | 無 | 免費 | 小專案、開源 |
| Notion | 需手動 | 無 | 無 | 無 | $10 起 | 非工程團隊 |
| Shortcut | 內建 | 內建 | 內建 | 內建 | $8.50 起 | 中型團隊 |
我的建議
- 工程團隊首選 Linear：速度快、鍵盤操作友善、報表內建
- 企業環境用 Jira：不是因為好用，是因為大家都在用
- 預算有限用 GitHub Projects：夠用，但報表要自己做
什麼指標給誰看
給 Leadership 看的
| 指標 | 呈現方式 | 目的 |
|---|---|---|
| 進度 vs 計畫 | Burnup Chart | 知道目前在哪裡 |
| 風險 | 文字列表 + 紅黃綠燈 | 知道要不要擔心 |
| Scope Change | 數量 + 原因 | 理解為什麼延遲 |
| 下個里程碑 | 日期 + 信心度 | 知道能不能答應客戶 |
團隊內部看的
| 指標 | 用途 |
|---|---|
| Velocity 趨勢 | 校準估算 |
| Cycle Time | 找瓶頸 |
| WIP | 確認沒有多工 |
| Burndown | 每日追蹤 Sprint 進度 |
| Bug 數量趨勢 | 品質指標 |
不要給 Leadership 看的
- Velocity 數字：他們會拿來跨團隊比較
- 個人完成的 SP 數：會變成績效工具
- Code review 等待時間：內部改善就好，不要讓老闆介入
專案追蹤 Dashboard 模板
一個好的 Dashboard 一頁就能看完：
┌──────────────────────────────────────┐
│ Sprint 12 | Goal: 完成結帳功能 MVP │
├──────────────────────────────────────┤
│ 進度: 18/24 SP (75%) | 剩餘 4 天 │
│ 狀態: 🟡 有風險 │
├──────────────────────────────────────┤
│ Burnup Chart │
│ [圖表] │
├──────────────────────────────────────┤
│ 風險: │
│ - 金流串接測試環境不穩定 (Medium) │
│ - 設計稿延遲 1 天 (Low) │
├──────────────────────────────────────┤
│ Scope Change: +2 tickets (bug fix) │
│ Blockers: 0 │
└──────────────────────────────────────┘
FAQ
Q1：多久看一次指標？
Burndown 每天看（standup 時掃一眼），Velocity 和 Cycle Time 每個 Sprint 結束時看，CFD 每週看一次。不要太頻繁——每小時看一次 burndown 跟每小時量體重一樣，只會讓你焦慮。
Q2：團隊抗拒被追蹤怎麼辦？
先溝通目的：「追蹤是為了早期發現問題和改善流程，不是為了監控個人表現。」然後用行動證明——不要把指標跟績效掛鉤、不要在公開場合點名個人的數字。如果你真的用指標來打績效，團隊的抗拒是合理的。
Q3：指標造假怎麼辦？
如果團隊開始灌水（ticket 故意估大、簡單的事也開 ticket），代表你把指標當 KPI 了。回到根本：指標是溫度計，不是目標。Goodhart’s Law：當一個指標變成目標，它就不再是好的指標。
Q4：沒有工具只有 spreadsheet，能做追蹤嗎？
可以。一個 Google Sheet 就能做 Burndown 和 Velocity 追蹤。但要有人每天更新。超過 10 人的團隊建議投資一個專用工具，手動更新的摩擦力太大。
Q5：遠端團隊怎麼做專案追蹤？
工具比面對面更重要。確保看板是所有人的「單一事實來源」——ticket 的狀態要即時更新。每天的 standup 可以是非同步的（寫在 Slack），但每週至少有一次同步的 video call 看 Dashboard。