敏捷開發和瀑布開發的本質區別

現在大多數項目的變更頻繁，需求不確定，但是有沒有人反思過，需求不確定和頻繁變化可能來源於你的技術人員不專業無法深度挖掘到用戶的實際需求呢?

說到敏捷開發和瀑布開發誰更好一些，這個問題就好像再問，貌似像在問我們午餐到底是吃西餐還是中餐呢?其實大家都知道，兩者各有優勢，無好壞之分，準確點來說就是看你所做的東西，更加適合那種開發方法吧!

敏捷和瀑布更多的是一種思維的變化，如果思維沒有轉變，你就想象一下，雙手十指交叉的時候，挪動一下大拇指的位置，感覺如何?在從傳統瀑布方式走向敏捷方式的時候，會有非常多的不適應和「老方法不是蠻好的么」的瞬間，克服他們，才能得到優勢。

用兩個詞吧，一個是擁抱變化，一個是進度可視。

1.任何軟體類系統或項目，即使你前期花在需求上的時間足夠長，你也很難在需求階段真正的分析和挖掘出所有的需求。有些需求註定會在設計實現或用戶使用過程中才逐漸出現。要承認軟體開發中存在這種不確定性。而瀑布模型將這種識別變化延遲到最好的測試或用戶使用階段才發現，極大的增加了返工或變更成本。敏捷思想裡面通過短周期迭代，儘可能早的交付可用的迭代版本來擁抱和適應變化。

2.任何一個軟體項目，需求或設計做完我們並不清楚進度是否真正完成了60%或者更多，任何不是經過測試通過的功能我們都很難把握真正的完成進度情況。因此在敏捷裡面換了一種思路，如講這個項目拆分為100個粒度差不多的功能點，如果有60個功能點全部完成並通過驗證和測試，我們就比較有把握說整體進度完成了60%。這種可視化的評估進度模式在瀑布裡面較難以做到。

由此可見，敏捷開發和瀑布開發二者相比較而言，敏捷視比較適應當代發展前景的，通俗點來說，對於現代更佔主導地位的軟體開發類型來說，敏捷才是更適合它們的方法。當然了，更適合瀑布方法的軟體開發類型或許仍然存在的。