敏捷開發淺談

    在看過資料後，本身對敏捷開發有了一些粗淺的認識，在這裏略作淺談。

    簡單的說，敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。

    敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提升開發效率和響應能力。除了原則和實踐，模式也是很重要的，多研究模式及其應用可使你更深層次的理解敏捷開發。其實，敏捷開發有本身的核心價值觀：溝通、簡單、反饋、勇氣、謙遜。

    多數軟件開發仍然是一個顯得混亂的活動，即典型的「邊寫邊改」 。設計過程充斥着短時間的、即時的決定，而無完整的規劃。 這種模式對小系統開發其實很管用，可是當系統變得越大越複雜時，要想加 入新的功能就愈來愈困難。同時錯誤故障愈來愈多，愈來愈難於排除。一個典 型的標誌就是當系統功能完成後有一個很長的測試階段，有時甚至有遙遙無期 之感，從而對項目的完成產生嚴重的影響。軟件行業中最初的一場運動是要改變這種狀況，而引入了「正規方法」 的概念。這些方法對開發過程有着嚴格而詳 盡的規定，以期使軟件開發更有可預設性並提升效率，這種思路是借鑑了其餘 工程領域的實踐 － 所以我把它們稱爲工程方法。工程方法已存在了很長時間了，可是沒有取得使人矚目的成功，甚至就 沒怎麼引發人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣， 要是按照它的要求來，那有作太多的事情須要作，而延緩整個開發進程。敏捷型方法的發展是對這些工程方法的反叛。 對許多人來講，這類方法的吸引之處在於對繁文縟節的官僚過程的反叛。它們 在無過程和過於繁瑣的過程當中達到了一種平衡，使得能以很少的步驟過程獲取 較滿意的結果。

     敏捷型與工程型方法有一些顯著的區別。其中一個顯而易見的不一樣反映在文檔 上。敏捷型不是很面向文檔，對於一項任務，它們一般只要求儘量少的文檔。 從許多方面來看，它們更象是「面向源碼」。事實上，它們 認爲最根本的文檔應該是源碼。

可是，我並不覺得文檔方面的特色是敏捷型方法的根本之點。文檔減 少僅僅是個表象，它其實反映的是兩個更深層的特色：1.敏捷型方法是「適應性」而非「預見性」。 工程方法試圖對一個軟件開發項目在很長的時間跨度內做出詳細的計劃， 而後依計劃進行開發。這類方法在通常狀況下工做良好，但（需求、環境等） 有變化時就不太靈了。所以它們本質上是拒絕變化的。而敏捷型方法則歡迎 變化。其實，它們的目的就是成爲適應變化的過程，甚至能容許改變自身來適 應變化。2.敏捷型方法是「面向人」的(people-oriented) 而非「面向過程」的 (process-oriented)。 工程型方法的目標是定義一個過程，不論是誰用都工做。而敏捷型方法 則認爲沒有任何過程能代替開發組的技能，過程起的做用是對開發組的 工做提供支持。

      敏捷開發的預見性與適應性：1.將設計與建造分離開來  設計是難於預見的，而且 須要昂貴的有創造性的人員，建造則要易於預設。咱們有了設計以後， 即可對建造進行計劃了。而有了建造計劃後，咱們進行建造則能夠是很是可 預見性的了。在土木工程中，建造不論在經費上仍是在時間上的成本都要比 設計和計劃大得多。因此，軟件工程方法的途徑是象這樣的：咱們想要可預見的生產進度計劃， 以便能使用技能較低的人員。要達到這一點，咱們必須得把設計與建造分離 開來。所以，在軟件開發中，咱們得想法做出這樣的設計，使得計劃一經完 成，建造將會是直接而明確的。2.需求的不可預見性  做軟件開發的費用估算是不容易的，這有多種緣由。部分緣由是由於軟件 開發是一種設計活動，所以難於精確計劃。部分緣由是系統的「基本材料」變化 很是之快。部分緣由是開發活動極大地依賴於項目參與人員，而個體是難於 預測和量化的。軟件的「不可觸摸」性也是一個緣由。在系統建成以前，有時很難判斷一項 功能的具體價值。也就是說，只有當你在實實在在地使用系統時，你才能 知道哪些功能是有用的，哪些沒什麼用。軟件開發的一切都取決於系統需求，若是需求不固定，你就不能制訂出一個可 預見性的計劃。3.不可預見過程的控制 － 迭代   那麼，咱們如何對付一個不可預測的世界呢？最重要，也是最困難的是要隨時 知道咱們在開發中的情形處境，這須要一個誠實的反饋機制來不斷準確地告訴 咱們。這種機制的關鍵之點是「迭代式」開發方法。這並非一個 新思路，迭代式開發方法已存在好久了，只是名稱不一樣。迭代式開發的要點是常常不斷地生產出最終 系統的工做版本，這些版本逐部地實現系統所需的功能。它們雖然功能 不全，但已實現的功能必須忠實於最終 系統的要求，它們必須是通過全面整合和測試的產品。這樣作的理由是：沒有什麼比一個整合了的、測試過的系統更能做爲一個項目 紮紮實實的成果。文檔能夠隱藏全部的缺陷，未經測試的程序可能隱藏許多缺 陷。但當用戶實實在在地坐在系統前來使用它時，全部的問題都會暴露出來。 這些問題多是源碼缺陷錯誤，也有多是對需求理解有誤。雖然迭代式開發也可用於可見性環境，但它基本上仍是用做「適應性」 過程,由於適應性過程能及時地對付需求變動。需求變動使得長 期計劃是不穩定的，一個穩定的計劃只能是短時間的，這一般是一個「迭代周 期」。迭代式開發能讓每一個迭代週期爲下面的開發計劃提供 一個堅實的基礎。

    此外，敏捷開發須要把人放在第一位，在軟件開發中應以人爲中心，其實這種概念在許多軟 件行業的有識人士中已經是共識。這形成了一個很強的正反饋機制。若是你指望你的開發人員是可互替的編程插件，則你不會去試着把他們當作是不一樣的個體。這會下降士氣，並使優秀的人才跳到一個能發揮其個性特長的地方，最後你卻是獲得你所須要的：可互替的編程插件。敏捷型過程當中「以人爲本」的理念能夠有不一樣的表現，這會致使不一樣的效果， 而並不是全部結果都是徹底一致的。實施敏捷型過程的一個關鍵之處是讓你們接受一個過程而非強加一個過程。 一般軟件開發的的過程是由 管理人員決定的，所以這樣的過程常常受到抵制，特別是若是管理人員已脫離 實際的開發活動很長時間了。而接受一個過程須要一種「自願致力」 ，這樣你們就能以積極的態度參與進來。這樣致使了一個有趣的結果，即只有開發人員他們本身才能選擇並遵循一個適 應性過程。這一點在XP中特別明顯，由於這須要很強的自律性來運行這個過程。 。另外一點是開發人員必須有權做技術方面的全部決定。XP很是強調這一點。 在前期計劃中，它就說明只有開發人員才能估算幹一件工做所需的時間。對許多管理人員來講，這樣形式的技術領導是一個極大的轉變。這種途徑要求 分擔責任，即開發人員和管理人員在一個軟件項目的領導方面有同等的地位。 注意我說的同等。管理人員仍然扮演着他們的角色，但需認識並尊重開發 人員的專業知識。之因此強調開發人員的做用，一個重要的緣由是IT行業的技術變化速度很是之快。今天的新技術可能幾 年後就過期了。這種狀況徹底不一樣於其餘行業。即便管理層裏的之前幹技術的人 都要認識到進入管理層意味着他們的技術技能會很快消失，所以必須信任和依靠當前的開發人員。