制定計畫的目的是確定本次迭代的範圍。
本步驟的重心應該放在決定什麼是對客戶來說最重要的任務和如何首先完成這些任務。 計畫的制定包括客戶選擇的專案大小、程式功能的優先順序、各個版本的合成和發布日期。
小版本這一實踐背後的觀點是：用最少的**工作量帶來最大的業務價值。 程式的特性必須有原子性（不可分解）。 乙個特性必須實現足夠的功能來實現它的業務價值。 這個步驟可能是違反直覺的，但這樣做是為了使專案盡快轉化為產品。
發布小版本可以從客戶那兒得到反饋和通過讓客戶確認，這就是他們需要的軟體來降低專案的風險。 基本上，這個步驟使用paredo規則：20%的努力能帶來80%的業務價值。 小版本在計畫的制定下，一版接一版地發布來決定何種特性將帶來巨大的影響， 同時這也配合保持簡單設計這一實踐的實施。
簡單的設計能保證**的簡單。
這個步驟伴隨著小版本的發布。 如果你的系統架構不能夠很好的表達和滿足預期的需要，你將不能夠盡快的交付。
我們是程式設計師，不是占卜者。 我們沒有水晶球，所以**客戶未來的需求最好的方法是給他們乙個可以工作的系統， 並且從他們那兒得到反饋。 大多數客戶不知道如何準確表達他們的需要，你交付一些他們能夠切實可用的東西有助於緩解這種問題。 記住，一幅勝過千言萬語，乙個工作模型抵得上一千幅。
測試是極限程式設計的核心。
測試應該是自動的，這樣你會有信心和勇氣來改變和重構**，同時不破壞系統。 這與瀑布開發模型正好相反。
持續整合是乙個至關重要的概念。
為什麼我們要等到專案的最後才檢查系統的每一部分是否都能正常工作？ 每幾個小時（至少一天一次）系統必須構建和測試一遍。 通過經常這樣做，你將能夠知道何處的改變破壞了系統並作出調整， 從而避免浪費時間一直等到修改已堆積成山並且你自己都忘記了修改的細節。
重構的使用確保程式設計師加入新的功能後**仍保持簡單， 從而保證簡單的**仍然能夠執行所有的測試。
這個實踐的思想是不複製**，也不寫「醜陋」、「發臭」的**。 重構的重心在於測試能夠驗證**仍然具備需要的功能。 測試和重構交替進行。 自動單元級（unit-level）測試給你勇氣來重構和保持**的簡單和表現力。
結對程式設計大概是極限程式設計中最具革命性的實踐—這通常是管理者最花時間來習慣的地方。
在表面上，他們的反應很容易理解：如果我們的專案進度落後了， 那麼怎樣在同乙個任務中使用兩個程式設計師來提高開發速度呢？ 為什麼需要兩個程式設計師使用乙個鍵盤和乙個顯示器呢？
首先，它增加了團隊成員之間的交流。 我們工作的很大一部分需要依靠其他程式設計師的工作。 這個程式設計師今天和你在乙個團隊，不一定明天還有必要和你在乙個團隊。 同樣，如果乙個人知道許多特定的技術（如：ejb或是oralce）或者掌握專業領域的技能， 試問有其他更好的方法比和那個人結對能更好地向對方學習嗎？ 什麼是質量？ 結對程式設計能提供持續的資訊反饋和確保正在程式設計的人進行重構、測試和遵守編碼標準。
**共享這一極限程式設計中的實踐表明任何乙個人都能夠對系統作出修改。
每個程式設計師都擁有系統的所有權和需要對系統負責。 如果沒有人了解某一特定細節，那麼單元測試負責檢驗api和檢查你的改變有沒有破壞系統。 因此，你沒有必要等到團隊中的另乙個成員來修正這個錯誤。 如果不採用**共享，並且在系統中有一些錯誤，那麼每乙個人必須停下來等待直到你將這個錯誤修復。
充分利用時間。
這一規則的隱含意思是統計的時間是處於高效率工作的有效時間和必須從你的工作時間中得到最大的收益。 長時間的仁義應該避免。 任何妨礙在下乙個發布版本中提供最大商業價值的行為都應該被避免。 勞累過度的程式設計師將犯下許多錯誤。
如果有可能，客戶應該與程式設計師直接接觸。
客戶必須闡明需求的功能。 客戶也參與到計畫的制定中，記錄客戶需求時，用程式設計師和客戶都能理解的語言編寫。
記錄客戶需求時，用程式設計師和客戶都能理解的語言編寫。
極限程式設計的實行者應該遵守編碼標準這一實踐。 你必須能夠明白其他程式設計師寫的**。
極限程式設計 XP 12個最佳實踐
現場客戶 on site customer 規範 code standards 每週40小時工作制 40 hour week 系統隱喻 system metaphor 通過隱喻來描述系統如何運作 新的功能以何種方式加入到系統。它通常包含了一些可以參照和比較的類和設計模式。簡單設計 design 測試...
敏捷開發XP極限程式設計的12個最佳實踐
1.計畫遊戲 planning game 1 快速制定計畫 隨著細節的不斷變化而完善 2.小型發布 small release 1 系統的設計要能夠盡可能早地交付 2 詳解 強調在非常短的週期內以遞增的方式發布新版本，從而可以很容易地估計每個迭代週期的進度，便於控制工作量和風險 同時，也可以及時處理...
極限程式設計實踐
摘自 敏捷軟體開發 原則 模式與實踐 robert c.martin 著 鄧輝 譯 極限程式設計實踐 1.完整團隊 xp專案的所有參與者 開發人員 業務分析師 測試人員等等 一起工作在乙個開放的場所中，他們是同乙個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的 顯著的圖表以及其他一些顯示他們進度的東西...