Marty Cagan 於 2010 年發文，深度剖析「大爆炸式發布」的弊端與替代策略。什麼是大爆炸式發布？指團隊耗時數月憋大招，企圖在單一盛大發布會上一炮走紅。這不等同於瀑布式開發，但常為其終極環節；即便 Scrum 團隊也常被迫採用。

大爆炸式發布為何會出問題？

• 幾乎從不順利：時間緊、功能堆疊，管理層不斷加需求，導致非得大改或痛苦砍功能。
• 無調整緩衝：上線後幾乎沒時間依實際數據迭代，預期落空卻無力回天。
• 穩定性風險：一次性大量變更導致系統脆弱，問題只能上線後發現；即便穩定，用戶也會因改動過大產生抗拒。

為何團隊仍選擇大爆炸？

1. 行銷想要震撼效果：誤以為產品未曝光才能配合活動。其實可採增量發布，讓用戶幾乎感知不到變化，大爆炸行銷≠大爆炸發布。
2. 截止日期過於激進：為趕工犧牲測試與發布時間。若真要準時上線，增量式開發部署才是正解。
3. 大公司審查流程強制瀑布化：層層評審將團隊推向瀑布模式。不妨用原型與真實用戶回饋參與評審，評審結束即繼續增量構建、部署、測試。

核心建議

若有人要求大爆炸式發布，請盡可能以增量式設計、構建、測試、發布替代。小步快跑，才能在不確定性中掌握主動權。