文/秋之川
这是《落叶》文集里第 190 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
今天来和大家聊聊怎么才能让敏捷软着陆，它和其他规范或者工具引入还不太一样，因为它包含了一整套研发体系流程，而且现在要引入敏捷的公司大多都是想从瀑布转型的，这可是一套根深蒂固的传统流程，所以如果硬着陆的话，很容易折翼。
【你问】
怎么才能让敏捷软着陆？
【我答】
我也不敢说我今天聊得软着陆成功率就是百分之一百，但至少这是我在实际的敏捷实施过程中，不断总结和反思得出的一些经验，有接地气的，也有偏个人理想化的。
1、问题驱动：
我之前说过，敏捷并不是万能的，所以不要只听到别人家的公司说用了敏捷之后，效率提高了百分之多少，成本降低了百分之几等等，就盲目的去追赶这股“敏捷风”。
还是应该由问题驱动，先收集当前的研发模式有哪些问题，分析一下，到底是人的问题、技术的问题、还是流程的问题，如果真的是流程问题，那就再看，是需要全盘替换，还是仅仅吸取敏捷里的若干特色工具或方法即可。
这里举一个真实的案例，曾经有一个项目组，想全面实施 Scrum 研发流程，所以找到我去给他们做了一次分享，分享结束后，我跟项目组的人沟通了一下他们想采用敏捷的初衷和当前到底有哪些问题，最后发现其实根本原因是因为项目组的规模比原来大了一些，导致项目经理对项目进度的把控和组内沟通上出了问题。所以我给了他们两套方案：
方案A：引入 Scrum 的全套流程，前期可能需要消耗不少时间在学习和磨合上，所以同期的产出肯定会下降。
方案B：针对目前的问题，只引入 Scrum 里的“任务墙”和“Daily Scrum Meeting”，让整个项目的进度变得直观透明，同时让沟通更及时快捷，其他流程保持不动，这种对于项目组成员来说，学习成本最低，基本不会影响产出量。
项目经理最终选择了我推荐的方案B，而且在实施了一段时间后，反馈的确已经解决了他们的实际问题。所以说，敏捷的引入一定要切合实际要解决什么问题，而不要为了敏捷而敏捷。
2、自上而下的推动：
敏捷的引入及推行，一定是要自上而下的。什么意思呢？就是说，公司高层首先要从思想上认可敏捷，同时要给予最大限度地支持。这样敏捷在落地的过程中，会少去很多障碍。千万不能是自下而上地去推行敏捷，那样基本上很难成功。
同样举个实际的例子，我们的 SM 和 Team 开了一整天的 Planning Meeting，制订了团队都认可的 Sprint Plan，大家正准备按照这个计划开工的时候，职能经理跑过来质问团队，哪天代码完成提交测试啊？哪天代码冻结啊？哪天提交运维发布啊？怎么你们的计划里都看不到这些里程碑了呢？
SM 跟他说，现在都拆分到 User Story 颗粒度了，每个 Sprint 结束的东西都可以发布上线的，结果职能经理来了一句，我不管你什么颗粒度，也不管什么 Sprint，我只想看到那几个主要的里程碑，最终上线不会 Delay，就 OK 了。
结果，SM 又熬了一晚，从 Sprint Plan 里又提炼出来几个主要的里程碑，按线性的模式列给了职能经理。最后，大家做计划时，又回归老的模式了。
3、专职的 Scrum Master：
很多公司在实施敏捷的时候，对于 Scrum Master 这个角色总是不够重视，特别是那种内部研发类的项目，因为之前就没有专门的项目经理角色，所以在转敏捷时，也经常会让开发组长或测试组长兼任。但从实践角度出发，我个人一直都强烈建议这个角色要专人专职，特别是在初期。
在前期整个团队开始采用敏捷时，SM 起到了很重要的教练的作用，他需要花很大的精力和时间在学习、指导、总结、分析和改进等工作上，还有相关会议的组织、项目数据的统计、项目问题的跟踪、进度的汇报等等常规工作。如果不是一个专职的人去做，势必会影响到他本职的工作，也会消耗他很多在教练这个角色上的精力，导致两个角色都没有做的很好。
另外，如果由某个角色的人去兼任，那他不管是在做教练还是保镖时，不可避免地会下意识地站在自己的本职角色去考虑和看待问题。在做一些决策和判断时，就会带有偏向性。
4、核心成员，以老带新：
敏捷团队，强调的是自组织，自管理，对每个人的要求都相对较高，但从实际角度出发，不可能每个 Scrum Team 的人员配比都是高阶人力，所以只能建议在初期组建时，至少保证每个角色都配备一名高阶人力，再按实际需求配备中低阶人力，以老带新，通过若干个迭代的打磨和成长，让整个团队都能达到自组织和自管理的“理想”状态；
5、从“循规蹈矩”到“因地制宜”：
很多 Scrum 团队在刚开始的时候，就对本身标准的流程、方法和工具做优化和改进，我一直在问他们，你们所谓的“优化”和“改进”是基于什么的呢？我听到的最多的回答都是：”我们原来的流程就是这么玩的呀！“ 那你们就按你们原来的玩法玩呗，为什么要用敏捷呢？
这些团队最终的成果就是打造出了 N 个不同摸样的，奇形怪状的，似是而非的研发流程，不仅仅效率没得到提升，团队成员在执行起来，也是蹩手蹩脚的。
所以，我一直建议的实施步骤如下：
初始阶段：在我们刚刚起步，什么都不懂的学习阶段，就让我们严格按照 Scrum 教科书，采用标准的方法、流程和工具，打好理论基础，学以致用，通过几个迭代的”生搬硬套“，真正理解并掌握 Scrum 的精髓。
优化阶段：有了几个迭代的真实数据和经验，我们可以开始尝试对 Scrum 流程中做的不好的地方进行总结分析和反思，看到底是流程水土不服的问题，还是我们自身的问题，再针对性地进行优化。
推广阶段：我们已经形成了团队自己的一套模式，而且是通过实践证明，且整个团队都认可的，这个时候，我们就可以开始结合公司实际的项目环境，总结流程，将其固化下来，作为“本地化”的 Scrum+ 流程，开始向其他项目组推广运行。
自此，敏捷研发流程才算是真正地软着陆了，不过不要忘记 Scrum 里的核心理念：持续改进！
《测试路上你问我答》里的 Q&A 48，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
网友评论