瀑布模型開發：
嚴格把軟體專案的開發分隔成各個開發階段：需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。
使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。
強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷彿已經超過了**的重要性。
瀑布模型把開發人員定義為流水線上的工人。由於各階段的開發人員只能接觸到自己工作範圍內的東西，所以對客戶需求的理解程度高低不等。對於客戶需求變更，編碼人員會比設計人員更容易產生很強的牴觸情緒。
在每個開發階段都會有一些資訊刻意的不讓其他開發階段的人員知道（本意是為了提到效率，但實際上有時候產生的是互相的理解偏差）。
瀑布模型產生的管理文件(計畫書，進度表)等，能讓不太了解該項目的人也能看懂專案的進度情況（只有能看懂百分比就行），很適合向領導匯報用。所以管理人員比較喜歡瀑布模型，但是開發人員不喜歡，因為它束縛了開發人員的創造性。
既然叫做瀑布，就意味著不應該走回頭路。否則如果出現返工，付出的代價會很大。
軟體生命週期前期造成的bug的影響比後期的大的多。
敏捷開發：
核心是迭代。
因為最終目標是讓客戶滿意，所以能夠主動接受需求變更，這就使設計出來的軟體有靈活性，可擴充套件性。
宣言：個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
簡單設計，重複迭代。減少不必要的文件。
客戶最關心的功能最先完成。
要求客戶有時間對每次迭代的成果進行確認，提出改進意見。
溝通是非常重要的，所有的開發人員對專案活動的理解應該是一致的。
開發團隊有兩個隊伍，業務團隊和技術團隊。如果任何一方控制了溝通，那麼專案注定會失敗。如果業務一方控制，專案會議上就會不斷的要求功能和交付日，而不太擔心開發人員是否能夠全部完成或開發人員是否明白他們的真正要求；如果開發人員控制了溝通，那麼專案會議上技術術語會代替面向客戶的業務語言，開發人員也失去了通過傾聽來了解客戶真正需求的機會。
pmbok的專案管理是自上而下的命令式管理，而敏捷的管理是團隊的自我管理和專案經理的服務式管理。
敏捷開發不能在一開始就給出專案的成本計畫。
在有技術問題還沒有解決的情況下不適合展開迭代。
敏捷 瀑布模型
敏捷模型 核心是快速迭代，擁抱變化。以使用者的需求進化為核心，採用迭代 循序漸進的方法進行軟體開發。因為最終目標是讓客戶滿意，所以能夠主動接受需求變更，這就使設計出來的軟體有靈活性，可擴充套件性。宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應...
瀑布模型 迭代模型和敏捷開發
瀑布模型 瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計畫 需求分析 軟體設計 程式編寫 軟體測試和執行維護等六個基本活動，並且規定了它們自上而下 相互銜接的固定次序，如同瀑布流水，逐級下落。...
敏捷開發和瀑布開發的區別
個人覺得 敏捷開發強調以人為中心,快速迭代，客戶參與多溝通，減少不必要的文件,包括scrum和xp 優點 快速適應變化,做出的專案比較接近客戶需要的 缺點 文件不多，如果人員流動大，維護相對更難 瀑布開發強調文件，就是不同階段按照順序自上而下而來，如需求 設計 編碼 測試 單元測試 系統測試 維護，...