这是《落叶》文集里第 68 片落叶，希望你能喜欢，不为别的，只为这份坚持。
今天我这个老兵再来说说敏捷这个看上去很美好的东西，在实际落地时都会有哪些痛吧。
第一步：全员培训
1、面向管理层、未来的PO和SM的敏捷实施的培训；
2、面向公司所有员工的敏捷思想和基本概念的培训；
【问题描述-1】：实施过成长，每个 PO 和 SM 都按照自己的理解去贯输敏捷流程，并指导团队如何去执行，导致同一类型的项目，不同的 Scrum Team 却有不同的流程。
【分析解决】：先严格按照 Scrum 标准流程去执行，让团队通过实践理解和熟悉了 Scrum 流程之后，再结合原有流程进行融合改造。同时，让各个 Scrum 团队的 PO 和 SM 定期开展 Lean Coffee 活动去交流分享各自的经验心得。
第二步：在新产品的研发过程中要求使用 Scrum
【问题描述-2】：产品虽然是新的，但是团队成员都是从老的项目组抽调出来的，所以大家骨子里其实还是传统的瀑布式研发流程，而且在开工之前，并没有人提供相关的模板或工具，导致团队成员无从下手，最后做成了每个 Sprint 里包着一个个小的瀑布。
【分析解决】：PO 和 SM通过理论结合实际，预先定义一些算法和模板，包括：用户故事的颗粒度、故事点的大小、Team Capacity 的算法、相关会议流程和注意事项等等。在前几个 Sprint Planning Meeting 和 Retrospective Meeting 时做持续性的宣贯和讨论。
【问题描述-3】：公司的产品团队在美国，因为时差和地域的差异，和本地团队的工作节奏很难同步，是否能由开发团队的开发人员或测试人员兼任？
【分析解决】：我们在本地设立了 PPO （Proxy Product Owner，产品负责人代理）的角色，相当于 US PO 在本地的角色投影，他们从 US PO 那儿获取产品的需求和相关信息，和本地的 Scrum Team 紧密地在一起工作。
【问题描述-4】：有些团队成员学习到敏捷是轻文档的，就简单地认为文档就可以能省则省，包括 SPEC 和 Test Plan 等。
【分析解决】：很多敏捷的队在初期阶段都有这样的误解，敏捷思想是说有价值且可工作的软件胜于详尽的文档，但是必要的需求文档、设计文档、测试计划、测试用例等等，在产品的项目实施过程中，都是需要保留的，否则无法做到一个很好的知识积累和传承。敏捷里只是不需要像传统瀑布流程一样，把文档作为每个阶段的一个输入条件，比如说 PRD 是开发设计阶段的输入，开发的 SPEC 是测试用例设计阶段的输入等等。在敏捷里，文档应该就是一个输出产物，产品经理、开发、测试在完成一个 Sprint 任务的同时，协同产出的有价值，并持续更新的一些文档。
第三步：在本身就是一个月发布一次的项目中推行。
【问题描述-5】：项目组成员在最初推行 Scrum 时会有较大困惑，因为我们已经是一个月发布一个版本了，为什么还要转为敏捷模式，而且迭代周期也是一个月，哪又有什么区别呢？
【分析解决】：PO 和 SM 引导团队从几个方面去感受传统的瀑布式流程和敏捷流程的区别：对需求理解的一致性、对代码改动的回归测试范围的确定性、对项目整体进度和自身能力的可视化等等，虽然从项目周期上看没有区别，但是从开发到测试对质量的信心和减少需求实现偏差上都有了很大的提高和改进。
第四步：在公司所有项目中开始运行。
【问题描述-6】：管理层认为敏捷团队是一个自组织、自管理的团队，所以可以是铁打的营盘流水的兵，因此会随意调动人员去应对一些 EP，或者喜欢每个项目开始之前打散原有团队重新自由组合。
【分析解决】：SM 需要通过对执行过程中的问题分析和燃尽图的对比，让管理层明白，一个团队的协同工作是需要时间去磨合的，当团队成员之间的默契度达到一个较高值时，战斗力是几何级的增长，任何任务都可以很好的完成。另外，团队在做 Sprint Plan 时，应该要预留10%~20%的 Buffer，来应对 EP和一些临时任务。
【问题描述-7】：在引入 Scrum 的初期，因为美国的 Release Manager 和 Cloud Service 团队并没有同步地跟上转型的节奏，他们仍然按照瀑布模型里 CC，CF，ER 等几个 milestone 去跟本地团队讨论发布和部署计划，让本地团队觉得同时在两种流程的规范下做项目很痛苦。
【分析解决】：PO 和 SM在跟 team 做 Sprint Plan 的时候，会把团队承接的有代码改动的 User Story 工作量控制在 CF 能完成，CF 到 ER 之间主要承接的是版本的回归测试、升降级测试、发布文档的编写等 User Story，同时 SM 也会尽可能地去跟 RM 和 CS 统一沟通，保护团队不受太多的干扰。
【问题描述-8】：在前期引入 Rally（适用于 Scrum 的一种管理工具），增加了团队额外的一些工作量，从表面上看，工作效率反而下降了，从而产生了一些抵触情绪。
【分析解决】：SM 在跟团队做 Sprint Plan 的时候就把工具的学习量也算在内，并跟管理层和团队做好沟通，敏捷团队的 Capacity 算法里要加上学习量的计算，因为团队是在不断总结、不断学习中成长的，不管是工具，还是新的项目，新的技术领域，都需要花时间去学习，这些都需要在每个 Sprint 开始的时候考虑进去。
【问题描述-9】：有的团队觉得过多的会议耗费了他们的精力，而且一个 Sprint结束之后就要立即投入下一个 Sprint 的工作当中了，所以取消了项目结束之后的反思会议，还自以为对流程效率做了优化。
【分析解决】：SM 通过对几个 Sprint 的 Capacity 数据进行统计对比，让团队认识到这个值已经连续几个 Sprint 没有变化了，再引入一些成功案例做对比，在团队里做几次分享和头脑风暴，并采用各种方法引导团队成员慢慢说出自己眼中的不足，持续总结，持续改进，让团队切身体会到这种反思会议正是敏捷中持续改进的重要基石，那么团队自然就不会觉得开 Retrospective Meeting 是在浪费时间了，另外，就是这种会一定切记，不能开成抱怨大会或者批斗大会。
作者简介：14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵
