共计 799 个字符，预计需要花费 2 分钟才能阅读完成。
瀑布开发就是严格遵守 需求 -> 设计 -> 编码 -> 测试 的顺序，做完一个环节才能做下一个，界限分明，简单明了，最省脑力了。
把一个大项目拆分成多个模块，有人按照敏捷的做法，迭代开发其中一个模块。
第一个迭代做需求
第二个迭代做设计
第三个迭代做编码
第四个迭代做测试
四轮迭代后完成该模块的交付。
又或者，该轮迭代为期两周，目标是完成一个功能。
第一周：
前半周需求，后半周设计。
第二周：
前半周编码，后半周测试。
以上两种模式仍然是瀑布模式，时间越短，瀑布越小。然而无论它们有多小，仍然逃不过瀑布固有的宿命：浪费，越后期的问题越致命。
- 浪费
做需求的时候，开发人员在干啥？测试人员在干啥？测试人员可能早早写好测试案例，在苦苦等待开发的可测试版本。
- 车顶的豆腐
想象一下一块放置在行驶着的汽车车顶的豆腐，一个急转弯，一个加速或者一个急刹，足以让豆腐崩塌了。后期的瀑布项目就是那一块车顶的豆腐，路上任何一个小石子都是一个大阻碍。你敢需求变更我就敢延期。
通常，开发任务都要经过瀑布里的那几个环节，敏捷开发也不例外。说一下我们目前的做法：
- 一周一迭代，每轮迭代明确要完成的功能（经过敏捷扑克评估合适的工作量）
- 团队里开发测试人员比为 3:1 或者 4:1（测试人员由开发人员轮流扮演）
- 周初测试人员写测试案例，与开发人员明确接口输入输出定义，写自动化测试代码，准备随时对接测试。开发人员则全力投入开发
- 周三左右，有可以测试的接口或者功能产出，测试人员随即展开自动化测试或者手动测试。开发人员同时接着开发其它接口或者功能。测试人员返馈问题，开发人员及时修复
- 周四，更多的接口或功能开发完成，测试人员接着测试。测试人员返馈问题，开发人员及时修复。
- 周五，如果所有任务都已开发完成，则全员转成测试人员，全力测试，并修复缺陷。
以上大概就是我们团队的日常作战模式，我们不允许任务大到要周五才能产出，每天通过站会同步所有人的状态，以及任务的状态（开发、待测、测试、完成）。
正文完
