敏捷 | 如何正确推进敏捷？

无论你的公司是在做敏捷转型还是一开始就使用敏捷，在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤：评估诊断、敏捷试点和大规模推广。

相关阅读：

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

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

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

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

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

1 评估诊断

不管你是使用哪一种敏捷实践方法（虽然大部分企业都是用的Scrum），在推进的时候如果不了解企业自身团队的现状和痛点，也就不知道要从哪里下手去推进。

因此，一般来说，在推进敏捷的时候，我们都需要先进性评估诊断，正如你去医院看病，医生总是会让你先做一些检查，然后再根据检查的结果对症下药。同样，也只有对自身的情况有个清晰的认知，才能针对自身的问题找到适合自己的方法。在敏捷转型实践中，大部分的企业都选择请外部的敏捷教练或者咨询师来帮助企业做敏捷转型，而评估诊断也通常是由他们来做。如果没有请敏捷教练或者咨询师，那也应该从企业内部指定一个熟悉敏捷和了解业界敏捷实践的人来做评估诊断。

对于评估诊断，一般遵循“四步法”来做：

（1）挑选具有代表性的项目（针对进行敏捷转型的企业来说，而针对团队来说可以跳过这一步）

在企业中挑选一些业务上或研发模式上具有代表性的项目，进性深入评估。

（2）访谈评估

对这些选中的项目组中的团队成员进行访谈，从流程、组织、人员技能、度量和技术等维度，对项目进行评估，目的是探查项目的痛点。一般来说，普遍存在的问题都是敏捷的成熟度不高，团队的透明程度不够，协作水平和沟通效率比较低。

（3）制定转型计划

针对访谈评估中找到的痛点，制定推进敏捷的计划，这个计划是要有针对性的。

（4）沟通

在正式推进敏捷之前，与相关干系人进行沟通，比如团队成员、团队Leader等。沟通内容也应该使得整个团队能够达成共识，才能朝着同一个目标努力。

总结：评估诊断的目的是为了了解自己团队的现状以及痛点在哪里，并针对这些痛点，结合短期的目标并找到解决方案，制定合理的计划。在敏捷中，计划的指定通常来说都是渐进的，近期的计划可以落实到细节，但远期的只能是粗略的，这也和我们强调短迭代快反馈的思想一致。

2 团队敏捷试点

试点工作的展开可以分为试点前准备和试点推进过程两个步骤，敏捷转型，重在转型，它也是一场变革，对于大一点的企业来说（特别是外企），都建议先从局部试点。只有在试点中积累了经验，测试了可行性之后，才进行大规模的推广。

试点前的准备

“凡事预则立，不预则废”，只有做好准备，才能在敏捷试点时有备无患。很多人还给这个试点前的准备工作起了个外号“迭代0 (Iteration 0)”。

首先，如果是大型企业做敏捷转型的话，需要先挑选试点团队，一般来说都会挑选业务价值高的团队又或者敏捷意愿很强烈的团队。对小企业来说，不存在这个问题，但需要有一个经验丰富的敏捷教练或Scrum Master指导团队。

其次，针对选择的团队，调整好组织结构（确认PO，SM等角色），组织好人员（确保小团队内沟通顺畅），规定好需求（PO的知识储备和User Story的编写标准），搭建好架构（演进式架构），选择好方法和工具（Scrum方法、Unit Test、CI/CD等实践），布置好办公环境（看板、白板、Dashboard等），每一步相辅相成，都不能马虎。

“心急吃不了热豆腐”，对于试点前的准备工作来说，就是给团队成员以心理准备和技能储备的缓冲时间，有了这些准备，才有可能在敏捷转型中“事半功倍”。

试点推进过程

在试点推进过程中，其关键核心就是打造一支充满活力和战斗力的敏捷团队。因此，需要朝着这个目标采取一些方法去激活团队的活力。

比如，在试点进行前，为团队指定一个“社会契约”（这些规则需要由团队集体讨论确认达成共识）并张贴到所有团队成员都能看到的地方，保证团队能够有序和高效的运转。在推进试点进行中，定期开展“回顾会议”，引导团队成员自发思考每个迭代的不足和改进方法，使得团队能够做到持续改进，也锻炼团队的自组织能力。在试点过程中和结束后，通过“成绩墙”和“错题集”记录团队的成长，总结敏捷实践中的经验。

PS：针对敏捷回顾会议，我去年有专门写一篇文章来分享如何开好回顾会议，有兴趣的童鞋特别是Scrum Master可以阅读一下。

3 大规模推广

做试点时为了确认敏捷在企业中的可行性和积累踩坑经验，如果确认可行，就可以根据试点结果推广到其他团队了。

但是，规模化推广也并不等于简单拷贝复制，同一个框架不一定适合所有的团队。因为，试点涉及的主要是团队内部的敏捷，而规模化推广则还涉及到团队之间的敏捷。比如，当相互协作的团队个数达到某个程度的时候，管理的复杂度就上升了，使用管理小团队的方法就不够用了。

当前业界主要有两个规模化推广的框架 SaFe（Scaled Agile Framework）和 LeSS（Large Scale Scrum），它们是做规模化推广比较成熟的范式，可以为我们提供一些参考。有兴趣的童鞋，可以自行搜索查阅这两个框架的内容。在我之前所在的M公司的敏捷转型实践中，针对全员做了敏捷基础培训，对核心人员做Scrum Master或Product Owner能力培训或认证，使用Scrum of Scrum来进行跨团队协作的定期沟通，引入白板、电视机（Dashboard）、DevOps等工具营造好的环境氛围等。

规模化推广过程中，个人觉得最重要的有两件事：

（1）因地制宜确定方法

比如，针对纯运维类的项目团队，因为运维类项目开发的内容通常来自客户的建议或生产上的bug，比较零散且无规划，所以不一定适用Scrum，单纯适用看板可能更有效；针对产品较大，大团队拆分后小团队数量众多的情况，可能单纯的Scrum方法不一定能解决好团队协作和沟通，那么可能需要引入Scrum of Scrum会更好；

（2）以“项目”为中心转变为以“产品”为中心

比如，确定Product Owner负责制，统一对外沟通，作为业务代表人管理业务需求，让业务战略与产品战略保持一致，从而使得整个团队的目标也一致，所谓“劲往一处使”。

（3）端到端研发全流程向业务敏捷靠拢
比如，在整个产品研发流程中制定定期反馈机制，争取在每个环节都定期收集反馈，为全流程提供数据支持，便于团队回顾审视的时候识别问题和不足，能够帮助团队做到持续改进。

最后，正如上一篇中提到的，无论它是不是知名的框架，又或者它是否打着敏捷的名头又或者冠以敏捷，本身是无所谓的，也觉得并非要全盘采纳框架的所有方法，只要在具体实践中能够体现敏捷思想，帮助我们解决实际问题就是敏捷的好实践。

4 小结

一般来说，对中小企业来说，由于团队数量较少，所以一般不会涉及到规模化推广的阶段以及规模化框架的使用，只要不断学习和实践Scrum并且有敏捷教练指导就可以做好敏捷实践。但是对于大型企业来说，规模化推广是必不可少的一个环节，这其实也意味着这种企业已经克服了一些困难并取得了一定成果了，需要定制度、定反馈机制、定团队文化和环境等等方式去帮助整个企业完成规模化的推广并持续改进。