因——差異之源
近來秋將盡，京中陰霾好幾日不見好轉，更有幾天雨水擾人心煩。幸得一日周末，又逢雨過天晴，秋高氣爽，撿得幾番文筆來細述敏捷軟件開發與傳統軟件工程之異同。
從字面看來，二者無非是“敏捷”與“傳統”一詞之差。然而這兩個詞又同屬修飾之詞，因此就這兩個詞之差自然就是兩種開發方法的差別所在。
敏捷一詞，自然是好理解。正如眾人所云如游俠身手之敏捷，為稱贊游俠反映之迅速，應對變化之機敏。此處用以修飾軟件開發，我們亦可套用迅速應變之意，也就是在軟件開發過程中能迅速應對需求的改變。至于傳統，傳統一詞有許多注解，佛語曰：色不異空,空不異色。萬物并非本來實有，因緣所生。如今要用到此道理來解釋傳統。這里傳統與敏捷結緣，自然用敏捷的反面來解釋傳統最為恰當。于是，傳統就解釋為對變化應變遲緩之意。
正所謂大道至簡，方才所述為敏捷與傳統字面詞意的區別，而這種區別正是敏捷軟件開發與傳統軟件開發的區別根源所在。以下所述的具體差異，皆因此而生。為求思慮周全，僅用簡單羅列對比加以詳述其中的異同。
果——細述差異
僅對敏捷傳統二者詞義進行詞義進行分析，語言略顯蒼白，不能通達其中的深邃大義。在此對他們定義進行詳細說明。
所謂敏捷開發，是以客戶需要之變化為根本，用迭代、循序漸進的方法進行軟件開發。如何以用戶為根本，只能讓客戶常久持續地參與在軟件開發過程之中。然而客戶在開發方面毫無認識，又如何讓客戶參與進來？就只能給客戶看成果，提意見了。為了能讓客戶看成果，軟件開發過程中就得保證軟件是隨時可以運行進來的。敏捷開發有12條原則：
其一，遲早交軟件，持續交軟件，使客戶滿意。
其二，歡迎變更，即使在后期。
其三，交付頻率短越好。
其四，業務人員和開發人員天天一起工作。
其五，開發人員個人提供支持，并給予信任。
其六，面對面交談。
其七，把可運行軟件作為進度的首要度量標準。
其八，開發速度持續穩定。
其九，關注優秀技能和設計。
其十，簡單。
其十一，最好的架構、需求和設計出自于自組織團隊。
其十二，團隊定期反省。
至于傳統軟件工程，大體基于“瀑布模型”，瀑布式開發是一種傳統的計算機軟件開發，之所以叫瀑布，自然有李白描述的“飛流直下三千尺”的氣勢，不過這里指的是一去不回頭的勢頭。它是最典型的預見性軟件開發方法，嚴格遵守計劃、分析、設計、編碼、測試、維護的步驟。相比于敏捷軟件開發，傳統式的似乎不把重點放在客戶上，而是以軟件架構(software architecture)為核心。
實例差異：
敏捷開發實例包括極限編程（extreme programming,XP）、自適應軟件開發（adaptive software development,ASD）、Crystal、Scrum、特性驅動編程（feature-driven development,FDD）。它是一個標準的，定義良好的，組織持續改進的過程。其中極限編程是敏捷開心使用最廣泛的方法。
傳統軟件工程模型包括包括瀑布模型、增量模型、螺旋模型、快速原型模型、噴泉模型等。它們的共同點是項目需要的細節是在開發之前給出的，開發過程客戶不會參與，而開發團隊會在項目開發完整后一并交給客戶。他們的一般流程是分析、設計、開發、測試、實施、維護，整個過程沒有客戶的參與。或者也可以劃分為下面幾個階段：問題定義、可行性研究，需求分析、總體設計、詳細設計、編碼與單元測試、綜合測試、軟件維護。各個階段的工作自頂向下，從抽象到具體順序進行，每個階段都必須完成規定的文檔，只有前一階段的輸出文檔正確，后一階段的工作才能獲得正確的結果。
這里說到模型，就有必要給模型作一些解釋。這里的模型指軟件開發過程模型，過程模型描述了軟件工程工作中遇到的過程相關的問題，明確了問題環境并給出了針對該問題的解決方案。
方法的應用：
1、主要目標：敏捷開發的目標是以最好的形式適應變更，最大程度地讓程序符合客戶的需要。盡量縮短可運行軟件提交的周期，提高軟件提交的頻率，來獲得更多的來自客戶的反饋。
傳統開發的目標則是在開發前使與客戶進行充分交流，提高軟件開發的可預見性、穩定性和可靠性。
2、規模：由于常變和相對較低的可靠性，敏捷開發不太適用于大規模軟件的開發。什么叫大規模這里不能給出較為嚴格的定義。可以想象，當規模達到一定程序時，一開始不做好詳細而細致的規劃設計是不切實際的。
3、環境：就應用的環境來說，敏捷開發也適用于變更頻繁的環境，而傳統的軟件開發則更睛睞于穩定的，變化小的情況。
開發過程管理：
1、客戶關系：這兩種開發方法都怎么處理好開發團隊跟客戶的關系呢？敏捷開發的根本是用戶需要，而且在開發過程中，客戶會跟開發人員在進行頻繁的交流溝通，另外還有可運行的中間成果給客戶展示，這些都足以用來取得客戶對開發團隊的信任和支持。而傳統的軟件開發模式則不同，它只依賴于合同和規格說明，他們沒中間成果給用戶展示，開發過程也沒有太多的交流，整個開發過程客戶必須有耐心等待最終產品完成。而在這過程中，開發團隊只能憑靠過程的熟練程度來取得客戶的信任。
2、開發計劃的控制：敏捷開發一開始沒有制訂具體的開發計劃，計劃只能是持續地給用戶提交中間產品，并吸取客戶意見再持續改進。而傳統軟件開發則需要制訂詳細的開發計劃，開發人員按計劃一個階段一個階段地完成開發，并按計劃與客戶進行有效的溝通和協調。
3、項目的溝通：敏捷開發依賴于頻繁的開發人員和客戶之間的溝通，雖然溝通很頻繁，但是客戶對開發工作內部知識可謂是毫不知情的。這樣的客戶一般都是提一些很模糊的要求，并不能對開發人員用什么方式去開發提供意見，更不能對軟件的內部結構進行詳細地說明，這樣難免會存在風險。而傳統的開發則是依賴于文檔開發，文檔化的知識具有明確性，但是不同的人理解起來就不太一樣，這樣沒有與客戶充分交流，同樣也存在風險。
技術：
1、軟件需求：敏捷軟件開發的需求不需要很正式，也不需要很明確，甚至沒有正規的文檔說明，而只是憑著客戶提出的一些模糊的設想去進行開發，在開發過程中再去對需求進行進一步的細化。而傳統的開發則更傾向于明確的、詳細的、形式化的開發需求，而且開發過程一般不怎么去修改需求。
2、開發：敏捷軟件開發對設計的偏好是簡單。簡單的設計能以更低的成本進行改寫和快速地響應需要的變化。傳統開發則更側重于完善細致地設計，這樣能增強開發過程的可靠性。
3、測試：敏捷開發在開發之前進行開發測試，并在開發過程中進行不斷地測試，而傳統開發的測試是對規格說明進行測試。
以上從各方面對二者進行了對比，但在總覺缺少點什么。正如放翁一句“紙上得來終覺淺，絕知此事要躬行”，可審察今日這勢態，要把兩種方法都嘗試過是不切實際的了，只好另求它法。于是想到再把二者的典型方法加以介紹，想來也能寫到位了。
瀑布模型：
瀑布，以一氣呵成之態勢示人，此處用心修飾軟件開發的一種模型，自然是一種順序型。瀑布型屬于傳統的軟件開發模型，有人稱之為經典生命周期，它提出了一個系統的順序的軟件開發方法，從用戶需求規格說明開始，通過計劃、建模、構建和部屬的過程終能得到一個完整的軟件并提供持續的技術支持。瀑布模型有最早的軟件工程范例之稱，然時過境遷，“江山代有才人出”，老的方法終會為現代人質疑其有效性，在新的方法出現后不免被拿來與新方法做對比。由于它屬于傳統模型，自然有著傳統模型的缺點。這些缺點無非是從上文中尋來，在此再做簡單例舉。比如線性模型不可迭代性，不能確實客戶需求的模糊描述，客戶必須有耐心等待產品最終才能產生。
極限編程：
極限編程是敏捷開發使用最廣泛的一個方法。極限編程強調用戶和開發者進行緊密的非正式的合作。此外，為了做到簡明，極限編程提倡開發者只對即時需求做設計，而不考慮長遠需求。這樣能讓代碼設計簡單化，方便以后變更甚至重構。在極限編程過程中得到有效的反饋來處于軟件本身、客戶和軟件開發者。
極限編程可分為以下四個活動，而這四個活動是順循環執行地，重點在于循環。
策劃：了解客戶的初步需求，為軟件各功能設置權值也就是優先級。計算成本，分配工作。
設計：設計追求簡單。為軟件功能設計實現原則，不鼓勵額外功能。
編碼：不直接開始寫代碼，而是先開發一系列用于測試本次開發功能的測試代碼。
測試：編碼前先寫好測試代碼是極限編程方法的關鍵因素。所建立的單元測試應當使用一個可以自動實施的框架。
文終處天色已晚。
文章列表
留言列表
