在行业数字化转型加速的今天，精益敏捷、DevOps等已成为软件研发团队经常提起的热点词汇。对于软件研发而言，效率、质量是永恒的主题，提升软件研发效能的关键是要提升持续交付能力，而要构建持续交付能力，走好敏捷转型实践之路是其中非常重要的选择。
然而，不同于互联网企业或产品型企业的软件研发团队，对于类似我们以项目型为主导的传统软件研发团队而言，敏捷转型这条道路并不那么好走，况且不同企业不同团队的实际情况也迥然不同，很难有可复制、可照搬的敏捷转型经验，更多时候需要结合自身实际进行持续探索并不断总结经验。
之所以说是传统研发团队，除了一开始软件研发模式是基于瀑布型模式之外，更重要的是不是基于自主产品开发的模式，而是以定制化开发为主，项目需求往往很大程度上依赖于客户，变化性很大，且由于项目的规模和可持续性都可能不是很强，由此也可能会出现团队成员调动频繁等情形，各种错综复杂的情形相互交织，定然会给没有任何敏捷实践经验的研发团队带来很大的挑战。
借此机会，简要复盘一下鄙人所在研发团队的敏捷转型实践情况。在这次敏捷转型实践中，历经了好几个阶段，在围绕持续交付体系构建的过程中包含了诸多实践，例如研发流程及标准规范建设、基础架构及应用架构建设、工具链及部署流水线建设、敏捷及DevOps关键实践、敏捷组织文化建设等等，当然在这个转型的过程中，也根据实际情况进行了诸多调整。
要推进敏捷转型工作，首要一点就是要明确敏捷转型目标。比如，针对敏捷转型通常都是从试点开始，主要的目标就是引入敏捷软件开发方法，推行DevOps实践，探索研发效能提升方法，并形成具有指导意义的可推广的实践方法体系，用于指导更大范围内敏捷&DevOps的转型实践。
具体的敏捷转型目标可以包括如下几个方面：
1、引入Scrum敏捷软件开发方法、看板方法、用户故事需求分析方法等，形成相关规范及实践指南。
2、落地部分工具链，包括团队协同、任务管控、持续集成、自动化测试等。
3、强化持续集成（CI）实践，形成相关实践指南。
4、搭建自动化测试平台，试行接口自动化测试。
5、确立初步的研发效能度量指标，用数据驱动持续改进。
同时，需要确定敏捷转型团队的范围，包括选取什么样的团队作为敏捷转型的试点团队，何时开始进行敏捷转型试点等等。
在本人所在研发团队的敏捷转型试点过程中，明确了以下推进策略：
（1）转型推进小组牵引推动
成立敏捷转型推进小组，首批的推进小组成员由各部门主要负责人、项目经理、需求负责人及开发经理共同组成，负责敏捷转型试点各项工作的推进落实。
（2）关键实践刻意练习
转型试点团队重点围绕Scrum敏捷开发方法、看板方法、用户故事需求分析方法等持续训练并熟练运用，同时通过开展相应的学习、培评进一步加深对敏捷开发、看板方法、用户故事、持续集成等的理解。
（3）数据驱动持续改进
关注转型试点期间各类数据的收集与分析，用数据驱动团队的持续改进，用数据度量软件研发效能。
（4）定期回顾与持续学习
定期开展转型试点工作回顾与总结，促进转型推进小组带动学习与相关方法的运用落地。
在推进敏捷转型的各项实践中，主要包括持续学习培训、开展敏捷转型相关管理实践与工程实践、优化完善软件研发管理流程及相关规范、持续收集并分析相关度量指标、加强敏捷组织文化建设等等。
根据不同时期的实际需要，开展了多种形式的学习与培训，包括学习交流会、学习·评估阶段启动会、学习·评估阶段小结会、参加敏捷项目管理实战训练营、参加Exin DevOps Professional 培训、参加《凤凰项目》沙盘课程、组织开展主题分享季、组织开展敏捷系列培训等等。
在管理实践方面，主要包括看板方法实践、用户故事实践和Scrum管理实践。为顺利启动敏捷转型试点工作，试点团队从看板墙开始，将各项工作可视化到看板墙上，梳理和分析各项价值流，并通过引入Scrum框架，调整团队角色，按2-4周为一个迭代，在实践过程中不断总结经验和持续改进。
在用户故事实践方面，主要是采用用户故事拆分、估算等方法实现对各类功能需求的拆分。
在Scrum管理实践方面，着重于实践“3355”，即三种角色、三个工件、五个事件、五大价值观。
具体到试点团队中，主要是在每一个迭代开始前召开迭代计划会讨论迭代待办列表及各项任务，迭代进行中执行每日站会，迭代结束前召开迭代评审会，迭代结束后开展迭代回顾会。通过这些实践，进一步促进了项目团队的沟通和互动，对团队工作氛围的营造也起到了积极的促进作用。同时，在迭代评审会上，也邀请客户一起对交付成果进行评审验收，进一步增加了沟通和互信。
而在迭代回顾会上，全体成员共同回顾迭代过程，总结做得好的、做得不好的以及需要改进的，并明确了下一个迭代的改进项，有利于构建团队的持续改进环，并在每一次迭代中通过考虑容量分配问题，对用户故事、技术债务及常规维护做了动态分配调整，整体上加强了质量管控。
在工程实践方面，主要包括持续集成实践（包括代码自动构建、代码自动扫描）、接口自动化测试实践等方面。持续集成（CI）目前主要通过搭建代码质量平台（Jenkins+SonarQube）实现对代码的自动构建和代码的静态扫描。每一次的代码构建和代码质量检查，会自动发送邮件给到相关人员。
在接口自动化测试方面，组织进行了接口自动化测试工具的研究，并结合团队及项目实际需要进行了相应的开发改造，逐步形成了适合项目团队使用的接口自动化测试框架。
伴随着敏捷转型的持续推进，原有的软件研发管理流程及相关规范已然不能很好地适应实际需要，为此我们在合适时机组织进行了软件研发管理流程及相关规范的梳理，并增加了敏捷软件开发相关指南（如迭代会议实践指南、用户故事实践指南、看板方法实践指南、内部教练实践指南等等）。
在数据指标方面，主要收集了各迭代用户故事开发完成情况、各迭代内部流动效率情况、各迭代缺陷分布情况、各迭代缺陷类型走势情况、各迭代版本发布次数以及燃尽图等相关数据。并伴随着对敏捷理解的深入，逐步明确了三类主要度量指标，分别是需求交付周期、开发交付周期和线上缺陷密度。
随着敏捷转型各项工作的深入推进，我们愈来愈发现，敏捷要取得长期持续性成功实践，敏捷组织文化建设就显得非常重要。
为此，我们开始在敏捷学习资料库的建立、敏捷题库的建立、培训辅导（包括新团队的敏捷专项培训和新员工的敏捷专项培训等）及敏捷宣传等方面落实相关工作，逐步种下敏捷高效组织文化的种子。在敏捷宣传方面，我们曾经组织开展了每两周一期的敏捷文化看板墙的绘制活动，对敏捷理念、原则等的宣传和理解起到了一定的促进作用。
任何的转型变革都会经历阵痛期，都会面临各种困难与障碍，敏捷和DevOps转型也不例外。在敏捷转型的过程中，随着相关管理实践和工程实践的逐步深入推进，就像湖水岩石效应一样，越来越多的问题会逐步暴露出来。
没有有效的度量就很难评价转型效果，研发效能度量指标（包括交付效率、交付质量、交付能力）的确定、相关数据的准确收集及管理需要一套可行的标准/方法，要通过数据不断驱动改进提升。
传统的研发团队由于分工细致，也容易在人员技能交叉培养等方面出现空缺，在I型人才尚且难以高效培养的情况下，对T型人才的培养更是难上加难。
每一个项目都可能会有一大批技术债务需要解决，过重的技术债务会不同程度影响开发效率和质量。而且每一个项目团队可能面临的技术债务都不一样，需要在敏捷转型实施过程中对症下药。
要顺利推进敏捷转型，还需要特别注重内部敏捷教练的培养，虽然从外部引入敏捷教练也是一种不错的做法，但通常培养一批内部敏捷教练也非常重要。
对如何打造敏捷的组织文化没有太多实践，敏捷的转型变革要取得实质性突破最终还是要在组织文化层面下功夫。
此外，还要在敏捷转型过程中，防止出现Scrum僵尸化问题，防止敏捷形式主义，防止走回头路等。