因——差異之源
近來秋將盡，京中陰霾好幾日不見好轉，更有幾天雨水擾人心煩。幸得一日週末，又逢雨過天晴，秋高氣爽，撿得幾番文筆來細述敏捷軟體開發與傳統軟體工程之異同。
從字面看來，二者無非是「敏捷」與「傳統」一詞之差。然而這兩個詞又同屬修飾之詞，因此就這兩個詞之差自然就是兩種開發方法的差別所在。
敏捷一詞，自然是好理解。正如眾人所云如遊俠身手之敏捷，為稱讚遊俠反映之迅速，應對變化之機敏。此處用以修飾軟體開發，我們亦可套用迅速應變之意，也就是在軟體開發過程中能迅速應對需求的改變。至於傳統，傳統一詞有許多註解，佛語曰：色不異空,空不異色。萬物並非本來實有，因緣所生。如今要用到此道理來解釋傳統。這裡傳統與敏捷結緣，自然用敏捷的反面來解釋傳統最為恰當。於是，傳統就解釋為對變化應變遲緩之意。
正所謂大道至簡，方才所述為敏捷與傳統字面詞意的區別，而這種區別正是敏捷軟體開發與傳統軟體開發的區別根源所在。以下所述的具體差異，皆因此而生。為求思慮周全，僅用簡單羅列對比加以詳述其中的異同。
果——細述差異
僅對敏捷傳統二者詞義進行詞義進行分析，語言略顯蒼白，不能通達其中的深邃大義。在此對他們定義進行詳細說明。
所謂敏捷開發，是以客戶需要之變化為根本，用迭代、循序漸進的方法進行軟體開發。如何以使用者為根本，只能讓客戶常久持續地參與在軟體開發過程之中。然而客戶在開發方面毫無認識，又如何讓客戶參與進來？就只能給客戶看成果，提意見了。為了能讓客戶看成果，軟體開發過程中就得保證軟體是隨時可以執行進來的。敏捷開發有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、測試：敏捷開發在開發之前進行開發測試，並在開發過程中進行不斷地測試，而傳統開發的測試是對規格說明進行測試。
以上從各方面對二者進行了對比，但在總覺缺少點什麼。正如放翁一句「紙上得來終覺淺，絕知此事要躬行」，可審察今日這勢態，要把兩種方法都嘗試過是不切實際的了，只好另求它法。於是想到再把二者的典型方法加以介紹，想來也能寫到位了。
瀑布模型：
瀑布，以一氣呵成之態勢示人，此處用心修飾軟體開發的一種模型，自然是一種順序型。瀑布型屬於傳統的軟體開發模型，有人稱之為經典生命週期，它提出了乙個系統的順序的軟體開發方法，從使用者需求規格說明開始，通過計畫、建模、構建和部屬的過程終能得到乙個完整的軟體並提供持續的技術支援。瀑布模型有最早的軟體工程範例之稱，然時過境遷，「江山代有才人出」，老的方法終會為現代人質疑其有效性，在新的方法出現後不免被拿來與新方法做對比。由於它屬於傳統模型，自然有著傳統模型的缺點。這些缺點無非是從上文中尋來，在此再做簡單例舉。比如線性模型不可迭代性，不能確實客戶需求的模糊描述，客戶必須有耐心等待產品最終才能產生。
極限程式設計：
極限程式設計是敏捷開發使用最廣泛的乙個方法。極限程式設計強調使用者和開發者進行緊密的非正式的合作。此外，為了做到簡明，極限程式設計提倡開發者只對即時需求做設計，而不考慮長遠需求。這樣能讓**設計簡單化，方便以後變更甚至重構。在極限程式設計過程中得到有效的反饋來處於軟體本身、客戶和軟體開發者。
極限程式設計可分為以下四個活動，而這四個活動是順迴圈執行地，重點在於迴圈。
策劃：了解客戶的初步需求，為軟體各功能設定權值也就是優先順序。計算成本，分配工作。
設計：設計追求簡單。為軟體功能設計實現原則，不鼓勵額外功能。
編碼：不直接開始寫**，而是先開發一系列用於測試本次開發功能的測試**。
測試：編碼前先寫好測試**是極限程式設計方法的關鍵因素。所建立的單元測試應當使用乙個可以自動實施的框架。
文終處天色已晚。
軟體開發就是軟體工程嗎
幾年前，有乙個關於軟體開發是否可以被稱為軟體工程的大辯論，這源於一篇名為 software engineering an idea whose time has come and gone?的文章，作者是tom demarco。demarco認為，短命的軟體開發已經死去，這對於所謂軟體 變革 的建立...
軟體工程和軟體開發流程
人們在開發 運營 維護軟體的過程中有很多技術 做法 習慣和思想體系。軟體工程把這些相關的技術和過程統一到乙個體系中，叫 軟體開發流程 軟體開發流程的目的是為了提高軟體開發 運營 維護的效率，並提高軟體的質量 使用者滿意度 可靠性和軟體的可維護性。program data structure algo...
敏捷軟體開發
敏捷軟體開發 英語 agile software development 又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱 理念 過程 術語都不盡相同，相對於 非敏捷 更強調程式設計師團隊與業務專家之間的緊密協作...