不要把敏捷玩成小瀑布了

瀑布开发就是严格遵守 需求->设计->编码->测试 的顺序，做完一个环节才能做下一个，界限分明，简单明了，最省脑力了。

把一个大项目拆分成多个模块，有人按照敏捷的做法，迭代开发其中一个模块。

第一个迭代做需求
第二个迭代做设计
第三个迭代做编码
第四个迭代做测试

四轮迭代后完成该模块的交付。

又或者，该轮迭代为期两周，目标是完成一个功能。

第一周：
前半周需求，后半周设计。

第二周：
前半周编码，后半周测试。

以上两种模式仍然是瀑布模式，时间越短，瀑布越小。然而无论它们有多小，仍然逃不过瀑布固有的宿命：浪费，越后期的问题越致命。

• 浪费

做需求的时候，开发人员在干啥？测试人员在干啥？测试人员可能早早写好测试案例，在苦苦等待开发的可测试版本。

• 车顶的豆腐

想象一下一块放置在行驶着的汽车车顶的豆腐，一个急转弯，一个加速或者一个急刹，足以让豆腐崩塌了。后期的瀑布项目就是那一块车顶的豆腐，路上任何一个小石子都是一个大阻碍。你敢需求变更我就敢延期。

通常，开发任务都要经过瀑布里的那几个环节，敏捷开发也不例外。说一下我们目前的做法：

1. 一周一迭代，每轮迭代明确要完成的功能（经过敏捷扑克评估合适的工作量）
2. 团队里开发测试人员比为3:1或者4:1（测试人员由开发人员轮流扮演）
3. 周初测试人员写测试案例，与开发人员明确接口输入输出定义，写自动化测试代码，准备随时对接测试。开发人员则全力投入开发
4. 周三左右，有可以测试的接口或者功能产出，测试人员随即展开自动化测试或者手动测试。开发人员同时接着开发其它接口或者功能。测试人员返馈问题，开发人员及时修复
5. 周四，更多的接口或功能开发完成，测试人员接着测试。测试人员返馈问题，开发人员及时修复。
6. 周五，如果所有任务都已开发完成，则全员转成测试人员，全力测试，并修复缺陷。

以上大概就是我们团队的日常作战模式，我们不允许任务大到要周五才能产出，每天通过站会同步所有人的状态，以及任务的状态（开发、待测、测试、完成）。