敏捷 | 如何填好推进的坑？

无论你的公司是在做敏捷转型还是一开始就使用敏捷，在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享几个在推进过程中常见的坑，以及如何填坑。

相关阅读：

（1）如何正确理解敏捷？

（2）如何正确推进敏捷？

（3）如何填好推进的坑？

（4）如何做服务型Scrum Master？

（5）无处不在的敏捷思想

1 坑一：团队说不想做敏捷

第一个常见的坑就是在进行敏捷转型的企业中一定会有一个或几个团队对敏捷不感冒，在推进上会有阳奉阴违的现象。一跟团队Leader交流，就会以“我们已经很忙了，根本没有时间做敏捷”为理由拒绝正常推进。

对于此类型的团队，需要挖掘其深层次的原因，一般都有以下几个原因：

（1）团队没有真正地理解什么是敏捷，能给他们带来啥好处。

（2）团队的确真的很忙（是否是有效的忙碌？这是个值得深度挖掘和探讨的话题）。

（3）团队中有人搞一言堂（一般来说都是团队的一把手），这个人的意见不改变，其他人不敢动。

挖掘到根本原因之后，就可以对症下药辅导团队进行敏捷认知和思想转变，几轮迭代之后大多数都会有所好转。

然而，在实际推进中，很多时候我们都是不了解和分析现状就直接推进敏捷，而忘记了看清现实和分析痛点，只有在此基础之上导入并推进敏捷才是可行的。

2 坑二：仅仅将敏捷作为一种新的流程

第二个常见的坑就是即使企业已经在全面推广敏捷，但对于大多数对敏捷理解不深的员工来说，他会仅仅认为敏捷只是一种新的流程和工具。

其实这也是我初期学习和实践敏捷时的一种心态，认为敏捷就是一种替代瀑布的新流程，就是几个工件+几个会议而已。我们团队一直在开Scrum中的五个会议，开的烦闷又枯燥，但又没有看到显而易见的效益，却又不敢停下来，因为领导给了压力。特别是每次回顾会议上提了很多问题，也总说后面会逐步解决每个问题，但很多时候这些问题团队内部又无法解决，于是一而再再而三地拖了下去，没人去推动。最后，团队对于只有形式而没有成果的会议怨声载道，浪费时间。

对于这种情况，一来是对于敏捷的系统性的基础培训没有做好，光靠自己自学领悟是远远不够的；二来是缺乏一名强有力且有经验的敏捷教练做指导，在持续改进方面做得远远不够。

因此，要让整个团队更加清晰地理解和接受敏捷，需要公司对于基础培训这块投入资金和时间，需要给团队成员做系统性的基础培训，不能只让员工照猫画虎快速实践，那样成效不高。另外，由于敏捷本身其实更是一场变革，它也涉及到人的思维和习惯上的改变，不是一件容易的事情。因此，也需要公司舍得投入引入一名敏捷教料咨询师来为团队做指导，也帮助公司进行文化层面的转变。对于大公司，你可能需要多名敏捷教练来做指导。

3 坑三：Scrum过程缩水到只剩每日站会

第三个常见的坑是有敏捷教练指导时，团队可以做的有声有色，而敏捷教练一离开，团队没人指导就会流于形式，会议没人张罗，过程没人关心，慢慢团队就开始觉得没有继续下去的必要了。

对于这种情况，一来是团队的敏捷习惯还没有固化，二来是团队没有培养起来自己的Scrum Master。因此，一旦敏捷教练撤离，没有自己的SM进行接棒，很容易就会让团队走回敏捷之前的状态。

要解决这个问题，首先要认识到Scrum Master在敏捷实践中的重要性，他负责具体实践的导入和守护，要坚定帮助团队养成新的敏捷习惯。同时，他也是一名服务型领导，帮助团队打造敏捷文化。其次要在团队成员心中都留有敏捷的火种，即推进敏捷的初期，团队就应该识别出有潜力的Scrum Master并进行培养，敏捷教练也需要带着这个Scrum Master进行具体实践并给予定期反馈，让他能在敏捷教练离开时接棒，持续推动团队的敏捷实践。

4 坑四：研发管理的全链条不够通畅

对于一个企业的敏捷转型，如果只有研发部门在唱独角戏，其他部门不接受敏捷的转变的话，也是会拖慢整个产品的进程的。比如，业务部门如果在每次迭代开始前，对需求的分析理解十分缓慢导致Backlog出不了，打乱研发节奏从而造成延期风险。

对于这种情况，究其原因就是因为研发管理的全链条不够通畅，换句话说，只有研发部门在拥抱敏捷，其他部门还是各自为政走老一套，出现研发部门和其他部门的效率失衡。

要解决这个问题，一般来说需要自上而下的统一认知，即所有部门都认识到敏捷转型的重要性和好处，并在推进过程中予以必要的帮助。毕竟，敏捷也是一场变革，既然是变革，就会涉及到组织的变动（组织、合并、重组都不容易），需要企业的高层认可才能推进下去。数字化转型也是如此，如果没有自上而下的一致性推动，也是无法推进数字化转型的。

解决了认知障碍后，可以试着组件一个个全功能团队，综合考虑需求管理的推进策略，这一点和中台架构中的共享服务中心的业务组织类似。

对于这类型的问题，可以统一表示为：在推进过程中一旦识别出新的障碍，都需要及时去除。

5 坑五：将敏捷走成了“小瀑布”

有些团队在敏捷实践中会逐步将迭代演进成“小瀑布”，即将大项目拆分成一个个的模块，通过小的迭代来进行推进，但是本质还是按照“需求-设计-开发-测试”的流程来做的。

既然是瀑布，那就必然存在着时间和资源的浪费，比如：需求人员在做需求的时候，开发人员需要等着；开发人员在实现的时候，测试人员需要等着；

因此，小瀑布仍然是一个瀑布，并不会克服瀑布模式的缺陷，离真正的敏捷还很远。对于这样的团队，究其原因，一是没有真正了解敏捷，大部分都只是了解了一个皮毛，并着急模仿推进；二是需求的确太大，每次拆完需求后，需求的大小不能满足一个两周的小迭代可以做完一个端到端的交付功能。

要解决这个问题，一来也是需要给团队做系统性的基础培训，培养敏捷实践的技能。二来就是需要挑选好需求，即先从最优价值、优先级最高的开始做，将大需求拆分成一个个可以独立开发测试的小需求。换句话说，需要保证每一个User Story都有独立的价值，可以独立上线。如果的确拆分后还是过大，无法在一个两周的迭代之内完成，那就需要识别其中的障碍，并在推进中解决。比如，如果是系统架构比较老旧，代码耦合度较高，依赖度较高，还没有单元测试不敢乱动，这对于产品的交付来说都是很大的障碍。