程讀書筆記

大部分公司仍使用傳統瀑布模型（或序列式開發方法）進行開發?

我所工作過的公司，以及我身邊的朋友工作所在的公司，再加上招聘時從求職者那里所了解到的其他一些公 司的開發過程，
基本上都是使用傳統的軟件開發?模式?，類擬或者就是瀑布開發模式，這種模式有如下特點：
?

1)?將項目的生命周期明確地劃分為幾個階段，完 成一個階段才進入下一個階段。

2)?在項目初期希望細化所有的需求，并希望在一個階段將需求固定后不再改變。

3)?在需求定義完畢后，在編碼之前進行較詳細的預 先設計，完成所有或者大部分的設計工作才開始編碼。

4) 每一個階段需要產出大量的文檔作為下一階段的輸入。

傳統瀑布開發?模式有哪些缺點？

由于現代軟件系統的功能和設計越來越復雜，市場需求變化較快，所以?瀑布開發模式所要求的嚴格地完成一個階段再進入下一個階段被認為是太過理想化，原因有如下一些：

1) 現代大部分項目，寄望于在某一個階段將需求固定是不現實的，太多的誘因會引起需求的變化了，例如：

??? 1a)?沒有真正的用戶參與需求定義過程，定義的需求可能很難符合最終用戶 的工作習慣。

????? 1b)?就算把需求定義好給到最 終用戶，讓最終用戶去確認，需求也有改變的風險，原因是用戶在看到可運行的系統之前，一切都是假想，有不合理的地方他也不能完全看出來，我就假設這個用戶 很認真地配合需求的確認，并假設大部分需求能在這個階段確認了，但一些非功能性的需求用戶是沒有辦法體現到的，例如性能、操作的流暢度等。?這就像給你一本iPhone的手機說明書，再給你一本其它智能手機的說明書，讓你去評價哪一個手機更優秀，除了iPhone外觀、 界面漂亮點外，你可能真的看不出iPhone到底有什么突出的優點值得這么多年輕人追棒，直到你真正拿在手上用時，體會了iPhone操作流暢的爽快感， 以及爽心悅目的窗口動態效果時，你才能體會它的與眾不同之處。

??? 1c)?競爭者、市場需求在不斷變化，用戶的需求也在跟著市場進行變化，特 別是研發性的項目，“用戶”與研發部之間，不像一些非研發性質的項目需求的變更有合同來約束。

?

2) 接下來的設計階段假設需求已經確定，但如果需求在項目后期還會有較大變化的風險，那么早期就做較詳細和較完整的設計工作可能是不適當的。

?

3) 那么，假設需求能夠確定，設計是否能夠確定呢？我的理解是，只有在我們對所在的技術領域非常熟悉的情況下才有可能，怎樣才算對技術領域非常熟悉呢？

我的理解是就像一些做信息化項目的小企業，他們為A企業開發了OA辦公系統，再為B企業開發相擬的 系統時，所用的技術幾乎是一樣的，只是業務有一些異同而以。

但如果是研發性質的公司，常常需要涉足一些陌生的技術領域，你在投入人力進入這些功能的預研之前，你很難去細化這一部分的設計，但這 些技術的預研工作通常又需要很長的工作時程，可能需要經歷較長的項目周期，所以說，要在項目初期就細化好完整的設計可能會事與愿違。

4)?當使用瀑布模型（或序列開發模式）時，如果需求與用戶的設想出現了偏離，這 種錯誤將會貫穿整個項目周期，設計受需求的影響，代碼受設計的影響，直到項目接近完成，將產品交付給用戶使用測試時，錯誤才被用戶提出，這時項目已處于尾 聲，為遲已晚。

如何解決傳統瀑布開發模式存在的問題？

針對傳統瀑布開發模式?所存在的問題， 業界提出的解決方法就是應用迭代開發方式，而敏捷開發更是在迭代開發的基礎上，作了進一步的改進，敏捷開發方法由于它應用迭代和增量的開發模式，所以可以 看作是經過改進的迭代開發方法。

?

敏捷開發提出了以下的一些原則：
1) 假設需求總是會變化的，并歡迎需求的變化，因為需求的變化可能意味著可以提升產品的商業價值。
2) 設計是演進式的，并要保持簡單設計和彈性設計，以便能快速響應需求的變化，而需求變化總是會引起設計的腐化，因此，經常性的對代碼進行重構是必須的。
3) 短期持續交付可運行的系統給用戶，目的是盡早取得用戶的反饋。
4) 更多原則可參考書籍：<<敏捷軟件開發：原則、模式與實踐>>。

?

近年來，隨著敏捷開發思想的提出，以及UP(Unified Process,統一流程) 、敏捷UP、Scrum 和XP(極限編程實踐) 等一系列的實踐方法得到應用，迭代、增量的開發模式得到了更多的贊譽聲音，目前，最為熱門的是以Scrum和XP進行組合的敏捷開發方式，已經被騰訊、華 為、上海貝爾等一些大公司所采用。?

?

?

迭代、增量的開發模式 是如何進行的？

迭代開發模式會將項目周期分為多個迭代來完成，每一個迭代只實現一小部分功能， 完成一次迭代時就將系統給到用戶進行演示或測試，進而及早得到用戶的反饋來改進需求和設計，每一次迭代也需要經歷需求分析、設計和編碼和測試等多個活動， 但通常是輕量級的，項目的整個周期可能要進行十多次或更多這樣的迭代。?

那么，迭代和增量開發模式又是如何進行的呢？下面作一下簡述：
1)?? ?項目初期和我們現用的方法一樣，會定義好產品設想以及功能列表，并對產品功能排好優先級，但與傳統的開發模式不同的是，這個階段不會去細化所有需求。
2)?? ?根據優先級，挑選一小部分需求進行細化，項目初始階段通常挑選高風險的、決定核心架構的、業務性質重要的功能需求來細化。
3)?? ?針對細化的一部分需求進行設計和編碼，得到可運行的軟件然后交付給用戶，或給用戶演示并收集反饋。
4)?? ?根據用戶的反饋修改需求，并提交新版本的軟件給用戶，直到用戶滿意。
5)?? ?重復 2~4，直到完成所有的功能。2~4 被稱為一次迭代，每次迭代大約需要數周，不宜太長，越短越好，每個項目可能要經歷十多次迭代。
6)?? ?其它活動略

轉載：https://blog.csdn.net/kwiner/article/details/5447647

總結

以上是生活随笔為你收集整理的传统序列式软件开发方法的缺点，以及迭代开发方法的选择的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。