敏捷式軟體開發 (Agile Software Development)VS傳統軟體工程

標籤：美國   切換   思想   度量   科學   速度   scope   軟體   領域   

　　敏捷式軟體開發 (Agile Software Development)：又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新興軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。

　　與傳統軟體工程相比，它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程式員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發中“人”的作用。

　　本文將介紹敏捷式軟體開發 (Agile Software Development)的曆史背景與發展，探討敏捷軟體工程相對於傳統軟體工程的特點，並闡述一些我個人在學習過程中的認識和思考。

　　20世紀六十年代，電腦硬體技術有了很大的發展，為電腦的廣泛應用創造了條件，並要求軟體與之相適應。當時的軟體生產具有個體化、作坊式特點，開發工具落後，開發平台單一，程式設計語言功能差。尤其是軟體維護工作，耗費大量的人力、物力和電腦資源，許多程式的個體化特性使得它們無法修改和維護。有的乾脆廢棄原有系統不用，從頭編寫新軟體。

　　與此同時，七十年代時，軟體的規模越來越大，結構越來越複雜，軟體管理和維護困難，開發費用不斷增加。這種軟體開發技術、開發工具和生產方式落後的狀況與電腦應用迅速普及和對軟體的需求日益增加形成了尖銳的矛盾，由此而產生了“軟體危機”。

　　軟體危機的產生使電腦軟體專家認識到軟體開發必須以新的方法作指導，原有的軟體開發方法必須改變，他們決定把工程技術的思想引入軟體開發領域，使軟體開發走上工程學科的途徑，以擺脫日益嚴重的軟體危機。於是，美國和西歐的一些科學家在1968年的NATO(北大西洋公約組織)會議上第一次提出了“軟體工程”這個名詞，是利用工程學的方法開發和維護電腦軟體的一門學科。從此，軟體工程正式誕生，人們開始了軟體工程的研究。

　　八十年代，軟體工程引入成熟生產製造管理方法，以“過程為中心”分階段來控制軟體開發（瀑布模型），一定程度上緩解了軟體危機。至九十年代，軟體失敗的經驗促使過程不斷增加約束和限制，軟體開發過程日益“重型化”，開發效率降低、響應速度變慢。

　　從2000年代開始，隨著資訊時代到來，需求變化更快速，軟體的交付周期成為企業的一項核心競爭力，因此，輕量級的，更能適應變化的敏捷式軟體開發 (Agile Software Development)方法被普遍認可並迅速流行開來。2001年初，由於許多公司的軟體團隊陷入了不斷增長的過程的泥潭，一批業界專家聚集在一起概括出一些可以讓軟體Team Dev具有快速工作、響應變化能力的價值觀和原則，並稱自己為敏捷聯盟。

　　我對敏捷同盟宣言的理解大致為：

　　1）個體和互動勝過過程和工具。

　　　“人和人之間的互動是複雜的，並且其效果從來都難以預期，但卻是工作中最為重要的方面。” 人是獲得成功的最為重要的因素。一個優秀的團隊不一定由一群最頂尖優秀的程式員組成，在團隊中，能夠和他人很好的合作、順利的溝通以及高效的互動能力比單純的編程能力更為重要。即使有一群高水平的程式員，如果沒有良好的溝通，也未必可以組成一個高效的團隊，畢竟人不是“插入即相容的編程裝置”。項目的順利進行需要由具有合作精神、自組織且有凝聚力的團隊來保證，合適的工具雖然也非常重要，但是工具的作用不應該被過分的誇大，我們應該明白物極必反，過多或過於龐大複雜的工具和缺少工具一樣都是不合適的。總之，團隊的構建要比環境的構建重要的多，應該首先致力於構建合適的團隊，再基於需要來配置合適的環境。

　　2）可以工作的軟體勝過面面俱到的文檔。

　　　沒有文檔的軟體是一種災難，這意味著沒有嚴格規劃和明確目標的盲目行動，顯然是非常低效的，然而，過多的文檔並不意味著高效，相反，這會花費大量的時間和精力來編製和更新。因此，編寫和維護一份恰如其分的文檔是明智的，文檔應該簡短，主題鮮明，邏輯概括性強。在團隊成員的交流中，近距離的培訓和互動是最有效方式。應該竭力避免注重文檔而非軟體導致進度拖延的情況發生。Martin文檔第一定律告訴我們：直到迫切需要並且意義重大時，才來編製文檔。

　　3）客戶合作勝過合約談判。

　　　傳統：你想清楚你具體要個啥？

　　　敏捷：你再看看還有啥要改的。

　　　Just kidding，但是，確實，我們無法像訂購其他用品一樣來訂購一個軟體，在我的認識裡，軟將更大程度上像是一個“作品”而非一個嚴格意義上的“產品”，所以像大多數藝術創作一樣，讓人在固定的時間內以固定的成本來複刻客戶的需求，是難以達到的，即使這種簡單的交易模式非常具有誘惑力，但一個指明需求、進度以及項目成本的合約其實存在根本上的缺陷，如果僅僅依賴於此，則很大可能會導致項目的失敗。因此，“敏捷”認為，成功的項目需要的是有序和頻繁的客戶回函，而不僅僅是冰冷的合約和死板的工作彙報會議。軟體Team Dev客戶在工作上建立密切的聯絡，盡量經常的溝通和反饋。合約的編製也應該對項目的開發協作起指導作用，而非去約束和規定進度和成本上的細節來試圖使開發工作受到完全的控制。

　　4）響應變化勝過遵循計劃。

　　　在瞬息萬變的現代資訊社會，響應變化的能力常常決定著一個軟體項目的成敗。因此計劃的構建應該保證足夠靈活來適應商務和技術方面的變化。

　　　計劃不可考慮的過遠，因為商務環境以及客戶需求的變化往往是不可預見的。即使需求被確定下來也並不代表開發時間就隨之確定。因此，較好的策略是，先進行短期的詳細計劃，和稍長的粗略計劃。以便靈活地作出改變。計劃中這種逐漸降低的細緻度，意味著我們僅僅對於迫切的任務才花費時間進行詳細的計劃，這樣可以保證短期內工作的有序高效和長期上的靈活適應性。

　　此外，敏捷式軟體開發 (Agile Software Development)開發提出了12條更詳盡的原則，宗旨和宣言一致，也是體現了與傳統軟體工程的區別所在。

　　1、最優先要做的是：通過儘早地、持續地交付有價值的軟體來使客戶滿意。

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

　　3、經常交付可工作的軟體，其時間間隔可以是幾周到幾個月。 交付的時間間隔越短越好。

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

　　5、不斷激勵開發人員，開展項目的有關工作。給他們提供所需要的環境和?支援，並信任他們能夠完成所承擔的工作。

　　6、在團隊內部，最有效果的、最有效率的傳遞資訊的方法，就是面對面的交談。

　　7、首要的進度度量標準是工作的軟體。

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

　　9、不斷關注優秀的技能和設計，增強敏捷能力。

　　10、簡單是根本的。

　　11、最好的體繫結構、需求和設計，出自自己組織的團隊。

　　12、每隔一段時間，團隊對如何才能有效工作進行反省，然後對自己的行為進行適當的調整。

　　我們知道，傳統的軟體開發採用的是瀑布式開發的流程，包括收集需求、定義、設計、編碼、測試、發布等階段。前一階段的完成為後一階段開始的先決條件，每個階段都有其明確的目標和審核標準，整個過程嚴格有序，可預測性逐步增強，這樣的好處是避免資源的無效投入，步步為營，保證開發品質。

　　但傳統開發模式也存在著明顯的缺陷，這種瀑布式流程的每個階段間具有強烈的依賴關係，導致問題的產生可能會導致連鎖的後果。如果前一階段未達到標準，也會造成後續階段的停滯。舉個似乎是我的編譯課老師舉過的例子，一個工程有五個部分的話，如果每個部分做到90分，那麼最終的工程就只能得到59分，就是一個不合格的工程。因此這種模式的靈活性差，很難應對後期需求的變化，調整的代價高昂。

　　所以，在這樣的背景下誕生了敏捷開發的理念，靈活性的提高便是其最大的優勢。市場需求瞬息萬變導致成品需求收集完整性難以保證，可以說在瀑布式開發中的前幾階段我們連九十分都很難做到，所以傳統軟體工程的失敗率之高便不言而喻了。

　　我很認可一種說法，敏捷開發相對於傳統開發是一個核心思維的轉換：從“Fix scope，Flex time”轉向“Fix time，Flex scope”。在市場變化和技術變化背景下，既然市場需求和產品定義的“範圍”無法實現固化，因而資源需求也不確定，那不妨切換重心，旋轉一下我們的座標系，固定資源，來儘可能達到“範圍”的最大化實現。從“計劃驅動”轉向為“價值驅動”。而且敏捷開發更強調“人”的價值功效，康德說，“人即目的”，從這個角度來說，敏捷式軟體開發 (Agile Software Development)的宗旨像是軟體工程發展史上的“文藝複興”運動。

　　最後表達一些我個人不成熟的想法，敏捷式軟體開發 (Agile Software Development)的出現根本上來自於商業環境的現實，人力成本高昂，商業市場上“快魚吃慢魚”的競爭模式等等。敏捷開發這種模式取“敏捷”二字為名，但“敏捷”並不僅僅意味著“多快好省”，速度只是敏捷的一部分，正如我前文提到的，軟體開發更像一門藝術，應該在合理範圍內盡量高效，但浮躁和急功近利是無所裨益的，真正以“人”為驅動力並不應該意味著使開發人員心力交瘁，開發生理潛能的極限，如何協調個中利害關係，想必還是任重道遠。

敏捷式軟體開發 (Agile Software Development)VS傳統軟體工程