1. 程式人生 > >瀑布開發模式和敏捷開發模式的區別和思考

瀑布開發模式和敏捷開發模式的區別和思考

瀑布開發模式:

瀑布開發模式有以下顯著的特點:

1.嚴格把軟體專案的開發分隔成各個開發階段:需求分析,要件定義,基本設計,詳細設計,編碼,單體測試,結合測試,系統測試等。

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

2.重視和強調過程文件,在開發的中後期才會看到軟體原型,早起只能通過文件來了解系統的模樣。

在這種情況下,文件的重要性彷彿已經超過了程式碼的重要性。

3.瀑布模型把每個開發階段都定義為黑盒,希望每個階段的人員只關心自己階段的工作,不需要關注其他階段的工作。

好處是:可以讓開發人員能夠更專注於本職工作,提高階段效率。

壞處是:

a.由於各階段的開發人員只能接觸到自己工作範圍內的東西,所以對客戶需求的理解程度高低不等,開發人員更像是定義為流水線上的工人。

b.對於客戶需求變更,編碼人員會比設計人員更容易產生很強的抵觸情緒。

c.在每個開發階段都會有一些資訊刻意的不讓其他開發階段的人員知道(本意是為了提到效率,但實際上有時候產生的是互相的理解偏差)。

4.瀑布模型產生的管理文件(計劃書,進度表)等,能讓不太瞭解該專案的人也能看懂專案的進度情況(只有能看懂百分比就行),很適合向領導彙報用。所以管理人員比較喜歡瀑布模型,但是開發人員不喜歡,因為它束縛了開發人員的創造性。

5.既然叫做瀑布,就意味著不應該走回頭路。否則如果出現返工,付出的代價會很大。

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

代價比較大的主要原因還是每個開發階段的步子過大,每一次調整都可能傷筋動骨。

6.更適合需求相對穩定的大型專案。

敏捷開發模式:

核心是快速迭代,擁抱變化。

因為最終目標是讓客戶滿意,所以能夠主動接受需求變更,這就使設計出來的軟體有靈活性,可擴充套件性。

宣言:

個體和互動 勝過 過程和工具

可以工作的軟體 勝過 面面俱到的文件

客戶合作 勝過 合同談判

響應變化 勝過 遵循計劃

敏捷開發模式有以下顯著的特點:

1.story細化。

2.簡單設計,避免過度設計。

3.重複迭代。

4.減少不必要的文件。

5.客戶最關心的功能最先完成。

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

7.showcase。

8.溝通是非常重要的,所有的開發人員對專案活動的理解應該是一致的。加強團隊之間和客戶之間的溝通。

9.測試驅動開發(TDD)

10.需要更強的個人和團隊能力。

11.敏捷的管理是團隊的自我管理和專案經理的服務式管理。

12.敏捷開發不能在一開始就給出專案完整的成本計劃。

13.在有技術問題還沒有解決的情況下不適合展開迭代。

14.敏捷實踐:晨會,deadline,負責人制等等。

瀑布+敏捷開發模式:

核心是減小瀑布模型的粒度,採用敏捷開發的優秀實踐方式,提高開發的溝通效率,提供專案的全景檢視。

敏捷開發,首先把客戶最關注的軟體原型先做出來,交付或者上線,在實際場景中去修改彌補需求中的不足,快速修改,再次釋出版本。再次上線或者交付。通過一些敏捷實踐方式,細化story,可以提供更小的迭代。如此迴圈,直到使用者(客戶)滿意。適用於需求不明確的專案、創新性的專案或者需要搶佔市場的專案。 瀑布式開發,要求明確的需求,大家按照需求一步步做好規劃,在專案運作過程中嚴格產出各種文件,按著流程一步步走下去。這種模式一般適用於需求比較明確、to B端專案 但總的來說,在現在管理專案過程中,並沒有嚴格的按照完全的敏捷或者完全的瀑布模式,都是各自摻雜了其他的方式。在實際專案過程中,過於強調模式並沒有意義,重要的是能不能預防問題的發生,在問題發生之後能不能用最小的成本解決,模式更多起一個參考作用 最後借用民國時候的一句話:少研究一些主義,多關注一些實際問題。 文章中部分內容是借鑑於其他文章。