这是《落叶》文集里第 188 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
昨天最后强调了一点，敏捷研发模式的引入一定是基于现有流程存在问题的基础之上，不能为了敏捷而敏捷，要就具体问题分析，如果只有引入敏捷才能解决，那再引入。否则，不要盲目引入敏捷。所以今天在针对一些同学的疑问说一说为什么敏捷不是万能的。
【你问】
为什么敏捷不是万能的？
【我答】
在实施敏捷的过程中，我们遇到过一些问题，并找到了解决方案，但还有一些问题，我们没有找到解决方案，今天就列举这些，来从侧面说明一点：敏捷不是万能的。
【问题1】：开发工程师对自动化测试的认知和理解比较粗浅，所以在做架构设计和代码实现时并没有考虑如何有效地支持自动化测试框架。
【分析1】：高效的敏捷团队离不开自动化测试框架的支撑：持续集成的自动构建环境，自动执行的 BVT 脚本，用于版本回归的自动化脚本，等等这些都是敏捷流程中不可或缺的一部分。如果前期设计阶段没有考虑进去，因为代码结构的复杂度，过程中很难对架构进行调整，所以只能在自动化方案的设计阶段，考虑能否按模块去做一些相对简单的改动，比如针对一些非标准控件去增加 ID 属性，从而便于自动化脚本能够识别到它们。
【问题2】：团队中的测试工程师，黑盒测试经验丰富，但技术是短板，短期内很难基于代码去做单元测试或白盒测试。
【分析2】：这是在产品开发初期，对测试工程师的要求相对单一导致的，如今只能逐步引导部分优秀的黑盒测试工程师转型，或者是补充新鲜的技术类测试工程师资源，无论是哪种方案，都不是短期能立竿见影的，学习、提升、熟悉、磨合。。。都是需要时间的。
【问题3】：产品的功能模块之间，耦合度和依赖性比较大，在做一个规模较大的需求时，通常需要 DB、Server、Page 和 Client 同时支持，所以在 User Story 的细化、Task 拆分、以及不同的 Scrum Team 之间的协作上有很大难度。
【分析3】：首先不可能为了敏捷而去大幅度调整产品代码架构，这个只能在合适的时期，逐次分批地进行调整。其次，在 User Story 的细化和 Task 的拆分上尽量降低耦合性。如果 DB、Server、Page 和 Client 都是由不同的 Scrum Team 在承担任务，那就需要通过 Scrum of Scrum 的形式去管理项目，从而保证所有模块在每个迭代的步调是一致的。
【问题4】：虽然 Major Release 能做到在一个 Release 周期内的每个迭代都能提交可发布版本，但运维团队的部署节奏还跟不上，所以就存在产品研发团队即使在1个季度里提交了3 个可发布的迭代版本，但运维团队却只能发布其最后1个 。
【分析4】：因为产品的复杂度决定了 Deployment 的步骤繁多，而且不同组件之间还有 Hard Dependency 和 Feature Dependency，同时，线上部署也还没有做到完全的自动化，上线成本较高，这也是在敏捷实施过程中一个暂时不可调和的矛盾。
【问题5】：线上产品的小版本并存和定制版本太多，而且自动化测试覆盖率不高，导致在安全问题修复和 OS/Browser 版本更新时，Scrum Team 可能需要在一个迭代周期内同时在很多 Branch 上进行代码合并和大量的手工回归测试，SM 也很难保证团队在一个迭代周期里只Focus 在当前 Sprint 的计划任务上。
【分析5】：提高持续集成测试和自动化测试覆盖率，同时要尽可能地说服客户尽快都升级到最新的版本，逐步减少多版本并存的现象。
《测试路上你问我答》里的 Q&A 46，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
