什麼極限程式設計 極限程式設計實踐

1.完整的團隊。

XP 專案的所有參與者（開發人員、客戶、測試人員等）在乙個開放的地方一起工作，他們屬於同乙個團隊。 大而顯眼的圖表和其他顯示他們進度的東西隨機掛在這個地方的牆上。

2.計畫遊戲。

該計畫是連續的和漸進的。 每 2 周，開發人員估算候選功能未來 2 周的成本，客戶根據成本和業務價值選擇要實現的功能。

3.客戶測試。

作為選擇每個所需功能的一部分，客戶可以根據指令碼語言定義自動驗收測試，以證明該功能有效。

4.設計簡單。

該團隊使設計與當前系統功能完全一致。 它通過了所有測試，不包含任何重複，表達了作者想說的一切，並且包含盡可能少的**。

5.結對程式設計。

所有生產軟體都是由兩個程式設計師併排坐在同一臺機器上構建的。

6. 測試驅動開發。

編寫單元測試不僅是一種驗證行為，也是一種設計行為。 同樣，這更像是一種編寫文件的行為。 編寫單元測試避免了大量的反饋迴圈，尤其是在功能驗證方面。

程式設計師的工作週期非常短，他們新增乙個失敗的測試，然後使其通過。

7.改進設計。

使用重構方法隨時改進損壞的**，並盡可能保持**乾淨和富有表現力。

8. 持續整合。

該團隊始終使系統完全整合。 當乙個人辦理登機手續時，所有其他所有者都有責任。

9.集體所有制。

任何成對的程式設計師都可以隨時改進任何**。 沒有程式設計師對任何特定的模組或技術負全部責任，每個人都可以參與開發的任何其他方面。

10.編碼標準。

系統中的所有**看起來都像是由乙個人編寫的。

11.隱喻。

將整個系統聯絡在一起的全球視野; 它是系統未來的形象，它使所有單個模組的位置和外觀清晰直觀。 如果模組的外觀與整個比喻不匹配，那麼您就知道該模組是錯誤的。

12. 可持續的速度。

球隊只有堅持下去，才能有希望獲勝。 他們以可以長時間維持的速度努力工作，他們節省體力，他們將比賽視為馬拉松比賽而不是全速衝刺。

極限程式設計是一種旨在提高開發效率、縮短開發周期的程式設計思路，符合客戶的需求。

混凝土。 翻閱書籍！ 希望對你有所幫助。

除了技術實踐之外，XP作為一種管理風格，甚至是一種商業理念，更重要。

XP是一種敏捷交付的實踐，幾乎可以應用於所有業務領域，包括零售，如果你有興趣，可以搜尋“精益製造”，看看這種管理風格是如何應用於其他領域的。

極限程式設計（XP）是由Kentbeck在1996年提出的。 在90年代初與Wardcunningham合作，Kentbeck一直在共同探索軟體開發的新方法，希望使其更容易、更有效。 Kent 仔細觀察和分析了簡化軟體開發的先決條件、可能性和挑戰。

1996 年 3 月，Kent 終於在他為戴姆勒克萊斯勒從事的乙個專案中引入了乙個新的軟體開發概念——XP。 非常適合小型團隊開發。

極限程式設計是一種輕量級、靈巧的軟體開發方法; 同時，這也是一種非常嚴謹且經過深思熟慮的方法。 它的基礎和價值觀是溝通、簡單、反饋和勇氣; 也就是說，任何軟體專案都可以通過四種方式進行改進：加強溝通; 從簡單開始; 尋求反饋; 勇於實事求是。

XP 是一種近乎螺旋式的開發方法，它將複雜的開發過程分解為相對簡單的週期。 通過積極的溝通、反饋等一系列方法，開發者和客戶可以非常了解開發進度、變化、需要解決的問題、潛在的困難等，並根據實際情況及時調整開發過程。

通過軟體工程設計的簡單而美觀的軟體並不比設計為複雜且難以維護的軟體更有價值。 這是真的嗎？ XP認為事實並非如此。

乙個典型的專案在人身上花費的錢是硬體的 20 倍，這意味著乙個專案每年在程式設計師身上花費 200 萬美元，而在計算機裝置上只花費 100,000 美元。 許多聰明的程式設計師說，“我們太聰明了，找到了一種方法來節省 20% 的硬體開銷”，然後他們把源程式弄得龐大，難以理解和維護，他們說：

但我們每年可以節省 20% 或 20,000 美元，這是一筆可觀的節省。 相反，如果我們編寫簡單且易於擴充套件的程式，我們將節省至少 10% 的人力開銷，節省更多，這是您的客戶肯定會注意到的一些事情。

另乙個對客戶很重要的問題是錯誤。 XP 不僅強調測試，還需要正確的測試。 測試必須自動化，以便為程式和客戶提供安全的環境。

在編碼的所有階段，我們都會不斷新增測試用例。 當我們發現乙個錯誤時，我們會新增新的測試，並建立乙個緊密的安全網。 如果同乙個錯誤沒有出現兩次，這些肯定會引起使用者的注意。

您的客戶必須注意的另一件事是：XP 開發人員接受不斷變化的需求。 XP允許我們接受需求的變化。

一般來說，客戶只有在系統開發完成後才能真正欣賞它。 另一方面，XP 通過加強客戶反饋來縮短開發周期，同時獲得足夠的時間來更改功能並獲得使用者支援。 在 XP 中，您的客戶應該明確地知道這一點。

XP開發過程中的大部分革命都發生在軟體開發方法上，其中質量比人們通常認為的更重要。 僅僅因為我們的客戶無法理解我們的來源並不意味著我們不必努力管理質量。