敏捷式軟體開發 (Agile Software Development)與傳統軟體工程——因果篇

標籤：單元測試   詳細設計   驅動   apt   迴圈   自組織   建立   分析   修改   

因——差異之源

 

　　近來秋將盡，京中陰霾好幾日不見好轉，更有幾天雨水擾人心煩。幸得一日周末，又逢雨過天晴，秋高氣爽，撿得幾番文筆來細述敏捷式軟體開發 (Agile Software Development)與傳統軟體工程之異同。

從字面看來，二者無非是“敏捷”與“傳統”一詞之差。然而這兩個詞又同屬修飾之詞，因此就這兩個詞之差自然就是兩種開發方法的差別所在。

敏捷一詞，自然是好理解。正如眾人所云如遊俠身手之敏捷，為稱讚遊俠反映之迅速，應對變化之機敏。此處用以修飾軟體開發，我們亦可套用迅速應變之意，也就是在軟體開發過程中能迅速應對需求的改變。至於傳統，傳統一詞有許多註解，佛語曰：色不異空,空不異色。萬物並非本來實有，因緣所生。如今要用到此道理來解釋傳統。這裡傳統與敏捷結緣，自然用敏捷的反面來解釋傳統最為恰當。於是，傳統就解釋為對變化應變遲緩之意。

　　正所謂大道至簡，方才所述為敏捷與傳統字面詞意的區別，而這種區別正是敏捷式軟體開發 (Agile Software Development)與傳統軟體開發的區別根源所在。以下所述的具體差異，皆因此而生。為求思慮周全，僅用簡單羅列對比加以詳述其中的異同。

 

果——細述差異

　　僅對敏捷傳統二者詞義進行詞義進行分析，語言略顯蒼白，不能通達其中的深邃大義。在此對他們定義進行詳細說明。

所謂敏捷開發，是以客戶需要之變化為根本，用迭代、循序漸進的方法進行軟體開發。如何以使用者為根本，只能讓客戶常久持續地參與在軟體開發過程之中。然而客戶在開發方面毫無認識，又如何讓客戶參與進來？就只能給客戶看成果，提意見了。為了能讓客戶看成果，軟體開發過程中就得保證軟體是隨時可以運行進來的。敏捷開發有12條原則：

其一，遲早交軟體，持續交軟體，使客戶滿意。

其二，歡迎變更，即使在後期。

其三，交付頻率短越好。

其四，業務人員和開發人員天天一起工作。

其五，開發人員個人提供支援，並給予信任。

其六，面對面交談。

其七，把可運行軟體作為進度的首要度量標準。

其八，開發速度持續穩定。

其九，關注優秀技能和設計。

其十，簡單。

其十一，最好的架構、需求和設計出自於自組織團隊。

其十二，團隊定期反省。

　　至於傳統軟體工程，大體基於“瀑布模型”，瀑布式開發是一種傳統的電腦軟體開發，之所以叫瀑布，自然有李白描述的“飛流直下三千尺”的氣勢，不過這裡指的是一去不回頭的勢頭。它是最典型的預見性軟體開發方法，嚴格遵守計劃、分析、設計、編碼、測試、維護的步驟。相比于敏捷軟體開發，傳統式的似乎不把重點放在客戶上，而是以軟體架構(software architecture)為核心。

執行個體差異：

　　敏捷開發執行個體包括極限編程（extreme programming,XP）、自適應軟體開發（adaptive software development,ASD）、Crystal、Scrum、特性驅動編程（feature-driven development,FDD）。它是一個標準的，定義良好的，組織持續改進的過程。其中極限編程是敏捷開心使用最廣泛的方法。

　　傳統軟體工程模型包括包括瀑布模型、增量模型、螺旋模型、快速原型模型、噴泉模型等。它們的共同點是項目需要的細節是在開發之前給出的，開發過程客戶不會參與，而Team Dev會在項目開發完整後一併交給客戶。他們的一般流程是分析、設計、開發、測試、實施、維護，整個過程沒有客戶的參與。或者也可以劃分為下面幾個階段：問題定義、可行性研究，需求分析、總體設計、詳細設計、編碼與單元測試、綜合測試、軟體維護。各個階段的工作自頂向下，從抽象到具體順序進行，每個階段都必須完成規定的文檔，只有前一階段的輸出文檔正確，後一階段的工作才能獲得正確的結果。

　　這裡說到模型，就有必要給模型作一些解釋。這裡的模型指軟體開發過程模型，過程模型描述了軟體工程工作中遇到的過程相關的問題，明確了問題環境並給出了針對該問題的解決方案。

方法的應用：

1、主要目標：敏捷開發的目標是以最好的形式適應變更，最大程度地讓程式符合客戶的需要。盡量縮短可運行軟體提交的周期，提高軟體提交的頻率，來獲得更多的來自客戶的反饋。

傳統開發的目標則是在開發前使與客戶進行充分交流，提高軟體開發的可預見性、穩定性和可靠性。

2、規模：由於常變和相對較低的可靠性，敏捷開發不太適用於大規模軟體的開發。什麼叫大規模這裡不能給出較為嚴格的定義。可以想象，當規模達到一定程式時，一開始不做好詳細而細緻的規劃設計是不切實際的。

3、環境：就應用的環境來說，敏捷開發也適用於變更頻繁的環境，而傳統的軟體開發則更睛睞於穩定的，變化小的情況。

開發過程管理：

1、客戶關係：這兩種開發方法都怎麼處理好Team Dev跟客戶的關係呢？敏捷開發的根本是使用者需要，而且在開發過程中，客戶會跟開發人員在進行頻繁的交流溝通，另外還有可啟動並執行中間成果給客戶展示，這些都足以用來取得客戶對Team Dev的信任和支援。而傳統的軟體開發模式則不同，它只依賴於合約和規格說明，他們沒中間成果給使用者展示，開發過程也沒有太多的交流，整個開發過程客戶必須有耐心等待最終產品完成。而在這過程中，Team Dev只能憑靠過程的熟練程度來取得客戶的信任。

2、開發計劃的控制：敏捷開發一開始沒有制訂具體的開發計劃，計劃只能是持續地給使用者提交中間產品，並吸取客戶心聲再持續改進。而傳統軟體開發則需要制訂詳細的開發計劃，開發人員按計劃一個階段一個階段地完成開發，並按計劃與客戶進行有效溝通和協調。

3、項目的溝通：敏捷開發依賴於頻繁的開發人員和客戶之間的溝通，雖然溝通很頻繁，但是客戶對開發工作內部知識可謂是毫不知情的。這樣的客戶一般都是提一些很模糊的要求，並不能對開發人員用什麼方式去開發提供意見，更不能對軟體的內部結構進行詳細地說明，這樣難免會存在風險。而傳統的開發則是依賴於文檔開發，文檔化的知識具有明確性，但是不同的人理解起來就不太一樣，這樣沒有與客戶充分交流，同樣也存在風險。

技術：

1、軟體需求：敏捷式軟體開發 (Agile Software Development)的需求不需要很正式，也不需要很明確，甚至沒有正規的文檔說明，而只是憑著客戶提出的一些模糊的設想去進行開發，在開發過程中再去對需求進行進一步的細化。而傳統的開發則更傾向於明確的、詳細的、形式化的開發需求，而且開發過程一般不怎麼去修改需求。

2、開發：敏捷式軟體開發 (Agile Software Development)對設計的偏好是簡單。簡單的設計能以更低的成本進行改寫和快速地響應需要的變化。傳統開發則更側重於完善細緻地設計，這樣能增強開發過程的可靠性。

3、測試：敏捷開發在開發之前進行開發測試，並在開發過程中進行不斷地測試，而傳統開發的測試是對規格說明進行測試。

　　以上從各方面對二者進行了對比，但在總覺缺少點什麼。正如放翁一句“紙上得來終覺淺，絕知此事要躬行”，可審察今日這勢態，要把兩種方法都嘗試過是不切實際的了，只好另求它法。於是想到再把二者的典型方法加以介紹，想來也能寫到位了。

瀑布模型：

　　瀑布，以一氣呵成之態勢示人，此處用心修飾軟體開發的一種模型，自然是一種順序型。瀑布型屬於傳統的軟體開發模型，有人稱之為經典生命週期，它提出了一個系統的順序的軟體開發方法，從使用者需求規格說明開始，通過計劃、建模、構建和部屬的過程終能得到一個完整的軟體並提供持續的支援人員。瀑布模型有最早的軟體工程範例之稱，然時過境遷，“江山代有才人出”，老的方法終會為現代人質疑其有效性，在新的方法出現後不免被拿來與新方法做對比。由於它屬於傳統模型，自然有著傳統模型的缺點。這些缺點無非是從上文中尋來，在此再做簡單例舉。比如線性模型不可迭代性，不能確實客戶需求的模糊描述，客戶必須有耐心等待產品最終才能產生。

極限編程：

　　極限編程是敏捷開發使用最廣泛的一個方法。極限編程強調使用者和開發人員進行緊密的非正式的合作。此外，為了做到簡明，極限編程提倡開發人員只對即時需求做設計，而不考慮長遠需求。這樣能讓代碼設計簡單化，方便以後變更甚至重構。在極限編程過程中得到有效反饋來處於軟體本身、客戶和軟體開發人員。

極限編程可分為以下四個活動，而這四個活動是順迴圈執行地，重點在於迴圈。

策劃：瞭解客戶的初步需求，為軟體各功能設定權值也就是優先順序。計算成本，分配工作。

設計：設計追求簡單。為軟體功能設計實現原則，不鼓勵額外功能。

編碼：不直接開始寫代碼，而是先開發一系列用於測試本次開發功能的測試代碼。

測試：編碼前先寫好測試代碼是極限編程方法的關鍵因素。所建立的單元測試應當使用一個可以自動實施的架構。

　　文終處天色已晚。

敏捷式軟體開發 (Agile Software Development)與傳統軟體工程——因果篇