关于研发:研发效能平台的双流模型

本文摘于《软件研发效力权威指南》——第 9 章

外围观点

• 开发人员在多个“单点式”工具平台之间的来回切换是很消耗工夫和精力的。
• “一站式”是指把研发各个环节的软件工程能力集成在一个对立的平台上，对新人敌对，对老人提效。
• “一键式”是指让研发工程师只关怀具备创造性价值的工作，而不须要解决可能由研效平台主动实现的事件。
• “双流”模型能够实现需求价值流和研发工程流双向主动联动。

传统单点研发效力工具平台面临的挑战

一个残缺的研发效力工具平台，须要包含需要合作、代码治理、构建能力、测试能力、环境部署能力、制品治理、配置管理、监控告警、高效运维等性能。能够说，效力工具平台是研发工作发展的载体，涵盖了软件研发全生命周期的各个环节，其设计与应用体验做得好，整体研发过程的晦涩度就高，工程师的无效价值就能更好地被施展。

软件研发全生命周期中的各个环节都有各自畛域的单点工具，比方需要管理工具罕用的是 Jira、代码管理工具罕用的是 GitHub 和 GitLab 等，这些垂直畛域的单点工具平台不论是商业化产品，还是企业自研，根本都是以 SaaS 的模式在企业内为宽广工程师提供服务。

开发工程师要实现一个需要开发工作，往往须要在多个单点垂直工具间来回重复切换。当咱们的软件工程纪律和流程管控越严格时，工具来回切换的次数就会越多，而且每次切换都可能须要以人工的形式在各个工具平台间传递信息，甚至是“翻译”信息。

比方，在一个典型的开发工作场景中，开发工程师首先要拜访需要管理工具，从中找到对应的工作项，而后将其状态从 “待开发”转变为“开发中”，接着到代码管理工具中找到对应的代码仓库并下载代码。同时，先应用需要管理工具中的开发工作 ID 作为分支名字来创立性能分支，而后在该性能分支上实现本地的开发与测试工作。在此期间，为了做到品质左移，往往会在 开发过程中应用近程动态代码扫描工具中的代码规定，在本地执行动态代码查看，同时也会应用 Mock 能力来实现本地的单元测试。当本地开发和测试达到品质要求时，就会先通过代码工具提交代码评审，而后在工具平台的反对下实现代码评审的交互，之后代码合流过程中会应用 CI 平台来执行流水线，流水线实现一系列的步骤（如单元测试、动态代码扫描、平安扫描和编译等），并且达到品质门禁的要求后，会将产生的制品存入制品库。最初，开发工程师还须要再次拜访需要治理平台，找到之前的工作，并将工作的状态从“开发中”设置为“待测试”。

我置信，很多开发人员对以上过程曾经很相熟了。在这个过程中，除了业务代码开发和测试，你须要和各种工具平台频繁打交道，须要拜访需要治理平台支付工作，须要拜访代码管理工具拉取代码并创立分支，须要调用动态代码扫描平台的能力，还须要应用 CI 平台和制品库的能力，最初还要再次拜访需要治理平台更新工作状态。

在这个过程中，有屡次工具切换，要花费大量工夫在流程性的事务上，造成工夫和精力的节约，还须要你对各个工具平台的应用办法和流程都很分明。

更蹩脚的是，各个工具平台的概念模型可能还不完全一致。比方代码治理平台上的“我的项目”概念和测试平台上的“我的项目”可能就不是雷同逻辑下的概念；再比方“利用”的概念在不同的工具平台上可能不是一个意思，这就使研发过程的流畅性大打折扣，工程师的了解和学习老本很高。同时，各个工具平台之间还会造成研发数据孤岛，很难进行对立的研发过程数据收集和度量。因而，咱们迫切需要“一站式”和“一键式”的 对立研发效力平台对各个工具平台进行横向整合和拉通，以此来晋升研发过程的整体效力。

“一站式”和“一键式”

“一站式”的概念

“一站式”是指把研发各个环节的软件工程能力集成在一个对立的平台上，研发工程师在研发过程中不再须要来回拜访多个工具平台，也不须要人工记住并恪守研发流程，更不须要记住多个工具平台的拜访入口，这样的设计对新人敌对，对老人提效。

具体来讲，就是研发工程师不须要记住每个单点工具平台（比方，需要管理系统、CI 零碎、自动化测试零碎等）的域名，在一个对立的研效平台上实现所有的研发工作，而且各个阶段的产出物也能更加顺畅地在各个工具平台间流动。这样，不仅能对立各个工具的权限管理体系，还能让研发过程的度量数据收集实现自动化，不须要任何人为干涉，而且各个工具中的概念名词也能在一站式的理念下失去对立，研发的各个阶段可能实现无缝链接与合作，实现真正意义上的研发全流程流水线。

“一键式”的概念

有“一站式”作为根底，就能在此基础上进一步实现“一键式”。“一键式”是真正晋升研发效率的利器。

“一键式”是指让研发工程师只关怀发明价值的工作内容，比方聚焦于架构设计、编写代码、编写单元测试用例、发展代码评审等流动；而不须要解决可能由工具平台主动实现的事务性工作，比方需要状态流转、代码分支创立、动态代码查看、测试环境搭建、利用部署、测试用例执行等。

“一键式”最现实的成果是用户在提交代码后，能够不须要人工来实现后续的事务性工作，也不须要再盯着整个流程期待下一步，而是能够转向解决其余事件，研效平台会主动执行动态代码扫描和单元测试、判断品质门禁、构建制品、将制品部署到测试环境且执行接口测试，接着将制品部署到预公布环境，通过自动化的零碎测试后，最终实现生产环境的正式公布，在此过程中会使用灰度公布等机制来升高危险。在整个过程中，只有呈现谬误时才须要研发工程师染指解决，真正意义上实现了“一把梭”。

研发效力平台的“双流”模型

本书提出的研发效力 “双流”模型是“一站式”和“一键式”概念 的最好诠释。“双流”模型蕴含需要价值流和研发工程流，其中需要价值流是产品经理和项目经理关注的视角，反映了各个需要的实现状态和我的项目整体的实现状况；研发工程流是研发工程师关注的视角，反映了开发工作在工程维度上的实现状态，更多是从代码、测试和 CI/CD 等工程视角来看工作的停顿。

研发效力“双流”模型实现需求价值流和研发工程流双向主动联动

需要价值流和研发工程流双向主动联动

在“双流”模型中，能够实现需求价值流和研发工程流双向主动联动，不须要研发工程师在实现开发和测试工作后独自到需要管理系统中去更新工作状态，需要的状态更新（比方，需要状态从“开发中”转到“待测试”）由代码分支合并进骨干后主动流转，不须要人工参加，这样就能让研发工程师更好地聚焦在发明价值的工作上。

“双流”模型是实现研发效力平台的一个参考根据，值得借鉴。以下就通过具体例子介绍“双流”模型的工作原理和实现形式。

首先，在一个研发迭代周期开始之前，咱们会从 Backlog 中抉择迭代须要实现的需要工作列表，并将每个需要分解成开发工作。在现实的状况下，咱们尽可能把每个开发工作的颗粒度都管制在一个代码仓库的范畴内，如果某个业务需要的实现须要波及多个服务模块（如多个微服务模块）的改变，则倡议为每个模块创立一个开发工作。也就是说，倡议创立多个独立的开发工作，以开发工作为单位进行迭代打算的安顿，并且每个开发工作都会当时确定好开发工程师的人选。

在传统模式下，在一个迭代开始后，被分配任务的开发工程师就会收到零碎邮件告诉，再依据邮件中的链接到需要管理工具中浏览并了解该需要，并且手动设置工作的状态为“开发中”，而后去代码平台拉取相应的代码，创立开发分支，之后在 IDE 中开始开发和测试工作。然而 以“双流”模型实现的效力工具平台就会简略很多，齐全不须要在需要管理工具、代码平台工具和 IDE 之间切换，只须要在 IDE 中即可实现全副工作。具体的过程如下：

在一个开发工作被调配给某个开发工程师后，该工程师所应用的 IDE 中就会通过研效平台的 IDE 插件收到任务分配告诉，工程师能够间接在 IDE 中浏览需要详情并一键支付工作，这一支付行为首先会主动把对应代码仓库的代码拉取到 IDE 工作区，而后会主动以需要工作 ID 为名字创立代码的性能分支，并确保 IDE 曾经切换到该分支。同时，会主动调用需要治理平台的 API 接口，将该需要工作的状态从“待开发”转为“开发中”。这一系列的行为都 间接由研效平台 IDE 插件主动发动，对开发人员来说做到了齐全通明，其要做的只是简略地在 IDE 中一键支付工作，就能够目不转睛地在本地进行开发和测试工作了。

在本地开发和测试工作实现后，以后的性能分支达到可交付状态时，由开发工程师在 IDE 中间接发动代码合流申请，该代码合流申请会先被研效平台中的 CI 子系统接管，而后 CI 子系统主动发动代码评审流程，代码评审的交互过程能够间接集成在 IDE 中实现。同时，研效平台工具能主动依据代码变更的 Code Diff 主动举荐最佳的评审人。比方，将最近这段时间改过雷同逻辑的工程师作为评审人是一个很经济的抉择，因为其认知老本是最低的。更进一步，研效平台工具还会对此次代码评审变更的大小进行标识，以便评审人能够依据其闲暇工夫片段的大小来抉择适合的评审内容。代码评审实现后，CI 子系统会主动触发 CI 流水线实现惯例的单元测试、动态代码扫描，并且判断品质门禁的达成状况，最初生成制品并上传至制品库。接下来，研效平台工具会再次主动调用需要治理平台的 API 接口，将该需要工作的状态从“开发中”转为“待测试”。

研发流程的后续环节也会采纳相似的联动设计，用系统化的工具能力来保障需要状态和代码理论状态的联动。

由此可见，以“双流”模型理念打造的研发效力平台能够让工程师聚焦在最要害的外围工作上，而不须要人工去做事务性的工作，让整个研发过程的价值流动更顺畅，进而晋升团队的研发效力，再次验证了“工欲善其事，必先利其器”。

软件研发各个阶段的高效实际

除此以外，“双流”模型还明确定义了软件研发各个阶段的高效实际。比方，在需要阶段有哪些最佳实际能够从源头上保障效力，在本地开发和测试阶段有哪些实际能够保障质效晋升，在代码合流阶段有哪些高效实际等，本书第 2 篇介绍的研发效力实际其实就是“双流”模型各个阶段的具体实际与落地，这里不再具体介绍。

研发效力“双流”模型明确定义了软件研发各个阶段的高效实际

总结

这部分介绍了传统单点研发工具平台在横向拉通维度上的痛点，并在此基础上提出了研发效力平台“一站式”和“一键式”的概念。同时，介绍了这一概念的落地案例：研发效力“双流”模型，并且对“双流”模型中的需要价值流和研发工程流双向联动能力进行了介绍。