背景程序員
因爲軟件開發過程當中需求不斷變更,導致開發週期不斷延遲,經費預算一再上漲,在規定的時間內開發出令用戶滿意的軟件愈來愈難。而傳統軟件開發方法則認爲只要軟件工做人員足夠努力,就能夠在早期肯定全部的需求,從而減小後期需求變更引起的成本增長,而且把變更排斥在開發進程以外。事實上,外部環境變化每每引發軟件開發過程當中的重大變更,這在飛速發展的當今社會是難以免的,從而敏捷型軟件開發方法應運而生。編程
2001年初,一批業界專家彙集在一塊兒歸納出了一些可讓軟件開發團隊具備快速工做、響應變化能力的價值觀和原則,他們稱本身爲敏捷(Agile)聯盟。在隨後的幾個月中,他們建立出了一份價值觀聲明。也就是敏捷聯盟宣言(The Manifesto of the Agile Alliance)。工具
敏捷軟件開發宣言內容:測試
個體和交互 賽過 過程和工具 編碼
能夠工做的軟件 賽過 面面具到的文檔 spa
可戶合做 賽過 合同談判 設計
響應變化 賽過 遵循計劃 繼承
雖然右項也有價值,可是咱們認爲左項具備更大的價值。遊戲
敏捷實踐原則: 進程
敏捷軟件開發是一個開發軟件的管理新模式,用來替代以文件驅動開發的瀑布開發模式。敏捷方式也稱輕量級開發方法。能不斷根據環境的變化,修改本身的設計,指導開發的方向是敏捷開發的目標。
敏捷開發避免了傳統瀑布方式的弊端,主要是吸取了各類新型開發模式的「動態」特性,關注點從文檔到開發者,管理方式也從工廠的流水線到團隊的自我放鬆式的組織。總結敏捷開發與瀑布模式的不一樣,主要是下面幾個「敏捷」的關注點:一是迭代。軟件的功能是客戶的需求,界面的操做是客戶的「感受」,對迭代的強調是縮短了軟件版本的週期; 二是
客戶的參與。以人爲本,客戶是軟件的使用者,是業務理解的專家,沒有客戶的參與,開發者很難理解客戶的真實需求 ;三是版本小。能快速的展現給客戶,對於複雜的客戶要求,有機的進行分割和兼顧總體的統一是很不容易的,要二者相結合。
極限編程(eXtreme Programming,簡稱XP)是敏捷方法中最著名的一個。它由一系列簡單卻互相依賴的實踐組成。這些實踐結合在一塊兒造成了一個敏捷開發過程。以下:
迭代:一次又一次循環逼近的過程
完整團隊:XP項目的全部參與者(開發人員、業務分析師、測試人員等等)一塊兒工做在一個開放的場所中,他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛着大幅的、顯著的圖表以及其餘一些顯示他們進度的東西。
計劃遊戲:計劃是持續的、按部就班的。每2周,開發人員就爲下2周估算候選特性的成本,而客戶則根據成本和商務價值來選擇要實現的特性。
客戶測試:做爲選擇每一個所指望的特性的一部分,客戶定義出自動驗收測試來代表該特性能夠工做。
簡單設計:團隊保持設計剛好和當前的系統功能相匹配。它經過了全部的測試,不包含任何重複,表達出了編寫者想表達的全部東西,而且包含儘量少的代碼。
結對編程:全部的產品軟件都是由兩個程序員、並排坐在一塊兒在同一臺機器上構建的。
測試驅使開發:程序員以很是短的循環週期工做,他們先增長一個失敗的測試,而後使之經過。測試用例按部就班的對代碼的編寫進行指導。
改進設計:隨時改進糟糕的代碼。保持代碼儘量的乾淨、具備表達力。
持續集成:團隊老是使系統完整的被集成。
集體代碼全部權:任何結對的程序員均可以在任什麼時候候改進任何代碼
編碼標準:系統中全部的代碼看起來就好像是被單獨一個——很是值得信任的——人編寫的。
隱喻:團隊提出一個程序工做原理的公共景象。
可持續的速度:團隊只有持久纔有獲勝的但願。他們以可以長期維持的速度努力工做。他們保存精力,他們把項目看作是馬拉松長袍,而不是全速短跑。
敏捷就是「快」,快才能夠適應目前社會的快節奏;要快就要發揮我的的個性思惟多一些,個性思惟的增多,雖然經過結隊編程、代碼共有、團隊替補等方式減小我的對軟件的影響力,但也會形成軟件開發繼承性的降低,所以敏捷開發是一個新的思路,但不是軟件開發的終極選擇。對於長時間、人數衆多的大型軟件應用的開發,文檔的管理與銜接做用仍是不可替代的。如何把敏捷的開發思路與傳統的「流水線工廠式」管理有機地結合,是軟件開發組織者面臨的新課題。