對於許多接觸極限程式設計的人來說，似乎 XP 要求軟體設計的死亡。不僅許多設計活動被嘲笑為「大前期設計」，而且 UML、彈性架構，甚至模式等設計技術都被淡化或徹底忽略。事實上，XP 涉及大量的設計，但它以不同於既有軟體流程的方式進行。XP 以允許演化成為可行設計策略的實務，復興了演化設計的概念。它也提供新的挑戰和技能，因為設計師需要學習如何進行簡單的設計、如何使用重構來保持設計的簡潔，以及如何以演化的方式使用模式。

持續整合是一種軟體開發實務，團隊中的每位成員每天至少一次將他們的變更合併到程式碼庫中，與同事的變更合併在一起。每次整合都會透過自動建置（包括測試）進行驗證，以盡快偵測整合錯誤。團隊發現這種方法可以降低交付延遲的風險、減少整合的工作量，並啟用實務，以促進一個健全的程式碼庫，以便快速增強新功能。

重構是一種規範化的技術，用於重新建構現有的程式碼，改變其內部結構，而不改變其外部行為。其核心是一系列小型的行為保留轉換。每個轉換（稱為「重構」）所做的不多，但這些轉換的序列可以產生顯著的重新建構。由於每個重構都很小，因此出錯的可能性較低。每次重構後，系統都會保持完全運作，降低在重新建構期間系統嚴重損壞的機率。

今日許多從事軟體開發的人員都聽過結對程式設計的作法，但它在業界的採用率仍然參差不齊。其接受度不一的原因之一，在於它的好處並非立竿見影，而是較能於中長期發揮效益。而且它也不像「兩個人共用一台電腦」那麼簡單，因此許多人在感到不適應時便很快地放棄了。然而，根據我們的經驗，結對程式設計對於協作團隊合作和高品質軟體至關重要。

六月底，超過一百人齊聚於地中海島嶼薩丁尼亞，參加XP2000會議，討論極限程式設計 (XP) 和其他彈性方法論。

2002 年 5 月底，XP 社群再次齊聚於地中海島嶼薩丁尼亞。在本文中，我將探討 Ken Schwaber、David Parnas、Enrico Zaninotto、Bill Wake 和 Standish Group 的 Jim Johnson 所做的主題演講。他們引導我思考敏捷開發的精髓、數學規範的角色、不可逆性的複雜性、隱喻以及大幅降低軟體成本的最佳方法。

XP 其中一個吸引人的地方，在於它對於要如何執行 XP 給出了相當明確的說明。此外，這套實務做法經過仔細設計，以相互配合。移除任何一項都會造成嚴重的後果。然而，XP 和其他敏捷方法的其中一項原則，在於它們應該是自我適應的：也就是說，你應該在開發專案的過程中改變流程。這個概念要如何與 XP 嚴格的實務做法相符？

2001 年，我前往斯諾伯德參加會議，會中促成了宣言的誕生，吉姆為他正在撰寫的書採訪了我。這本書簡要介紹了我對極限編程的想法，以及幾天後我們稱之為敏捷軟體開發的觀念。

皮爾森為宣傳我們的書 規劃極限編程所做的訪談。我們輕鬆地聊了聊 XP 的背景，以及規劃在 XP 專案中扮演的角色。

肯特·貝克在 1990 年代後期開發 極限編程 時，提出了四項簡單設計規則。我將它們表達如下。

C3 是克萊斯勒綜合補償專案的簡稱，這是克萊斯勒的一個薪資專案，後來以 極限編程 的「發源專案」而聞名。

我曾接觸過各種程式碼擁有權的方案。我將它們分為三大類

以下是關於敏捷方法的常見誤解。它集中在使用者故事的建立方式，以及在開發活動中的流動方式。誤解在於產品負責人（或業務分析師）建立使用者故事，然後將它們放在開發人員面前實作。這個概念是從產品負責人到開發的流程，產品負責人負責決定需要完成「什麼」，而開發人員負責決定「如何」完成。

丹尼爾·特霍斯特-諾斯最近在軟體工匠精神上的部落格文章引發了許多部落格討論（如果您有興趣，我將在下面總結）。其中有很多內容，但他的其中一個主題特別引起我的共鳴，因此有了這篇文章。

極端程式設計（XP）是一種軟體開發方法，主要由Kent Beck開發。XP 是最早的敏捷方法之一，事實上，在 Scrum 在 00 年代初期成為主流之前，XP 是 90 年代後期和 00 年代初期主要的敏捷方法。許多人（包括我自己）認為 XP 是讓敏捷方法受到關注的主要催化劑，並且比 Scrum 更適合作為敏捷開發的入門基礎。

現場客戶是極端程式設計的實務之一，是白皮書中提到的十二項實務之一。它表示客戶應與開發人員坐在開放式工作區中，以便回答問題並與開發團隊互動。事實上，他們是開發團隊的一份子，並認知到團隊的成功與開發人員一樣取決於他們。他們不必放棄原本的工作來執行此項任務，但必須親自到場。

配對程式設計是一種軟體開發實務，讓開發人員以兩人一組的方式工作。所有重要的程式碼都是由兩位程式設計師編寫，通常並排坐在一台螢幕前，通常使用一個鍵盤。當他們新增程式碼時，會一起討論每一步驟。

關於配對程式設計的一些常見迷思。

每個 XP 愛好者都知道 4 個價值觀和 12 個實務，但有多少人知道 15 個原則？我承認，上週 Kent 在JAOO談論這些原則時，我並不知道。在演講後，我問 Kent：「這些原則在白皮書中嗎？」「是的」，他回答說，「巧妙地隱藏在名為『基本原則』的章節中」。

自我測試程式碼是我在 重構 中用來指稱與功能性軟體結合撰寫全面自動化測試的實務。如果執行得當，這會讓你可以呼叫執行測試的單一命令，而且你可以確信這些測試會找出藏在程式碼中的任何錯誤。

在軟體開發中經常會談到單元測試，而且在我撰寫程式碼的整個過程中，這是一個我已經很熟悉的術語。然而，就像大多數軟體開發術語一樣，它的定義非常不明確，而且我看到人們經常會在認為它的定義比實際上更嚴謹時產生混淆。

當人們談論 極限編程 時，他們經常會專注於它的適應性規劃風格或它的演化式設計方法。一個小但正在成長的趨勢特別引起我的興趣，那就是缺陷率極低的極限編程專案數量正在增加，我的意思是每個月少於一個生產錯誤。

速度是一個概念，它有助於通過將廣泛的努力陳述與經過的時間聯繫起來來校準計劃。速度是團隊（或個人，如果是個人速度）在一段時間內完成多少工作的陳述。您通常應根據 YesterdaysWeather 原則衡量過去幾個週期完成了多少工作來確定速度。一種典型的方法是對過去三個時間段的速度取平均值，以確定未來時間段的速度。速度最初是作為 ExtremeProgramming 的一部分形成的，但此後已廣泛傳播，現在廣泛用於各種 敏捷軟體開發 中。

這是這樣一個原則，它說你今天完成的工作量和你昨天完成的一樣多。在迭代專案中，它表示你應該計劃在此次迭代中完成與上次迭代中一樣多的工作。這個術語來自極限編程社群。