Shape Up 塑形法 Shape Up
六週一輪、固定時間可變範圍，讓團隊不再被無止盡的 backlog 追著跑。
什麼時候該用它？
當你的團隊陷入「永遠做不完的 Sprint」或「Backlog 越長越沒人想看」的惡性循環時，Shape Up 能讓你重新掌控節奏。
- Sprint 疲勞：兩週一次的 Sprint 變成行政儀式，團隊花更多時間在會議上而非寫 code
- 範圍蔓延失控：一個功能從「加個按鈕」變成「重寫整個模組」，沒人喊停
- 小團隊要做大事：3-6 人的團隊想要有紀律地交付完整功能，而不只是零碎的 ticket
- 探索型產品開發：你知道要解決什麼問題，但不確定解法長什麼樣
- 遠端團隊協作：需要一個能讓大家自主運作、減少同步會議的框架
- 想擺脫估時文化：不想再聽到「這個 Story 到底是 3 點還是 5 點」的爭論
框架結構
Shape Up 的核心哲學是「固定時間、可變範圍」（Fixed Time, Variable Scope）— 跟傳統 Scrum 的「固定範圍、可變時間」完全相反。
三個階段
- Shaping（塑形）：資深成員在幕後把模糊的想法「塑形」成有明確邊界的提案。不是寫 spec，是畫出粗略的解法方向和「不做什麼」的邊界
- Betting（下注）：高層在 betting table 上決定下一個 6 週週期要「賭」哪些提案。選上的就全力做，沒選上的不進 backlog — 直接消失
- Building（建造）：小團隊（1 設計 + 1-2 工程）拿到提案後自主決定怎麼做，6 週內交付
Shaping 的關鍵元素
- Appetite（胃口）：不是「這要多久」，而是「我們願意花多少時間」。Small Batch = 2 週，Big Batch = 6 週
- Fat Marker Sketches：故意用粗筆畫的草圖，避免太早陷入細節
- Breadboarding：用文字流程圖描述互動邏輯，不碰 UI
- No Go Zone：明確標出「這次不做什麼」，比定義要做什麼更重要
Hill Chart（山丘圖）
Shape Up 用山丘圖取代進度百分比。每個工作項目在山丘上有一個點：
- 上坡：還在搞清楚「怎麼做」（探索期）
- 山頂：已經知道怎麼做了
- 下坡：就是執行，沒有未知數
Circuit Breaker（斷路器）
6 週到了沒做完？預設就是砍掉，不延期。這不是懲罰，是設計 — 如果 6 週做不完，代表 shaping 階段沒做好，需要重新塑形。
來源與歷史
- 2003-2018：Basecamp（前身 37signals）內部實踐了十五年的開發方法論，從未正式對外公開
- 2019：Ryan Singer 將方法論整理成免費線上書《Shape Up: Stop Running in Circles and Ship Work that Matters》
- 2020-2021：在中小型 SaaS 和遠端團隊中快速傳播，成為 Scrum 的主要替代方案之一
- 2022-2023：Linear、Basecamp 等工具原生支援 Shape Up 工作流，37signals 持續以此方法開發 HEY 郵件服務
- 2024 至今：越來越多 10-50 人的產品團隊採用混合模式，將 Shape Up 的 shaping 概念融入既有的敏捷流程
真實案例：Basecamp 的 HEY 郵件服務
Basecamp 在 2020 年用 Shape Up 方法開發了 HEY — 一個挑戰 Gmail 的付費郵件服務。團隊約 12 人（4 組小隊），從概念到上線花了不到 2 年。
具體做法：
| 週期 | 下注項目 | 結果 |
|---|---|---|
| Cycle 1-3 | 核心收件匣 + 分類系統 | 6 週內完成 Imbox/Feed/Paper Trail 三分類 |
| Cycle 4 | 「Screener」陌生信過濾 | 原本預計 6 週，實際 4 週完成，團隊用剩餘時間做 polish |
| Cycle 5 | 行動版 App | 砍掉 30% 原定功能（如離線模式），6 週內上架 |
上線首日 30 萬人註冊候補，付費轉換率達 15%。Ryan Singer 事後表示，關鍵不是做得多，而是每個週期都有明確的「不做清單」，讓團隊能專注在最重要的體驗上。
使用步驟
Step 1：設定 Appetite
在動手之前，先問「這個問題值得我們花多少時間？」不是估時，是定預算。Small Batch（2 週）給明確的小改善，Big Batch（6 週）給需要探索的新功能。
Step 2：Shaping 提案
資深 PM 或設計師用 Fat Marker Sketch + Breadboard 把想法塑形。重點不是畫 wireframe，而是定義「解法的邊界」：要解決什麼問題、大致的互動流程、明確的 No Go Zone。
Step 3：Betting Table
每 6 週（或每週期結束後）召開 betting table。參與者通常是 CEO、CTO、資深 PM。每個提案 pitch 5 分鐘，當場決定下注或不下注。沒選上的提案不進 backlog — 如果它夠重要，下次自然會再被提出來。
Step 4：交給小團隊自主執行
被選中的提案交給 1 設計 + 1-2 工程的小團隊。他們自己決定技術方案、拆分任務、安排順序。PM 不寫 ticket，不追進度 — 只看 Hill Chart。
Step 5：6 週結束，Ship 或 Kill
時間到了就結束。完成的上線，沒完成的預設砍掉（circuit breaker）。接著進入 2 週 Cool-down，團隊自由修 bug、探索新想法、或補技術債。
這樣做 vs 避免這些
這樣做
- Shaping 花足夠時間 — 好的 shaping 佔整個週期成功的 80%，別急著把半成品丟給團隊
- 嚴格執行 circuit breaker — 第一次砍掉未完成的項目會很痛，但這是整個系統運作的關鍵
- Cool-down 真的讓團隊休息 — 不是偷塞「小需求」的空間，是讓人喘息和探索的時間
- 讓團隊自己決定怎麼做 — Shaping 定義「什麼」和「邊界」，Building 階段的「怎麼做」交給執行團隊
避免這些
- 不要把 Shape Up 當成「6 週的 Sprint」— 核心差異在於可變範圍和自主權，不只是把 2 週換成 6 週
- 不要在 Building 階段追加需求 — Appetite 是固定的，想加東西就等下個週期
- 不要用 Shape Up 管日常維運 — Bug fix、客訴處理、SLA 承諾不適合放進 6 週週期
- 不要跳過 Shaping 直接下注 — 沒有塑形的提案就是在賭運氣，6 週後大概率失敗
Shape Up 對台灣電商團隊來說，最大的衝擊是「沒有 backlog」這件事。
我待過的電商公司，backlog 都是怪獸 — 業務部的需求、老闆在逛競品時的靈感、客服轉來的抱怨、去年沒做完的技術債，全部堆在一個 Jira board 裡，300 多張票沒人敢刪。Shape Up 說：沒選上的就讓它消失，夠重要自然會回來。這對習慣「什麼都記下來」的團隊是很大的心理突破。
但我要說實話：純粹的 Shape Up 在電商團隊很難 100% 落地。因為電商有太多「非做不可的即時任務」— 大促活動、平台規則變更、金流串接 deadline。這些東西不能等 6 週。我的建議是混合模式：用 Shape Up 管「主動型開發」（新功能、體驗優化），用看板管「反應型任務」（bug、活動、合規）。
Shaping 這個概念倒是可以直接用。電商最常見的災難就是「老闆說加一個促銷功能」，然後工程師理解成要做一整套促銷引擎。如果你在 shaping 階段就畫好邊界 —「這次只做滿額贈，不做組合折扣，不做會員分級」— 兩週就能交付，而不是拖三個月。
Hill Chart 我個人非常推薦導入。比起每天站會問「進度幾%」，看一眼山丘圖就知道哪個任務卡在上坡（還在摸索），哪個已經到下坡（就是收尾了）。特別是對遠端團隊，這比任何 daily standup 都有效。