如果用一个关键词来总结当今的大环境，VUCA是再贴切不过，身处这样的大环境下，对于互联网行业以及需要数字化转型的传统行业，提高研发效能来实现降本增效是越来越重要了。在这篇文章里，我以自己实践经验或者学习到的一些知识，来跟大家分享下提高研发效能的几个路径。也希望自己能通过学习总结和分享，从当前项目级/产品级管理能力向组织级管理能力方向扩展。
一、精益，敏捷思想构建和优化研发价值流
这部分应该是我最擅长的领域，我觉得却不太好写，为什么呢？ 原因在于精益和敏捷是一种思想，并不是一个个完全不变的步骤。我们需要先具备了思想，然后又了解了很多方法论后，根据实际情况去形成一套适应项目的管理办法。
什么是敏捷？我们可以从四个角度去描述
道 -- 敏捷是一种价值交付的思维模式；法-- 为了实现这样得思维模式需要用道很多方法，比如看板 scrum 极限编程还是xp等这些方法论；术 - 方法论落地的时候，就需要一些具体的框架和流程；气 -- 需要一些工程实践和工具去承载。
敏捷转型和优化研发价值流的意义在于：
1，确保产品对市场的快速响应，快速交付。从传统需求交付模式转为价值交付模式。
2，建立标准化的研发体系有助于研发能力的提升，降低组织规模扩张时对整体效能的影响。
一般这部分的转型一般由研发总监或PMO组织来负责。
敏捷研发流程的制定，类似于弹钢琴，十个手指都要动，不能有的动，有的不动，但是是个手指同时按下去也不能调子，十个手指要有节奏，要互相配合，这样才能产生好的音乐。
如下图能够很好地描述敏捷研发流程以及各角色之间的协作关系：
这张图能够很好地描述需求从产生到最终价值交付的全过程以及过程中的关键活动：
为什么要使用研发管理工具？
因为工具是流程落地的载体，在流程落地的过程中无需太多的人工管理，从而降低成本，且可形成流程执行的过程中数据，方便后期不断优化流程，以及形成指标指导团队自驱优化。敏捷项目管理工具使用。
组织级敏捷转型执行的步骤可以分解为：
1、根据公司项目特征，做敏捷实践方案，寻找1个团队试点，并在试点的过程中不断优化方案
2、明确方案后找3个以上团队持续试点，并根据团队敏捷实践中的问题，持续优化方案。运行一段时间后，敏捷方案定稿。
3、大规模推广至所有研发团队。一定会存在当前的敏捷方案不适配项目的情况，这时候就需要做出更多的方案。最终实现敏捷转型的全覆盖。
4、敏捷实践的规范性需要团队一定时间的习惯培养以及管理者的关注，需要设计出敏捷指标，以进一步推动实践的规范性。
二、平台化工程理念降低开发者认知负担
平台化工程是为了降低开发团队的认知负担，让他们用95%以上的精力和时间来做与业务目标直接相关的设计，开发，测试，部署，发布等工作项，而不用去研究和维护支撑这些工作项所需的底层工程能力。
2.1 云开发平台
传统的开发模式，一般是在本地环境进行编码调试，再通过线上系统交付，由于本地环境与线上环境以及工具链的差异，效率还是有很大的限制的，比如：搭建新的环境成本高，新的成员需要较长时间来搭建开发环境；本地环境和线上环境配置差异大，在本地成功运行的环境，线上就是走不通；测试发现问题时，开发者本地环境难以再现问题；代码的安全性问题，泄露风险等。
那么什么是云研发？云研发的优势在哪里？
也就是所有的开发，调试，测试，上线部署的动作全部线上化。开发者只需要一个账号就可以在任何终端进入开发环境。
其优势在于化简为繁，开箱即用；标准一致的开发环境；弹性资源，根据需要扩展；低风险易管控；随时随地有终端就可以使用；一键分享，高效协作。
可选择的云研发的工具有：
VS Code Remote; web端的vsCode; Cloud IDE等。
2.2 devops
什么叫devops？
是development，quality assurance，operations的组合，是一组开发运维的过程、方法与系统的统称。
它用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，来达到研发效率的提升，以及公司级的降本增效。
devops 又可以演进为 devxops，可以分为如下组成部分：
DevSecOps 安全和devops结合起来。
DevPerfOps 性能保障和devops结合起来，代码复杂度 架构合理性和系统容量。
DevAiOps 在devops的各个阶段融入ai能力。
devdataops 大数据协作性的数据管理，强调内部数据管道的沟通集成和自动化。
gitops 以git作为交付流水线的核心，加速和简化应用部署，交付和运维管理工作。
chatops 以聊天机器人作为运维管理的方式，工作人员只需要对着聊天机器人发出指令就可以完成与后台服务的交互，进行运维管理。
finops 云财务管理学与devops结合。
bizdevops 业务与devops结合，强调对业务价值的快速交付。
负责构建和维护devops的团队，需要对整个公司的工具进行统一建设，平台工具体系建设需要考虑几个方面：
1、平台化：以平台化思维进行工具体系建设以避免个团队重复造轮子的资源浪费现象，通过登录平台，既可获得所有的服务和能力。
2、一体化：各个工具需要在平台上提供统一入口，以解决工具多且割裂的问题，且为团队中的不同角色提供不同的视角，打通平台工具间的数据和流程，并形成联动，实现真正意义上的一体化平台。
3、产品化：工具的使用方为各团队成员，所以他们的用户体验，反馈是非常重要的，要以客户为核心的产品化思维来打造工具平台，才能支撑平台在公司推广落地。
推荐开源工具如图所示：
为了减少工具集成的开发工作量以加快工具平台化的建设，也可以直接采购集成好的较为成熟的端到端一体化工具。
devops在项目&产品全生命周期上的管理，不仅仅体现在Dev/Ops阶段，而且要覆盖到 CI (持续集成)/CD（持续交付）/CO（持续优化），如图所示。
三、数据驱动，用场景+指标来运作和改进研发
管理学之父德鲁克曾经说过：“如何你不能度量它，就无法改进它“。
当敏捷流程和平台化建设到了一定阶段，如何查看各产品线的进度和完成情况，如何识别团队的瓶颈，如何从不同的维度去分析提高研发的产能和效率，就是一件非常重要的事。也就是戴明环PDCA中的checking 环节。这样才能对整个产研流程形成反馈闭环，行动过程中产生数据，通过数据分析和根因定位，制定改进方案和行动项，从而指导下一个循环的实践。并且基于价值流的实时数据能够为公司战略发展提供决策依据。
而没有过程中数据的时候，问题的发现完全是依赖管理者对项目对团队的持续关注。我们需要以数据代替经验作为治理抓手，更客观，即时，轻量的识别研发过程中的问题与根因，更精确地匹配治理和改进方案。
我们需要对数据进一步的挖掘，分析，整理，可视化，所以我们需要建立度量指标体系，它是一系列可量化研发效能水平的指标集合。关于指标的设计可以参考如下，选择几个适合的具有代表性的即可：
需求的吞吐量：固定周期内团队需求的产出数，用于度量团队的整体研发能力吞吐。
需求的积压量：周期内团队需求的积压数，用于度量识别团队的研发能力池。
需求变更率：迭代计划开始后，需求产生变更的比率。
需求交付周期：需求的交付周期（Lead Time)，用于衡量团队单个需求的交付生命周期。
项目交付周期：项目的交付周期，用于衡量项目团队的项目交付速率。
测试周期：需求转测试后，到测试完成的时间
测试覆盖率：判断测试用例的执行情况以及测试执行是否充分
测试通过率：判断测试用例的执行结果，衡量软件质量
迭代交付速率：单冲刺内开发需求时间与冲刺总人天工作量的占比
迭代吞吐量：迭代实际完成的工作量
迭代工作量变更率：迭代预估工作量和最后完成工作量的占比
整体缺陷密度：当前版本的整体缺陷密度占比。
生产缺陷密度：版本上线后，生产缺陷密度占比。
人均需求产出：人均版本上线需求产出数。
团队利用率：团队成员在迭代中的工作量饱和度。
平台工具使用率：统计用平台工具的人员占比。
代码提交频率：单位周期内提交代码的频率
每日构建次数：每天完成的构建次数
持续集成时长：单位时间内，持续集成所花费的时间周期
部署时长：单位周期内，部署版本所花的时间周期
在度量设计方面，还要支持指标的层级下钻。从部门领导关注的管理维度指标可以逐层下钻到具体研发团队的工程能力指标，更加直观。
关于指标度量的实现，可以参考如下图：
我自己的经验是读取平台工具的数据库，帆软报表分析展示。
关于数据度量的呈现，可以参考如下图（研发驾驶舱）：
或者是这样：
对于指标数据的结果，团队管理人员应定期分析原因，指导团队优化，如图所示：
最后利用度量指标来推动效能改进，这并不是一蹴而就的，需要周期性反复地去找原因，快速反馈，持续精进，从而做到持续，逐迭代地提升研发效能。
四、架构解耦业务和组织的复杂度
这部分没有啥经验，也就不写了。有兴趣的可以评论补充。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
