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

標籤：利用   開發項目   humble   電腦   目的   水晶   png   長度   需要   

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

本文寫作的主題為介紹在軟體工程領域流行的兩種軟體開發模式——敏捷式軟體開發 (Agile Software Development)與傳統軟體工程，以及它們的優缺點。

一、傳統軟體工程

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.計划下一個階段，一圈如同原型模型開發的過程。

 

二、敏捷式軟體開發 (Agile Software Development)(Agile software development)

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

在2001,17名軟體開發人員在Snowbird會議上發布了敏捷式軟體開發 (Agile Software Development)宣言(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天的周期，其長度由Team Dev決定）當中，Team Dev建立可用的（可以隨時推出）軟體的一個增量。在衝刺中，每一天都會舉行項目狀況會議，被稱為“Scrum”或“每日站立會議”。 每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是為了進行持續流程改善。

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

三、特點分析與對比

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

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

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

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

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

但這並不能說我們可以全部使用敏捷開發，拋棄傳統軟體開發，它也有其缺點，個人總結以下幾條：

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

在軟體需求極大的今天，我們要針對不同的項目特徵使用不同的項目開發方法，在客戶需求能夠早期基本確定的情況下，傳統方法，更加有效，對於項目需求不明確的項目敏捷開發更加適用。希望日後學術界能夠提出更加普適的開發方法。

 

參考資料

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，維基百科：敏捷式軟體開發 (Agile Software Development)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

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