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