我們在專案中要控制四個變數——成本、時間、品質、範圍。其中，範圍提供了我們最有價值的控制手段。

控制變數模型#

把軟體開發看成一個控制變數系統，其中有四個變數：

• 成本（Cost）
• 時間（Time）
• 品質（Quality）
• 範圍（Scope）

這個模型中，軟體開發的遊戲規則是：外部力量（客戶、管理者）可以挑其中任意三個變數的值，開發團隊則得到第四個變數的結果值。

有些管理者與客戶相信自己可以決定全部四個變數：「下個月一號以前，就用現在這個團隊，把這些需求全做完。品質是我們的第一要務，所以品質也要維持一貫水準。」

當這種情況發生時，品質永遠先出局（雖然「一貫水準」倒是維持住了），因為沒有人在過大壓力下做得出好活。接著失控的往往是時間。結果是——你拿到又爛又遲的軟體。

解法是讓四個變數可見。如果每個人——程式設計師、客戶、管理者——都看得到全部四個變數，他們就能有意識地選擇要控制哪些。若不喜歡第四個變數被推導出的結果，他們可以改變輸入，或改挑另外三個變數來控制。

變數之間的交互作用#

• 成本——多一點錢可以稍微潤滑輪子，但太早給太多錢，製造的問題比解決的多；而錢給得太少，專案根本無法解決客戶的業務問題。
• 時間——多一點交付時間能提升品質、增加範圍。但由於「來自正式運行系統的回饋」品質遠高於任何其他回饋，給專案太多時間反而會傷害它；給太少時間則品質受損，接著範圍、時間、成本也跟著陪葬。
• 品質——品質作為控制變數糟糕透頂。你可以靠刻意犧牲品質換到極短期（數天或數週）的收益，但代價——人的、業務的、技術的——極其巨大。
• 範圍——縮小範圍能交付更好的品質（只要客戶的業務問題仍被解決），也能讓你交付得更快或更便宜。

四個變數之間沒有簡單的線性關係。例如你不能光靠多花錢就讓軟體更快做好。俗話說：「九個女人生不出一個月大的孩子。」（而且與某些管理者說的相反，十八個女人也一樣不行。）

成本是限制最多的變數#

在許多方面，成本是受限最深的變數。你沒辦法用錢買到品質、範圍或短發布週期。事實上，在專案初期，你根本花不了多少錢——投資必須從小開始，隨時間成長。過一陣子之後，你才能有生產力地花更多錢。

成本上的種種限制會把管理者逼瘋——尤其當他們專注於年度預算流程時。他們太習慣一切從成本驅動，以至於會忽略「成本能給你多少控制力」的限制，因而犯下大錯。

成本的另一個問題是：高成本常常餵養了旁支目標，例如地位或聲望。「我當然有個 150 人的專案（哼哼）。」這會導致專案失敗，只因為管理者想看起來很威風。畢竟，用 10 個程式設計師做同一個專案、還用一半時間交付，有什麼地位可言？

不過從另一面看，成本與其他變數關係深厚。在合理的投資區間內，多花錢可以擴大範圍、可以讓步伐更從容而提升品質、也可以（某種程度上）縮短上市時間。花錢還能減少摩擦——更快的機器、更多技術專家、更好的辦公室。

時間常常不在你手上#

用「控制時間」來控制專案，其限制通常來自外部：年底、季度開始之前、舊系統排定關閉的時點、某個大型展會——這些都是外部時間限制的例子。所以時間變數往往不在專案經理手上，而在客戶手上。

品質是個奇怪的變數#

品質是另一個奇怪的變數。堅持更好的品質，往往能讓專案更早完成，或在同樣時間內做更多事。

作者開始寫單元測試時就是如此：一旦有了測試，他對自己程式碼的信心大增，寫得更快、也沒有壓力；系統更容易整理乾淨，後續開發也就更容易。團隊層級也一樣——一旦開始測試、或一旦對編碼標準達成共識，速度就提上來了。

「暫時犧牲內部品質以縮短上市時間，期望外部品質不會受太大影響」是誘人的短線操作。你常常真的可以搞亂個幾週或幾個月而全身而退。但終究，內部品質問題會追上你，讓你的軟體貴到無法維護，或再也達不到有競爭力的外部品質水準。

品質還有人的效應。每個人都想把工作做好，而且當他們覺得自己做的是好工作時，表現會好得多。如果你刻意降低品質，團隊一開始也許會變快，但「產出垃圾」帶來的士氣崩壞，很快就會壓過你從不測試、不審查、不守標準那裡暫時賺到的一切。

為什麼要聚焦於範圍#

很多人知道成本、品質、時間是控制變數，卻不承認第四個。對軟體開發而言，範圍是最重要、最該意識到的變數。

無論程式設計師或業務人員，對於「開發中的軟體到底哪裡有價值」都只有模糊的概念。專案管理中最有力的決策之一，就是刪掉範圍。 只要你主動管理範圍，就能給管理者與客戶對成本、品質、時間的控制權。

範圍最棒的一點是：它是個變動幅度很大的變數。

數十年來程式設計師一直在抱怨：「客戶說不出他們要什麼。等我們照他們說的做出來，他們又不喜歡。」這是軟體開發的絕對真理——需求一開始從來就不清楚，客戶永遠無法精確告訴你他們要什麼。

一套軟體的開發過程，會改變它自己的需求。 客戶一看到第一版，就學到他們第二版想要什麼……或是他們第一版真正想要的是什麼。而這是有價值的學習，因為它不可能靠臆測產生，只能來自經驗。但客戶無法獨自抵達那裡——他們需要會寫程式的人，不是當嚮導，而是當同伴。

把「軟」當成機會#

如果我們把需求的「軟性」視為機會而非問題呢？那我們就能把範圍看成四個變數中最容易控制的那一個。正因為它軟，我們才能捏塑它——往這邊一點、往那邊一點。發布日逼近而時間吃緊時，永遠有東西可以延到下一版。不試圖做太多，我們才保住了「準時產出所需品質」的能力。

如果我們據此建立一套開發紀律，做法會是：

1. 固定軟體的日期、品質與成本
2. 看看前三個變數隱含的範圍是多少
3. 隨著開發推進，持續調整範圍以匹配我們實際發現的狀況

這必然得是一套輕易容忍變化的流程，因為專案會經常改變方向。你不會想在最後根本沒被使用的軟體上花大錢；你不會想蓋一條因為轉了彎而從沒開上去的路。同時，你也必須有一套流程，能在系統的整個生命週期內把變更成本維持在合理範圍。

別讓客戶被砍到火大#

如果每個發布週期結尾你都砍掉重要功能，客戶很快就會翻臉。為避免這點，XP 用兩個策略：

1. 大量練習估算，並回饋實際結果。 更好的估算降低了你不得不砍功能的機率。
2. 先實作客戶最重要的需求。 這樣即使後面得砍功能，被砍掉的也比系統中已經在跑的那些更不重要。