※ 引述《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，但就我看来还是蛮土法炼钢的一种软件开发流程，跟欧美的软件公司比，
依然是落后相当的多。不过本来亚洲软件公司的软工就跟欧美公司有一段很大的落
差了，这也是很多台湾有在钻研这块的人很想让台湾能赶上的一块。