瀑布式開發和敏捷開發的對比

瀑布模型開發：

嚴格把軟件項目的開發分隔成各個開發階段：需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。

使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。若是達不到要求的輸出，下一階段的工做就不展開。

 

強調文檔，在開發的後期纔會看到軟件的模樣。在這種狀況下，文檔的重要性彷彿已經超過了代碼的重要性。

 

瀑布模型把開發人員定義爲流水線上的工人。因爲各階段的開發人員只能接觸到本身工做範圍內的東西，因此對客戶需求的理解程度高低不等。對於客戶需求變動，編碼人員會比設計人員更容易產生很強的抵觸情緒。

在每一個開發階段都會有一些信息刻意的不讓其餘開發階段的人員知道（本意是爲了提到效率，但實際上有時候產生的是互相的理解誤差）。

 

瀑布模型產生的管理文檔(計劃書，進度表)等，能讓不太瞭解該項目的人也能看懂項目的進度狀況（只有能看懂百分比就行），很適合向領導彙報用。因此管理人員比較喜歡瀑布模型，可是開發人員不喜歡，由於它束縛了開發人員的創造性。

 

既然叫作瀑布，就意味着不該該走回頭路。不然若是出現返工，付出的代價會很大。

軟件生命週期前期形成的Bug的影響比後期的大的多。

 

 

敏捷開發：

核心是迭代。

由於最終目標是讓客戶滿意，因此可以主動接受需求變動，這就使設計出來的軟件有靈活性，可擴展性。

 

宣言：

個體和交互 賽過 過程和工具

能夠工做的軟件 賽過 面面俱到的文檔

客戶合做 賽過 合同談判

響應變化 賽過 遵循計劃

 

簡單設計，重複迭代。減小沒必要要的文檔。

客戶最關心的功能最早完成。

要求客戶有時間對每次迭代的成果進行確認，提出改進意見。

 

溝通是很是重要的，全部的開發人員對項目活動的理解應該是一致的。

 

開發團隊有兩個隊伍，業務團隊和技術團隊。若是任何一方控制了溝通，那麼項目註定會失敗。若是業務一方控制，項目會議上就會不斷的要求功能和交付日，而不太擔憂開發人員是否可以所有完成或開發人員是否明白他們的真正要求；若是開發人員控制了溝通，那麼項目會議上技術術語會代替面向客戶的業務語言，開發人員也失去了經過傾聽來了解客戶真正需求的機會。

 

PMBOK的項目管理是自上而下的命令式管理，而敏捷的管理是團隊的自我管理和項目經理的服務式管理。

 

敏捷開發不能在一開始就給出項目的成本計劃。

 

在有技術問題尚未解決的狀況下不適合展開迭代。