很多敏捷团队跑SCRUM时候都会发现开始时候挺顺利，团队跑起3355来也有模有样的，但是几个迭代过去后就逐步开始出现开发效率降低，测试资源不足，质量问题频出的情况。
为什么会这样呢，其中一个主要原因就是：工程实践技能不足，缺少自动化测试。套用个别激进的敏捷实践者经常说的一句话 “一切没有自动化支撑的敏捷都是伪敏捷”，这句话看上去武断，但是其实说的确是一个基本事实。
假设一个执行scrum的团队，开发速率是稳定的，每个迭代可以完成10个故事点的开发，经过五个迭代后，开发和测试工作量的比例变化如下图
可以看出，因为我们每个冲刺都要交付可以工作的软件，所以每个冲刺都需要确保交付的全量软件的质量是可靠的，在只采用手工测试的情况下，经过五个迭代后手动测试需要覆盖到的需求范围已经比第一个迭代膨胀了五倍，五个迭代测试总工作量是150个点所覆盖的需求范围，这还没有算开发因为需要配合完成测试工作所需要付出的代价。
作为对比，如果是瀑布过程，因为可能要几个月才发布一次，日常只需要测试新功能，最后发布前做一次全量回归就可以了，其工作量只是敏捷条件下的一半甚至更少，这也成为了很多人攻击scrum拉低了团队效率的主要论据之一。
面对这种情况团队常见的处理方式是什么呢？
- 尽量只测这个冲刺变动的部分功能，至于有没有旧有功能在本次冲刺内被破坏就要看团队成员感觉了，如果发现了可能会被修改的功能则会提醒QA测试时候覆盖那部分旧功能，如果忘了那就只能等着用户带来的惊喜了。
- 通过架构上解耦来解决，例如通过拆分微服务，抽取基础服务等方法分离已完成功能代码与新代码，这样已发布的服务和功能已经经过测试了，并且大部分代码新的迭代内不会动到，这样可以大大降低旧代码被误动的风险，也可以极大的降低回归测试工作量。
- 提高单元测试覆盖率和自动化测试比例，让回归过程自动化，降低手动测试工作量，这个是敏捷推荐的方法，也是实现真正的CI/CD的基础。
多数情况下，不光是SCRUM，任何通过高频率短周期迭代的产品交付方法，如果没有自动化回归测试做保护，都会面临因为手动测试工作量膨胀而拖慢交付速度或者拉低产品质量的问题。
有没有例外情况呢？
- 产品功能很少，每个迭代都在围绕的固定的一部分功能开发或者修改，回归测试工作量很快就达到稳定的水平。
- 并未强制要求每个迭代都发布到生产环境，也没有要求每个迭代都做全量回归。
- 系统没人用，所以也没人反应质量问题。
所以不是Scrum把团队效率和质量降低了，而是Scrum暴露了团队在工程实践方面不足的现实，大部分人这时候不愿意面对自己的不足，反而会找一堆理由来质疑Scrum，实际上如果你没打算在工程实践上做出努力与改善，只是尝试Scrum的话多数情况下只能退回到传统方法的老路上。
更多文章请关注 @敏捷新视界
(原文链接)
