極限程式設計 - 簡介
本章概述了極限程式設計。
什麼是敏捷？
“敏捷”一詞意味著：
能夠快速輕鬆地移動身體。
能夠快速清晰地思考。
在商業中，“敏捷”用於描述規劃和開展工作的方式，其中理解到根據需要進行更改是工作的重要組成部分。企業的“敏捷性”意味著公司始終能夠適應市場變化。
參考：劍橋線上詞典。
在軟體開發中，“敏捷”一詞被用來表示“響應變化的能力——來自需求、技術和人員的變化”。
敏捷宣言
2001年，一個軟體開發團隊釋出了敏捷宣言，強調了開發團隊的重要性、適應變化的需求以及客戶參與。
敏捷宣言指出：
我們正在透過實踐和幫助他人實踐來發現更好的軟體開發方法。透過這項工作，我們已經開始重視：
個體和互動 高於 流程和工具。
工作的軟體 高於 詳盡的文件。
客戶合作 高於 合同談判。
響應變化 高於 遵循計劃。
也就是說，雖然右邊的專案也有價值，但我們更重視左邊的專案。
敏捷的特性
以下是敏捷的特性：
敏捷軟體開發中的敏捷性關注整個團隊的文化，包括具有多學科、跨職能的、授權的和自組織的團隊。
它促進共享責任和問責制。
促進有效的溝通和持續的協作。
全團隊的方法避免了延遲和等待時間。
頻繁和持續的交付確保了快速的反饋，這反過來又使團隊能夠與需求保持一致。
協作有助於及時地將不同的觀點結合到實施、缺陷修復和適應變化中。
進度是持續的、可持續的和可預測的，強調透明度。
軟體工程趨勢
在軟體工程中觀察到以下趨勢：
在開發開始之前收集需求。但是，如果稍後需要更改需求，則通常會注意到：
在開發後期抵制更改。
需要一個嚴格的變更流程，其中涉及一個變更控制委員會，甚至可能將變更推遲到以後的版本。
交付的產品需求已過時，無法滿足客戶的期望。
無法在預算內適應不可避免的領域變化和技術變化。
儘早發現並消除軟體開發生命週期中的缺陷，以降低缺陷修復成本。
只有在編碼完成後才開始測試，並且測試被認為是測試人員的責任，儘管測試人員不參與開發。
衡量和跟蹤流程本身。由於以下原因，這變得昂貴：
在任務級別和資源級別進行監控和跟蹤。
定義指導開發的度量標準並測量開發中的每個活動。
管理干預。
在開發之前詳細闡述、分析和驗證模型。
模型應該用作框架。然而，關注模型而不是關注至關重要的開發將不會產生預期的結果。
編碼是開發的核心，但沒有得到足夠的重視。原因是：
負責生產的開發人員通常與客戶沒有持續溝通。
編碼被視為設計的轉換，而程式碼中的有效實現幾乎從未迴圈回到設計中。
測試被認為是交付前檢查缺陷的途徑。
透過忽略測試需求來彌補早期開發階段的進度延誤，以確保按時交付。
這導致交付後修復缺陷的成本超支。
測試人員對產品質量負責，儘管他們在整個開發過程中沒有參與。
限制資源（主要是團隊）以適應預算會導致：
資源過度分配
團隊倦怠。
團隊能力的有效利用率下降。
人員流失。
極限程式設計——一種處理常見缺點的方法
軟體工程涉及：
創造力
透過反覆試驗學習和改進
迭代
極限程式設計建立在這些活動和編碼之上。它是詳細的（並非唯一的）設計活動，透過有效的實施、測試和持續重構具有多個緊密的反饋迴圈。
極限程式設計基於以下價值觀：
溝通
簡潔
反饋
勇氣
尊重
什麼是極限程式設計？
XP是一種輕量級、高效、低風險、靈活、可預測、科學且有趣的方式來開發軟體。
極限編程 (XP) 的構思和開發是為了應對小型團隊在面對模糊和不斷變化的需求時軟體開發的具體需求。
極限程式設計是敏捷軟體開發方法之一。它提供價值觀和原則來指導團隊行為。團隊應自行組織。極限程式設計提供具體的核心實踐，其中：
每個實踐都簡單且自成一體。
實踐的組合產生更復雜和湧現的行為。
擁抱變化
極限程式設計的一個關鍵假設是，更改程式的成本可以在一段時間內保持相對恆定。
這可以透過以下方式實現：
強調來自客戶的持續反饋
短迭代
設計和重新設計
頻繁編碼和測試
儘早消除缺陷，從而降低成本
讓客戶參與整個開發過程
向客戶交付可工作的產品
極限程式設計概覽
極限程式設計包括：
在程式設計之前編寫單元測試，並始終保持所有測試執行。單元測試是自動化的，可以儘早消除缺陷，從而降低成本。
從簡單的設計開始，足以編寫手頭的功能，並在需要時重新設計。
結對程式設計（稱為結對程式設計），兩名程式設計師在一臺螢幕上，輪流使用鍵盤。當其中一人在使用鍵盤時，另一人會不斷審查並提供輸入。
每天多次整合和測試整個系統。
快速將最小的工作系統投入生產，並在需要時進行升級。
始終讓客戶參與並獲得持續反饋。
迭代有助於適應軟體隨著不斷變化的需求而演變的變化。
為什麼它被稱為“極限”？
極限程式設計將有效的原則和實踐提升到極致。
程式碼審查非常有效，因為程式碼會一直進行審查。
測試非常有效，因為存在持續的迴歸和測試。
設計非常有效，因為每個人都需要每天進行重構。
整合測試非常重要，因為每天都要進行多次整合和測試。
短迭代非常有效，因為有用於釋出計劃和迭代計劃的計劃遊戲。
極限程式設計的歷史
Kent Beck、Ward Cunningham和Ron Jeffries於1999年制定了極限程式設計。其他貢獻者包括Robert Martin和Martin Fowler。
在80年代中期，Kent Beck和Ward Cunningham在Tektronix啟動了結對程式設計。在80年代和90年代，Smalltalk文化產生了重構、持續整合、持續測試和緊密的客戶參與。這種文化後來被推廣到其他環境。
在90年代初期，核心價值觀在模式社群、Hillside Group中得到發展。1995年，Kent在Smalltalk最佳實踐中總結了這些內容，1996年，Ward在劇集中總結了這些內容。
1996年，Kent在Hewitt增加了單元測試和隱喻。1996年，Kent承擔了克萊斯勒C3專案，Ron Jeffries被新增為教練。這些實踐在C3上得到完善，並在Wiki上釋出。
Scrum實踐被納入並改編為計劃遊戲。1999年，Kent出版了他的著作《極限程式設計詳解》。同年，Fowler出版了他的著作《重構》。
從那時起，極限程式設計一直在發展，並且這種發展持續至今。
行業成功
遵循極限程式設計實踐的專案的成功歸功於：
快速開發。
對客戶不斷變化的需求做出即時響應。
關注低缺陷率。
系統持續向客戶提供一致的價值。
高客戶滿意度。
降低成本。
團隊凝聚力和員工滿意度。
極限程式設計的優勢
極限程式設計解決了軟體開發專案中經常遇到的以下問題：
進度延誤——可實現的開發週期確保按時交付。
專案取消——專注於持續的客戶參與確保與客戶的透明度以及任何問題的立即解決。
更改產生的成本——廣泛且持續的測試確保更改不會破壞現有功能。始終執行的工作系統始終確保有足夠的時間來適應更改，從而不會影響當前操作。
生產和交付後缺陷：重點在於——單元測試以儘早檢測和修復缺陷。
誤解業務和/或領域——讓客戶成為團隊的一部分，確保持續溝通和澄清。
業務變更——變更被認為是不可避免的，並且可以在任何時候進行調整。
員工流動——密集的團隊協作確保熱情和善意。多學科的凝聚力培養了團隊精神。