XP的十二種方法

XP的十二種方法将其定義為規則，下面我們來簡單地看看到底是哪十二種“極限”方法：



[b]規劃政策(The Planning Game) [/b]

這一方法背後的主要思想是迅速地制定粗略計劃，然後随着事物的不斷清晰來逐漸完善。規劃政策的産物包括：一堆索引卡，每一張都包含一個客戶素材，這些素材驅動項目的疊代；以及對下一兩個發行版的粗略計劃。

[b]結對程式設計(Pair programming)[/b]

就是在開發中兩個程式員一起編寫一個項目的一種技術。兩個程式員工作在同一台機器上，當一個程式員在寫代碼的時候，另一個程式員在一旁觀看，同時認真地審查代碼。寫代碼者從戰術上考慮具體實作，其夥伴則從戰略上考慮整個程式。他們之間頻繁地交換角色，這樣将使得可以更快寫完代碼，并且減少錯誤。



[b]測試(Testing)[/b]

包括單元測試和驗收測試。就是開發人員在編寫代碼之前先寫單元測試代碼，以便告訴開發人員系統在某一點上是否正常“工作”。而客戶在開發人員定義了素材後就寫驗收測試計劃，以告訴團隊系統是否執行使用者希望它執行的操作。

[b]重構(Refractoring)[/b]

重新劃分是實作特性之前和之後的兩個時機，并且在不更改功能性的前提下對代碼加以改進。

[b]簡單設計(Simple Design)[/b]

使用能夠工作的最簡單的設計，然後不斷随着現實的顯現來更改這些設計，而不是一開始就把額外的特性設計給包含進來。

[b]代碼集體所有權(Collective Code Ownership)[/b]

就是項目小組中的任何人都應該有權對代碼進行更改，以求改進整個項目。

[b]持續內建(Continuous Integration)[/b]

XP 團隊在一天中內建了代碼幾次，每次都在所有單元測試對系統運作後執行。經常進行代碼內建可以幫助您避免內建夢魇。

[b]現場客戶(On-site Customer)[/b]

要使功能最理想，XP 小組需要現場有一位客戶來明确素材，并做出重要的企業決策。開發人員是不允許單獨做這些事情的。讓客戶随時在場可以消除開發人員等待決策時出現的瓶頸。

[b]小型釋出（Small Release）[/b]

發行版應該盡可能地小，同時仍然提供足夠的企業價值以證明它們值得。

[b]每周40小時工作制（40-hour Week）[/b]

長時間地持續工作會扼殺工作績效，疲勞的開發人員會犯更多錯誤。XP将按正常的每周40小時工作時間表來進行工作。

[b]編碼規範（Code Standards）[/b]

目标不是建立一個事無巨細的規則清單，而是将能夠確定您的代碼可以清晰進行交流。

[b]系統隐喻（System Metaphor）[/b]

比喻為團隊提供了一緻的畫面，他們可以用它來描述現有系統的工作方式、新部件适合的位置，以及它們應該采取的形式。它與大多數軟體開發方法中被稱為體系結構的差不多。