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

Jan 6, 2020

07 | 填坑指南：填好这4个坑，快速做对敏捷-极客时间



下载APP





关闭

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

渠道合作

推荐作者

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

2020-01-06 宋宁来自北京

《说透敏捷》

课程介绍



讲述：宋宁

时长20:12大小16.19M



你好，我是宋宁。
今天这节课我来给你讲讲敏捷实践中，你会遇到的一些问题以及解决方案。
理想很丰满，现实很骨感。敏捷听起来那么美好，它的推进策略和推进路线貌似也有迹可循，但现实却往往事与愿违。在实践过程中，我经常听到有这样一些问题：
团队刚开始做敏捷时就遇到了很强的阻碍，因此不喜欢做；
敏捷做着做着就流于形式，大家慢慢地就偃旗息鼓了；
开发测试人员干得很苦，然而只是他们自己在忙活，他们的上游产品却游离在外，很不给力。
如果你也遇到过这些问题，并且不知道该怎么办，那么今天，我就带你来看看 A 公司的敏捷实践历程，结合他们在推进敏捷时遇到的一些坑，给你讲讲相应的填坑策略吧。
我先来简单介绍一下 A 公司的情况。这是一家国有企业，是业界排名前几的保险公司，研发团队有一千多人，前些年因为受到互联网冲击，业绩压力比较大，加之他们有提升研发效率和透明度的诉求，因此就准备通过推进敏捷改良现状。
前期他们没有自己的敏捷教练，也没有向外聘请敏捷教练，自己分步推进，磕磕碰碰地实践了接近两年，结果遇到了很多问题和困难。无奈之下，他们只好找专家组来帮忙。
专家组来到现场后，慢慢梳理了他们的问题，给出了解决方案，也亲自做了示范，一段时间后，团队最终把敏捷推进成功。作为专家组中的首席敏捷教练，我经历了这个过程，现在就来分享给你。
坑一：团队说他们不想做敏捷我刚进这个公司做咨询时，他们就请我帮忙诊断一个团队，据说是个难啃的骨头，因为这个团队不想做敏捷。他们的领导希望能够引进敏捷做一些改进，然而团队对此并不感冒，在推进敏捷上阳奉阴违。
我先跟这个团队的 Leader 做了一次约谈，他对我说：“我们已经很忙了，没有时间做敏捷。”看来我马上就要吃闭门羹了，这时该怎么办呢？
以我的经验来分析，团队不想做的原因有很多方面，不能只看表面，必须深层次挖掘，比如：
团队没有真正理解到底什么是敏捷，能给他们带来什么切实有效的帮助；
团队真的很忙（当然“忙”要分情况应对，是否是有效的忙碌也是一个值得探讨和挖掘的方面）；
团队中有人一言堂，这个人的意见不改变，其他人不敢动。
我在调研后发现，这个团队之所以很忙，其实是因为资深老员工不够信任新员工，凡事都要亲力亲为。那么我是怎么发现这个原因的呢？
在并不太被接受的情况下，我跟这个团队的 Leader 说：“我不影响你们工作，只坐在你们旁边可以吗？”他表示赞同。
就这样，我坐在他们团队旁边，观察他们的一举一动，没几天我就发现了这个团队的小情况。他们有两位资深员工，另外 5 个人都是新人。其中一位资深员工经常在团队工作中一言堂，与此同时，他不信任新员工，对新员工做的很多工作都不放心，于是基本上所有核心一点的工作都是这两位老员工在做，其他同事最多打打杂，这样他们不忙才怪呢。结果就是，两位老员工忙得脚打后脑勺，新员工却没什么大事儿可做，每天也不开心，总觉得自己被边缘化。
在分析了这个根本原因后，我制定了以下对策。
我决定从这位资深老员工下手，慢慢地解决问题。首先，我先找他分享了我的观察，交流了一些基本管理技巧；其次，我鼓励他试着慢慢放手，让其他团队成员参与进来，并定期做代码 Review。这样几轮迭代以后，他们的工作变得均衡了，老员工不那么累，新人也成长起来了，团队整体的满意度也提升了。在此基础上再引进敏捷的新思想和实践，也就没人反对了。
总而言之一句话，不了解和分析现状就直接推进敏捷是非常不靠谱的，必须要看清现实，摸清痛点，在这基础上导入并推进敏捷才是可行的。
坑二：不理解敏捷背后的意义，把它当作一种新的流程，而忘记它的核心是持续改进上面我们解决了团队不想做敏捷的情况，在实际工作中还有一种情况是：即使公司已经在推进敏捷，但对于很多并不深刻理解敏捷的员工来说，他会说敏捷不就是一套新的流程、一种新的工具吗？
我在调研 A 公司的员工时发现，大概有一半以上的人认为“敏捷就是一种替代瀑布的新流程”，他们一直在开 Scrum 中的五个会议，已经开得烦闷又枯燥，也没看到显而易见的好处，但迫于高层的压力，不敢停下来。
于是整个团队每天都在机械地重复着，回顾会议里的问题也就是反反复复的那几条，而这些问题基本上又是自己内部不能解决，需要别的团队协同或者高级管理层来协助才能解决的，但没有人去推动，问题就日复一日地挂在那里。团队里渐渐怨声载道，觉得敏捷只是凭空增加了很多会议，并没有带来什么新的好处。
面对这种情况，我认为他们犯了两个错误：
公司敏捷实践的基础导入工作没有做好，连敏捷究竟是什么，以及为什么要做敏捷都没给团队讲清楚；
缺乏一名强有力的敏捷教练做引导，在持续改进方面欠缺较大。
那么，如何能让整个团队更清晰地理解和接受敏捷呢？我认为可以通过两种方法来实现：
基础培训、基础培训、基础培训，重要的事情说三遍。有很多公司舍不得投入前期的基础教学时间，大家对敏捷的理解一知半解时，就开始让大家照猫画虎、迅速展开实践，这就造成了大家在做各种实践之前根本不知道这样做的背后有什么意义，从而导致了整个程序的僵化。通常来说，敏捷推进会经历三个阶段：做敏捷（doing agile）、思考敏捷（thinking agile）和思想敏捷（being agile），但如果只停留在“做敏捷”的阶段，就会出现这样的问题。
找一个靠谱的敏捷教练陪伴。敏捷本身是一种变革，是从指挥和控制到协作的、以团队为中心的结构性转变，它也涉及到人的思维和习惯上的改变，归根结底不是那么容易的。因此这种转变需要一个有丰富经验和影响力的人来持续引导，敏捷教练就是这样的角色。他不仅负责组织一个敏捷团队，还通过敏捷帮助公司进行文化层面上的转变。因此在推进敏捷过程中，你需要一位甚至几位敏捷教练来陪伴。
坑三：Scrum 过程被严重缩减，只剩下每日站会在团队认识到敏捷会带来好处并开始推进它后，是不是就可以顺利推进了呢？其实不然，在推进过程中你仍然会遇见各种各样的问题。
有一天，一个负责理赔服务研发的团队 leader 找到我，对我说：“宋宁老师，你快过来看看我们团队吧，我们的敏捷现在很尴尬，只剩下站会了……”我很诧异，因为这个团队之前做得还是很不错的，怎么就变成这个样子了呢？带着种种疑惑，我到团队里进行了调研和观察，我发现他们用的是 Scrum，但很默契地剪掉了里面几乎所有的会议，只留下了站会。
但是，我没有急着下结论、给建议，我了解了他们的实践经历后，我发现他们在公司整体的转型中，导入敏捷比较晚，刚开始大家还很有激情，每个 Scrum 的实践都做到了，将敏捷做得有声有色。但等他们的导入者走后，会议就渐渐地没人张罗了，会议过程也没人关心、没人引导了，慢慢地大家就开始觉得没有做下去的必要了。
再到后来，大家觉得聚到一起开会无话可谈、倍显尴尬，就自然省掉了这些流程，还美其名曰为了提高效率。半年以后，当他们发觉自己的敏捷有问题再请我去看时，整个实践已然是病态的了，前期的成果基本前功尽弃，我需要再多花一倍的时间帮他们重新建立信心，重新燃起敏捷的火种。
那么这个团队的问题在哪呢？在我看来，最重要的问题是他们没有培养出属于自己的合格的 Scrum Master，这导致敏捷教练或咨询师撤场以后，敏捷的火种无人守候，纪律也没人看管。敏捷的效果在短期内并不容易显现，因此在团队的习惯刚刚养成还没有固化时，一旦敏捷教练或 Scrum Master 不在场，大家很容易迅速回到引入敏捷前的状态，使敏捷的成果付之一炬。
那么该如何解决这个问题呢？
首先，你一定要认识到 Scrum Master 在敏捷实践中的重要性。在团队还不成熟的时候，他负责宣讲敏捷的价值观和理念，也负责具体实践的导入和守护。一个好的 Scrum Master 在引导（facilitation）、教育（teaching）、辅导（mentoring）、教练（coaching）这四个方面都有很强的能力，并能根据具体的情景选择专项的能力，帮助团队体验敏捷，坚定维持团队新养成的敏捷习惯。在领导力方面，他具有服务型领导的理念，是团队的主心骨，能帮助团队打造敏捷文化。
其次，要想将敏捷推进到底，必须在基层留有敏捷的火种。因此，在推进敏捷之初，团队就应该计划一系列 Scrum Master 的培养活动，识别出优秀的 Scrum Master，然后相互配合着推进敏捷；每周也要举办工作研讨会，学习和实践我刚刚讲的那 4 种能力。在敏捷实践后期，由 Scrum Master 来负责引导团队，并听取敏捷教练的反馈意见，这样在教练离开之后，培养好的他就会接过敏捷的大旗，专心引导和辅导团队，在团队遇到困难时及时帮助解决。与此同时，跟随着团队推进敏捷的步伐，引入新的合适的实践。
坑四：筒仓中的敏捷所谓筒仓，原指贮存散装物料的仓库，用在研发领域，指的是公司部门各自为政，不好协同。A 公司的敏捷实践进行了一段时间后，这样的问题也出现了。
公司开发测试部门的副总最先意识到敏捷的价值，他带着一腔热情，撸胳膊挽袖子，将开发测试部门敏捷了，然而火种却并没有传播到其它支持协同部门，除了开发和测试部门以外，其它各部门之间还是各自为战，形成了严重的筒仓。比如：
产品业务部门没有协同，因此对需求的分析理解还是极其缓慢，每次到迭代开始时，需求都准备不好，打乱了开发的节奏；
上线运维部门也与开发测试部门割裂，导致虽然开发测试做得很快，然而到了上线那一步又变慢了，最终拖慢了整个进程。
因为研发管理的全链条没有打通，开发测试部门也不能真正感受到敏捷带来的好处，最后推动无力，大家越来越没有信心，敏捷遂在大家的愤懑中偃旗息鼓，人人不愿再提“敏捷”二字。
针对上面的状况，如何来解决呢？
仅就这个问题本身来讲，我认为前期应该多宣讲敏捷的本质和好处，尤其应该推动对高管层面的宣讲，成立更高级别的敏捷实践督导团队。当高管层面理解到敏捷的好处和他们应该做的事情之后，就不会阻碍整个推进过程了，还能及时为敏捷提供必要的帮助，这尤其适用在一些大型的控制型传统企业中。
以 A 公司为例，他们现阶段要想实现“需求 - 开发 - 测试 - 运维”的全链条协同，必须推动组织变革。但这是一家大型国有企业，从某种意义上说，推动组织变革尤其是大部门的组织、合并、重组并不容易，必须由高层领导认可才能推进下去。
在经过谨慎的思考后，我鼓起勇气将这个问题提到了他们总经理的办公会上，并跟总经理约到半个小时的访谈时间，借由这个机会向他宣导敏捷。最终的结果很让人满意，他们的高管高度重视和推进了这件事。在几个月后，我做回访时，发现他们已经做完了组织重组，并按照之前我们的规划进行了研发全链条的协同，不仅提升了研发效率，也提升了研发的整体满意度。
就这个问题再深层次地挖掘一下，我认为：
第一，推进敏捷时要通盘考虑整个链条应该怎么推进。组织全功能团队，除了一个一个的敏捷小团队以外，还要考虑需求管理怎么推进，并想好推进策略。
第二，敏捷可以分步推进，但是推进过程中一旦识别出新的阻碍，要及时去除。像在 A 公司这个案例中，我相信当产品团队没有跟着一起推进敏捷时，整个流程很快就会有新的问题浮现出来，例如每个迭代前，需求条目都准备不好，在这种情况下，这个障碍就应该及时去除。
总结好啦，我们今天的课到这里就要结束了，结合我给出的填坑策略，现在我来总结一下。
敏捷是个整体工程，需要从全局上考虑怎么去推进。在前期，要做好诊断和规划，在解决痛点的基础上导入适合自己的敏捷方法；推进过程可以分步进行，但要及时排查每一步中可能出现的新的障碍；要加强协作，打通研发管理的全链条，必要时要成立高层参与的督导团队，请高层领导帮忙推动；在整个实践过程中，都需要有能力的敏捷教练陪伴，并培养出适合自己团队的 Scrum Master。
从今天的课程你可以看出，推进敏捷确实不是一件容易的事，在这个过程中你会踩到很多坑，而在填坑时既要有方法的甄选，又离不开人力的支持，很多公司和团队之所以会遇到各式各样的问题，也是由于他们或是浅尝辄止，或是急于求成，没有把敏捷实践真正落实好。所以我相信，只要你稳扎稳打，踏实、耐心、正确地完成每一步，夯实基础、持续改进，再多的问题都会迎刃而解；你更会举一反三，成为一名真正的“填坑专家”。
思考题最后，我想请你思考下，在推进敏捷的过程中，你踩到过哪些坑呢？除了文章中提到的方法，你还有更好的填坑方法吗？
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。

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

生成海报并分享

赞 15

提建议

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

08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？

 写留言

精选留言(27)

escray
2020-01-14
说透敏捷 07 | 填坑指南：填好这4个坑，快速做对敏捷在国企，一千多人的研发团队里面推广敏捷，这个难度还真是挺大的。我觉得敏捷教练到现场去观察是一个非常好的方案，能够发现一些细节。但是在坑一中，如果资深员工没有办法说服，不可放手怎么办？估计会有很多人，担心敏捷之后，自己的绝活就不能体现价值了。填二号坑主要靠的是基础培训和靠谱的敏捷教练，但是我始终认为在导入敏捷的初期，一定要想方设法降低团队的无效劳动，包括 Scrum 的五个会议。在我目前的单位，开会的时候，领导有时候会讲的一时兴起，然后时间就没有了。坑三的问题是缺乏团队内部的 Scrum Master，我觉得 Scrum 方法似乎讲究蛮多的，可能不适合刚开始接触敏捷的团队来练手，对教练和 Master 的要求都比较高。坑四应该也是在大企业中常见的问题，能够推动高层介入，并且克服阻碍，最后实现全流程的敏捷，这个真的是不容易。感谢作者给出的案例，并且有针对性的给出了解决方案。没有推进过敏捷，但是在自己试图使用敏捷方法的时候，发现一开始其实可能会需要更多的时间，比如搭建基础环境，并且要写单元测试；一个人的话，那些站会什么的也比较难以进行。我应该属于接受敏捷思想，尝试敏捷方法，但是没能坚持使用的阶段。学习专栏之后，希望有机会，再试一次。
展开
共 1 条评论
7
霸波儿奔
2020-01-09
这四个坑确实是实践中实实在在存在的，讲的非常棒，谢谢
6
layton0216
2020-03-29
团队刚开始做敏捷时就遇到了很强的阻碍，因此不喜欢做；敏捷做着做着就流于形式，大家慢慢地就偃旗息鼓了；开发测试人员干得很苦，然而只是他们自己在忙活，他们的上游产品却游离在外，很不给力。这些问题就是我们现在面临的，老师确认给我一个指向。
4
J
2020-02-10
Scrum Master的角色和职责怎么划分？Ta与BA、PM、Developer的关系是什么？感觉有点像PM，或者是PM来兼任？那么，一个Scrum Master可以同时做多个项目吗？或者说一个Scrum Master同时属于多个团队，会有什么问题？
作者回复: 一个小团队一个Scrum Master是最好的，但是对很多公司来讲有点过于奢侈。所以一般一个全职的Scrum Master可以带2-3个团队。不要让PM来兼任。
3
进击的小明
2020-02-03
我们公司就是搞敏捷最后只剩下站会了 😂😂学习了
共 1 条评论
1
王刚
2020-01-08
文章上面提到的4个坑，真是现实公司中实际存在的；该专栏真心好！感谢！！！
作者回复: Good，希望内容对你有帮助
1
ifelse
2022-11-28 来自浙江
不了解和分析现状就直接推进敏捷是非常不靠谱的，必须要看清现实，摸清痛点，在这基础上导入并推进敏捷才是可行的。--记下来
ifelse
2022-11-28 来自浙江
学习打卡
甘亚鹏
2022-07-30 来自北京
测试与产品的之间关系很微妙，影响产品的输出定海神针
Silence Wang
2022-04-02
产品经理确实也需要敏捷，把一个需求拆细，控制好颗粒度，不要把一次迭代搞得太长，搞成了瀑布。
1
霍霍
2022-03-23
刚开始接触敏捷，积累一些理论来指导实践
banxiaobu
2022-03-17
2022年了，我是一名研发人员，在目前工作岗位中遇到敏捷，对这些感兴趣了，才来学习敏捷知识的。宋老师提到的这些，我觉得，不仅将来，很快我们公司就都会遇到。敏捷绝不是说说而已，而我现在作为参与者，我只能用心体会与思考。至少“持续改进”，与我目前自己的工作方式，以及小组内推广的改进方式想吻合。就这一点，嗯，未来加油！
展开
吴杨明
2021-12-06
1 建制度、指引 2 组织训练营、培训和考试 3 试点，推广到项目、部门、集团 4 提供工具服务 5 度量与统计 6 培养分享、透明、协作的组织文化和价值观。
展开
行骏
2021-09-01
改变的过程中，容易放大问题而减少收益获得，这样容易形成摇摆和不坚定，然后乱撞乱改。
Melody~
2021-06-16
有一个细节，如果您和不配合敏捷的那位资深研发沟通，她继续不配合你，怎么办？一切都是顺利情况下，然而现实中，沟通的逆境也较多！您如何从一个陌生人让各自为政的部门都信任你
1
刘隐林
2021-05-27
团队无法拒绝,业务压力大,PO强压任务,导致开发的测试任务量重,每个人加班多,质量下降,被吐槽批评,然后恶性循环.
李小歪
2020-05-25
搞敏捷最后只剩下站会了+1，而且站会也是重复对着白板陈述，士气低落，好不甘心
梁中华
2020-03-29
有些公司在开发都启动到一半了，老板不满意产品功能和交互，或者又有新的想法，要马上实施，这种情况该怎么办呢？
共 2 条评论
而立斋
2020-01-30
这篇是干货，能学到不少技巧
共 1 条评论
镜花水月
2020-01-28
感觉一个专业，经验丰富，有影响力的敏捷教练非常重要，否则就慢慢演变出各种问题
共 1 条评论

