重點摘要#

• 範圍膨脹是專案成功的最大敵人——範圍加倍通常會讓失敗機率增加一個數量級
• 複雜架構的失敗率遠高於簡單架構
• 縮減範圍是架構師提高成功率的最有效策略之一
• 盡早交付最重要的功能，在最需要時獲得回饋

詳細內容#

範圍指的是專案的大小：需要多少時間、精力和資源？功能有多少？品質水準如何？風險多高？這些答案定義了專案的範圍。軟體架構師往往熱衷於大型、複雜的專案挑戰，但擴大範圍就是在與成功為敵。

為什麼範圍越大越危險#

• 影響非線性增長：直覺告訴我們資源加倍就能做兩倍的工作，但歷史告訴我們影響不是線性的。四人團隊的溝通成本遠超兩人團隊的兩倍
• 估算遠非精確科學：誰沒遇過比預期困難許多的功能？

管理範圍的策略#

以下策略可幫助在真實世界的專案中減少或管理範圍：

• 理解真正需求：需求定義功能或功能品質。質疑任何無法用可衡量的客戶價值解釋的需求
• 分而治之：尋找機會將工作拆分成較小的獨立區塊。管理幾個小型獨立專案比管理一個有著互相依賴部分的大型專案容易得多
• 排定優先順序：商業世界變化快速，大型專案的需求在完成前會改變很多次。優先排序能讓你先交付最重要的需求
• 盡早交付結果：很少有人在真正得到東西之前就知道自己要什麼。先做最重要的事能在最需要的時候獲得最重要的回饋

敏捷倡議者勸我們建造「最簡單的可行方案」。縮減專案範圍往往會帶來更簡單的架構，而這正是提高成功機率的最有效策略。

— By Dave Quick