極限程式設計 - 持續演進的實踐

極限程式設計自誕生以來一直在不斷發展，其實踐也被發現有效地應用於其他敏捷方法。

下表展示了極限程式設計實踐的演進過程。

現場客戶 – 完整團隊

極限程式設計依賴於專案社群，強調以團隊為中心的方法。所有參與極限程式設計專案的貢獻者，包括客戶，都屬於同一個團隊。

客戶提供需求，設定優先順序並指導專案。這使客戶能夠了解開發的實際細節，並相應地設定優先順序和期望。這改變了從“按客戶要求開發”到“客戶理解並與開發合作”的方式。

專案目標是共享責任，開發是在整個團隊中進行的持續對話。這是一個發明和溝通的合作遊戲。實踐證明，面對面的溝通是開發過程中最高效、最有效的方法，可以消除等待時間和延誤。

計劃遊戲 – 釋出和迭代計劃

增量專案計劃被證明是有效的，因為它促進了準確的計劃。隨著開發的進展，基於實際效能，會學習到更多更好的資訊。首先制定一個粗略的計劃，然後逐步細化。

釋出計劃設定長期目標，掌握整體大局。客戶提出所需功能，開發人員進行估算，釋出日期由雙方共同商定並承諾。由於釋出計劃在每次釋出後都會進行修訂，因此隨著專案的進展，它會變得越來越精確。

迭代計劃設定短期時間框，包含迭代，通常為1周到1個月。迭代計劃的主要目標是在每次迭代結束時獲得可工作的軟體。開發人員選擇迭代的功能/故事，將其分解成任務，估算任務並承諾分配的任務。透過平衡團隊中的負載係數，並考慮40小時工作制，確保可持續的節奏。

驗收測試

客戶為某個功能編寫一個或多個自動化的驗收測試，以確保系統正確地實現了所需的功能。驗收測試與故事一起編寫，並在實現之前提供。

團隊自動化這些測試以驗證功能是否正確實現。測試執行後，團隊確保此後在迴歸測試時透過執行到目前為止實現的所有驗收測試，使其保持正確執行。

驗收測試提供了功能需求的明確規範。此外，透過的驗收測試的百分比衡量了釋出完成情況，避免了最後一刻的意外。

系統始終改進，永不倒退。

單元測試

開發人員編寫單元測試，並具有足夠的覆蓋率，包含程式碼模組和方法的意圖和用法。單元測試是自動化的，具有明確的透過/失敗結果。大多數語言都有 xUnit 框架（例如，nUnit、jUnit）。

所有單元測試都非常頻繁地執行，並且只有在所有單元測試通過後才能簽入程式碼。單元測試結果也有助於重構。

測試驅動開發

測試驅動開發被認為是最具創新性的極限程式設計實踐。

在測試驅動開發中，開發人員在編寫程式碼之前編寫單元測試。目的是使單元測試失敗。由於程式碼尚未實現，單元測試會失敗。開發人員編寫足夠多的程式碼以使單元測試透過，然後，開發人員進行重構以確保程式碼簡潔明瞭（沒有重複和複雜性）。

開發人員迭代直到編碼完成並且驗收測試透過。

所有單元測試都收集在一起，每次結對整合並將程式碼釋出到儲存庫時，結對都需要確保每個測試都正確執行。如果任何測試失敗，則結對知道需要糾正其程式碼，因為之前的整合沒有出現任何缺陷。

測試驅動開發往往導致 100% 的單元測試覆蓋率，並確保程式碼簡單且最少。

重構 – 設計改進

重構允許設計逐步發展，使其保持簡單，消除您注意到的重複和複雜性。它透過重構來改進現有程式碼的設計，而不改變其功能。

重構應該由從新的實現中學習來驅動。建議在編寫新程式碼後立即進行重構。重構將程式碼導向更高層次的設計模式，並得到測試的支援。

40小時工作制 – 可持續節奏

以可以無限期維持的速度工作。可持續節奏確保了人力對專案成功的貢獻，考慮到以下事實：

• 疲勞和壓力會降低生產力和產品質量。它可能導致員工流失。

• 開發不會隨著衝刺而停止，它應該瞄準長期目標。

• 除非團隊就期望達成一致，否則不會有承諾和責任感。

• 確切的小時數不如執行能力重要。

• 應避免微觀管理，同時確保在需要時提供支援。