研发效能提升的双流模型初探

17 小时前   出处:研发效能宣言  作/译者:茹炳晟  

本文核心观点:

  • 研发工程师在多个“单点式”工具平台之间来回切换是很耗费时间和精力的。

  • “一站式”是指把研发各个环节的软件工程能力集成在一个统一的平台上,对新人友好,对老人提效。

  • “一键式”是指让研发工程师只关注具有创造性价值的工作内容,而不需要处理能够由工具自动完成的事情。

  • 双流模型可以实现需求价值流和研发工程流双向自动联动。

  • 双流模型明确定义了软件研发各个阶段的高效实践。

1. 传统“单点式”研发效能工具面临的挑战

一个完整的研发效能工具平台,需要包括需求协作,代码管理,构建能力,测试能力,环境部署能力,制品管理,配置管理,监控告警以及高效运维等功能。可以说,效能工具平台是研发工作开展的载体,涵盖了软件研发全生命周期的各个环节,效能工具平台的设计与使用体验做的好,整体研发过程的流畅度也就高,工程师的有效价值就能更好地被发挥。

软件研发全生命周期中的各个环节都有各自领域的单点工具,比如需求管理工具常用的是Jira,代码管理工具常用的是GitHub和GitLab等,这些垂直领域的单点工具平台不论是商业化产品,还是企业自研,基本都是以SaaS的形式在企业内为广大工程师提供服务。

一个开发工程师要完成一个需求开发任务,往往需要在多个单点垂直工具间来回反复切换,当我们的软件工程纪律和流程管控越是严格的时候。这种工具来回切换的次数就会越多,而且每次切换都可能需要以人工的方式在各个工具平台间传递信息,甚至是“翻译”信息。

比如在一个典型的开发任务场景中,开发工程师首先要访问需求管理工具,从中找到对应的任务项,然后将其状态从“待开发”转变为“开发中”,接着到代码管理工具中找到对应的代码仓库并下载代码,同时使用需求管理工具中的开发任务ID作为分支名字来创建功能分支,然后在该功能分支上完成本地的开发与测试工作。

期间为了做到质量左移,往往会在开发过程中使用远程静态代码扫描工具中的代码规则,在本地执行静态代码检查,同时也会使用Mock能力来完成本地的单元测试。当本地开发和测试达到质量要求时,接下来就会通过代码工具提交代码评审,然后在工具平台的支持下完成代码评审的交互,之后代码合流过程中会使用CI平台来执行流水线,流水线成功完成一系列的步骤(比如单元测试,静态代码扫描,安全扫描和编译等),并且达到质量门禁的要求后,会将产生的制品存入制品库。最后开发工程师还需要再次访问需求管理平台,找到之前的任务,并将任务的状态从“开发中”设置为“待测试”。

以上的整个过程我相信很多开发人员再熟悉不过了,几乎是你每天例行的工作,在这个过程中,除了业务代码开发和测试,你还需要和各种工具平台频繁打交道,你需要访问需求管理平台领取任务,你需要访问代码管理工具拉取代码并创建分支,你要调用静态代码扫描平台的能力,你需要使用CI平台和制品库的能力,这些都完成后你还要再次访问需求管理平台来更新任务状态。

你可以算一下在这个过程中,你会有多少次的工具切换,又有多少时间是花费在了这些流程性的事务工作上,你会发现这种频繁的工具切换不仅会造成时间和注意力上的浪费,还需要假定你对各个工具平台的使用方法和流程都很清楚。

更糟糕的是,各个工具平台中的概念模型可能还不完全一致,比如代码管理平台上的“项目”概念和测试平台上的“项目”可能就不是相同逻辑下的概念,再比如“应用”的概念可能在不同的工具平台上又完全不是一个意思,这使得研发过程的流畅性会大打折扣,工程师的理解和学习成本都会很高。

同时,各个工具平台之间还会形成研发数据的孤岛,很难进行统一的研发过程数据收集和度量。所以我们迫切需要“一站式”和“一键式”的统一研发效能平台来对各个工具平台进行横向整合和拉通,以此来提升研发过程的整体效能。

2. “一站式”的概念

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

具体来讲就是研发工程师可以不需要记住每个单点工具平台(比如需求管理系统,CI系统,自动化测试系统等)的域名,能在一个统一的研效平台上完成所有的研发任务,而且各个阶段的产出物也能更加顺畅地在各个工具平台间流动。这样不仅能统一各个工具的权限管理体系,还能让研发过程的度量数据收集实现自动化,不需要任何人为干预,而且各个工具中的概念名词(比如项目,应用,模块等概念)也能在一站式的理念下得到统一,研发的各个阶段能够实现无缝链接与协作,实现真正意义上的研发全流程的流水线。

3. “一键式”的概念

有了一站式作为基础,就能在此基础上进一步实现“一键式”。“一键式”是真正提升研发过程效率的利器。

“一键式”是指让研发工程师只关心具有创造性价值的工作内容,比如聚焦于架构设计,编写代码,编写单元测试用例,开展代码评审等活动,而不需要处理能够由工具平台自动完成的事务性工作,比如需求状态流转,代码分支创建,静态代码检查,测试环境搭建,应用部署,测试用例执行等。

“一键式”最理想的效果是用户在提交代码后,可以不需要人工来完成后续的事务性工作,也不需要再盯着整个流程等待下一步,而是可以转向处理其他事情,研效平台会自动执行静态代码扫描,执行单元测试,判断质量门禁,构建制品,将制品部署到测试环境且执行接口测试,接着将制品部署到预发布环境,经过自动化的系统测试后,最终实现生产环境的正式发布,过程中会运用灰度发布等机制来降低发布过程的风险。上述整个过程当中,只有出现错误时才需要研发工程师介入处理,真正意义上实现“一把梭”。

4. 研发效能提升的双流模型

本文提出的研发效能双流模型(如图)是“一站式”和“一键式”概念的最好诠释。双流模型包含需求价值流和研发工程流,其中需求价值流是产品经理和项目经理关注的视角,反映了各个需求的完成状态和项目整体的完成情况,研发工程流是研发工程师关注的视角,反映了开发任务在工程维度上的完成状态,更多是从代码,测试和CI/CD等工程视角来看任务的进展。

图:研发效能双流模型实现需求价值流和研发工程流双向自动联动

5. 需求价值流和研发工程流双向自动联动

在双流模型中,我们可以实现需求价值流和研发工程流双向自动联动,不需要研发工程师在完成开发和测试任务后单独到需求管理系统中去更新任务状态,需求的状态更新(比如需求状态从“开发中”转到“待测试”)是由代码分支合并进主干后自动流转的,而不需要人工参与,这样就能让研发工程师更好地聚焦在创造性价值的工作上。

双流模型是实现研发效能平台的一个参考依据,值得我们借鉴。以下就通过研发过程的一个具体例子来讲解双流模型的工作原理和实现方式。

首选,当一个研发迭代周期开始之前,我们会从Backlog中选择这个迭代需要完成的需求任务列表,并将每个需求分解成开发任务,在理想情况下,我们尽可能把每个开发任务的颗粒度都控制在一个代码仓库的范围内,如果某个业务需求的实现需要涉及多个服务模块(比如多个微服务模块)的改动,那么我们建议为每个模块创建一个开发任务,也就是说,我们建议创建多个独立的开发任务,然后以开发任务为单位进行迭代计划的安排,而且每个开发任务都会事先确定好开发工程师的人选。

在传统模式下,当一个迭代开始后,被分配任务的开发工程师就会收到系统邮件通知,然后根据任务通知邮件里的链接来到需求管理工具中,阅读理解该需求,并且手工设置任务的状态为“开发中”,然后去代码平台拉取相应的代码,接下来再创建开发分支,之后在IDE中开始开发和测试工作。但是以双流模型实现的效能工具平台就会简单很多,完全不需要在需求管理工具,代码平台工具和IDE之间切换,而只需要在IDE中工作即可完成全部工作,具体的过程如下所述。

当一个开发任务被分配给某个开发工程师后,该工程师所使用的IDE中就会通过研效平台的IDE插件收到任务分配通知,工程师可以直接在IDE中阅读需求详情并一键领取任务,这个一键领取行为首先会自动把对应代码仓库的代码拉取到IDE的工作区,然后会自动以需求任务ID为名字来创建代码的功能分支,并确保IDE已经切换到该分支,同时会自动调用需求管理平台的API接口,将该需求任务的状态从“待开发”转为“开发中”,以上一系列的行为都直接由研效平台IDE插件自动发起,对开发人员来说做到了完全透明,开发人员要做的只是简单地在IDE中一键领取任务,然后就可以聚精会神地在本地进行开发和测试工作,其他所有的细节都不用操心。

当本地的开发和测试任务完成后,当前的功能分支达到可交付状态的时候,由开发工程师在IDE中直接发起代码合流请求,该代码合流请求会被研效平台中的CI子系统接管,然后CI子系统首先会自动发起代码评审流程,代码评审的交互过程可以直接集成在IDE中完成,同时研效平台工具能够自动根据代码变更的Code Diff自动推荐最佳的评审人,比如最近这段时间改过相同逻辑的工程师作为评审人将会是一个很经济的选择,因为其认知成本是最低的。更进一步,研效平台工具还会对此次代码评审变更的大小进行标识,以便评审人可以根据其空闲时间片段的大小来选择合适的评审内容。代码评审完成后,CI子系统会自动触发CI流水线来完成常规的单元测试,静态代码扫描,并且判断质量门禁的达成情况,最后生成制品并上传至制品库。接下来研效平台工具会再次自动调用需求管理平台的API接口,将该需求任务的状态从“开发中”转为“待测试”。

研发流程的后续环节也会采用类似的联动设计,用系统化的工具能力来保证需求状态和代码实际状态的联动。

由此可见,以双流模型理念打造的研发效能平台可以让工程师聚焦在最关键的核心任务上,而不需要人工去做哪些研发过程中的事务性工作,让整个研发过程的价值流动更顺畅,进而提升团队的研发效能,这里再次验证了中国人的一句谚语“工欲善其事必先利其器”。

6. 软件研发各阶段的高效实践

除此以外。双流模型还明确定义了软件研发各个阶段的高效实践(如图),比如在需求阶段我们有哪些最佳实践可以从源头上保证效能,在本地开发和测试阶段有哪些实践可以保证质效提升,在代码合流阶段有哪些高效实践等,关于这部分内容建议关注下面介绍的三本新书。

图:研发效能双流模型明确定义了软件研发各个阶段的高效实践

本文总结

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


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容,版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
62°|621 人阅读|0 条评论

登录 后发表评论

Baidu