不要把敏捷玩成小瀑布了

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


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

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

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

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

第一周:
前半周需求,后半周设计。

第二周:
前半周编码,后半周测试。


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

  • 浪费

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

  • 车顶的豆腐

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


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

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

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

相关推荐