测试落后开发一个迭代，这是你跑的“Scrum”吗？

有些团队，特别是从传统瀑布方法过渡到 Scrum 的团队，对于在一个 Sprint 内交付经过充分测试的，且有价值的功能增量的想法非常纠结。他们并不相信自己能在一个 Sprint 内真正交付“已完成”的增量（Done increment） – 包括对有价值功能的开发和测试。有时，Scrum 的新手团队可能会决定对 Scrum 做些修改，以便将开发阶段和测试阶段划分到两个连续的 Sprint 当中。

我能理解。在一个 Sprint 中开发和测试可用的功能增量，对于刚刚从诸如瀑布的预测性过程转入 Scrum 的团队来说，可能会望而生畏。

Scrum 的增量式方法让团队有足够的灵活性来改变方向，因为他们开发的都是较小的，易管理的功能增量。当开发和测试被分割在两个 Sprint 中进行时，团队就会积累大量的“半成品”工作。因此，迅速调整方向和响应需求变化就变得困难重重。要调整方向，团队必须等到开发和测试阶段都完成，至少需要等待两个 Sprint。

敏捷宣言的第一条原则强调“尽早和持续的交付有价值的软件”，是敏捷团队的关键原则。在一个 Sprint 开发，下一个 Sprint 测试的方式为客户价值交付引入了不必要的延迟。如果团队在一个 Sprint 开发功能，在下一个 Sprint 做测试，这就意味着你的 Scrum 团队至少需要两个迭代才能向客户交付可用的功能，而不是一个迭代。

注：部分图片来源于网络

Scrum.org专业Scrum培训师。