06 | 规模化推广：复制粘贴试点的经验就够了吗？

Jan 6, 2020

06 | 规模化推广：复制粘贴试点的经验就够了吗？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

06 | 规模化推广：复制粘贴试点的经验就够了吗？

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长16:58大小13.59M



你好，我是宋宁。
在前两节课中，我讲了如何做团队敏捷试点，这节课我就给你说说怎么把试点成功的经验做规模化推广。
试点不是目的，做试点是为了在我们的环境中探索敏捷实践的可行性，积累经验，若是确认敏捷在我们的环境中是好用的，我们就要根据试点结果，把这个过程中积累的成功方法推广到更多团队中。
规模化推广≠直接复制试点经验那么其他的团队该怎么使用试点团队的成功经验呢？是不是把它们直接复制过来就大功告成了呢？
在我做咨询的经历中，我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”，但其实这个说法只对了一半。
没错，我们是做了试点，试点中的经验教训也是可以拿来给后面的推广做参考，但如果直接复制未免有点简单粗暴。
举个例子。某个试点团队成功使用了 Scrum，于是领导一拍脑袋，也不管其他团队能不能吃得消，直接让所有团队一股脑儿在一个月内全部上马 Scrum。结果，有的团队导入 Scrum 比较顺利，而有的团队却遇到了很多困难。
其中，一个团队做的是运维类的项目，由于运维类项目开发的内容通常来自客户的建议或生产上的 Bug，比较零散，没有一定的规划性，所以对于他们来说使用 Scrum 并不合适，他们其实更适合使用看板；还有一个近百人的团队，产品本身比较大，团队拆分后有十几个小团队，只使用 Scrum 却没有解决好团队间的协同问题，效果同样不佳。
从这个例子你可以看出，上面这位领导除了拍脑袋和一刀切做决策，在推广敏捷时也只是机械地简单复制试点的成功经验，这非但没有给其他团队带来好处，对于他们来说反而成了一种桎梏。
此外，试点涉及的主要是团队内部的敏捷，而规模化推广还要涉及团队间的敏捷。
在做试点时，我们更多解决的是小团队内部的敏捷怎么用，所以对于单一小团队来说，借鉴试点中的经验更为便利有效。
而当你想规模化推广敏捷时，一旦小团队的数量多于两个，就会牵涉到团队与团队之间的协同问题。当然，在多个团队一起开发同一个产品的情况下，试点可能就是在多个团队中同时进行的，那么团队间的管理你也多少会涉及到。
当小团队数量多于 5 个时，如果你用的是 Spotify 这个组织模式，那小团队的管理就上升到部落（Tribe）级别，这时就要考虑部落内的管理了；而如果你的团队数量超过一个部落的范畴，你还需要考虑部落与部落间的管理。所以说当团队足够大时，它在管理上也就更复杂，使用管理小团队的方法就不够用了。
所以，从试点到规模化推广，是要从团队内敏捷扩充到团队间敏捷的过程。由于牵涉到团队间的协同管理，团队间的敏捷较之团队内的敏捷更为复杂，因为你要开始考虑让各个团队方向一致而不是互相羁绊，还要考虑跨多个迭代、多个团队、多个产品的情况下推进计划和安排优先级，更要考虑团队间的依赖、更大规模的沟通协调、多团队版本控制等一系列的问题，所以要想做好规模化推广，直接复制团队内敏捷的成功经验远远不够。
规模化推广的正确方法关于怎么做敏捷的规模化推广，当前有两个主流的框架，SaFe（Scaled Agile Framework）和LeSS（Large Scale Scrum），这里我不想用大量的笔墨给你介绍它们，如果你对它们的具体内容感兴趣，可以去它们各自的官网了解一下。
而之所以提到这两个框架，是因为它们是如今做规模化推广比较成熟的范式，它们的方法可以为我们提供参考，有很多团队甚至直接套用这两个框架，但我并不建议你这么做，因为它们都有各自的长处和短板，如果你使用不当，反而会陷入敏捷实践的歧途。
其实不只这两个框架，每个框架都有各自的优劣之处，所以我想和你强调的是，要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，你就可以有选择地拿来使用。就像我在一开始讲敏捷的价值时提到的，是不是冠以敏捷的名称不重要，只要它能帮助我们解决问题就好。
那规模化推广到底该怎么做呢？我认为，在做之前，还是要从企业或团队的痛点切入，看他们究竟需要解决什么问题。分析具体问题后，你可以从下面这些方面考虑怎么去推广，并形成自己的方案：
选择合适的规模化推广策略。推广时该选择激进式变革还是渐进式改革？其实这两种策略没有优劣之分，你需要结合企业变革的急迫程度、领导支持敏捷推广的力度以及团队能接受的方式来进行选择。
做好敏捷文化铺垫，培养好敏捷的中坚力量。文化和人员始终都是整个敏捷推进过程的坚实基础，在规模化推广过程中也是如此，所以你也要做好必要的全员敏捷基础培训和核心敏捷人员的能力培养，以便支持更多团队开展敏捷。
搭建适合敏捷的工作环境，做好必要的工具和自动化准备。适合敏捷的工位布置，必要的物理白板和各种协同管理工具等，这些无论在试点还是规模化推广中都是必要的硬件设施，配合着规模化推广也要有相应的硬件准备。
组织级别的敏捷度量以及持续改进。你要做好组织级别的敏捷度量，从效率、质量、成本等方面收集敏捷相关的数据，并借由这些数据辅助企业做持续改进。
重视大型团队的敏捷导入与推广。这一点是规模化敏捷的核心，因为有的产品需要多个团队共同交付，这就涉及到复杂的团队间的敏捷，因此很多企业在做规模化推广时都会遇到这个问题，这也是我想重点给你讲的部分。
接下来我会结合一个案例，来给你讲具体怎么做大型团队的敏捷导入与推广，做好了这点，我相信你的规模化敏捷之路会更加平稳顺畅。
规模化推广实例分析这个案例来自一家银行，我们姑且叫它 D 公司，他们的研发团队有接近 2000 人，在比较顺利地做了试点后，希望做规模化推广，让敏捷为整个公司的研发赋能。
我先分析了他们的痛点，总的来说就是研发效率比较低，无法满足业务发展的要求。他们的问题也很突出，主要有 3 点：
研发中各个环节的效率有待提升，各个角色的等待时间过长；
敏捷走到业务那里就卡壳，业务人员参与度低；
跨团队沟通不畅，协作效率低。
针对问题 1，我们在规模化前的试点中，改变了研发模式，让小团队使用了 Scrum，很有效地解决了这个问题。
而问题 2 和问题 3 涉及的就是大型团队导入与推广敏捷最需要解决的两个问题。要想做好规模化敏捷，主要就是要突破这两个问题。
那么该如何解决这两个问题呢？
针对问题 2 业务人员参与度低这个问题，其实就是 D 公司在推广时忽视了业务这一环。
你要注意，只做到开发、测试团队的敏捷，只算是敏捷的一个小胜利，最重要的是要走向业务敏捷。只有业务敏捷了，我们才能和 IT 团队一起真正打通研发整个过程的敏捷，才能在短时间内快速交付业务价值。
因此，大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。
所以针对问题 2，我们主要通过两个方法来解决。
第一是定制度。确立产品负责人制度，将过去以“项目”为中心的管理改为以“产品”为中心的管理。只有这样，才能让业务战略与产品战略合二为一，让整个团队目标一致，“劲儿往一处使”，从而方便团队做好研发全链条的敏捷。
第二是定反馈机制。在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉到需求识别，到开发上线，再到业务运营的整体大反馈闭环。这样做的好处是为端到端的研发过程提供了数据支持，以便在后续工作中识别整个研发过程的瓶颈，为持续改进做支持。
针对问题 3 跨团队沟通不畅这一问题，涉及的就是团队间的敏捷实践。
我们很多团队在需要兄弟团队协助开发时，总是希望对方在我们需要时能够随叫随到，但每个团队都有自己的优先级工作，哪里有时间随时“听喝”呢？
因此，要建立各团队间的敏捷实践，就需要提前安排支持工作。这样，你们团队需要协助的工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理，省去了很多无效的沟通和无谓的等待。
由于管理实践是后面一切具体技术实践的基础，因此在这里我只想教你如何在管理实践上探索团队间的敏捷，带你做好这关键的第一步。
所以针对问题 3，我们主要是建立沟通机制，对齐团队目标，把“做什么”和“怎么做”这两个方面的目标对齐以后，团队间的沟通就更加有序和高效了。
具体的措施是定义了一系列关于产品团队内以及与 Scrum 团队间的沟通策略和沟通机制，定期的产品集体计划会议，并将团队间的依赖放到看板上，通过 Scrum of Scrum 来定期沟通进展。其它还包括一些具体的技术实践，例如怎么进行团队间版本控制，团队间的架构解耦等等。
把这两个问题解决好以后，D 公司根据自己的情况优先选择了做管理实践的规模推广，又在工具和自动化方面做了更多工作。考虑到要做敏捷的长期实践规划，我们又通过培养核心人员，也即内部敏捷教练来延续企业的敏捷文化，具体的举措，你可以参考后续09的文章来看。这样他们的规模化敏捷工作就开始平稳地推进下去。
最近我又对他们进行了电话回访，发现几年以后的今天，他们内部已经完成了规模化敏捷 1.0，目前正在循序渐进地推进规模化敏捷 2.0，重点放在 DevOps 方面的建设。据其核心负责人反馈，他们一直在做持续改进，我为他们的持续性探索而开心，因为这也是敏捷的本质所在。
总结好了，现在我带你总结一下今天这节课的内容，帮助你更好地理解。
敏捷的规模化推广不是去简单拷贝试点经验，也不是找来几个规模化框架往企业身上套，而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。当然在这个过程中，成熟的规模化框架可以给予我们参考。
规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷这两点上。你可以通过定制度、定反馈机制推进业务敏捷，可以通过在管理实践上建立沟通机制，对齐团队目标来保证团队间敏捷的高效和有序。当然除了这一点，你也需要统筹全局，从推广策略、文化、环境等方面完成整个规模化推广的持续改进。
敏捷的推进不是一帆风顺，但是走到了规模化推广这一步，我想由衷地恭喜你，因为这意味着你的敏捷实践已经克服了很多困难并取得了一定成果，我相信只要你以更加坚韧的心态和努力的态度去不断检视、改善自己，坚持下去，你的敏捷实践一定会取得更大的成功。
思考题现在，我想请你来思考一下，假设你在一个大型的研发组织里，你会怎么做敏捷规模化推广呢？你有成功或失败的经历吗？
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

分享给需要的人，Ta购买本课程，你将得9元

生成海报并分享

赞 7

提建议

05 | 团队试点（二）：打造一支无往不胜的敏捷团队

07 | 填坑指南：填好这4个坑，快速做对敏捷

 写留言

精选留言(24)

吴言乱语
2020-01-07
举一个由我们小团队主导的项目在业务需求沟通后，我们发现需要ABC三个技术部门同时协同完成，于是 1.在第一时间询问ABC三个团队的产品负责人，了解他们的项目排期，是否有时间支持。其中A团队表示他们在我们的计划时间内目前没有新需求导入，BC均表示已有安排。 2.将技术团队沟通结果反馈我们对接的业务部门，业务部门表示优先级很高，所以请业务中心统一协调BC团队的对应业务部门调整需求优先级。 3.达成一致后，由我方团队发送项目立项邮件，抄送ABC团队产品及业务负责人，约定立项会议召开时间。 4.会议宣讲项目需求，及所需配合事项及我们的各时间节点期望。 5.会议明确我方主导，ABC辅助，明确产品，开发，测试对接负责人，明确沟通交流机制，每天下午5：00-6：00为集中答疑时间；如有优先级更高的问题，反馈至产品负责人协调。 6.会议后，我方团队与A、B、C三方团队分别细致拆分技术方案，达成共识，并共同确定各时间节点。 7.将项目排期邮件抄送全项目组。 8.成立项目组线上沟通群。 9.项目顺利上线
展开
共 3 条评论
35
bentley
2020-01-14
请教，老师能讲一下针对问题3，制定的具体沟通策略、沟通机制吗？
作者回复: 因为管理实践是后面一切具体技术实践的基础，基于篇幅原因，我在这里就只展开谈如何在管理实践上探索团队间的敏捷。具体到怎么做上，主要有下面几个方面。  定义了一系列关于业务分析师的沟通策略和沟通机制，来在“做什么”上的目标对齐，即产品目标对齐。例如产品团队中，业务分析师每天有自己的站立会议，沟通各自的产品工作，这样来保证不同团队间的产品工作内容是可以协同的，既不会让目标分解后有产品内容落掉，也不会有做重复的；而到Scrum团队中，业务分析师会定期跟团队开需求梳理会议，也会有需求做完后的评审会议，平时也有跟团队成员的不定时沟通，例如沟通用户故事的内容和验收准则等。这是因为，在组织中，业务分析师在产品管理中起到了承上启下的作用。他承担了两部分工作，一个是在产品团队里，定期聚在一起来看各自的产品目标分解，来完善自己小团队需要做的产品细节内容，另一个是要到各自的Scrum团队去，给Scrum团队成员讲解需求细节等等，以便于团队能够正确理解需求细节并在此基础上正确实施。  定期的产品集体计划会议，保证在“怎么做”上的目标对齐。在这个会议上，产品负责人来给大家宣讲未来两个月的产品目标，并简单介绍产品主要要完成的功能；各个业务分析师把各自团队需要的做的细化需求展示给他们各自的团队，该需求列表是排好优先级的；Scrum团队对需求条目进行粗略估算，估算完毕大家根据各自的产能来进行4个迭代的需求排步，在排布的过程中，识别各个团队之间的依赖；在做排布的过程中，各团队的Scrum Master要聚到一起来看依赖的情况，并一起做一张依赖关系表和依赖的开发安排。在会议结束的时候，大家一起制定了未来2个月的迭代计划，识别了各个团队之间的依赖，并在会议结束的时候将团队依赖做到看板上，以便后续管理依赖。我们的产品集体计划会议，类似于Safe的增量计划会（PI Planning），不过，我们没有做3个月长度的计划，而是缩短为2个月，因为团队还没有能力做更长时间的规划和预判。我们也没有全盘复制SaFe里的关于这个会议的全部内容，而是根据实际情况做了一些修改。例如我们没有选择集体澄清需求，而是在正式开这个会议的时间之前，让各个小团队自己先理解各个小团队的需求，这样我们整体会议就不需要2天的时间，而是缩短为1天。  定期的团队的Scrum Master之间的Scrum of Scrum会议，来沟通大家各自的进展。只将团队间的依赖关系做到看板上，这是不够的，更多的还需要在开发过程中，及时地跟进依赖的开发进度。所以我们安排了定期的团队的Scrum Master之间的Scrum of Scrum会议来沟通大家各自的进展，这个会议一般在一周中安排2-3次，如果团队间的依赖开发有延迟，就会提前预警。
20
escray
2020-01-15
在我的印象里面，敏捷一般只适用于小团队，规模化推广的时候最难的应该就是团队间的敏捷和沟通。不过，我还是认为敏捷开发多少有一点精英倾向，如果人员的素质达不到的话，最好还是放慢节奏，逐步推进。通过定制度和反馈机制来试图解决业务敏捷的问题，我觉的也是难点。如果业务部门比较强势的话，那么想要把业务拉到 IT 团队的敏捷开发过程中，应该是一件比较困难的事情。团队间的敏捷实践，需要大量而有效的沟通，这个也不容易，特别是每个团队有不同的利益诉求。如果将来有机会换工作，那么我也希望能够进入一个采用敏捷开发的团队，同时我更倾向于小团队，而不是大组织。如果我在一个大型的研发组织，想要做敏捷的规模化推广，我觉的也只能让那些有敏捷意愿的团队去试点并实施，对于一些比较排斥敏捷的部门，那就由他们自己去探索。即使高层领导想敏捷，而一线开发团队不想要，那么也不能强推。如果能把瀑布流做好，其实也没什么不好。当然，比较理想的是，在试点和早期采用敏捷的团队影响下，组织内的人员都能够意识到敏捷的益处，并且在敏捷的基础设施比较齐备的情况下，愿意尝试，有意转型。
展开
共 1 条评论
3
Jason
2020-04-16
老师，我看到这里我还是不明白为什么不一开始就将所有的坑以及好的方法论告诉大家，而是让团队自己去试错，这样试错的不是会造成成本更高吗？站在巨人的肩膀上在进行迭代不是更好吗？
共 3 条评论
2
行骏
2021-08-29
规模化推广之前，还是识别哪些业务或者团队是不适合敏捷研发的，不然会形成了无解反馈，容易造成以此举例的反响案例。
1
梁中华
2020-03-29
我遇到过一个master把自己活成了项目管理，例外去协调，结果整个团队特别依赖他，他一走整个团队的工作就很被动，没人愿意主动协调我，推动了。请问这种情况怎么破？
2
天天铛铛铛
2020-03-14
以项目”为中心的管理和以“产品”为中心的管理，有什么差异，各自侧重点是什么，还请老师指导下
作者回复: 产品管理强调What，也就是做的什么产品。重点在需求管理，计划管理，发布管理。产品管理既关注产品的具体形式，也关注产品实现的过程，也要对最终使用产品的用户负责。而项目管理强调How，怎么做，主要是任务管理，侧重的是如何实现这些需求。项目管理更关心达成项目目标实现的过程。
1
mithril
2020-02-20
这些东西不就是我看了十几年的新军事革命的东西嘛，连过程和名词都高度相似。马克思说人类进行生产的方式就是人类进行战争的方式，这句话不但对而且还能反过来啊
共 1 条评论
1
Raymond吕
2020-01-09
想请教老师，规模化敏捷和项目集管理是否有相似之处？感觉从单项目敏捷到一些有联系的项目，相互作用共同产生价值，这点和项目集的理念有点相似。
作者回复: 有些基本点是相似的，因为都要解决团队间的沟通问题等等。
1
ifelse
2022-11-28 来自浙江
规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷这两点上。--记下来
ifelse
2022-11-28 来自浙江
学习打卡
甘亚鹏
2022-07-30 来自北京
试点经验不是复制粘贴，但是很多经验可以参考
Jerry
2021-03-13
老师还有没有进阶课程，这一期的感觉没有说透敏捷，只说透了教练
小寞子。(≥3≤)
2020-08-18
不知道作者还在不在IBM。我们最近在推的garage methodology其实就是敏捷加design thinking。其中scale问题和文章中写的一模一样。
Happytu
2020-05-12
请问老师，我们团队是一个开发测试产品加起来有150人的团队，想进行敏捷推广，尝试了小组划分，但是共同做一个产品，小团队的开发在不同的迭代因为需求的不同需要动态变更敏捷组，请问老师这种局面怎么破？
共 2 条评论
layton0216
2020-03-29
敏捷的规模化推广不是去简单拷贝试点经验，也不是找来几个规模化框架往企业身上套，而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。每个机构和团队都有自己的情况，因地制宜是再正确不过的了。
姜华梁taric
2020-02-24
我们现在团队有四个敏捷小组，项目负责人怎么去监控整个项目进度，老师有没有什么好的方法
作者回复: 首先是这样，可以有在线工具管理起来，比方说Jira，每个小团队每天都会更新，所以进度都可以在工具上显示出来，只要登录在线工具，就可以看到进度情况；再者为了更好地管理风险，以及促进团队之间的协同，可以建立一个小组之间的沟通机制，隔几天让每个小组的负责人碰一下面，沟通一下依赖的进度情况，以及是否有风险等等。
咖啡
2020-02-02
我们公司有140的研发有 6 7 个业务团队我们团队直接经常英文业务这些不对齐迭代不一样出现问题
镜花水月
2020-01-28
我们是500人的研发团队规模化敏捷，团队间的依赖主要在需求收集阶段识别出来并提给相关方。
J.Smile
2020-01-27
今天学习有感: 从小团队试点到团队之间协同，我相信通过敏捷教练或者专家的指导可以建立起来一套机制，但是我担忧这套机制如何长久维持，如何被监督执行下去？毕竟世界趋于不确定性(熵)

