敏捷開發學習總結(1)：傳統序列式軟體開發方法的缺點，以及迭代開發方法的選擇
阿新 • • 發佈：2018-12-24
大部分公司仍使用傳統瀑布模型（或序列式開發方法）進行開發。
我所工作過的公司，以及我身邊的朋友工作所在的公司，再加上招聘時從求職者那裡所瞭解到的其他一些公司的開發過程，基本上都是使用傳統的軟體開發模式 ，類擬或者就是瀑布開發模式，這種模式有如下特點：
1)將專案的生命週期明確地劃分為幾個階段，完成一個階段才進入下一個階段。
2)在專案初期希望細化所有的需求，並希望在一個階段將需求固定後不再改變。
3)在需求定義完畢後，在編碼之前進行較詳細的預 先設計，完成所有或者大部分的設計工作才開始編碼。
4)每一個階段需要產出大量的文件作為下一階段的輸入。
傳統瀑布開發 模式有哪些缺點？
由於現代軟體系統的功能和設計越來越複雜，市場需求變化較快，所以瀑布開發模式所要求的嚴格地完成一個階段再進入下一個階段被認為是太過理想化，原因有如下一些：
1)現代大部分專案，寄望於在某一個階段將需求固定是不現實的，太多的誘因會引起需求的變化了，例如：
a)沒有真正的使用者參與需求定義過程，定義的需求可能很難符合終端使用者的工作習慣。
b)就算把需求定義好給到終端使用者，讓終端使用者去確認，需求也有改變的風險，原因是使用者在看到可執行的系統之前，一切都是假想，有不合理的地方他也不能完全看出來，我就假設這個使用者很認真地配合需求的確認，並假設大部分需求能在這個階段確認了，但一些非功能性的需求使用者是沒有辦法體現到的，例如效能、操作的流暢度等。這就像給你一本iPhone的手機說明書，再給你一本其它智慧手機的說明書，讓你去評價哪一個手機更優秀，除了iPhone外觀、 介面漂亮點外，你可能真的看不出iPhone到底有什麼突出的優點值得這麼多年輕人追棒，直到你真正拿在手上用時，體會了iPhone操作流暢的爽快感，以及爽心悅目的視窗動態效果時，你才能體會它的與眾不同之處。
c)競爭者、市場需求在不斷變化，使用者的需求也在跟著市場進行變化，特別是研發性的專案，“使用者”與研發部之間，不像一些非研發性質的專案需求的變更有合同來約束。
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被稱為一次迭代，每次迭代大約需要數週，不宜太長，越短越好，每個專案可能要經歷十多次迭代。
我所工作過的公司，以及我身邊的朋友工作所在的公司，再加上招聘時從求職者那裡所瞭解到的其他一些公司的開發過程，基本上都是使用傳統的軟體開發模式 ，類擬或者就是瀑布開發模式，這種模式有如下特點：
1)將專案的生命週期明確地劃分為幾個階段，完成一個階段才進入下一個階段。
2)在專案初期希望細化所有的需求，並希望在一個階段將需求固定後不再改變。
3)在需求定義完畢後，在編碼之前進行較詳細的預 先設計，完成所有或者大部分的設計工作才開始編碼。
4)每一個階段需要產出大量的文件作為下一階段的輸入。
傳統瀑布開發 模式有哪些缺點？
由於現代軟體系統的功能和設計越來越複雜，市場需求變化較快，所以瀑布開發模式所要求的嚴格地完成一個階段再進入下一個階段被認為是太過理想化，原因有如下一些：
1)現代大部分專案，寄望於在某一個階段將需求固定是不現實的，太多的誘因會引起需求的變化了，例如：
a)沒有真正的使用者參與需求定義過程，定義的需求可能很難符合終端使用者的工作習慣。
b)就算把需求定義好給到終端使用者，讓終端使用者去確認，需求也有改變的風險，原因是使用者在看到可執行的系統之前，一切都是假想，有不合理的地方他也不能完全看出來，我就假設這個使用者很認真地配合需求的確認，並假設大部分需求能在這個階段確認了，但一些非功能性的需求使用者是沒有辦法體現到的，例如效能、操作的流暢度等。這就像給你一本iPhone的手機說明書，再給你一本其它智慧手機的說明書，讓你去評價哪一個手機更優秀，除了iPhone外觀、 介面漂亮點外，你可能真的看不出iPhone到底有什麼突出的優點值得這麼多年輕人追棒，直到你真正拿在手上用時，體會了iPhone操作流暢的爽快感，以及爽心悅目的視窗動態效果時，你才能體會它的與眾不同之處。
c)競爭者、市場需求在不斷變化，使用者的需求也在跟著市場進行變化，特別是研發性的專案，“使用者”與研發部之間，不像一些非研發性質的專案需求的變更有合同來約束。
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被稱為一次迭代，每次迭代大約需要數週，不宜太長，越短越好，每個專案可能要經歷十多次迭代。