有些团队，特别是从传统瀑布方法过渡到 Scrum 的团队，对于在一个 Sprint 内交付经过充分测试的，且有价值的功能增量的想法非常纠结。他们并不相信自己能在一个 Sprint 内真正交付“已完成”的增量（Done increment） – 包括对有价值功能的开发和测试。有时，Scrum 的新手团队可能会决定对 Scrum 做些修改，以便将开发阶段和测试阶段划分到两个连续的 Sprint 当中。
我能理解。在一个 Sprint 中开发和测试可用的功能增量，对于刚刚从诸如瀑布的预测性过程转入 Scrum 的团队来说，可能会望而生畏。
但是下面我要说说为什么在一个 Sprint 开发，下一个 Sprint 测试这个方法带来的麻烦比解决的问题更多。
当开发和测试被分割在两个 Sprint 中时，干系人对团队进度的可见性就会降低。他们需要更长的等待时间才能了解到 Scrum 团队的工作进展，从而阻碍了协作和反馈。除此之外，这种方法还降低了可预测性，因为团队在 Sprint 计划会时，实际上是在规划两个 Sprint 的工作。跨越两个迭代间协调开发和测试工作安排也会成为一种负担，使得坚持达成 Sprint 目标变得更有挑战。Scrum 的增量式方法让团队有足够的灵活性来改变方向，因为他们开发的都是较小的，易管理的功能增量。当开发和测试被分割在两个 Sprint 中进行时，团队就会积累大量的“半成品”工作。因此，迅速调整方向和响应需求变化就变得困难重重。要调整方向，团队必须等到开发和测试阶段都完成，至少需要等待两个 Sprint。
敏捷宣言的第一条原则强调“尽早和持续的交付有价值的软件”，是敏捷团队的关键原则。在一个 Sprint 开发，下一个 Sprint 测试的方式为客户价值交付引入了不必要的延迟。如果团队在一个 Sprint 开发功能，在下一个 Sprint 做测试，这就意味着你的 Scrum 团队至少需要两个迭代才能向客户交付可用的功能，而不是一个迭代。
2020版Scrum指南强调，Scrum旨在通过迭代增量式的方法来控制风险。在一个 Sprint 开发，下一个 Sprint 测试会使风险大大增加。它推迟了从客户和干系人那里获得反馈的机会，增加了可能投资在客户不感兴趣的功能开发上的潜在风险。此外，Scrum 团队要花费两个迭代才能知道计划的功能技术上不可行。这也导致了精力的资源的浪费。在两个迭代中分别进行开发和测试，为流程带来了不必要的复杂性。团队必须跟踪哪些功能已经开发完成但还没有测试，这超出了单一 Sprint 的范围。一些问题会陆续出现，比如功能开发和功能测试是否需要分成两个待办项记录在 Backlog 中，这些待办项如何绑定？缺乏明确的定义会导致混乱和低效，很难衡量开发工作究竟何时才真正完成。对于刚刚过渡到 Scrum 的团队来说，在一个 Sprint 进行开发，下一个 Sprint 进行测试，似乎是一个合理的折衷方案，但这并不符合 Scrum 框架或敏捷宣言的基本原则，而且它带来的问题比解决的问题还要多。Scrum 强调增量价值交付、灵活性、风险控制、简洁、可见性和可预测性，这就清楚的表明，将开发和测试结合在一个 Sprint 中才是最佳方法。为了充分发挥 Scrum 的优势，团队应该努力在每个 Sprint 完成潜在可交付的增量，从而实现尽早、持续向客户交付有价值的软件的承诺。你的 Scrum 团队是如何结合开发和测试工作的？是否有好的经验和方法分享？欢迎在评论区留言交流。注：部分图片来源于网络
Scrum.org专业Scrum培训师。
Mary Iqbal 是 Rebel Scrum 的实践敏捷顾问和讲师，教授过数以千计的软件专业人士，是一位经验丰富的敏捷转型教练。Mary擅长通过定义产品和帮助团队自组织以形成最适合的结构，来帮助组织实施规模化敏捷。【译者】Scrum中文网翻译组
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构，Scrum.org官方合作培训机构，和大规模敏捷SAFe官方机构SAI中国区授权合作伙伴。
Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
