※ 引述《abadcafe (abadcafe)》之銘言：
: 這個地方可能有些朋友產生了誤解.
: 傳統的waterfall模式非常嚴謹, 整個系統從需求評審一直到最後測試上線, 要耗費大量的
: 時間. 因此不可能快速響應各種需求變更, 這在瞬息萬變的互聯網行業中是不可接受的.
: 事實上, 在互聯網行業中, 最盛行的是waterfall模式的變種: 快速迭代模式.
: 快速迭代模式講究的是分而治之, 把整個系統拆解成非常小的模塊, 然後針對每個模塊進
: 行waterfall, 並且若有需要還可以跳過某些階段. 每個waterfall的運行時間可能就只有
: 1周甚至更少.
: 這種模式下, 產品經理在尚未弄清楚所有需求的情況下, 就可以從已經確定的部分開始一
: 輪迭代, 有新的需求就再下一輪迭代. 響應速度非常快.
: 至於有朋友提到敏捷開發, 其實這與快速迭代並不衝突.
: 雖然大多數情況下, 快速迭代在每一輪迭代中都是使用waterfall模式, 但你也完全可以根
: 據需要在每一輪迭代中使用敏捷模式. 或者這一輪是敏捷, 下一輪是waterfall. 這都可以
: 沒有什麼問題.
基本上我接觸的所謂大陸版快速迭代waterfall，就我的看法就是單純把waterfall壓縮
到非常短的週期而已，有些人號稱這是Agile，但Agile的精神和practice他們根本沒有
用到，這種方法waterfall帶來的浪費還有低效率依然存在，之所以能壓得很快，說穿
了就是硬壓員工加班加到爆而已。但這種硬壓schedule的方法，技術債一定會不斷累積
，等到技術債累積到連每天加班到半夜都趕不上進度時，就是團隊壓力鍋爆炸的時候。
這種方法跟真Agile最大的差別在:
1. 依然需要在開發後放一個手動測試的phase跟解bug的phase，而這兩個phase就是最
趕最亂技術債欠最多的phase。相較於Agile特別是XP，使用自動化，CI還有TDD把
測試拉到很前面，和開發幾乎同步，Waterfall無可避免的就是造成浪費時間在人工測
試，以及浪費在前期時測試人員的閒置。
2. 沒有團隊速度的概念，Scrum會要求了解每個sprint平均能消化多少story points
，從而了解團隊速度並做出調整。Agile是固定時間和成本下，根據團隊速度決定要
開發多少feature，並根據現實狀況在每個sprint不斷調整，而不去做出無根據的預
估然後硬吃下根本不可能吃得下的feature量。Waterfall則是一開始什麼都沒有就要
做出毫無根據的預估，然後通常都過於樂觀，最後都會在成本，時程跟scope中間至少
無法達成其中一個。
3. 沒有end to end大團隊的概念，各個角色壁壘分明，互踢皮球的狀況非常常見
總之，大陸互聯網這種所謂的快速迭代waterfall，看似agile，甚至有人就稱這叫
agile，但就我看來還是蠻土法煉鋼的一種軟體開發流程，跟歐美的軟體公司比，
依然是落後相當的多。不過本來亞洲軟體公司的軟工就跟歐美公司有一段很大的落
差了，這也是很多台灣有在鑽研這塊的人很想讓台灣能趕上的一塊。