１.[b]它允許需求的變化[/b]。需求的變化和「進一步的蔓延」 — 技術和客戶驅動的特性的累加 — 一直是專案中導致麻煩、延期交付、令客戶不滿意和使開發人員洩氣的主要原因。為了解決這些問題，使用迭代開發方法的團隊應該在專案開發的幾周裡就關注生成和演示可執行的軟體，這樣就強制了需求的檢查並可以幫助減少需求從而反映系統的本質。
２.[b]整合不是在專案的尾聲進行的"大動作"[/b]。將系統的整合留到專案的結尾幾乎總是會導致耗時的返工 — 有時這種返工會花費整個專案工作量的百分之四十的時間。為了避免這種返工，每一次迭代都以整合構建系統各部分結束；這樣不斷的積累將最小化日後的返工。
３.[b]早期的迭代可以暴露風險[/b]。迭代的開發方法可以幫助團隊在早期的迭代中減少風險，因為在這些迭代中包括了對所有過程元件的測試。當早期的迭代覆蓋了專案的很多方面時 — 工具、購買的軟體和團隊成員的技能等等 — 團隊能夠很快的發現被預感的風險是否是真實的，並且能夠在問題相對容易並花費很少成本解決時揭示沒有被發現的新的風險。
４.[b]對產品的管理能夠採取戰術性的變化[/b]。迭代開發能夠快速的生成可執行的架構（雖然功能有限），這個架構能夠為了應對競爭對手的快速版本發布容易的調整產品使之成為」輕量級的「或者「改進的」版本。
５．[b]它使重用更加容易[/b]。識別在迭代中進行的部分設計和實現的公用部分要比在計畫期間找出公用部分更加容易。在早期開發中的設計評審允許架構師們發現潛在的可重用的機會，並且利用這個機會為接下來的迭代開發成熟的公用**。
６．[b]你能夠在每乙個迭代中發現並更正缺陷[/b]。這會生成健壯的架構和高質量的應用。你甚至能夠在早期的迭代中而不是在專案末期的大規模測試階段發現缺陷。你能夠在效能瓶頸沒有破壞你的計畫之前發現它。
７．[b]它能夠更好的利用專案的人員資源[/b]。很多開發組織使用一種管道式的組織方式來匹配他們的瀑布型開發方法：分析人員將被完成的需求傳送給設計人員，設計人員將被完成的設計傳送給開發程式設計人員，程式設計人員再將他們開發的元件傳送給集**員，集**員將元件整合起來傳送給測試人員測試。這種多次的傳遞不僅容易產生錯誤而且應用造成誤解；這種方式也會使人們感覺他們對最終的產品有很少的責任。迭代開發過程鼓勵在專案的各個環節中團隊成員參與範圍更加寬廣的活動，允許團隊成員扮演多種角色。專案經理能夠更好的利用可得到的專案人員並其可以消除有風險的傳遞。
８．[b]團隊成員能夠沿著專案的道路進行學習[/b]。工作在迭代開發的專案中的開發人員在軟體開發周期內有很多的機會從他們所範的錯誤中吸取教訓，並能夠從乙個迭代到另乙個迭代的過程中增進他們的技能。通過評估每乙個迭代，專案經理能夠為團隊成員發現培訓的機會。相反，工作在瀑布型開發方法中的開發人員典型的被限制在狹窄的技術專長上，並且僅僅有機會從事設計、編碼或者測試之一方面的工作。
９．[b]你能夠沿著專案的道路改進開發的過[/b]程。迭代末尾的評估不僅能夠從產品或者計畫方面揭示專案的狀態；他們也可以幫助專案經理分析在下乙個迭代中如何改進專案的組織結構和過程。
迭代開發優點
它允許需求的變化。需求的變化和 進一步的蔓延 技術和客戶驅動的特性的累加 一直是專案中導致麻煩 延期交付 令客戶不滿意和使開發人員洩氣的主要原因。為了解決這些問題，使用迭代開發方法的團隊應該在專案開發的幾周裡就關注生成 和演示可執行的軟體，這樣就強制了需求的檢查並可以幫助減少需求從而反映系統的本質。...
領域驅動開發的優點
一直以來，j2ee的開發過程 以struts hibernate spring為例 都是這樣的 1.設計資料庫 2.生成資料庫 3.從工程裡建立資料庫連線 4.把資料庫反向工程生成pojo 5.最後才能進行開發工作 如果需求發生了變更或者發現了資料庫的設計錯誤，那麼所有步驟都要再來一遍，工作繁瑣無比...
分布式開發的優點
分布式開發的優點 絕大部分傳統軟體是執行於單機系統之上的，它們的使用者介面 應用的業務流程以及持久化資料都會駐留於同一臺使用匯流排或電纜來連線外部裝置的計算機 上。不過，現今備受關注的系統中，幾乎沒有哪個還保有這種設計。如今，大多數計算機軟體都執行在分布式系統中，其互動介面 應用的業務流程以及資料資...