这是《规模化敏捷案例分析》第二辑。
在第一辑《规模化敏捷死亡之路》中通过2015年初的咨询经历，回顾了基于Scrum这样的小团队迭代交付框架扩展重量级产品交付时，所遇到的困境，以及S公司不可逆转的衰落。其实在启动咨询之前给S公司培训时我讲到Nokia的敏捷案例，当时与我搭配培训的张逸现场就给我反馈：“你为什么要讲Nokia？不怕人家问你为什么Nokia搞了敏捷却失败了？”我说：“我的目的就是让他们思考一下为什么Nokia失败了，他们又应该怎么避免失败。”
然而，组织的思考模式是不一样的。组织普遍擅长“从经验中学习”，去“复制成功”，对人来说，这其实等同于最为低智的喝鸡汤看成功学。在组织追求效率、价值与持续增长的过程中，适应性理论是现阶段的主流，而阻碍一个组织达成高适应状态的三大关键特征（而不是障碍！）是什么呢？我引用在组织决策理论领域大师级人物詹姆斯·马奇在《经验的疆界》中的描述：
第一，组织内部存在利益冲突。忽略了利益冲突，会让适应性理论变得不完备，特别是让成败判定、信息汇集变成非常复杂。
第二，组织适应涉及对数个层级水平的同步相互适应。组织层级在演化，同时，组织层级内部的个体组织也在演化。组织在演化，同时，组织内部的个体组织也在演化。这些层级适应系统相互影响，一个水平的适应有时会替代另一个水平的适应，有时又会干扰另一个水平的适应。
第三，在某种程度上，组织的环境是由其他组织构成的，因此，组织适应的一个基本特点是多个组织同步调整，共同演化，大部分有关组织学习的研究都把环境看成外源的。
而作为咨询公司的工作，或者客户公司对咨询工作的期望，一是引入成功的“经验”，二是提升所谓的“适应性”。因而，对于组织的改进，尤其是规模化的改进，面临的最大困境就是组织特征的挑战。
本次案例，是在W公司的大规模敏捷转型过程中，最终尘埃落地的最大部门级持续集成实施过程。
案例二 国内大型通信设备厂商W公司IT部门
持续集成实施
项目背景
W公司有很强的研发能力，但IT部门随着业务的发展，已有超过7000开发人员，外包人员占比多，开发效率和质量难以和庞大的IT成本相匹配。自2014年开始敏捷转型以来，先引入过SAFe，但很难感知到收益不说，反而陷入了效率质量越来越差的怪圈。我们介入后给出了几点评估：
架构笨重、耦合复杂，业务依赖更严重，无法直接进入迭代开发；
技术栈太多，一个企业存在多种平台、多种框架、多种实现方式，技术方案需要出多套，成本高；
基础设施太陈旧，云计算与虚拟化是近年来IT转型的重要方向，能否在基础设施层面做到自动化和不停机部署，才是敏捷能否落地要解决的关键障碍。
W公司接受了我们的方案提议，开始进行团队的工程技术能力提升，包括轻量级技术引入、简洁架构和自动化能力构建，并同步启动了组织级的持续集成云平台建设。
在使用Jenkins帮助一些团队搭建了流水线后，尤其是成功在几个小规模团队（小于50人）实施之后，W公司最大的S部门也有了兴趣。在我们的接口人安排下，我与S部门管理层进行了第一次交流。在此之前，W公司接口人一直对我们的规模化敏捷实施能力表示担心，并且一再推崇当时还在雅各布森的黄邦伟的规模化运作能力，客户说：“你们看人家黄博士改进大部门，从每个组找一两个人……聊一聊……”
第一次接触
在接口人与我沟通S部门有做持续集成的意向时，我首先明确提出他们自己要投入产品团队人员进来做， S部门表示没问题之后，第一次会议，包括BA负责人、开发负责人和试点团队高级开发和测试各一名。
我问产品团队：“你们希望持续集成给你带来什么?”对方当场愣住。这种场面不是第一次出现。W公司很多高层甚至一线领导其实都不清楚自己的痛点是什么，在不清楚目标的情况下结果往往无法令人满意。通过10多分钟的详细沟通，S部门渐渐梳理清楚了，希望通过持续集成来保障每一次版本能够稳定地发布，而不是每个环境都要反复测试，最后依然不能保证上了生产环境是对的。
训练试点团队
对试点团队的训练从2015年8月到10月，投入的时间主要分布在：
了解产品特点，让测试人员演示整个操作流程，讲解测试用例和难点
向开发人员了解发布流程和依赖关系，重整架构和依赖
指导自动化测试编写，使用了之前自己编写的Python Selenium框架
提供Jenkins使用指南，团队自己负责接入
在这一阶段内观察到的问题，一是S部门非常大，第一次沟通后信息被分别传递给几个人，他们居然相互都不知道彼此存在，而且信息不完整，误解很多；二是产品模块非常复杂，虽然只负责指导一个试点团队，结果是因为架构依赖关系，另两个团队也被卷进来搞整了一把。 这两个月的成功经验在于，与开发团队、测试团队建立了很好的关系，节奏安排得非常紧凑，在自动化测试的编写上，仅三周就扩大到24个测试人员全员学习和编写；并且通过供应商自己的传播，该供应商其它几个团队也自行动起来了，做Maven的切换，学习自动化测试，也想使用Jenkins等等。而开发团队养成了关注CI构建结果的习惯，构建成功率一直保持在100%。 试点的结果是：试点团队新版本上线达到了零缺陷，并且在到12月连续三个版本保持了零缺陷上线。（在2月这个团队已经做到了DEV/SIT/UAT持续部署）。
推行阻力
虽然是客户主动发起，但在试点过程中一直靠个人力量去推动，如果没有坚持朝着目标前进的动力，这种事情是非常难于持续的，怀疑主义往往自己选择倒下。 顾问能调动团队，主要是靠影响力。影响力一是来自于客户高层对你的直接授权，另一个则来自于你的能力， 以及和团队的关系。在W公司有一个好处是客户体量大，通过S部门影响力传播得非常广，直接又拉动了好几个团队学自动化测试，搞持续集成，当然由于个人时间有限，无法在每个团队进行指导。
不过在试点期间还是踩了些坑。首先是经验有限，没有给团队体系化地培训，也没有输出材料，对高层吹风为零，这样就错过了一些整体推进传播的时机，也不知道背后的一些政治阻力。
接下来试点团队找到我说，上面要让他们停用我们提供的Jenkins，切换到“组织级的Jenkins”。接到又接到接口人电话：“刚接到S部门电话，这边情况不妙，你说咋办?” 我说：“看到邮件了，咱们不要再继续用Jenkins了，让S部门把所有项目全部接入我们开发的持续集成云平台。”
群策群力
我们紧急召开了一次回顾会议，让团队每一个人写一个idea，叫“为什么我们的产品能超越Jenkins” 。
Idea最终呈现：
部署流水线模板，帮助产品团队快速适配互联网交付模式
更简洁的界面，降低CI配置复杂度
强大的弹性构建能力，低于CloudBees的费用
将通用配置规范化，快速上手
S部门600人，近34个项目将全面进入一个刚启动开发一个月、完成MVP的云平台……当然，更大的挑战是，我们没有多余的顾问来支持，最后，在飞机场拦下一个正去香港的开发同事，火速上岗。
人在旅途
星期一
S部门汇报会议，持续20分钟炮火：“你们搞的什么东西，看起来这也做了那也做了，结果没一样能跑通！”
“为啥这问题现在才报出来？一开始为啥不说？”
“我们现在根本就没有一个人从最高层面把项目全部拉通，导致每个人都在瞎搞！”
“现在这些情况是我们工作还做得不够好，这个问题我们不回避”——我说了这句话后，对方一下子安静了下来。
“关键是没有人把项目拉通......”
“拉通这个项目的事，只有两个人能搞，一个人就是我，别一个就是你，这个你来决定吧。”
“这个项目拉通......”X还磨叽着，“那就这样嘛，我负责总体方案，你负责实施，方案出问题就是我的事，实施落不了地就是你们的事，你认为呢？”
对赶快把实施接过去了，我们开始设计方案。
星期二
晚上，S部门高层例会。X赶了一个PPT，汇报了一下思路，被批不够细，“你要用一个Excel，列出每项任务，每项任务后面列出开始时间结束时间，Block了就红色高亮，让每一个人知道进度受阻。”客户高层高亮发出一个邮件：“大家分工合力，相信在新平台上，项目质量和效率一定会得到改进！”
星期三
看了下Excel：
任务：某项目技术方案
开始时间：12月22日
结束时间：12月24日
写起了好久都没写的PPT，花了一天。
星期四
上午发了一个PPT版本，把Excel刷成了Done，给S部门电话，约第二天中午碰头。
下午去项目组作了一个小调研，包括版本开发方式、部署方式、分支流程等等，使用我们的产品做了一个Demo，解决了若干冲突问题终于跑通，回酒店后觉得白天写的PPT不够接地气，结合白天调研到的情况，继续写PPT到凌晨。
星期五
X发会议通知上午10点开会，不想去，结果直接跑到座位上来抓人，没法，去。 PPT还没露，几句话把他们讲晕了，刷了Excel进度，闪。
中间小火花，我：“刷这个时间有啥用，都是假的”
“啥？你给我的时间假的，那我给你的钱都是假的，那咋办?”
“你看你们两个月前这个计划现在都成啥样子了？还在这里刷计划浪费时间。谁说假的就是要延期了，假的意思就是有可能延期，有可能提前，你们的项目管理方式落后，我们是敏捷，是迭代推进，滚动计划”
“......那样当然最好了”
“那你就先刷到这个日期嘛，反正没啥意义”
“.....”
下午约见到S部门领导，喝咖啡，聊天两小时......愉快地结束了方案讨论……努力了两次都没把PPT秀出来......心里直叫苦，写了一天一夜，真是多此一举啊！
酸菜肘子
一晃一个季度过去了，时间来到了2016年3月17日晚21点，我正准备去珠海好好休息一下，在欢乐海岸某餐厅点了一份肘子，上来把我震惊了：
这一个汉堡、一盘土豆、一份酸菜、半个肘子都能让我吃一天了！于是我就吃呀吃，吃到10点半过了还没吃完
突然电话响了，拿起一看，竟然是W公司熟悉的会议号码。神奇了，谁这大夜还会拉我开会呢？
“顾问，您好，我们这边实在没办法了，今晚得发布上线，但是部署包有问题，错误也找不到，我记得你说过，持续集成每次构建会生成一个版本，我们早上的版本是正确的，请问怎么找到这个包？”
这个电话的最后，我凭借着惊人的记忆力在他们搞不清楚什么是Maven坐标、版本号的情况下回忆服务器目录找到了他们想要的包……经过测试，这个包是正确的，发布成功！
“持续集成太牛了，我们得全面推广！”
搞了三个月对方完全“无感”，最后竟然吃着肘子打着电话全面推动了……我不得不感慨：失败的人生，就是差了一顿德国肘子。
大规模组织实践改进经验参考
执行了W公司最大产品团队（600人）的改进后，我总结了一些经验。
改进
改进非常简单，典型的模型就是PDCA闭环。改进又非常不简单，因为不是每一个都能意识到、做到闭环。
如果到一个团队只是简单的PPT宣讲，那就只停留在“管理思路”这个层次。对于 W公司这类型的客户，是非常强调计划（Planning）的细节的，而我们的咨询师又往往不具备计划排程的能力。在这种情况下，可以让客户做一个计划，再以此为基础讨论修订。
执行层面，一定要注意是被改进对象的执行，而不是咨询师去落地，否则咨询离开，什么也不曾留下。在一开始，就需要和客户谈判对改进的投入，如果不愿意投入，宁可说时机不成熟而Say no，因为一个好的结果可以为我们带来更多的客户，而一个坏的结果可能让我们失去现在的这个客户。
检查和调整通常是咨询师的行动：需要我们主动、定期检查执行结果，并且调整我们的方案和我们的行动。比如有的团队结果达不到预期是因为我们投入不够，有的团队是因为遇到了外部阻力，这些都需要动用我们的资源来解决，保证团队继续朝着目标前进。
每一轮PDCA闭环都需要对目标进行演进，我们要非常清楚终极目标和层层推进的节奏，始终把握客户的预期和 团队的压力。而一个没有检查、没有目标的计划与执行，将永远也达不到任何提升效果。
沟通
建立起沟通机制。对超过数百人的团队，每个团队需要一个固定的接口人；如果是技术能力提升，必须确保这个人是高级技术人员担任。
沟通的开始是倾听和调研，以单元测试为例，我们从倾听意见开始。
然后在例行沟通上列出目标和工作方式，工作就可以马上开展了。
沟通的闭环在于反馈和改进目标的达成一致，可以使用一些便笺纸以“收益”、“障碍”、“需要帮助”三方面来进行梳理。
持续集成阶段计划
以在S部门实施总结为例，虽然客户依然不明白为什么是什么，但实施整体效果非常好，在于没走什么弯路而且取得了收益。
实施过程中，目标往往落后于计划，个人意见还是按照计划往前走，对未达到的目标加大执行投入度，只要让客户看到方向和进展即可。
标准方案
精益中的一项工具就是“减少变量”，找到标准方案。如果在大规模组织改进中找不到一个基准改进点、一套标准方案，结果就会变成到处都在投入精力做事，客户也在到处投入资源，预期时间到了却没有什么明显收益。
痛点分析
咨询最大的价值在于为客户分析现象并梳理出正确的思路，以下是鱼骨图参考，当然，还有很多分析工具，有兴趣可以自行Google.
最后的感谢
在三个月内开发和交付持续集成云平台，无缝支持六百人的团队完成构建、发布和测试，这支早期由四名外包组成的开发团队克服重重困难，展示了极限编程的能力。
一名开发人员由于过度热爱新技术，在办公室不知不觉写了一个通宵的代码。第二天各级领导纷纷发出警告“你们工作压力不要太大了”。
一名开发人员在老婆生孩子当天还坚持写代码，提交了功能才赶去医院。
从最开始第一次代码评审W客户的不理解“功能都做不完，搞这些有什么用！”到每周五例行的水果分享会。
感谢你们对项目的付出，也希望一起合作的时光，真的给你们注入了激情。
本文来自微信公众号“敏捷加速器”（ID：Agile-Booster），作者 陈加兴，资深敏捷精益专家，场量科技创始人。拥有超过十五年行业经验，帮助华为、招行等数家顶级企业优化IT效能，是LEAP产品创新方法的提出者。
管理圈经授权转载，如需转载请联系原作者。
粤公网安备 44010602010970