CategoryResourceRepost/极客时间专栏/说透敏捷/策略篇/07 | 填坑指南：填好这4个坑，快速做对敏捷.md

<audio id="audio" title="07 | 填坑指南：填好这4个坑，快速做对敏捷" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4d/c5/4df9f0be3ce3e7feea1f533097628cc5.mp3"></audio>

你好，我是宋宁。

今天这节课我来给你讲讲敏捷实践中，你会遇到的一些问题以及解决方案。

理想很丰满，现实很骨感。敏捷听起来那么美好，它的推进策略和推进路线貌似也有迹可循，但现实却往往事与愿违。在实践过程中，我经常听到有这样一些问题：

- 团队刚开始做敏捷时就遇到了很强的阻碍，因此不喜欢做；
- 敏捷做着做着就流于形式，大家慢慢地就偃旗息鼓了；
- 开发测试人员干得很苦，然而只是他们自己在忙活，他们的上游产品却游离在外，很不给力。

如果你也遇到过这些问题，并且不知道该怎么办，那么今天，我就带你来看看A公司的敏捷实践历程，结合他们在推进敏捷时遇到的一些坑，给你讲讲相应的填坑策略吧。

我先来简单介绍一下A公司的情况。这是一家国有企业，是业界排名前几的保险公司，研发团队有一千多人，前些年因为受到互联网冲击，业绩压力比较大，加之他们有提升研发效率和透明度的诉求，因此就准备通过推进敏捷改良现状。

前期他们没有自己的敏捷教练，也没有向外聘请敏捷教练，自己分步推进，磕磕碰碰地实践了接近两年，结果遇到了很多问题和困难。无奈之下，他们只好找专家组来帮忙。

专家组来到现场后，慢慢梳理了他们的问题，给出了解决方案，也亲自做了示范，一段时间后，团队最终把敏捷推进成功。作为专家组中的首席敏捷教练，我经历了这个过程，现在就来分享给你。

## 坑一：团队说他们不想做敏捷

我刚进这个公司做咨询时，他们就请我帮忙诊断一个团队，据说是个难啃的骨头，因为这个团队不想做敏捷。他们的领导希望能够引进敏捷做一些改进，然而团队对此并不感冒，在推进敏捷上阳奉阴违。

我先跟这个团队的Leader做了一次约谈，他对我说：“我们已经很忙了，没有时间做敏捷。”看来我马上就要吃闭门羹了，这时该怎么办呢？

以我的经验来分析，团队不想做的原因有很多方面，不能只看表面，必须深层次挖掘，比如：

- 团队没有真正理解到底什么是敏捷，能给他们带来什么切实有效的帮助；
- 团队真的很忙（当然“忙”要分情况应对，是否是有效的忙碌也是一个值得探讨和挖掘的方面）；
- 团队中有人一言堂，这个人的意见不改变，其他人不敢动。

我在调研后发现，这个团队之所以很忙，其实是因为资深老员工不够信任新员工，凡事都要亲力亲为。那么我是怎么发现这个原因的呢？

在并不太被接受的情况下，我跟这个团队的Leader说：“我不影响你们工作，只坐在你们旁边可以吗？”他表示赞同。

就这样，我坐在他们团队旁边，观察他们的一举一动，没几天我就发现了这个团队的小情况。他们有两位资深员工，另外5个人都是新人。其中一位资深员工经常在团队工作中一言堂，与此同时，他不信任新员工，对新员工做的很多工作都不放心，于是基本上所有核心一点的工作都是这两位老员工在做，其他同事最多打打杂，这样他们不忙才怪呢。结果就是，两位老员工忙得脚打后脑勺，新员工却没什么大事儿可做，每天也不开心，总觉得自己被边缘化。

在分析了这个根本原因后，我制定了以下对策。

我决定从这位资深老员工下手，慢慢地解决问题。首先，我先找他分享了我的观察，交流了一些基本管理技巧；其次，我鼓励他试着慢慢放手，让其他团队成员参与进来，并定期做代码Review。这样几轮迭代以后，他们的工作变得均衡了，老员工不那么累，新人也成长起来了，团队整体的满意度也提升了。在此基础上再引进敏捷的新思想和实践，也就没人反对了。

总而言之一句话，**不了解和分析现状就直接推进敏捷是非常不靠谱的，必须要看清现实，摸清痛点，在这基础上导入并推进敏捷才是可行的。**

## 坑二：不理解敏捷背后的意义，把它当作一种新的流程，而忘记它的核心是持续改进

上面我们解决了团队不想做敏捷的情况，在实际工作中还有一种情况是：即使公司已经在推进敏捷，但对于很多并不深刻理解敏捷的员工来说，他会说敏捷不就是一套新的流程、一种新的工具吗？

我在调研A公司的员工时发现，大概有一半以上的人认为“敏捷就是一种替代瀑布的新流程”，他们一直在开Scrum中的五个会议，已经开得烦闷又枯燥，也没看到显而易见的好处，但迫于高层的压力，不敢停下来。

于是整个团队每天都在机械地重复着，回顾会议里的问题也就是反反复复的那几条，而这些问题基本上又是自己内部不能解决，需要别的团队协同或者高级管理层来协助才能解决的，但没有人去推动，问题就日复一日地挂在那里。团队里渐渐怨声载道，觉得敏捷只是凭空增加了很多会议，并没有带来什么新的好处。

面对这种情况，我认为他们犯了两个错误：

1. 公司敏捷实践的基础导入工作没有做好，连敏捷究竟是什么，以及为什么要做敏捷都没给团队讲清楚；
1. 缺乏一名强有力的敏捷教练做引导，在持续改进方面欠缺较大。

那么，如何能让整个团队更清晰地理解和接受敏捷呢？我认为可以通过两种方法来实现：

- **基础培训、基础培训、基础培训，重要的事情说三遍。**有很多公司舍不得投入前期的基础教学时间，大家对敏捷的理解一知半解时，就开始让大家照猫画虎、迅速展开实践，这就造成了大家在做各种实践之前根本不知道这样做的背后有什么意义，从而导致了整个程序的僵化。通常来说，敏捷推进会经历三个阶段：做敏捷（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。

从今天的课程你可以看出，推进敏捷确实不是一件容易的事，在这个过程中你会踩到很多坑，而在填坑时既要有方法的甄选，又离不开人力的支持，很多公司和团队之所以会遇到各式各样的问题，也是由于他们或是浅尝辄止，或是急于求成，没有把敏捷实践真正落实好。所以我相信，只要你稳扎稳打，踏实、耐心、正确地完成每一步，夯实基础、持续改进，再多的问题都会迎刃而解；你更会举一反三，成为一名真正的“填坑专家”。

## 思考题

最后，我想请你思考下，在推进敏捷的过程中，你踩到过哪些坑呢？除了文章中提到的方法，你还有更好的填坑方法吗？

我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。