極限程式設計 - 規則
考慮一下你參與的任何一項運動。你需要遵守該運動或遊戲的規則。同樣地，在極限程式設計中，由於整個專案是由團隊成員之間以及與業務方（代表客戶）的協作驅動的，因此需要在專案開始時就制定某些規則。這些規則應該與極限程式設計實踐相一致。
這些規則為團隊中的每個人提供了一個共同的參考，以便提醒每個人在事情順利進行時以及事情進展不順利時需要做什麼以及如何做。
我們在極限程式設計中提到的遊戲是計劃遊戲。
計劃遊戲的規則
在極限程式設計中，計劃遊戲從第一次釋出計劃會議開始，到最終釋出結束。
您必須在第一次釋出計劃會議之前根據極限程式設計實踐定義計劃遊戲的規則，並將規則告知業務方和團隊。您必須管理專案，確保遵守這些規則。
但是，在軟體開發中，不可能有一套簡單的規則適用於每個專案。它們可能需要根據業務和團隊而有所不同，但不能損害極限程式設計實踐。因此，可以首先制定一套具有必要目標的規則，並且只有在需要時才能在開發過程中修改這些規則。
遊戲的目標是最大化團隊生產的軟體價值。從軟體價值中，您必須減去其開發成本和開發過程中產生的風險。
團隊的策略是以儘可能少的投入，儘快將最有價值的功能投入生產，並結合設計和編碼策略來降低風險。
根據第一個工作系統的技術和業務經驗，業務方清楚地瞭解了現在最有價值的功能是什麼，團隊會迅速將其投入生產。
此過程將持續進行迭代和釋出，直到整個開發完成。
計劃遊戲的基本規則可以分為以下幾個方面：
計劃
管理
設計
編碼
測試
計劃
計劃在釋出計劃和迭代計劃期間進行。兩者的規則相同。
在釋出計劃中，
業務方和團隊是參與者。
使用故事卡。
客戶在故事卡上編寫使用者故事。
客戶在故事卡上編寫使用者故事。
業務方決定要實施的功能的優先順序。
團隊根據故事卡給出估算。
計劃進行短期的（頻繁的小型）釋出
釋出計劃需雙方協商制定。
下一個釋出需要劃分為迭代。
每個迭代開始時進行迭代計劃。
在迭代計劃中，
團隊成員是參與者。
使用任務卡。
為每個選定的迭代故事生成任務卡。
團隊成員需要根據任務卡估算任務。
每個團隊成員都被分配了任務卡。
然後，每個團隊成員需要根據其分配情況重新估算，以便於
接受工作。
承擔完成工作的責任。
獲取有關實際花費時間的反饋。
改進估算。
尊重這些估算。
因此，誰可以進行和更改估算的規則是明確的。
最終分配假設每週工作 40 小時並考慮負載係數。
管理
團隊被分配了一個專用的開放式工作區。
每個工作站的佈置應能讓兩位開發人員並排坐，並輕鬆滑動鍵盤和滑鼠。
設定可持續的節奏（每週 40 小時，加班不超過一週）並進行管理。
執行計劃遊戲的規則。
修復任何違反極限程式設計實踐的情況。
確保團隊之間的溝通。
避免以下溝通：
無幫助的
不合時宜的
過於詳細的
讓大家四處走動。
定期衡量實際時間並傳達給團隊，以便每個團隊成員都能瞭解其績效與預測的對比情況。這確保團隊成員在估算方面得到改進。
根據需要為團隊提供食物。
設計
設計的規則是：
為系統選擇一個隱喻，並在開發過程中對其進行演變。
保持設計的簡單性。
不要過早新增功能。
現在只構建滿足您當前需求的架構，並相信以後可以新增更多內容
在任何時候任何地方都可以進行重構。
編碼
編碼的規則是：
業務方（代表客戶）應始終可用。
開發人員應根據強調透過程式碼進行溝通的規則編寫所有程式碼。
應確保結對程式設計。
應遵循編碼標準。
所有程式碼都必須具有單元測試。
在為系統的每個部分編寫程式碼之前，先編寫單元測試，這樣建立程式碼就會更容易、更快。建立單元測試和建立一些程式碼以使其透過所需的時間與直接編寫程式碼所需的時間大致相同。它簡化了迴歸測試。
在編碼時，您應該只戴以下四頂帽子中的一頂：
新增新功能，但僅更改實現。
新增新功能，但僅更改介面。
重構程式碼，但僅更改實現。
重構程式碼，但僅更改介面。
為整個團隊提供一個專用的整合工作站。
一次只有一對開發人員整合程式碼，並確保所有測試都已透過。
應經常進行整合。
應使用集體所有權。
測試
測試的規則是：
所有程式碼在釋出之前都必須透過所有單元測試。
發現缺陷時應編寫測試。
應經常執行驗收測試。