當我們擁有一種風格，能彰顯一組同時服務人性需求與商業需求的一致價值時，我們就成功了。這組價值是：溝通、簡單、回饋、勇氣。

為什麼需要價值#

在把「學開車」的故事化約成一套軟體開發實踐之前，我們需要一些判準，來告訴我們方向對不對。要是先發明出一套開發風格，然後才發現我們不喜歡它、或它根本沒用，那就白搭了。

XP 的四項價值是：溝通（Communication）、簡單（Simplicity）、回饋（Feedback）、勇氣（Courage）。

溝通#

XP 的第一項價值是溝通。專案的問題，幾乎無一例外都能追溯到「某個人沒有就某件重要的事去跟另一個人講」：

• 程式設計師沒告訴別人設計上一項關鍵變更
• 程式設計師沒問客戶對的問題，於是搞砸了一個關鍵的領域決策
• 管理者沒問程式設計師對的問題，於是專案進度被誤報

溝通不良不是碰巧發生的。 有許多情境會導致溝通崩壞：程式設計師向管理者報告壞消息，管理者懲罰了他；客戶告訴程式設計師某件重要的事，程式設計師看起來卻沒理會。

XP 讓正確的溝通持續流動的方式，是採用許多「不溝通就做不了」的實踐——而且是些短期就划算的實踐，例如單元測試、結對程式設計、任務估算。測試、結對、估算的效果，就是逼得程式設計師、客戶與管理者不得不溝通。

這不代表 XP 專案裡溝通就不會阻塞。人會害怕、會犯錯、會分心。因此 XP 設有教練（coach），其職責就是察覺誰沒在溝通，並把他們重新介紹給彼此。

簡單#

XP 的第二項價值是簡單。XP 教練會問團隊：「能動的最簡方案是什麼？」

簡單並不容易。世界上最難的事，就是不去看明天、下週、下個月你會需要實作的東西。但那種強迫性的超前思考，其實是在聽從「指數型變更成本曲線」帶來的恐懼。

有時候教練得溫和地提醒團隊，他們正在聽從自己的恐懼：「也許你比我聰明得多，能把這套複雜的動態平衡樹搞定。而我大概會天真地假設，線性搜尋就夠用了。」

簡單與溝通相互支撐，關係美妙：

• 你溝通得越多，就越清楚看見究竟該做什麼，也越有信心知道什麼其實不必做
• 你的系統越簡單，需要溝通的東西就越少，溝通因此更完整——尤其當你能把系統簡化到只需更少程式設計師時

回饋#

XP 的第三項價值是回饋。教練還有兩句口頭禪：「別問我，問系統。」以及「你替那件事寫測試案例了沒？」

關於系統當前狀態的具體回饋，價值無可估量。樂觀是程式設計的職業病，而回饋是療方。

回饋作用在不同的時間尺度上：

分鐘與日的尺度#

• 程式設計師為系統中所有可能會壞掉的邏輯寫單元測試，因而對系統狀態有分分秒秒的具體回饋
• 客戶寫下新的**故事（story，即功能描述）**時，程式設計師立刻估算，於是客戶對自己故事的品質有了具體回饋
• 追蹤進度的人盯著任務的完成情況，讓整個團隊知道他們是否可能在既定時間內完成原訂的一切

週與月的尺度#

• 客戶與測試人員為系統實作的所有故事（可想成「簡化版使用案例」）撰寫功能測試，因而對系統當前狀態有具體回饋
• 客戶每兩三週檢視一次時程，看團隊的整體速度是否符合計畫，並據以調整計畫
• 系統一旦有意義就投入正式運行，讓業務端能開始「感受」系統實際運作的樣子，並發現如何最好地運用它

為什麼要盡早上線#

規劃流程的策略之一，是團隊盡快把最有價值的故事投入正式運行。這給了程式設計師關於「自己的決策與開發流程品質」的具體回饋——這種回饋在輪胎真正著地之前，永遠不會出現。有些程式設計師從沒和一套正式運行的系統共處過，那他們怎麼可能學會把工作做得更好？

大多數專案的策略恰恰相反。思路似乎是：「系統一旦上線，你就不能再做『有趣的』變更了，所以盡量讓系統留在開發階段。」

這完全搞反了。「開發中」是一種暫時狀態，只佔系統生命的一小部分。遠遠更好的做法是給系統獨立的生命，讓它自己站著、自己呼吸。 你終究得同時支援正式運行與開發新功能——那麼早點習慣這種兩手雜耍，好過晚點才習慣。

回饋與另外兩項價值的協同#

• 回饋越多，溝通越容易。如果有人反對你寫的某段程式碼，並遞給你一個能弄壞它的測試案例，那勝過一千小時關於設計美學的爭論。
• 如果你溝通得清楚，你就會知道該測什麼、量什麼，才能認識系統。
• 簡單的系統更容易測試；而寫測試又給了你一個焦點，去看系統究竟能簡單到什麼程度——測試沒過，你就沒完成；測試全過，你就完成了。

勇氣#

在前三項價值——溝通、簡單、回饋——的脈絡之下，該是全速衝刺的時候了。

如果你不是以絕對的最高速度前進，別人會，而他們會把你的午餐吃掉。

另一種勇氣：把程式碼扔掉#

你知道那種情況嗎——你花了一整天做某件事，進行得不太順，然後機器當掉了；隔天早上你來上班，半小時內就重建出前一天所有的成果，而且這次乾淨又簡單？

善用這一點。

• 如果一天快結束了而程式碼有點失控，扔掉它。如果你喜歡自己設計的介面，也許留下測試案例——也許連測試都不留，就從頭再來。
• 或者你有三個設計方案：那就各花一天寫寫看，感受一下，然後把程式碼扔掉，從最有希望的那個設計重新開始。

勇氣讓你跳出局部最佳解#

XP 的設計策略近似爬山演算法（hill-climbing algorithm）：先做出一個簡單設計，然後讓它複雜一點、再簡單一點、再複雜一點。爬山演算法的問題是會卡在局部最佳解（local optima）——任何小改動都無法改善現況，但一次大改動可以。

那憑什麼保證你不會把自己開發到死角裡？憑勇氣。

每隔一陣子，團隊中就會有人冒出一個瘋狂的想法，可能一舉砍掉整個系統的複雜度。如果他有勇氣，他會試試看；它（有時候）會成功。如果他有勇氣，他會把它推上正式環境——這時你就在爬一座全新的山了。

勇氣必須有前三項價值撐著#

如果前三項價值沒到位，勇氣本身就只是（貶義的）胡搞（hacking）。但與溝通、簡單、具體回饋結合時，勇氣變得極其有價值。

• 溝通支撐勇氣——因為它打開了高風險高報酬實驗的可能：「你不喜歡那個？我也討厭那段程式碼。我們看看一個下午能替換掉多少。」
• 簡單支撐勇氣——面對簡單的系統，你負擔得起更大膽，也遠比較不會在不知情的狀況下弄壞它。
• 勇氣支撐簡單——一看到簡化系統的可能性，你就去試。
• 具體回饋支撐勇氣——如果你能按個按鈕、最後看到測試變綠（或不綠，那就把程式碼扔掉），對程式碼動激烈手術就安全多了。

第五項價值：尊重#

作者曾請 C3 團隊（前面提到的第一個大型 XP 專案）分享他們在專案上最引以為傲的時刻。他原本期待聽到大重構、被測試救回一命，或客戶很開心之類的故事。結果他得到的是：

我最驕傲的時刻，是 Eddie 換到離家較近的工作、免掉每天兩小時的通勤，好讓他能多陪家人的時候。

團隊給了他完全的尊重。沒有人說一句反對他離開的話。每個人都只是問，他們能幫上什麼忙。

這指向一項更深的價值，一項潛藏在其他四項之下的價值——尊重（respect）。

如果團隊成員不在乎彼此、不在乎他們正在做的事，XP 註定失敗。 多數其他的寫軟體（或做任何事）的途徑大概也一樣，但 XP 對此極度敏感。

只要有基本的同理與興趣，XP 或許能為那些相互摩擦的零件提供持續的潤滑。如果團隊成員不在乎這個專案，沒有任何東西救得了它；但只要有最起碼的熱情，XP 就能提供正向回饋。這不是操弄——這只是享受身為某件行得通的事的一部分，而不是身為某件行不通的事的一部分。

不過，這些高尚的談論固然美好，若沒有辦法把它化約為實踐、強化它、讓這些價值成為自然的習慣，那我們擁有的不過是又一次勇敢躍入「方法論善意」的沼澤。接下來，我們需要一份更具體的指南，帶我們走向能滿足並體現這四項價值的實踐。