從四項價值出發，我們推導出十來條基本原則來引導這套新風格。往後每當有人提出開發實踐，我們都用這些原則來檢驗它夠不夠格。

為什麼價值還不夠#

〈學開車〉提醒我們：做大量小變更，而且永遠不把視線移開路面。

四項價值——溝通、簡單、回饋、勇氣——給了我們「成功解法」的判準。但價值太模糊，在決定該用哪些實踐時幫不上太多忙。我們得把價值蒸餾成可用的具體原則。

原則幫助我們在方案之間取捨：更完整符合原則的方案，勝過不符合的方案。

每條原則都體現了價值，但比價值具體。價值可能模糊——一個人的「簡單」是另一個人的「複雜」；原則則具體得多：你要嘛有快速回饋，要嘛沒有。

五條根本原則#

快速回饋（Rapid feedback）#

學習心理學告訴我們：行動與其回饋之間的時間，對學習至關重要。 動物實驗顯示，回饋時機上即使微小的差異，也會造成學習成效的巨大差異——刺激與反應之間延遲個幾秒，老鼠就學不會「紅色按鈕代表食物」。

因此其中一條原則就是：取得回饋、詮釋它，並盡可能快速地把學到的東西放回系統中。

• 業務端學到系統能如何做出最大貢獻，並在數天或數週內回饋這份學習，而不是數月或數年
• 程式設計師學到如何最好地設計、實作與測試系統，並在數秒或數分鐘內回饋這份學習，而不是數天、數週或數月

假設簡單（Assume simplicity）#

把每個問題都當作可以用荒謬地簡單的方式解決。你在那 98% 確實如此的問題上省下的時間，會給你荒謬地充裕的資源去對付剩下的 2%。

在許多方面，這是程式設計師最難嚥下的一條原則。傳統上我們被教導要為未來規劃、為重用而設計。XP 反過來說：今天把今天的工作做好（測試、重構、溝通），並相信自己未來有能力在需要的地方加上複雜度。把軟體視為選擇權的經濟學，支持這種做法。

增量式變更（Incremental change）#

一次做完的大變更就是行不通。 任何問題都該用一系列「能產生差異的最小變更」來解決。

增量式變更在 XP 中處處可見：設計一次改一點、計畫一次改一點、團隊一次變一點——連 XP 的導入本身也必須小步進行。

擁抱變化（Embracing change）#

最好的策略，是那個在真正解決你最急迫問題的同時，保留最多選擇權的策略。

品質工作（Quality work）#

沒有人喜歡邋遢地工作，每個人都喜歡把事情做好。

在範圍、成本、時間、品質這四個專案開發變數中，品質其實不是自由變數。它唯一可能的取值是「優秀」與「瘋狂地優秀」——取決於是否人命關天。除此之外，你不會享受你的工作、你不會工作得好，專案也就下水道見了。

十條次要原則#

以下原則不那麼核心，但仍能幫助我們在具體情境下做決定。

教導學習（Teach learning）#

與其講一堆教條式的宣言（「汝必須以 XYZ 的方式測試」），我們會專注於教導「學會你該做多少測試」的策略——設計、重構與其他一切也同理。有些想法我們會肯定地陳述；另一些我們沒那麼有把握的，則會以策略的形式陳述，讓讀者自行學出自己的答案。

小額初始投資（Small initial investment）#

專案太早投入太多資源，是災難的配方。

• 緊縮的預算迫使程式設計師與客戶削減需求與方案；緊預算所產生的專注，鼓勵你把手上每件事都做好
• 但資源也可能緊過頭：如果你連解決一個有趣問題的資源都沒有，那你創造出的系統保證不有趣
• 如果有人替你把範圍、日期、品質、成本全部指定死，那你不太可能航行到成功的終點

不過大多數情況下，每個人都能用比自己覺得舒適更少的資源撐過去。

為贏而打（Play to win）#

差別在於**「為贏而打」與「為不輸而打」**。

作者看到的多數軟體開發，都是為不輸而打：寫一堆文件、開一堆會、每個人都試著「照書」開發——不是因為那樣特別合理，而是因為他們想在最後能說「不是我的錯，我有照流程走」。明哲保身（CYA）。

為贏而打的軟體開發，會做所有幫助團隊獲勝的事，也不做任何無助於獲勝的事。

具體實驗（Concrete experiments）#

每當你做了一個決定卻不去測試它，這個決定就有某種機率是錯的。你做的決定越多，這些風險就複合得越厲害。

因此：

• 一場設計會議的產出，應該是一系列針對會中問題的實驗，而不是一份完成的設計
• 一場需求討論的產出，同樣應該是一系列實驗
• 每一個抽象決策都該被測試

開放、誠實的溝通（Open, honest communication）#

這句話太「政治正確」，作者差點把它刪掉——誰會不想開放誠實地溝通呢？但他拜訪過的每個地方，好像都做不到。

程式設計師必須能夠：

• 說明別人的決定造成了什麼後果：「你在這裡破壞了封裝，把我搞得很慘。」
• 告訴彼此程式碼裡哪裡有問題
• 自由地表達恐懼，並獲得支持
• 自由地、而且及早地向客戶與管理層傳達壞消息，而不受懲罰

如果作者看到有人在回答問題前先環顧四周、看看誰在聽，他會視之為專案陷入深層麻煩的徵兆。

如果要討論的是私人事務，他能理解隱私的需要。但「該用兩個物件模型中的哪一個」，絕不是那種蓋上「最高機密」戳章會有幫助的事。

順著人的直覺，而非逆之（Work with people’s instincts, not against them）#

人喜歡贏、喜歡學習、喜歡與人互動、喜歡成為團隊的一員、喜歡有掌控感、喜歡被信任、喜歡把工作做好、喜歡自己的軟體能運作。

設計一套「追求短期自利同時也服務長期團隊利益」的流程，一直很棘手。

你可以盡情闡述某項實踐長期而言如何符合大家的最佳利益，但壓力一升高，只要那項實踐沒解決一個立即的問題，它就會被丟掉。如果 XP 無法與人們的短期利益共處，它註定被打入方法論的外層黑暗。

有些人特別喜歡 XP 的這一點：它彰顯了程式設計師在無人干預時似乎自然會做的事，只加上剛好夠讓整個流程不脫軌的控制。作者記得有一句評語是：「XP 符合對野生程式設計師的觀察。」

被接受的責任（Accepted responsibility）#

靈長類的支配展示，只能在有限時間內讓人看起來在配合。過程中，一個被命令做事的人會找到一千種方式表達他的挫折，其中多數有損團隊，而許多也有損他自己。

替代方案是：責任是被接受的，不是被給予的。

這不表示你永遠只做自己想做的事。你是團隊的一員；如果團隊做出結論說某項任務必須完成，就會有人選擇去做它，無論那有多討厭。

因地制宜（Local adaptation）#

你必須把本書所讀到的一切，調整成適合你在地的條件——這是把「被接受的責任」套用到你的開發流程上。

採用 XP 不代表由作者決定你要怎麼開發，而是代表由你決定要怎麼開發。作者能告訴你他發現什麼行得通，能指出他所見到的偏離後果。但歸根結底，這是你的流程：你今天必須做出決定，你必須意識到它明天是否還管用，你必須改變與適應。

別抱著「太好了，我終於知道該怎麼開發了」的心情讀這本書。你讀完應該會說：「這些全都要我來決定，還要寫程式？」是的，沒錯——但值得。

輕裝上路（Travel light）#

你不能既扛著大批行李、又指望走得快。我們維護的產出物應該是：

• 少（Few）
• 簡單（Simple）
• 有價值（Valuable）

XP 團隊成為智識上的游牧民族，隨時準備好迅速收起帳篷、跟著獸群移動。這裡的「獸群」可能是一個想往預期外方向發展的設計、一個想轉向的客戶、一位離職的成員、一項突然火熱的技術，或一次商業氣候的轉變。

如同游牧民族，XP 團隊習慣輕裝：除了「持續為客戶產出價值」所必需的東西——測試與程式碼——之外，他們不多帶行李。

誠實的度量（Honest measurement）#

我們對「控制軟體開發」的追求引導我們去度量，這很好；但它也引導我們在儀器根本支撐不了的細緻程度上度量。

如果你根本沒有辦法估算到那種細緻程度，那麼說「這大概要兩週，上下差不多」，好過說「14.176 小時」。

我們也會努力挑選與我們想要的工作方式有相關性的指標。舉例來說，當我們學到更好的寫法而讓程式碼縮小時，「程式碼行數」就是一個毫無用處的度量。