極限編程與敏捷開發

      在按照我的理解方式審查了軟件開發的生命周期后，我得出一個結論：實際上滿足工程設計標準的惟一軟件文檔，就是源代碼清單。

      -- Jack Reeves

      簡介

       2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭，一批業界專家一起概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法很多，主要有：SCRUM，Crystal,特征驅動軟件開發（Feature Driven Development，簡稱FDD），自適應軟件開發(Adaptive Software Development，簡稱ASD)，以及最重要的極限編程(eXtreme Programming,簡稱XP)。極限編程(XP)是于1998年由Smalltalk社群中的大師級人物Kent Beck首先倡導的。

      極限編程

       設計和編程都是人的活動。忘記這一點，將會失去一切。

-- Bjarne Stroustrup

      極限編程(XP)是敏捷方法中最箸名的一個。它是由一系列簡單卻互相依賴的實踐組成。這些實踐結合在一起形成了一個勝于部分結合的整體。

下面是極限編程的有效實踐：

      1、完整團隊

      XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。

      2、計劃游戲

      計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。

      3、客戶測試

      作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。

      4、簡單設計

      團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，并且包含盡可能少的代碼。

      5、結對編程

      所有的產品軟件都是由兩個程序員、并排坐在一起在同一臺機器上構建的。

      6、測試驅動開發

      編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。

      7、改進設計

      隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的干凈、具有表達力。

      8、持續集成

      團隊總是使系統完整地被集成。一個人拆入（Check in）后，其它所有人責任代碼集成。

      9、集體代碼所有權

      任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發。

      10、編碼標準

      系統中所有的代碼看起來就好像是被單獨一人編寫的。

      11、隱喻

      將整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的。

      12、可持續的速度

      團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。

      極限編程是一組簡單、具體的實踐，這些實踐結合在形成了一個敏捷開發過程。極限編程是一種優良的、通用的軟件開發方法，項目團隊可以拿來直接采用，也可以增加一些實踐，或者對其中的一些實踐進行修改后再采用。

      敏捷開發

      人與人之間的交互是復雜的，并且其效果從來都是難以預期的，但卻是工作中最重要的方面。

-- Tom DeMacro和Timothy Lister

      敏捷軟件開發宣言：

n      個體和交互         勝過      過程和工具

n      可以工作的軟件 勝過      面面俱到的文檔

n      客戶合作             勝過      合同談判

n      響應變化             勝過      遵循計劃

      雖然右項也有價值，但是我們認為左項具有更大的價值。

      敏捷宣言遵循的原則：

n      我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。

n      即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

n      經常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

n      在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。

n      圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，并且信任他們能夠完成工作。

n      在團隊內部，最具有效果并富有效率的傳遞信息的方法，就是面對面的交談。

n      工作的軟件是首要的進度度量標準。

n      敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。

n      不斷地關注優秀的技能和好的設計會增強敏捷能力。

n      簡單是最根本的。

n      最好的構架、需求和設計出于自組織團隊。

n      每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。

      當軟件開發需求的變化而變化時，軟件設計會出現壞味道，當軟件中出現下面任何一種氣味時，表明軟件正在腐化。

n      僵化性： 很難對系統進行改動，因為每個改動都會迫使許多對系統其他部分的其它改動。

n      脆弱性： 對系統的改動會導致系統中和改動的地方在概念上無關的許多地方出現問題。

n      牢固性： 很難解開系統的糾結，使之成為一些可在其他系統中重用的組件。

n      粘滯性： 做正確的事情比做錯誤的事情要困難。