敏捷軟件開發技術簡述

熊柏祥

從計算機誕生開始，軟件開發工作，作為一項以單個人腦力勞動為基礎的工作，經歷了從最初簡單單一到現在繁重復雜的發展歷程。現今，軟件開發往往是一個，涉及到的知識領域廣，參與方和參與人員多，項目周期長，復雜程度非常高的工作。比如應用于金融行業和電信行業的軟件系統，往往涉及到相關應用行業的專業知識，國家的政策法規，計算機專業知識，數學等眾多學科和領域，參與方涉及客戶，軟件開發商，第三方軟件開發商，硬件系統供應商，政府部門等，參與軟件設計和開發的人員往往達到幾百人，并可能同時分布在多個不同城市/國家，使用不同的語言進行交流，項目周期達到幾年也很常見。這其中設計到的問題通常有：

（1）軟件開發人員對系統應用領域的專業知識不甚了解，

（2）開發人員技術能力參差不齊，

（3）開發過程的分工合作極為復雜，

（4）軟件系統的需求不斷變化，

（5）開發周期無限期延長，

等等。

為了有效的組織各種相關資源，科學有序的進行開發工作，確保軟件產品質量和按時交付使用，在軟件開發過程中，人們不斷總結和嘗試，衍生出了多種軟件工程方法。其中典型的有瀑布模型，螺旋模型，迭代模型等等。現在眾多的軟件開發商或者遵循其中的一種或者結合幾種，按照工程流程進行軟件開發。為了便于后面分析對比，我們先對應用瀑布模型的開發過程做簡要介紹。瀑布模型分為以下幾個階段依次進行：需求分析（產生需求分析報告），概要設計（產生概要設計報告），詳細設計（產生詳細設計報告），編碼（產生可運行代碼），測試（產生測試報告）等。每個階段必須等到上一個階段結束后才能開始，每個階段以上一個階段的產出物作為起點，最后提交一個產出物供后續階段使用。

以上典型軟件工程方法的特點是：

（1）對開發工作和流程的劃分十分細致。整體工作被分為調研，設計，開發，測試等多個環節，而且必須依次進行。

（2）開發人員的工作安排十分嚴格。（1）中各個階段的參與人員一般不能重復，而且不同階段均可能需要客戶方人員協作，這就使得交流工作十分繁重。

（3）軟件開發的中間產物非常多，各個階段的設計文檔，技術研究報告，評審報告，軟件使用說明等必須一一提供。

使用以上典型軟件工程方法（或稱為傳統軟件工程方法），對軟件開發的方方面面進行了嚴格的管理：開發工作的劃分，人員的安排，項目進度的預設，軟件質量和成本的控制。這在很大程度上，對建立在單個人腦力勞動基礎上的軟件開發工作起到了很好的幫助。典型軟件工程方法的特點注定了使用其規范進行的軟件開發工作都是一件大規模的工作，在一些大型軟件應用系統的開發中具有很好的實用價值。這些方法還在不斷得到發展，特別是到最近幾年，產生了CMMI體系，從一個更高的層次對軟件開發工作進行全面指導。

但是，軟件開發和軟件應用發展到最近幾年，又產生了許多新特點：

（1）軟件應用的多樣型。應用于各個行業的中小型軟件系統，游戲軟件大量產生。

（2）交付時間的急迫性。很多系統由于其應用環境特點，要求在很短的時間內完成并交付使用。

（3）軟件開發工作的多樣性。軟件開發技術和工具的大量出現，第三方軟件的大量使用。

顯然，典型的軟件工程方法并不適用于這些情況。于是，在傳統軟件工程方法的基礎上，人們結合近年軟件行業出現的特點，不斷對其改進，提出了敏捷開發技術。

敏捷開發（agile development）是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，不再依照傳統的軟件工程方法逐步深入進行（傳統方法下，管理的重點是開發工作逐步深入的個個環節），而是在項目開始的最初，將軟件項目的構建切分成多個子項目（這種情況下，管理的重點是開發工作被平行分割后的各個子項目），然后以各個子項目為基礎進行開發，各個子項目的成果都經過測試，具備集成和可運行的特征。簡而言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成。并在整個過程中，對子項目不斷集成，在此過程中軟件一直處于可使用狀態（但可能不具備最終的全部功能）。各個子項目完成后，整個項目也就完成。在敏捷開發內部，其實也借鑒了大量軟件工程中的方法。迭代與增量開發，這兩種在傳統軟件工程中常用到的方法，在敏捷開發模式中也扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子。

接下來，我們從一個實例上，分析敏捷開發技術的過程要要點。

敏捷開發概念從2004年初開始廣為流行。作為倡導人的Bailar非常支持這一理論，他采取了”敏捷方式”組建團隊：Capital One的”敏捷團隊”包括3名業務人員、兩名操作人員和5～7名IT人員，其中包括1個業務信息指導（實際上是業務部門和IT部門之間的”翻譯者”）；另外，還有一個由項目經理和至少80名開發人員組成的團隊。這些開發人員都曾被Bailar送去參加過”敏捷開發”的培訓，具備相關的技能。

每個團隊都有自己的敏捷指導（Bailar聘用了20個敏捷指導），他的工作是關注流程并提供建議和支持。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個項目階段，團隊人員密切合作，開發有規律地停頓，在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT項目會被拆分成多個子項目，安排給各”敏捷團隊”，這種方式在”敏捷開發”中叫”蜂巢式（swarming）”，所有過程由一名項目經理控制。

為了檢驗這個系統的效果，Bailar將項目拆分，從舊的”瀑布式”開發轉變為”并列式”開發，形成了”敏捷開發”所倡導的精干而靈活的開發團隊，并將開發階段分成30天一個周期，進行”沖刺”，每個沖刺始于一個啟動會議，到下個沖刺前結束。

在Bailar將其與傳統的開發方式做了對比后，他感到非常興奮，”敏捷開發”使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。”不過，有些需求不能用敏捷開發來處理。” Bailar承認，”敏捷開發”也有局限性，比如對那些不明確、優先權不清楚的需求或處于”較快、較便宜、較優”的三角架構中卻不能排列出三者優先級的需求。此外，他覺得大型項目或有特殊規則的需求的項目，更適宜采用傳統的開發方式。盡管描述需求一直是件困難的事，但經過陣痛之后，需求處理流程會讓CIO受益匪淺。敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，并于2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟件開發方法。

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

當然，我們不得不面對的現實是，模式與方法的優化并不意味著問題的終結。作為一種開發模式，敏捷開發同樣需要面對眾多挑戰。

大項目的拆分意味著更多子項目的出現，協調這些同步或異步推進的子項目，合理的資源調配都將變得更加復雜。另外，在當前項目和項目組普遍“增容”的情況下，遇到的問題同樣成倍增長。人的重要性被提到了更高的高度，而缺乏有效協調手段，減少人員流動和項目變更對整個項目造成的影響也將成為一大挑戰。新方法帶來眾多便利的同時，也相應引發了幾乎同樣多的問題。這同時，敏捷開發技術也在得到不斷的發展，這些問題也在得到不斷的改進。

參考文獻

[1]冀乃庚. 軟件開發人員績效考核體系研究[D].西北農林科技大學，2012.

[2]張友生，李雄. 軟件開發模型研究綜述[J]. 計算機工程與應用，2006，03：109-115.

[3]高禹，畢振波. 軟件開發過程模型的發展[J]. 計算機技術與發展，2008，07：83-86.