敏捷軟件開發 VS. 傳統軟件工程

敏捷軟件開發 VS. 傳統軟件工程

本文寫做的主題爲介紹在軟件工程領域流行的兩種軟件開發模式——敏捷軟件開發與傳統軟件工程，以及它們的優缺點。

1、傳統軟件工程

1,產生背景

傳統軟件工程(Software Engineering)的產生來源於上世紀60年代產生的軟件危機。軟件危機的產生是因爲計算機計算能力和要處理的問題複雜度的急速增加。1972年，艾茲赫爾·戴克斯特拉於計算機協會圖靈獎的演講描述了軟件危機產生的緣由：

　　軟件危機的主要緣由是機器變得強大不少。直白的說，只要沒有機器，編程便不會產生問題。當咱們只有幾臺計算能力差的電腦，編程是一件容易的事情。而如今咱們有了強大的計算機，編程天然也就成了一個大問題。——Edsger Dijkstra, The Humble Programmer (EWD340)

(筆者注：相信每一個計算機科學領域的人，沒有不知道Dijkstra的，他的Dijkstra算法不管任何算法書，任何算法課都會涉及的精妙算法，而他本人也是圖靈獎的得到者，在學術界有很大的影響力。筆者本人也十分崇拜他。)

軟件危機具體表如今：

• 項目運行超過預算
• 項目運行超過期間
• 軟件十分低效
• 軟件質量很低
• 軟件沒法知足需求
• 項目缺少管理，代碼難以維護
• 軟件難以交付

正是因爲計算機計算能力的顯著提高，以及當時人們對軟件的需求的提升，致使了人們意識到開發項目不能只是將程序員機械的組織在一塊兒參與進行開發，而是須要使用系統而科學的管理模式，相互之間須要協調一致配合。因而學術界和工業界爲了克服軟件危機，提出了傳統的軟件工程開發方法，累積了大量的研究成果，普遍地進行大量的技術實踐，將其發展爲一門學科，甚至能夠說是一個標準。

2,常見的傳統軟件工程模型

瞭解了傳統軟件工程的產生背景以後，下面介紹幾種常見的傳統軟件工程模型。傳統的軟件開發模型包括瀑布模型、增量過程模型、原型模型、螺旋模型等。

(1)瀑布模型(Waterfall Model)

1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的「瀑布模型」，直到80年代早期，它一直是惟一被普遍採用的軟件開發模型。瀑布模型是將軟件生存週期的各項活動規定爲按固定順序而鏈接的若干階段工做，形如瀑布流水，最終獲得軟件產品。

 

原始的瀑布模型將軟件開發過程分爲需求分析(Requirements)，設計(Design)，軟件實現(implementation)，測試(Verification)，維護(Maintenance)五個週期。而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。只有當上一級所有完成且檢查無誤後，開發才能從一個階段「流動」到下一個階段，這也是瀑布開發名稱的由來。瀑布模型核心思想是按工序將大問題分爲小問題，將功能的實現與設計分開，便於分工協做，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。它的創做靈感，來源於當時發達的製造工業，流水線式的做業體系。一項產品就如同一個項目，在當時產品的製造採用分階段流水，因而乎天然而然羅伊斯將其應用於軟件開發。羅伊斯提出原始瀑布模型以後，不一樣的演變瀑布模型(包括Royce's 最終瀑布模型)在過程當中略有改動。但基本保持原有的五大週期劃分。好比引入了「回溯」機制，在當前階段發現缺陷或需求不知足時，回到以前的某一週期，使之應對更加靈活，多變的現代項目要求。瀑布模型是傳統軟件開發模型中最典型的，也是其餘傳統軟件開發的模型的基礎。

(2)增量過程模型(Spiral Model)

 

增量過程模型是指每一個階段運用線性序列、每一個增量提交產品。它是像原型和其餘演化方法同樣,具備迭代的特徵，包括增量模型、RAD模型。增量過程模型融合了瀑布模型的基本成分（重複應用）和原型實現的迭代特徵。該模型採用隨着日程時間的進展而交錯的線性序列，每個線性序列產生軟件的一個可發佈的「增量」。

(3)原型模型(Prototype Model)

原型模型經過向用戶提供原型獲取用戶的反饋，使開發出的軟件可以真正反映用戶的需求。同時，原型模型採用逐步求精的方法完善原型，使得原型可以「快速」開發，避免了像瀑布模型同樣在冗長的開發過程當中難以對用戶的反饋做出快速的響應。相對瀑布模型而言，原型模型更符合人們開發軟件的習慣，是目前較流行的一種實用軟件生存期模型。

(4)螺旋模型(Spiral Model)

螺旋模型是一種演化軟件開發過程模型，它兼顧了快速原型的迭代的特徵以及瀑布模型的系統化與嚴格監控。螺旋模型最大的特色在於引入了其餘模型不具有的風險分析，使軟件在沒法排除重大風險時有機會中止，以減少損失。同時，在每一個迭代階段構建原型是螺旋模型用以減少風險的途徑。螺旋模型更適合大型的昂貴的系統級的軟件應用。圖中的四個象限1.決定目標，方案和限制2.評估方案，識別解決風險3.開發驗證下一級產品4.計劃下一個階段，一圈如同原型模型開發的過程。

 

2、敏捷軟件開發(Agile software development)

敏捷軟件開發沒有一個準確的定義，它來源於世紀之交時期。在90年代，當時盛行的複雜開發方法引發了程序員對其管理嚴格，高度規範的抱怨，爲了解決這個問題，許多輕量的軟件開發方法發展了出來。包括快速應用程序開發(rapid application development)，動態系統開發方法(DSDM)，Scrum開發方法等。它們如今被歸於敏捷軟件開發方法。

在2001,17名軟件開發者在Snowbird會議上發佈了敏捷軟件開發宣言(the Manifesto for Agile Software Development)，他們在其中提到：

• 我的與交互(Individuals and interactions)：自我管理及自我驅動與結對編程這樣的交互同樣重要
• 可用的軟件(Working software)：可用的軟件比文檔更有用更受歡迎
• 客戶合做(Customer collaboration):需求不可能在軟件開發的開始所有獲得，所以客戶參與到開發中及其重要
• 應對改變(Responding to change):敏捷開發專一於快速應對持續變化的開發

從上面官方宣言中，其實能夠看出敏捷開發更注重人與人的交互，快速應對開發過程當中的變化。因此筆者認爲敏捷開發的核心是敏捷，其中的Agile更確切的說是快速且靈活，它強調快速的開發可用軟件，如何實現這一點呢，交流，交互，靈活適應變動。這就是我我的理解敏捷開發的宗旨。

下面介紹幾種常見的敏捷開發方法，Crystal，透明水晶方法和Scrum讓咱們對敏捷開發有個初步的認識。

水晶方法Crystal

水晶方法，Crystal ，是由 Alistair Cockburn 和 Jim Highsmith 創建的敏捷方法系列，其目的是發展一種提倡「機動性的」方法。Crystal 方法適用於6-8名開發人員開發非生命攸關的系統。方法關注效率和適應性，注重人而不是過程。項目能夠按照參加的人員和重要性劃分。

重要性根據項目中的錯誤引起的後果分爲：

C   ：Loss of comfort （某些不溫馨）

D  ：Loss of discretionary money (經濟損失)

E   ：Loss of Essential Money (嚴重經濟損失)

L   ：Life Critical (生命危險)

一個項目稱爲C6說明參加人員在6人如下，重要性是C級，D20說明人員在6-20人，重要性是D級。

Crystal系列開發方法中，所適用的開發人員數量以及重要等級以下：

Crystal Clear適用於 C6,D6項目

Crystal Yellow適用於 C20,D20,E20項目

Crystal Orange 適用於 C40,D40,E40項目

Crystal Red 適用於 C80,D80,E80項目

Crystal方法有下列特徵：

 

• 常常交付
• 反思改進
• 滲透式交流
• 我的安全
• 焦點
• 反思改進
• 配有自動測試、配置管理和常常集成功能的技術環境

 

Scrum

 

 

Scrum是一種靈活的軟件管理過程框架，它能夠幫助駕馭迭代、遞增的軟件開發過程，主要用於產品開發或工做管理。在這個框架中，開發人員分爲了避免同的角色，整個開發過程由若干個短的迭代(Sprint)週期組成，在每一次衝刺或迭代（一個15到30天的週期，其長度由開發團隊決定）當中，開發團隊建立可用的（能夠隨時推出）軟件的一個增量。在衝刺中，每一天都會舉行項目情況會議，被稱爲「Scrum」或「每日站立會議」。 每個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上全部團隊成員都要反思這個衝刺。舉行衝刺回顧會議是爲了進行持續過程改進。

Scrum案例的一個案例：荷蘭鐵路天天要運送120萬乘客。該部門打造了一套全新的信息系統，爲乘客提供更準確的列車信息，減小人爲干預。這個PUB發佈系統，利用的就是Scrum開發模式。具體詳見：http://www.infoq.com/cn/articles/dutch-railway-scrum

3、特色分析與對比

傳統軟件工程開發模式做爲第一個被提出的科學性開發方法，使得軟件開發變得科學化、結構化，爲軟件開發提供了一套系統的開發路線。可是其缺點也在以後的數10年間顯現出來：

傳統軟件工程開發模式的出現使得一開始無序混亂的軟件開發變得有序、結構化，爲軟件開發提供了一套規整的、系統的開發路線，其一開始的確爲軟件開發帶來了很大的好處。但傳統軟件工程開發模式這種較爲單一的模式，其缺點也很快顯現出來：

• 沒法高效應對客戶需求變化大的項目
• 開發是線性的，會致使錯誤的重複累積，對最終的測試和交付環節帶來了很大的困難
• 沒有考慮對於開發中很重要的組成部分——人
• 開發過程須要填寫大量文檔交予客戶，拉低了效率

在上面的介紹中，敏捷開發能夠很好地解決上述的缺點，它的誕生其實也是爲了應對傳統軟件開發工程的不足。它的優勢在於：

• 將開發關注點聚焦於個體，注重整個團隊個體之間的交互，在協同開發中減小可能出現的問題以及加快問題的解決
• 將客戶做爲開發團隊中的一員，將客戶的需求放在第一位，使得再大的變更也能夠很快的處理
• 開發週期相應的變短，交流變多。
• 不須要撰寫過多的文檔，內部的文檔由每週一次的會議代替。

但這並不能說咱們能夠所有使用敏捷開發，拋棄傳統軟件開發，它也有其缺點，我的總結如下幾條：

• 過於急躁的求快，而致使代碼自己質量的降低，以及人員的工做量加劇
• 太過於關注需求，致使開發過程十分被動，當客戶的需求過多時，會致使團隊原有的計劃打亂
• 敏捷開發並不注重文檔，而這就要求了開發人員自身的能力比較強，可以對於同伴所寫代碼快速理解吸取
• 敏捷開發將工程週期切成一個個的小部分，缺少總體性，可能會致使系統的魯棒性降低。

在軟件需求極大的今天，咱們要針對不一樣的項目特徵使用不一樣的項目開發方法，在客戶需求可以早期基本肯定的狀況下，傳統方法，更加有效，對於項目需求不明確的項目敏捷開發更加適用。但願往後學術界可以提出更加普適的開發方法。

 

參考資料

1，維基百科：軟件工程https://en.wikipedia.org/wiki/Software_engineering

2，維基百科：瀑布模型https://en.wikipedia.org/wiki/Waterfall_model

3，MBA百科：過程增量模型http://wiki.mbalib.com/wiki/Incremental_process_model

4，維基百科：敏捷軟件開發https://en.wikipedia.org/wiki/Agile_software_development

5，CSDN博客：敏捷開發系列之旅 第四站（透明的Crystal水晶方法）http://blog.csdn.net/happylee6688/article/details/22625973

6，荷蘭鐵路公司的分佈式Scrum開發http://www.infoq.com/cn/articles/dutch-railway-scrum