一种基于git的软件研发效能度量系统的制作方法

文档序号:26138951发布日期:2021-08-03 14:22阅读:330来源:国知局
一种基于git的软件研发效能度量系统的制作方法

本发明涉及效能度量技术领域,特别涉及一种基于git的软件研发效能度量系统。



背景技术:

软件研发效能领域现有的产品(例如阿里巴巴-码云)主要通过一个独立的项目管理系统,一个独立的代码管理系统和一个独立的ci/cd系统组成,分别进行敏捷开发的任务管理,代码管理和持续发布集成;

现有技术虽然对研发流程所需要的各种工具和系统进行了集成,但各个系统功能之间没有关联,松散耦合,虽然一定程度上为团队开发提供了便利,但无法对团队的研发效能进行有效的度量,自然也就无法量化改进。



技术实现要素:

为了弥补上述缺陷,本发明提供一种基于git的软件研发效能度量系统,可以有效解决技术团队软件研发效能度量体系的搭建问题,实现了对团队的研发效能的有效度量,保证了产出的研发效能指标具有真实性和客观性。

为实现上述目的,本发明提供如下技术方案:

一种基于git的软件研发效能度量系统,所述系统包括:研发效能数据收集系统,通过api接口连接研发效能数据收集系统的数据库和研发效能度量系统;

其中,所述研发效能数据收集系统包括:项目管理系统和基于git的代码管理系统;

所述项目管理系统,用于以任务为粒度对开发项目进行管理,将开发项目定义为一个或多个任务上传至基于git的代码管理系统,并获取基于git的代码管理系统同步的任务状态;

基于git的代码管理系统,用于将每个任务以分支的形式下发给本地代码管理终端,获取本地代码管理终端中待同步的代码,所述代码包括所述本地代码管理终端的版本管理操作代码信息和业务项目代码信息;

数据库,用于通过api接口以预定格式将研发效能数据收集系统的流程数据作为研发效能元数据进行存储;

研发效能度量系统,用于提取与数据库中所述研发效能元数据匹配的效能指标,对整个技术部门或组织研发效能开发过程中每一环研发效能进行度量。

优选的,所述项目管理系统包括:

定义模块,用于根据项目开发需求定义发送至基于git的代码管理系统的任务;所述任务中包括:任务对应的项目开发需求以及任务相关人员的管理功能;

确定模块,用于确定所述任务状态对应的任务生命周期;其中,任务生命周期包括一个或多个任务生命周期状态以及各个状态之间的转换关系,具体包括需求响应中、待开发、开发中、待测试、测试中、待发布、发布中、发布完成、故障中、故障修复中、运行中;

获取模块,用于获取基于git的代码管理系统同步的代码信息。

优选的,其特征在于,所述基于git的代码管理系统包括:

接收模块,用于接收项目管理系统发布的任务;

创建模块,用于基于所述任务关联的任务生命周期和项目开发需求自动创建相应的代码分支,并为各级代码管理终端添加任务信息的订阅;

生成模块,用于根据所述任务生成命令指令,所述命令指令为对应于与项目管理系统发布的任务的代码逻辑、代码编写语言、代码环境兼容信息匹配的代码转换接口的代码指令;

发送模块,用于将每个任务及命令指令以分支的形式下发给任务相关人员的本地代码管理终端;

同步模块,用于在相应开发人员以命令指令规范的内容提交代码后,同步修改任务状态,并将更新后的任务状态同步至项目管理系统。

进一步地,所述同步模块包括:

第一同步单元,用于在相应开发人员以命令指令形式提交代码后,将任务状态同步至项目管理系统;

第二同步单元,用于在相应测试人员以命令指令形式提交代码后,将任务状态同步至项目管理系统。

进一步地,所述同步模块包括:校验单元,用于通过githooks验证提交的合法性,以保证代码和任务同步。

优选的,所述本地代码管理终端包括:

获取模块,用于获取任务及任务对应的命令指令;

反馈模块,用于以命令指令为格式依据,基于任务及所述任务关联的任务生命周期,向基于git的代码管理系统提交代码数据。

优选的,所述研发效能度量系统包括:时间周期设置模块,用于预先定义评估研发效能的效能指标,包括需求响应周期、需求交付周期、需求吞吐量和故障频率;

所述需求响应周期是指单位时间内技术部门从接到业务需求到开始开发所需的平均时间;

需求交付周期是指单位时间内技术部门从接到业务需求到需求完成交付所需的平均时间;

需求吞吐量是指单位时间内技术部门交付的需求总量;

故障频率是指需求交付后单位时间内出现故障的频率。

进一步地,所述研发效能度量系统还包括:需求响应周期度量模块,用于基于单位时间内技术部门从接到业务需求到开始开发所需的平均时间,衡量技术部门的产品及需求效能;

需求交付周期度量模块,用于基于单位时间内技术部门从接到业务需求到需求完成交付所需的平均时间,衡量技术部门整体需求的交付效能;

需求吞吐量度量模块,用于基于单位时间内技术部门交付的需求总量,衡量技术部门整体需求的承受能力;

故障频率度量模块,用于基于需求交付后单位时间内出现故障的频率,衡量技术部门整体需求交付的质量。

本发明的技术效果和优点:

本发明提供的一种基于git的软件研发效能度量系统,包括研发效能数据收集系统、数据库和研发效能度量系统;研发效能数据收集系统包括项目管理系统和基于git的代码管理系统;项目管理系统以任务为粒度对开发项目进行管理,将开发项目定义为任务上传至基于git的代码管理系统,并获取基于git的代码管理系统同步的任务状态;基于git的代码管理系统将每个任务以分支的形式下发给本地代码管理终端,获取本地代码管理终端中待同步的代码;数据库通过api接口以预定格式将研发效能数据收集系统的流程数据作为研发效能元数据进行存储;研发效能度量系统提取与研发效能元数据匹配的效能指标,对研发效能进行度量。通过上述方案实现了对团队的研发效能的有效度量。

本发明为难以量化的软件研发行业提供了一种可以度量的体系,不同于传统的任务管理系统,将代码开发流程与任务管理系统进行高度的融合和关联,较大程度上保证了量化数据源的真实性;

同时由于提供了过程量化的手段,也试研发团队针对自身的不足提供对应过程的解决方案变成了可能。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍。在所有附图中,类似的元件或部分一般由类似的附图标记标识。附图中,各元件或部分并不一定按照实际的比例绘制。

图1为本发明提供的一种基于git的软件研发效能度量系统结构示意图;

图2为本发明的研发效能数据收集系统结构示意图;

图3为本发明的研发效能度量系统结构示意图;

图4为本发明的基于git的软件研发效能度量系统中数据库读取流程数据的示意图;

其中,1-研发效能数据收集系统,2-数据库,3-研发效能度量系统,10-定义模块,11-确定模块,12-获取模块,13-基于git的代码管理系统,131-发送模块,132-第一同步单元,133-第二同步单元,134-校验单元。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

本具体实施方式中,提供一种基于git的软件研发效能度量系统,如图1所示,所述系统包括:研发效能数据收集系统1,通过api接口连接研发效能数据收集系统的数据库2和研发效能度量系统3;

如图2所示,研发效能数据收集系统包括:项目管理系统和基于git的代码管理系统;

其中,项目管理系统,用于以任务为粒度对开发项目进行管理,将开发项目定义为一个或多个任务上传至基于git的代码管理系统,并获取基于git的代码管理系统同步的任务状态;

基于git的代码管理系统13,用于将每个任务以分支的形式下发给本地代码管理终端,获取本地代码管理终端中待同步的代码,所述代码包括所述本地代码管理终端的版本管理操作代码信息和业务项目代码信息;

数据库,用于通过api接口以预定格式将研发效能数据收集系统的流程数据作为研发效能元数据进行存储;

研发效能度量系统,用于提取与数据库中所述研发效能元数据匹配的效能指标,对整个技术部门或组织研发效能开发过程中每一环研发效能进行度量。

所述项目管理系统包括:

定义模块10,用于根据项目开发需求定义发送至基于git的代码管理系统的任务;所述任务中包括:任务对应的项目开发需求以及任务相关人员的管理功能;

确定模块11,用于确定所述任务状态对应的任务生命周期;其中,任务生命周期包括一个或多个任务生命周期状态以及各个状态之间的转换关系,具体包括需求响应中、待开发、开发中、待测试、测试中、待发布、发布中、发布完成、故障中、故障修复中、运行中;

获取模块12,用于获取基于git的代码管理系统同步的代码信息。

所述基于git的代码管理系统包括:

接收模块,用于接收项目管理系统发布的任务;

创建模块,用于基于所述任务关联的任务生命周期和项目开发需求自动创建相应的代码分支,并为各级代码管理终端添加任务信息的订阅;

生成模块,用于根据所述任务生成命令指令,所述命令指令为对应于与项目管理系统发布的任务的代码逻辑、代码编写语言、代码环境兼容信息匹配的代码转换接口的代码指令;

发送模块131,用于将每个任务及命令指令以分支的形式下发给任务相关人员的本地代码管理终端;

同步模块,用于在相应开发人员以命令指令规范的内容提交代码后,同步修改任务状态,并将更新后的任务状态同步至项目管理系统。

所述同步模块包括:

第一同步单元132,用于在相应开发人员以命令指令形式提交代码后,将任务状态同步至项目管理系统;

第二同步单元133,用于在相应测试人员以命令指令形式提交代码后,将任务状态同步至项目管理系统。

所述同步模块还包括:校验单元134,用于通过githooks验证提交的合法性,以保证代码和任务同步。

所述本地代码管理终端包括:

获取模块,用于获取任务及任务对应的命令指令;

反馈模块,用于以命令指令为格式依据,基于任务及所述任务关联的任务生命周期,向基于git的代码管理系统提交代码数据。

所述研发效能度量系统包括:时间周期设置模块,用于预先定义评估研发效能的效能指标,包括需求响应周期、需求交付周期、需求吞吐量和故障频率;

所述需求响应周期是指单位时间内技术部门从接到业务需求到开始开发所需的平均时间;

需求交付周期是指单位时间内技术部门从接到业务需求到需求完成交付所需的平均时间;

需求吞吐量是指单位时间内技术部门交付的需求总量;

故障频率是指需求交付后单位时间内出现故障的频率。

所述研发效能度量系统还包括:需求响应周期度量模块,用于基于单位时间内技术部门从接到业务需求到开始开发所需的平均时间,衡量技术部门的产品及需求效能;

需求交付周期度量模块,用于基于单位时间内技术部门从接到业务需求到需求完成交付所需的平均时间,衡量技术部门整体需求的交付效能;

需求吞吐量度量模块,用于基于单位时间内技术部门交付的需求总量,衡量技术部门整体需求的承受能力;

故障频率度量模块,用于基于需求交付后单位时间内出现故障的频率,衡量技术部门整体需求交付的质量。

实施例1:

提供一种基于git的软件研发效能度量系统,技术方案的整体结构如下:

一.研发效能数据收集系统:

1.项目管理系统以任务为粒度对敏捷开发项目进行管理

2.代码管理系统以提交为粒度对代码进行管理

3.任务,提交,开发人员通过同步模块进行关联

二.研发效能度量系统:

1.整体指标用于整个技术部门或组织研发效能的度量

2.过程指标用于开发过程中每一环研发效能的度量

如图2所示,p1.项目管理系统:包含多个任务,每个需求以任务的形式下发给开发人员,项目和任务为多对多的关系,任务和开发人员为多对多关系

p11.任务:包含任务状态,任务相关人员的管理功能

p111.任务生命周期:包含多个状态:需求响应中、待开发、开发中、待测试、测试中、待发布、发布中、发布完成、故障中、故障修复中、运行中

p2.基于git的代码管理系统,包含多个分支,每个任务以分支的形式下发给开发人员,同时相关人员本地的代码管理终端以命令的形式规范提交内容,提交后同步修改任务状态,同时通过githooks验证提交的合法性,保证代码和任务同步。

p301.在需求被建立后自动创建相应的代码分支,并为相应开发人员的代码管理系统添加任务信息的订阅

p302.在相应开发人员以预定的命令形式提交代码后,将任务状态同步至项目管理系统。

p303.在相应测试人员以预定的命令形式提交代码后,将任务状态同步至项目管理系统

p304.当代码需要发布时,以预定的命令形式合并分支代码并自动进行打包,上传,部署的操作,并将任务状态同步至项目管理系统。

图4,c1:记录类,用于记录状态改变的每一次操作,包含唯一id,记录类型(枚举),创建时间,关联的人员id,关联的任务id

c2:任务类,用于记录任务状态及任务维度的统计数据,包含唯一id,任务状态(枚举),创建时间,该任务的前端开发周期,后端开发周期等指标

c3:人员类,用于记录研发人员及人员维度的统计数据,包含唯一id,人员职能(枚举),创建时间,该人员的前端开发周期,后端开发周期等指标

c2:统计类,用于记录整体的统计数据,包含唯一id,统计类型(枚举),创建时间,整体的前端开发周期,后端开发周期等指标。

具体地:

1.搭建任务管理系统(p1):

实际研发项目中,各个公司及项目组使用的任务管理系统往往各不相同,为了提高本方案的普适性,建议基于本项目正在使用的任务管理产品开放api,单纯的任务管理系统已经有成熟的解决方案,自主研发的成本较高,收益较低,第三方的任务管理系统如teambition,码云等产品,都提供了完整的开放api,包含项目管理,任务管理,人员管理,权限管理等模块,完全可以满足本方案的需求预期,且减少了迁移的成本。

2.搭建代码管理系统(p2):

实际研发项目中,各个公司和项目普遍使用第三方代码托管服务,为了提高本方案的普适性,建议基于本项目正在使用的代码管理系统开发api进行开发,包含分支管理,提交管理,人员管理,权限管理等模块,如gitlab,github等。

代码管理系统基于git搭建,供开发人员使用,包含一个命令选项模块和一个githooks同步模块

【命令选项模块】的能力包括(图p301,p302,p303,p304)将任务的状态抽象成选项共开发人员使用,如:任务开始/任务进行/任务完成/开始测试/测试完成/缺陷修复。

【githooks】的能力包括(图p301,p302,p303,p304)判断提交是否合法,在选项触发后通过调用相关api同步任务状态。

(注:流程中需要用到的任务相关的能力通过调用任务管理api实现,代码管理的相关能力通过调用代码管理api实现)。

p301:任务创建-自动创建代码分支–开发人员选择任务开始-选择任务–代码拉取–任务状态改变为开发中

p302:开发人员选择任务进行–提交代码–githooks验证提交合法性–提交成功-开发人员选择任务完成–提交代码-githooks验证提交合法性–任务状态改变为开发完成

p303:测试人员选择开始测试–选择任务–代码拉取–任务状态改变为测试中–测试人员选择测试完成–提交代码–githooks验证提交合法性–任务状态改变为测试完成

p304:运维人员选择开始发布–发布部署–任务状态改变为已发布

3.研发效能元数据存储

上述所有流程的数据通过api接口以固定的格式存储在数据库中:(如图c)

4.研发效能指标定时计算

通过服务器定时任务以天为维度计算所有指标并存储在统计表中,计算规则如下:

设周期时间为cycle,任务为mission,任务数量为count,单个任务各生命周期的时间分别为t11-tnn,缺陷为bug,发布前置时间为pret

需求响应周期(a):

∑missioni(t11+t12)+(t21+t22)+…(tn1+tn2))/count/cycle

需求交付周期(b):

设单任务的需求交付周期为b;b=∑t1(t1+t2+…+t11)

∑missionib1+b2+…bn/count/cycle

需求吞吐量(c):count/cycle

如图3,原型/文档交付周期(s1):∑tnt11+t12+…t1n/count/cycle

设计稿交付周期(s2):∑tnt21+t22+…t2n/count/cycle

前端开发周期(s3):∑tnt31+t32+…t3n/count/cycle

后端开发周期(s4):∑tnt41+t42+…t4n/count/cycle

联调周期(s5):∑tnt51+t52+…t5n/count/cycle

测试周期(s6):∑tnt61+t62+…t6n/count/cycle

开发中缺陷趋势(s7):f(t,bug)折线图表示

缺陷库存(s8):f(t,count(bug))折线图表示

发布频率(s9):count(t9)/cycle

发布前置时间(s10):∑tnpret1+pret2+…pretn/count/cycle

发布周期(s11):count(t11)/cycle

最后应当说明的是:以上实施例虽然已经参考优选实施例对本发明进行了描述,但在不脱离本发明的范围的情况下,可以对其进行各种改进并且可以用等效物替换其中的部件。尤其是,只要不存在结构冲突,各个实施例中所提到的各项技术特征均可以任意方式组合起来。本发明并不局限于文中公开的特定实施例,而是包括落入权利要求的范围内的所有技术方案。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1