極限程式設計 - 價值觀與原則
XP 透過引入基本的價值觀、原則和實踐來降低變更成本。透過應用 XP，系統開發專案在變更方面應該更加靈活。
極限程式設計價值觀
極限程式設計 (XP) 基於五個價值觀 -
溝通
簡單性
反饋
勇氣
尊重
溝通
溝通在專案的成功中起著至關重要的作用。專案的很多問題往往源於溝通不足。許多情況可能導致溝通中斷。一些常見的問題包括 -
開發人員可能沒有告知其他人關於設計中關鍵變更的資訊。
開發人員可能沒有向客戶提出正確的問題，從而導致關鍵的領域決策出現偏差。
管理人員可能沒有向開發人員提出正確的問題，導致專案進度被錯誤地報告。
開發人員可能忽略了客戶傳達的一些重要資訊。
極限程式設計強調團隊成員、管理人員和客戶之間持續不斷的溝通。極限程式設計實踐，如單元測試、結對程式設計、簡單設計、通用隱喻、集體所有權和客戶反饋都側重於溝通的價值。
XP 採用教練，其工作是在人們沒有進行溝通時注意到這一點並重新引導他們。更傾向於面對面溝通，並透過結對程式設計來實現，並且客戶代表始終在場。
簡單性
極限程式設計認為“今天做一件簡單的事情，明天付出一點額外代價來修改它”比“今天做一件可能永遠不會用到的更復雜的事情”更好。
做需要做的事情和被要求做的事情，但不要做更多。
“做最簡單可能起作用的事情”即 DTSTTCPW 原則。
以最簡單的方式實現新功能。也稱為 KISS 原則“保持簡單，愚蠢！”。
當教練看到極限程式設計開發人員做一些不必要複雜的事情時，可能會說 DTSTTCPW。
重構系統，使其成為具有當前功能集的最簡單的程式碼。這將最大化迄今為止投資所創造的價值。
採取小的簡單步驟來實現目標，並在問題發生時減輕故障。
創造一些你感到自豪的東西，並以合理的成本長期維護它。
永遠不要實現你現在不需要的功能，即“你不需要它”（YAGNI）原則。
溝通和簡單性相互支援。
溝通得越多，你就能越清楚地看到需要做什麼，並且對真正不需要做什麼更有信心。
你的系統越簡單，你需要溝通的內容就越少，需要的開發人員也越少。這將帶來更好的溝通。
反饋
每次迭代的承諾都會被認真對待，並交付一個可工作的軟體。軟體儘早交付給客戶並獲取反饋，以便在需要時進行必要的更改。關於系統當前狀態的具體反饋是無價的。反饋的價值在於一個持續執行的系統，該系統以可靠的方式提供關於自身的資訊。
在極限程式設計中，在不同的時間尺度上確保所有級別都有反饋 -
客戶告訴開發人員他們感興趣的功能，以便開發人員可以只專注於這些功能。
單元測試告訴開發人員系統的狀態。
系統和程式碼向管理人員、利益相關者和客戶提供有關開發狀態的反饋。
頻繁釋出使客戶能夠執行驗收測試並提供反饋，並使開發人員能夠根據該反饋進行工作。
當客戶編寫新的功能/使用者故事時，開發人員會估算交付更改所需的時間，以便與客戶和管理人員設定期望。
因此，在極限程式設計中，反饋 -
充當變革的催化劑
指示進度
讓開發人員相信他們走在正確的道路上
勇氣
極限程式設計以以下方式為開發人員提供勇氣 -
專注於所需內容
溝通並接受反饋
說出進度和估算的真相
重構程式碼
適應隨時發生的更改
丟棄程式碼（原型）
這是可能的，因為沒有人單獨工作，並且教練會持續指導團隊。
尊重
尊重是一個深刻的價值觀，它位於其他四個價值觀的表面之下。在極限程式設計中，
每個人都尊重彼此作為寶貴的團隊成員。
每個人都貢獻價值，例如熱情。
開發人員尊重客戶的專業知識，反之亦然。
管理層尊重開發人員接受責任和獲得對其自身工作授權的權利。
與溝通、簡單性和具體反饋相結合，勇氣變得極其寶貴。
溝通支援勇氣，因為它為更多高風險、高回報的實驗打開了可能性。
簡單性支援勇氣，因為對於簡單的系統，你可以負擔得起更大的勇氣。你不太可能在不知情的情況下破壞它。
勇氣支援簡單性，因為一旦你看到簡化系統的可能性，你就會嘗試它。
具體反饋支援勇氣，因為如果你能看到測試最終變為綠色，那麼在嘗試對程式碼進行徹底修改時你會感到更安全。如果任何測試沒有變為綠色，你就知道可以丟棄該程式碼。
極限程式設計原則
價值觀很重要，但它們很模糊，從某種意義上說，可能無法確定某件事是否有價值。例如，從某人的角度來看簡單的事情，從其他人的角度來看可能很複雜。
因此，在極限程式設計中，基本原則源於價值觀，以便可以根據這些原則檢查開發實踐。每個原則都體現了價值觀，並且更具體，例如快速反饋 - 你要麼擁有它，要麼沒有。
極限程式設計的基本原則包括 -
快速反饋
假設簡單性
增量變化
擁抱變化
高質量工作
快速反饋
快速反饋是為了獲取反饋，理解它，並儘快將學習成果重新應用到系統中。
開發人員設計、實現和測試系統，並在幾秒鐘或幾分鐘內使用該反饋，而不是幾天、幾周或幾個月。
客戶審查系統以檢查它如何才能最好地做出貢獻，並在幾天或幾周內提供反饋，而不是幾個月或幾年。
假設簡單性
假設簡單性就是將每個問題都視為可以用簡單的方式解決。
傳統上，你會被告知要為未來計劃，為重用而設計。這種方法的結果可能會變成“客戶今天需要的東西沒有得到滿足，最終交付的東西可能已經過時且難以更改。”
“假設簡單性”意味著“今天做好今天的工作，並相信你能夠在未來需要時新增複雜性。”在極限程式設計中，你會被告知要做好工作（測試、重構和溝通），專注於今天重要的事情。
有了良好的單元測試，你可以輕鬆地重構程式碼以進行其他測試。
遵循 YAGNI（你不需要它）。
遵循 DRY（不要重複自己）原則。例如，
不要有多個相同（或非常相似）程式碼的副本。
不要有多個冗餘的資訊副本。
不要浪費時間和資源在可能不需要的事情上。
增量變化
在任何情況下，一次性進行的重大更改都不會奏效。任何問題都可以透過一系列最小的變化來解決。
在極限程式設計中，增量變化以多種方式應用。
設計一次更改一點。
計劃一次更改一點。
團隊一次更改一點。
即使是極限程式設計的採用也必須採取循序漸進的步驟。
擁抱變化
最佳策略是在實際解決最緊迫問題的同時保留最多的選擇。
高質量工作
每個人都喜歡做好工作。他們試圖創造他們感到自豪的質量。團隊
工作良好
享受工作
在生產有價值的產品時感覺良好