最后，作為補充，我們再簡單介紹一種新的開發流程：敏捷開發和極限編程。
2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭的問題，一批業界專家一起概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法很多，主要有SCRUM、Crystal、特征驅動軟件開發(Feature Driven Development，簡稱FDD)、自適應軟件開發(Adaptive Software Development，簡稱ASD)，以及最重要的極限編程(eXtreme Programming,簡稱XP)。
極限編程是一套能快速開發高質量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發出來并向客戶提供最高的效益。XP在很多方面都和傳統意義上的軟件工程不同，同時，它也和傳統得管理和項目計劃得方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。
XP具有12個過程，只有完全使用12個過程才是真正使用了XP，只是簡單使用了其中一個方法并不代表使用了XP。XP的12個過程如下。
— 現場客戶(On-site Customer)
— 計劃博弈(Planning Game)
— 系統隱喻(System Design)
— 簡化設計(Simple Design)
— 集體擁有代碼(Collective Code Ownership)
— 結對編程(Pair Programming)
— 測試驅動(Test-driver)
— 小型發布(Small Release)
— 重構(Refactoring)
— 持續集成(Continous integration)
— 每周40小時工作制(40-hour Weeks)
— 代碼規范(Coding Standards)
下面是極限編程的有效實踐。
完整團隊XP項目的所有參與者(開發人員、客戶、測試人員等)一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。
計劃博弈是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
客戶測試作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。
簡單設計團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，并且包含盡可能少的代碼。
結對編程所有的產品軟件都是由兩個程序員并排坐在一起在同一臺機器上構建的。
測試驅動開發編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。
改進設計隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的干凈，具有表達力。
持續集成團隊總是使系統完整地被集成。一個人拆入(Check in)后，其他所有人負責代碼集成。
集體代碼所有權任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其他方面的開發。
編碼標準系統中所有的代碼看起來就好像是由一人單獨編寫的。
隱喻將整個系統聯系在一起的全局視圖，它是系統的未來影像，使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的。
可持續的速度團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。極限編程是一組簡單、具體的實踐，這些實踐結合在形成了一個敏捷開發過程。極限編程是一種優良的、通用的軟件開發方法，項目團隊可以拿來直接采用，也可以增加一些實踐，或者對其中的一些實踐進行修改后再采用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
