问答（40） 为什么敏捷不是万能的？
【背景】
上一篇最后强调了一点，敏捷研发模式的引入一定是基于现有流程存在问题的基础之上，不能为了敏捷而敏捷，要就具体问题分析，如果只有引入敏捷才能解决，那再引入。否则，不要盲目引入敏捷。所以今天在针对一些同学的疑问说一说为什么敏捷不是万能的。
【你问】
为什么敏捷不是万能的？
【我答】
在实施敏捷的过程中，我们遇到过一些问题，并找到了解决方案，但还有一些问题，我们没有找到解决方案，今天就列举这些，来从侧面说明一点：敏捷不是万能的。
【问题1】：开发工程师对自动化测试的认知和理解比较粗浅，所以在做架构设计和代码实现时并没有考虑如何有效地支持自动化测试框架。
【分析1】：高效的敏捷团队离不开自动化测试框架的支撑：持续集成的自动构建环境，自动执行的版本校验脚本，用于版本回归的自动化脚本，等等这些都是敏捷流程中不可或缺的一部分。如果前期设计阶段没有考虑进去，因为代码结构的复杂度，过程中很难对架构进行调整，所以只能在自动化方案的设计阶段，考虑能否按模块去做一些相对简单的改动，比如针对一些非标准控件去增加控件编号属性，从而便于自动化脚本能够识别到它们。
【问题2】：团队中的测试工程师，黑盒测试经验丰富，但技术是短板，短期内很难基于代码去做单元测试或白盒测试。
【分析2】：这是在产品开发初期，对测试工程师的要求相对单一导致的，如今只能逐步引导部分优秀的黑盒测试工程师转型，或者是补充新鲜的技术类测试工程师资源，无论是哪种方案，都不是短期能立竿见影的，学习、提升、熟悉、磨合。。。都是需要时间的。
【问题3】：产品的功能模块之间，耦合度和依赖性比较大，在做一个规模较大的需求时，通常需要数据库、服务端、前端页面和客户端同时支持，所以在用户故事的细化、任务的拆分、以及不同的 Scrum 团队之间的协作上有很大难度。
【分析3】：首先不可能为了敏捷而去大幅度调整产品代码架构，这个只能在合适的时期，逐次分批地进行调整。其次，在用户故事的细化和任务的拆分上尽量降低耦合性。如果数据库、服务端、前端页面和客户端都是由不同的 Scrum 团队在承担任务，那就需要通过 Scrum of Scrum 的形式去管理项目，从而保证所有模块在每个迭代的步调是一致的。
【问题4】：虽然主线发布版本能做到在一个发布周期内的每个迭代都能提交可发布版本，但运维团队的部署节奏还跟不上，所以就存在产品研发团队即使在1个季度里提交了3 个可发布的迭代版本，但运维团队却只能发布其最后1个 。
【分析4】：因为产品的复杂度决定了部署的步骤繁多，而且不同组件之间还有 Hard Dependency（强依赖关系） 和 Feature Dependency（功能依赖关系），同时，线上部署也还没有做到完全的自动化，上线成本较高，这也是在敏捷实施过程中一个暂时不可调和的矛盾。
【问题5】：线上产品的小版本并存和定制版本太多，而且自动化测试覆盖率不高，导致在安全问题修复和操作系统/浏览器版本更新时，敏捷团队可能需要在一个迭代周期内同时在很多 Branch（代码分支） 上进行代码合并和大量的手工回归测试，敏捷教练也很难保证团队在一个迭代周期里只聚焦在当前冲刺的计划任务上。
【分析5】：提高持续集成测试和自动化测试覆盖率，同时要尽可能地说服客户尽快都升级到最新的版本，逐步减少多版本并存的现象。
相关阅读：
版权声明：51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
