敏捷軟件工程和傳統軟件工程的比較

敏捷軟件工程和傳統軟件工程比較

(注：博文中加粗的正文部分爲引用部分)

一、引言

敏捷軟件開發從被提出以後就收到了普遍的關注，其從傳統開發中剝離開自成一體，逐漸佔據軟件工程學界的半壁江山，與傳統軟件開發平起平坐。在長期的軟件工程發展中逐步造成敏捷型和傳統型軟件工程相輔相成，並漸漸被軟件開發團體承認並運用於實際中。

二、步步爲營——傳統型軟件工程

       傳統型軟件開發是基於「瀑布模型」的開發方式，以軟件架構爲核心，採用結構化設計以及分析方法將軟件生命劃分期限，而且開發進度按照從上而下的順序相互銜接，如同瀑布通常。瀑布模型是Winston Royce在1970年提出的一種軟件開發模型，瀑布式開發是一種傳統的計算機軟件開發，是最經典的預見性軟件開發方法，嚴格遵照計劃、分析、編碼、測試、維護的步驟。階段之間經過文檔流通，每一個階段結束時要進行嚴格的審查，檢查功能設計和實現是否符合上階段流下了的文檔的要求，若是不符合就逆流到上個階段檢查並修正，以此往復，直到流到最後階段產品經過測試後進行發佈及運行期間的維護[i]

　

圖1  瀑布模型開發過程

 

       各個階段須要文檔相互流通，在軟件開發前期就須要對整個軟件的架構進行設計，優秀的架構可使軟件足以支撐整個功能體系以及便於維護，而這樣優秀強大的框架一般須要在十分有經驗而且有着獨特眼光的架構師在徹底理解開發用戶的需求以後纔可能設計出，一般這個難度是較大的，而這是傳統型軟件開發的第一步，也是最重要的一步。這樣開發的好處是，超前的預見性和每一階段都要經過嚴格的審查才能進行下一個階段，保證了軟件的質量。缺點是，軟件的框架一旦肯定下來就很難改變，甚至會牽一髮而動全身，難以適應變換莫測的客戶需求。此外，在軟件開發過程當中須要人員之間交流的並很少，每個階段對代碼的編寫或者測試都由文檔規定。因爲各個階段要自上而下相互銜接，各個階段的溝通要經過大量臃腫、複雜的文檔來傳遞信息。這樣的軟件開發一般會將每一塊的功能作的相對完善（基於明確的文檔），而模塊之間的銜接以及充分理解文檔的時間將顯得很是長。

 

 

 

   

三、靈巧精靈——敏捷型軟件工程

         敏捷型軟件開發不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導咱們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人，及突出了人做爲軟件開發的核心，在軟件開發中起到的價值。它採用的是迭代式開發敏捷開發以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。

       敏捷型軟件開發方法有不少，目前較爲被承認和接受的是SCRUM編程和XP編程，及極限編程。在軟件開發過程當中，將項目切分紅幾個子項目，以最核心的功能爲起點進行軟件開發，每當一個階段的軟件開發結束，就交付一個階段的可用開發成果，而且在保留可更改的能力的狀況下對於代碼進行優化，總結和經驗分析。

　

圖2 Scrum開發模型

    對於Scrum的詳細介紹，筆者從博主楊廣的博客中學習了不少，爲了節省篇幅，筆者在這裏給出博客的連接，對於這方面興趣較大的朋友不妨瞭解一下，講解的很是詳細。

    博客：http://blog.csdn.net/u012755393/article/details/52790887

四、舉個栗子——淺談兩種開發模式

         筆者在國慶期間和幾個同窗一塊兒開發了一款簡單的基於Microsoft平臺的UWP（Universal Windows Platform）軟件。軟件是一個日記本，其核心功能是提供寫日記的窗口而且保存日記。在開發初期的討論會議中肯定了開發軟件的內容（需求），開發中每一個人的分工，而後在國慶期間進行代碼編寫，測試，最終發佈。對於兩種開發模式有必定了解以後，這個例子中筆者陷入了一個泥潭：此次的開發，算是傳統型軟件工程，仍是敏捷型軟件工程？（儘管在實行過程當中有着種種例如根本就沒有寫文檔的一系列問題，此處假設全部的開發過程所有符合軟件工程開發的標準，在腦海中自動「.+/」選擇補齊對象 (ˉ▽ˉ；)…）

       看上去很像是傳統型軟件工程開發對吧？從一開始的初期會議肯定一系列內容，到分工編寫代碼，測試，優化，到發佈，每一步和上一步都有着很完美的銜接，若是上一步出現了差錯，下一步就沒法進行下去，如多米諾骨牌式的推進。然而筆者的團隊在每次開發階段截至以後都會對本身當前開發的部分進行測試而且發佈一個擁有局部功能的幾乎已經徹底可用的Demo，而且在開發過程當中總結開發經驗。這看上去又和敏捷型開發很是類似。

圖3 敏捷型開發的五個步驟

事實上，在開發過程當中，愚蠢的筆者突發奇想在軟件中加入了一些貌似頗有意思的東西，雖然這致使軟件開發在測試那一個環節卡死了好久，可是軟件最終仍是定期交付了。咱們再把瀑布型的開發過程的圖片引用一次：

圖4 瀑布模型開發過程

新的想法提出，意味着出現了在一開始定義階段上的問題，按照傳統的軟件開發來講，這將是一場災難而且有可能會無期限的拖延交付時間，而筆者的團隊並無推翻當前的大部分代碼，而是直接修改某些核心內容後較爲妥帖的合併上了，這很像敏捷型軟件工程開發中的「下一個階段工程」，在和小組成員交流後擬定新的開發計劃而且和原來的開發內容合併，並完成合並後的測試，防止愚蠢的筆者再產生一些神奇的想法，彷佛能夠理解爲，爲下一個階段的開發進行分析而且準備下一個階段的開發。

　　那麼，這個有些不三不四的開發過程應該算在什麼裏面呢？

　　其實筆者認爲，兩種都不算。

 

 

　　在開發過程當中，若是是傳統軟件開發過程的話，在計劃擬定的環節應該作到儘可能詳盡，準備徹底，而不是遺漏不少看上去理所固然然而並無被實現的功能。事實上，詳盡的擬定計劃是能夠實現的，若是作到的話，就不會出現以前所說的狀況。若是是敏捷型軟件開發，應該按期對於工程進行任務彙報，而不是幾乎沒有太多的交流。敏捷軟件開發的一個精髓就是「剛剛夠」思想。用逐步實現的思想替代完整架構，每一步的需求和人員及其溝通、開發成本都剛恰好，經過不斷地迭代，在迭代過程當中響應客戶需求的變化，實現最緊緻成本，體現「剛恰好」思想。同時對每次迭代的反饋進行討論和思考，總結經驗和吸收教訓。按照這個標準，就不該該出現爲了添加新的功能而對於核心代碼大動干戈。

　　若是將此次的工程規範化進行開發，咱們能夠比照一下較爲輕量級的工程使用兩種開發方式的效率。選擇傳統型軟件開發，勢必須要在軟件開發初期對於工程有一個較爲全面的功能需求分析而且撰寫開發文檔，這就要消耗不少的時間。開發過程當中對於文檔須要研究後再進行代碼編寫，完成後撰寫文檔，交給測試人員測試，再撰寫測試文檔。能夠看出除了代碼編寫以外，很大一部分精力都放在了文檔撰寫和閱讀上，對於小型的工程來講我認爲是沒必要要的。我更傾向於敏捷型開發，由於整個團隊只有三我的，開發的軟件輕量，沒有複雜數據庫和難以捉摸的架構，天天每人按照計劃定量完成，在寢室中交流討論，在完成核心代碼以後，先發布能夠運行的版本，再添加新的功能和細節，保證每一個階段都有能夠看到的成果。這樣免去了話很大功夫編寫文檔，同時階段性可用產品的發佈對於開發人員來講也是一種激勵和知足。

　　在此次工程結束後，筆者分析得出，敏捷型開發適用的範圍可能較小，團隊人員相對固定而且人數有限，對於編程人員的開發經驗和能力要求較多。若是開發的程序複雜度規模是日記本的不少倍，那麼在工程幾乎結束的時候新添加一個功能的難度可想而知。之因此開發的過程寸步難行，開發模式不三不四，我想主要仍是因爲筆者團隊開發時對於UWP幾乎沒有任何瞭解，在開發過程當中幾乎不能離開資料，遑論構建優秀輕便的體系結構。雖然團隊中有開發經驗相對豐富的開發者，然而因爲缺乏交流致使開發過程當中也很難在關鍵節點上對於一些問題提出建設性的見解。所以總結一下，在筆者認爲，敏捷型開發若是要體現其勢如破竹的氣勢，應當知足一下幾個條件：

一、開發人員擁有足夠的項目經驗和編程能力。

二、軟件規模適度，開發團隊人數較少。（筆者的觀點是，敏捷型開發並不如傳統開發那樣嚴謹，有可能有較多漏洞，在大型工程中有可能會出現差池）

三、軟件開發過程當中須要足夠的交流，可使用各類方式，如站立會議，任務看板以及燃盡線等等

四、及時對完成的任務進行測試調試，推出可用的Demo版本，經驗總結併爲下階段的軟件開發作好準備。

五、結束語

       2016年中國開源年會中，筆者有幸在後臺和易軟天創的創始人王春生先生對於兩種工程開發方式的內容進行一些交談。在真正的工程中，彷佛並無對於選擇敏捷型仍是傳統型開發看得那麼的重。開發方式只是一種方式，並非敏捷型開發就必定要在極限編程，水晶編程或者Scrum編程中選擇，其更多的是一種工程思想，在學習中不該該將本身過度的限制在教條中，把何爲傳統何爲敏捷當成範本在合適的工程中生搬硬套。最重要的仍是學會分析軟件需求，按照實際狀況選擇不一樣的開發方式，或許有些大型項目敏捷型開發會更加有用，而某些小的工程也須要傳統方式的嚴謹。

 

---

[1] Gyoung，博主  敏捷型軟件和傳統型軟件開發的比較