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