管理從磚瓦進化爲人——淺談傳統軟件工程到敏捷軟件開發之變革

管理從磚瓦進化爲人

——淺談傳統軟件工程到敏捷軟件開發之變革

前言

 

若是把軟件開發過程比做修築一座建築的話，傳統的軟件工程方法對人的管理就像是把人化做一磚一瓦，秩序地堆砌，一層一層構建起摩天大廈。

顯然地，人是不一樣於磚瓦那樣的死物的。人做爲一種複雜的動物，軟件開發者會有喜怒哀樂，枯燥重複的工做內容會使他們提不起興趣而缺少激情；客戶想法會隨變更的現實而一每天有所轉變，軟件需求很難保持一成不變；開發者與測試者對於項目的認識會存在差別，而差別將致使效率的下降……於是傳統的有些「反人類天性」的軟件開發方式也就天然而然會產生諸多矛盾與問題，在整個開發過程當中不斷帶來負面影響與做用。

敏捷軟件開發價值觀的提出，像是無機物原子忽然間化做有機物，有機物構建成爲生命，讓軟件開發開始擺脫「比照着藍圖堆砌磚瓦」的模式，一步步把軟件開發管理的根本回歸到人自己，讓人從磚瓦從新進化爲了人。

筆者試着運用較爲生動的類比，從開發者、客戶、軟件自己等多個視角，闡述傳統軟件開發到敏捷軟件開發的變革帶來的進步與益處。

欲言其弊，則必先言其質。首先筆者將對傳統軟件開發進行一個較爲全面客觀的描述，其中的不少軟件開發的標準與思想其實是準確且貼合實際的，於是並不能片面地認爲傳統軟件開發即是落後陳舊的，相反，其中提出的衆多標準與思想是經久不衰的，從此還將繼續指導咱們軟件工程方法的探索與發展，值得咱們學習和參考。

傳統軟件開發

       軟件開發方法誕生至今產生了許多模型與方法，通常來說，傳統軟件開發方法是指瀑布模型、螺旋模型、噴泉模型、RUP(Rational Unified Process)這4個重型軟件開發方法。其共同的特色是注重文檔的完整性，程序的易讀性，結構的完整性，它們在公司的大型軟件開發中普遍地獲得運用。

軟件開發標準

軟件開發是一個把用戶須要轉化爲軟件需求，把軟件需求轉化爲軟件設計，用軟件代碼來實現軟件設計，對軟件代碼進行測試，並簽署確認它能夠投入運行使用的過程。在這個過程當中的每個階段，都包含有響應的文檔編制工做。

判斷一個軟件的好壞，是沒有什麼絕對標準的，但一些定性的準則，能夠判斷什麼樣的軟件更好一些。

（1）    正確性

正確性是指軟件符合規定的需求的程度。正確的軟件具有且僅具有軟件「規格說明」中所列舉的所有功能，可以在預期的環境下完成規定的工做。

（2）    可靠性

可靠性指的是在規定的條件和時間內軟件不引發系統失效的機率。它主要取決於正確性和健壯性兩個方面。正確性如前所述；健壯性則是指系統萬一遇到意外時能按照某種預約的方式作出適當的處理，從而避免出現災難性的後果。

（3）    簡明性

簡明性是要求軟件簡明易讀。好的軟件設計風格有助於軟件達到簡明性要求。軟件應當結構清晰，編排得體，容易看懂，最重要的是不要人爲地增長複雜性。

（4）    有效性

有效性是指軟件的時間效率和空間效率要高。

（5）    可維護性

可維護性指的是軟件可以修改和升級的容易程度。它目前已經成爲愈來愈重要的軟件開發標準。好的可維護性要求軟件有好的可讀性、可修改性和可測試性。

（6）    適應性

適應性是指軟件使不一樣的系統約束條件和用戶需求獲得知足的容易程度。它要求軟件儘量適應各類軟、硬件運行環境，以便軟件的推廣和移植。

傳統軟件開發的階段

從工程學角度出發，軟件開發過程包括計劃、分析、設計、編碼、測試和維護等幾個階段，如圖所示。

 

這也就是咱們通常意義上講的瀑布模型。

瀑布模型

       瀑布模型(Waterfall Model)是由Royce在1970年提出的。該模型最先強調系統開發應有完整之週期，且必須完整的經歷週期之每一開發階段，並系統化的考量分析與設計的技術、時間與資源之投入等，所以瀑布模型又能夠稱爲‘系統發展生命週期’（System Development Life Cycle, SDLC）。

因爲該模式強調系統開發過程需有完整的規劃、分析、設計、測試及文件等管理與控制，所以能有效的確保系統品質。它像工廠流水線同樣，把軟件開發過程分紅各類工序，而且每一個工序能夠根據軟件產品的規模、參與人員的多少進一步細分紅爲更細的工序。每一個工序中的人員僅僅須要面對本身所負責的內容，而沒必要考慮除此之外其餘工序的實施方式。該模型以其很是符合軟件工程學分層設計思路的特色，成爲了軟件開發企業使用最多的開發模型。

瀑布模型的特色

一、強調文檔，前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的惟一信息。因此不少開發人員好象是在開發文檔，而不是開發軟件，由於要到開發的後期，才能夠看到軟件的「模樣」。

二、沒有迭代與反饋。瀑布模型對反饋沒有涉及，因此對變化的客戶需求很是不容易適應，瀑布就意味着沒有回頭路。

三、能夠把文檔理解爲開發的速度，管理人員能方便地界定不一樣階段的里程碑。

瀑布模型的缺點

Royce提倡重複地使用瀑布模型，以一種迭代的方式。可是，大多數人並不知道這一點，一些人也不相信它能被應用在現實生活中，由於過程不多可以以連續由上而下的方式進行。常常會須要回到前面的階段，或改變前一階段的結果。諷刺的是，在Royce 1970年的那篇文章中他提到：這種模型的目的是做爲用來講明這種模式有缺陷，而不適用。事實上，軟件開發相關文章中對這個名詞的大量引用正是對這個普遍流行的軟件開發作法的一種評判。

瀑布模型的缺點有五：

一、這種模型依賴於早期進行的惟一一次需求調查，當客戶難以表達真正的需求或發生須要求變動時，這種模型沒法解決具備二義性問題存在的問題， 並難以適應用戶需求的變化。

二、瀑布模型風險的暴露時間滯後，每每要延遲至後期的開發階段才顯露出來，於是失去及早糾正的機會。

三、有可能出現「堵塞狀態」。採用這種線性模型，在過程的開始和結束時會常常碰到等待其餘成員完成其所依賴的任務才能進行下去的狀況，從而有可能花在等待的時間比開發的時間要長。

四、因爲是單一流程，在項目各階段之間極少有反饋，開發中的經驗教訓不能反饋應用於本產品的過程。

五、因爲經過過多的強制完成日期和里程碑來跟蹤各個項目階段，使開發者將大量時間和精力放在定製的文檔中，增大了工做量。

 

瀑布模型的用戶不少，但反對的意見一直接連不斷，筆者認爲，其基於軟件文檔的開發形式是最本質的問題所在。把開發者變成磚瓦，去堆砌事先規劃好的設計圖紙，然而事實上，磚瓦會由於工做的枯燥而缺少激情，原先的圖紙會隨着時間推移暴露出設計缺陷，最終客戶手到的建築或許已不是客戶當前真正想要的樣子，同時漫長的開發週期也讓需求急迫而需求軟件規模較小的客戶苦惱不已。

在這樣的背景之下，以極限編程(extreme Programming,xp)爲首的敏捷軟件開發方法逐漸在軟件開發業界掀起變革的風潮。

敏捷軟件開發(Agile Software Development)

       幾乎全部富有個性的程序員都有這樣一個觀點，軟件開發應具備藝術性，這也是筆者所認同的一種思想：「編程自己是一種個體的，富有靈感的、邏輯性強的活動，可是現代的軟件開發更是一種羣體活動。」

       敏捷軟件開發是一種從1990年代開始鑄劍引發普遍關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於「非敏捷」，更強調開發團隊與業務專家之間的緊密協做、面對面的溝通（而不是書面的文檔）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好地適應需求變化的代碼編寫和團隊組織方法，換句話說，也就是更注重軟件開發過程當中人的做用。

       接下來先對敏捷開發進行一個簡單的介紹：

敏捷聯盟

 

       敏捷(Agile)一詞最先來源於2001年初美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者的聚會。他們彙集在一塊兒歸納出了一些可讓軟件開發團隊具備快速工做、響應變化能力的價值觀(value)和原則。他們稱本身爲敏捷聯盟(Agile Alliance)。在隨後的幾個月中，他們建立出了一份價值觀聲明，也就是敏捷聯盟宣言(The Manifesto of the Agile Alliance)。

       在筆者看來，這份宣言高度凝鍊地歸納了當下軟件開發的思想和要素，將以人爲本的思想具象化到了軟件開發方法中，極富吸引力又與實際牢牢貼合。若是把軟件開發的變革比做人類進化，那麼這一宣言的誕生，就彷彿矇昧的人類第一次擁有了語言和文字。

敏捷聯盟宣言

在敏捷聯盟的網站首頁寫着以下內容：

 

咱們一直在實踐中探尋更好的軟件開發方法，

身體力行的同時也幫助他人。由此咱們創建了以下價值觀：

l  個體和互動 高於 流程和工具

l  工做的軟件 高於 詳盡的文檔

l  客戶合做 高於 合同談判

l  響應變化 高於 遵循計劃

就是說，儘管右項有其價值，

咱們更重視左項的價值。

 

第一條價值陳述認識到，流程和工具的本質是服務於個體和互動的，這與業界傳統的以文檔編寫爲核心的方法偏偏相反，強調了我的是獨一無二的，於是互動聯繫必須更加緊密、直接，即面對面的交流。

一樣，相較於一份嚴謹、宏觀、詳盡的文檔，開發團隊與客戶真正關心的主體，必定是在於最終產品——一個能實際工做的軟件上。換句話講，將軟件開發過程當中文檔交付的決定權返還給項目組，由他們本身決定哪些文檔是非有不可的。與其管理者循規蹈矩地苛求開發人員循序漸進，不如由開發團隊來選擇更有效率的內部運做方式。與此同時，在當下的軟件開發環境裏，瞬息萬變的形勢與需求並不能容許開發團隊在文檔計劃階段過分停滯，一個快速產出的能解決眼前核心需求的工做軟件遠賽過歷時久遠、深謀遠慮的鴻篇鉅製。快速的版本迭代、適應形勢的動態維護，無疑更能適應這個時代。

軟件開發的過程實際上相似於人與人交流的過程，只有持續不斷的溝通，才能準確無誤地領會對方所要傳答的意思。比起經過死板的外部合同規定，客戶和供應商的團隊協做多是最好的解決方案。合同只提供邊界條件，保證參與者的工做，但只有不斷協調合做，開發團隊纔有但願交付客戶須要的產品。

俗話說「計劃趕不上變化快」。忠實地執行計劃在軟件開發中並非一件那麼好的事，不管是多麼詳細的計劃，若是它會阻礙人的隨機應變，那麼它就會變得很危險。所以開發團隊必須足夠敏捷，不斷適應外部的變化，才能取得成功。

敏捷宣言遵循的原則

• 對咱們而言，最重要的是經過儘早和不斷交付有價值的軟件知足客戶須要。
• 咱們歡迎需求的變化，即便在開發後期。敏捷過程可以駕馭變化，保持客戶的競爭優點。
• 常常交付能夠工做的軟件，從幾星期到幾個月，時間尺度越短越好。
• 業務人員和開發者應該在整個項目過程當中始終朝夕在一塊兒工做。
• 圍繞鬥志高昂的人進行軟件開發，給開發者提供適宜的環境，知足他們的須要，並相信他們可以完成任務。
• 在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。
• 能夠工做的軟件是進度的主要度量標準。
• 敏捷過程提倡可持續開發。出資人、開發人員和用戶應該老是維持不變的節奏。
• 對卓越技術與良好設計的不斷追求將有助於提升敏捷性。
• 簡單——儘量減小工做量的藝術相當重要。
• 最好的架構、需求和設計都源自自我組織的團隊。
• 每隔必定時間，團隊都要總結如何更有效率，而後相應地調整本身的行爲。

敏捷方法

       敏捷方法是一個開發軟件的管理新模式，用來替代以文檔驅動開發的瀑布開發模式。敏捷方法也稱輕量級開發方法。根據環境的變化，修改本身的設計，指導開發的方向是敏捷開發的目標。

敏捷開發避免了傳統瀑布方式的弊端，主要是吸取了各類新型開發模式的「動態」特性，關注點從文檔到開發者，管理方式上實現了開發者從磚瓦進化爲人的過程。

敏捷方法的特色

一、以人爲本，注重編程中人的自我特長髮揮。

二、強調軟件開發的產品是軟件，而不是文檔。文檔是爲軟件開發服務的，而不是開發的主體。

三、客戶與開發者的關係是協做，不是合約。開發者不是客戶業務的「專家」，要適應客戶的需求，是要客戶合做來闡述實際的需求細節，而不是爲了開發軟件，把開發人員變成客戶業務的專家，這是傳統開發模式或行業軟件開發企業的最大面臨問題。

四、設計周密是爲了最終軟件的質量，但不代表設計比實現更重要，要適應客戶需求的不斷變化，設計也要不斷跟進，因此設計不能是「閉門造車」、「自我良好」，能不斷根據環境的變化，修改本身的設計，指導開發的方向是敏捷開發的目標。

敏捷方法的核心思想

• 迭代。軟件的功能是客戶的需求，界面的操做是客戶的「感受」，對迭代的強調是縮短了軟件版本的週期
• 客戶參與。以人爲本，客戶是軟件的使用者，是業務理解的專家，沒有客戶的參與，開發者很難理解客戶的真實需求
• 小版本。快速功能的展示，看似簡單，但對於複雜的客戶需求，合理地分割與整體上的統一，要很好地兩者兼顧是不容易的。

總結

       敏捷開發是一種全新而快捷的軟件開發方法，在很大程度上是關於程序員能夠生成簡單、靈活性高的軟件技術。測試、連續集成以及重構，這些關鍵實踐結合在一塊兒可使設計風格比計劃更具可進化性。在當下需求多變的環境裏，這樣的風格無疑是最爲重要的。

參考文獻

[1]周瑩瑩. 敏捷軟件開發技術研究[D].長春理工大學,2006.

[2]wikipedia:Agile software development

https://en.wikipedia.org/wiki/Agile_software_development

[3]wikipedia:瀑布模型

https://zh.wikipedia.org/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B

[4]郭曉嫺. 淺析瀑布模型[J]. 福建電腦,2011,07:137-138.

[5]agilemanifesto:

http://agilemanifesto.org/iso/zhchs/manifesto.html

[6]Jack zhai. 瀑布模型、極限編程到敏捷開發---軟件開發管理者思惟的變化

http://zhaisj.blog.51cto.com/219066/46187