- 瀑布模型開發：
嚴格把軟件項目的開發分隔成各個開發階段：需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。
- 使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。
- 強調文檔，在開發的後期纔會看到軟件的模樣。在這種情況下，文檔的重要性彷彿已經超過了代碼的重要性。
瀑布模型把開發人員定義爲流水線上的工人。由於各階段的開發人員只能接觸到自己工作範圍內的東西，所以對客戶需求的理解程度高低不等。對於客戶需求變更，編碼人員會比設計人員更容易產生很強的抵觸情緒。
在每個開發階段都會有一些信息刻意的不讓其他開發階段的人員知道（本意是爲了提到效率，但實際上有時候產生的是互相的理解偏差）。
瀑布模型產生的管理文檔(計劃書，進度表)等，能讓不太瞭解該項目的人也能看懂項目的進度情況（只有能看懂百分比就行），很適合向領導彙報用。所以管理人員比較喜歡瀑布模型，但是開發人員不喜歡，因爲它束縛了開發人員的創造性。
既然叫做瀑布，就意味着不應該走回頭路。否則如果出現返工，付出的代價會很大。
軟件生命週期前期造成的Bug的影響比後期的大的多。
- 敏捷開發：
核心是迭代。
因爲最終目標是讓客戶滿意，所以能夠主動接受需求變更，這就使設計出來的軟件有靈活性，可擴展性。
宣言：
個體和交互 勝過 過程和工具
可以工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
簡單設計，重複迭代。減少不必要的文檔。
客戶最關心的功能最先完成。
要求客戶有時間對每次迭代的成果進行確認，提出改進意見。
溝通是非常重要的，所有的開發人員對項目活動的理解應該是一致的。
開發團隊有兩個隊伍，業務團隊和技術團隊。如果任何一方控制了溝通，那麼項目註定會失敗。如果業務一方控制，項目會議上就會不斷的要求功能和交付日，而不太擔心開發人員是否能夠全部完成或開發人員是否明白他們的真正要求；如果開發人員控制了溝通，那麼項目會議上技術術語會代替面向客戶的業務語言，開發人員也失去了通過傾聽來了解客戶真正需求的機會。
PMBOK的項目管理是自上而下的命令式管理，而敏捷的管理是團隊的自我管理和項目經理的服務式管理。
敏捷開發不能在一開始就給出項目的成本計劃。
在有技術問題還沒有解決的情況下不適合展開迭代。
理解二：
瀑布模型的特點：
（傳統的開發方式）
1、強調文檔
前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的唯一信息。所以很多開發人員好象是在開發文檔，而不是開發軟件，因爲要到開發的後期纔可以看到軟件的“模樣”。
2、沒有迭代與反饋。瀑布模型對反饋沒有涉及，所以對變化的客戶需求非常不容易適應。瀑布就意味着沒有回頭路。
3、管理人員喜歡瀑布模型的原因是把文檔理解爲開發的速度，可以方便地界定不同階段的里程碑。
敏捷開發
極限編程的思想體現了適應客戶需求的快速變化，激發開發者的熱情，也是目前敏捷開發思維的重要支持者。
敏捷軟件開發是一個開發軟件的管理新模式，用來替代以文件驅動開發的瀑布開發模式。
敏捷開發集成了新型開發模式的共同特點，它重點強調：
1.敏捷就是“快”。快纔可以適應目前社會的快節奏，要快就要發揮個人的個性思維多一些個性思維的增多。
2.客戶參與。以人爲本，客戶是軟件的使用者，是業務理解的專家，沒有客戶的參與，開發者很難理解客戶的真實需求。
3.強調軟件開發的產品是軟件，而不是文檔。文檔是爲軟件開發服務的，而不是開發的主體。
4.設計周密是爲了最終軟件的質量，但不表明設計比實現更重要。
5.迭代。軟件的功能是客戶的需求，界面的操作是客戶的“感覺”。對迭代的強調是縮短了軟件版本的週期。
6.小版本。快速功能的展現，看似簡單，但對於複雜的客戶需求合理地分割與總體上的統一，要很好地二者兼顧是不容易的。
