CN110348714A - 基于代码日志对研发人员的产出水平评价的方法 - Google Patents

Abstract

本发明公开了基于代码日志对研发人员的产出水平评价的方法，包括用于安装在线切割机床上的支撑框架，支撑框架上设有竖直向下的导轨，导轨上的滑块连接有重锤组件，重锤组件底部设有开关碰触部；支撑框架左、右两侧还分别设有导轮A、导轮B，重锤组件上还设有与导轮A、导轮B位于同一竖直面的导轮C，上述重锤组件下表面的开关碰触部对准线切割机床上，具有停止切割功能的数控开关。

Description

基于代码日志对研发人员的产出水平评价的方法

技术领域

本发明涉及软件研发管理领域，具体涉及基于代码提交日志分析技术的研发人员画像生成方法。

背景技术

软件研发是知识工作者的活动，也是目前企业管理中最复杂和最具挑战的一个领域。作为企业人力资源管理者，需要了解如何评价、激励以及招募合适的研发员工；作为业务管理者，需要了解研发的效率与投入是否成正比，与业务的要求是否匹配；作为研发管理者，需要了解研发员工的积极性、工作效率和工作质量，以及改进情况。

当前企业，尤其是传统企业，对如何有效管理研发人员存在着较大的困惑：业务及人力资源管理者不了解研发工作的实质，给不出合理的评价标准，难于听懂研发人员的表达，从而不能真实理解研发团队士气；业务部门不了解同行水平，难于评价研发的投入产出是否合理；研发管理者难于深入开发活动一线进行细节观察，仅能根据过程数据，包括文档、流程及一些估算环节对研发效率进行度量，由于文档和流程均滞后于实际发生的研发活动，许多情况下还是事后补充或后期维护，与真实的研发活动存在信息的滞后、不完整和偏差的问题，导致评价效果难于做到真实准确。

现行的研发度量模式缺乏对知识工作者活动的深刻理解：比如基于代码行统计的产出评价模式，在不同的编程语言、技术框架和编码习惯下已经完全不能真实反映研发人员的产出；基于功能点的评估模型，其估算和真实结果均存在不小偏差，进而影响评价效果，在新产品开发和创新阶段更由于缺乏基准参考，无法给出估算结果。

具体地说，由于传统的管理模式、评估办法均不能准确反映实际发生的研发活动，度量存在理解偏差、不及时、不完整的问题；其度量和真实结果均存在偏差，进而影响评价效果。

用户画像技术作为一种理解目标用户行为特征的重要工具，建立在对真实用户的深刻理解，及高精准的相关数据的概括之上，已被广泛应用在产品创新、设计与营销领域。在研发管理领域里，尚缺乏一种基于对研发行为的深度理解进行建模，并基于真实的活动数据进行分析归纳的方法，来帮助企业各层管理者理解研发活动。

发明内容

本发明的目的在于提供基于代码日志对研发人员的产出水平评价的方法，从研发人员提交的代码日志中提取研发人员的各项工作特征，从而实现对研发人员的产出水平进行评价，解决现有技术中的问题。

为了实现上述目的，本发明采取以下技术方案：

基于代码日志对研发人员的产出水平评价的方法，其特征在于，包括以下过程：

步骤S1:从研发人员提交的代码日志中获取研发人员工作特征；

步骤S2:对工作特征按照设定的标准进行转化，得到研发人员的工作效率标签；

步骤S3：通过工作效率标签，按照设定的评价标准，评价研发人员产出水平。

作为一种优选方式，工作特征包括研发工作效率和工作质量特征及行为特征。

作为一种优选方式，研发工作效率和工作质量特征的获取包括以下过程：

建立专家词汇数据库，专家词汇数据库中包含常规代码日志中出现的各种术语的所属属性；

从代码日志中获取文本信息，提取文本信息中术语，基于后台专家词汇数据库获取术语所属工作属性；

对带工作属性的术语的出现频次计算，从而得到研发工作效率和工作质量特征。

作为一种优选方式，行为特征的获取包括以下过程：

从代码日志中获取提交时间，并得到每次提交日志提交间隔时间，从而得到与提交时间相关的行为特征；

作为一种优选方式，行为特征包括：早晨提交占比、下午提交占比、晚间提交占比、深夜提交占比、凌晨提交占比、平均提交间隔。

作为一种优选方式，研发工作效率和工作质量特征包括带需求编号提交比例、有效描述提交比例、修复Bug比率和开发并行度。

作为一种优选方式，上述步骤S3中，通过工作效率标签评价研发人员产出水平包括以下过程：

基于时间区间对标签进行计算，获得与标签相关的评价指标的分布结果；

得到每个研究人员关联的评价指标，根据评价指标对应的研究人员类型，实现对研究人员的评价。

作为一种优选方式，还包括按照标准判断标签置信度。

作为一种优选方式，对研究人员的评价以研究人员画像形式呈现，分别包括高贡献者、积极者、合格者、不合格者和待改进者，研究人员身份ID与其代码提交日志及最后生成的研究人员画像关联，研究人员画像生成后被推送至用户终端。

附图说明

图1为实施例1的流程示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步说明，本发明的实施方式包括但不限于下列实施例。

实施例

基于代码日志对研发人员的产出水平评价方法，主要是通过生成研发人员画像来实现，利用研发人员画像生成系统实现，研发画像生成系统数据库内带有专家词汇数据库（以下简称专家词库），通过专家词库可以增加或删除专家词库中的专家词汇（即相关行业术语），同时对专家词库中的对词语定义其工作属性。即属于专家词库内的词语皆有所属的工作属性。比如，专家词库中将“修复”、“优化”、“fix”等词语的定义为“修复Bug”这一工作属性。

本实施例的技术思路是，通过程序员（即研发人员）提交的代码日志，从而获取文本信息及提交时间信息，从中提取出行为特征、工作效率和质量特征用以生产研发人员画像。

而在在本实施例中，行为特征包括：早晨提交占比、下午提交占比、晚间提交占比、深夜提交占比、凌晨提交占比、平均提交间隔；工作效率和质量特征包括：带需求编号提交比例、有效描述提交比例、修复Bug比率和开发并行度；研发人员画像参考模型包括五个类别，分别为高贡献者、积极者、合格者、不合格者和待改进者。根据每个研发人员所述的画像类别，管理者便可方便对研发人员的产出水平进行评价判断。

具体的，基于代码日志的研发人员画像生成方法，包括以下步骤：

步骤S1: 获取代码提交日志信息；代码提交日志信息包括提交日志的研发人员名称、提交时间和提交注释。

代码提交日志信息是指，通过代码版本管理服务器导出的提交日志，从中能获取到的提交人员名称、提交时间和提交注释。具体操作是，用户在系统内上传指定的代码提交日志，从而使得系统获取研发人员名称和与其关联的提交时间和提交注释，研发人名名称的作用是关联最终生成的画像类别，以识别出画像对应的具体研发人员，比如“高贡献者”对应的是哪些研发人员；提交时间的作用是用于识别行为特征，比如提交时间显著分布在上午九点，则会在“早晨提交占比”特征中处于高分布阶段；而提交注释是研发人员在提交代码时的备注信息，在系统中用于理解研发工作的内容细节。

步骤S2：对代码提交日志进行预处理，提取出日志提交的起止时间范围；消除提交注释分隔字符和特殊字符，转换为规定的行列表格式；

分隔字符是指提交注释中的逗号、竖线、分号或其它与表格分隔符保留符号相同的字符，消除分隔字符的作用是避免提交注释被表格处理程序错误地断句从而丢失文本内容。特殊字符是指由于键入异常产生的无法显示但能够被程序读取的字符，如回车、换行等，消除特殊字符的作用是提取有效的文本内容。

步骤S3：对代码提交注释进行标准化处理；标准化处理过程为：对文本内容进行大小写、简繁转换；然后提取词干；

步骤S4：对代码提交日志信息中的提交时间进行分析，提取出研发人员在代码提交上的行为特征；

研发人员的行为特征识别提取过程如下：

S401：基于无监督学习算法识别出研发人员提交时间、提交时间间隔的分布区间；

S402：基于Z-Score对研发人员提交时间进行标准化处理；

S403：将处理结果分布到S401识别出来的区间内。

比如，研发人员在提交时间上呈现出显著的早晨、下午的时间分布，具体的，如共有五名研发人员，其中三名都经常在早晨提交，另外两名经常在下午提交（本实施例的经常只是为了便于描述，在实际过程中，系统预设有基本值，达到或超过基本值则即为经常提交），或都在早晨提交，或都在下午提交，那么系统将生成早晨提交占比、下午提交占比两项行为特征，并分析出三名研发人员具有早晨提交占比高的行为特征，另两名研发人员具有下午提交占比高的行为特征。如果研发人员在提交时间上没有呈现出显著的分布，具体的，上述五名开发人员在早晨、中午、下午提交的分布非常平均，那么系统将不生成按时间段的行为特征，也不会分析出研发人员在提交时间段上具有任何行为特征。

比如，研发人员在提交时间间隔上呈现出显著的分布，具体的，如共有五名开发人员，其中三名都是每天提交3次，另两名每两天才提交1次，那么系统将生成提交时间间隔特征，并分析出三名研发人员具有提交时间间隔短的特征；另两名研发人员具有提交时间间隔长的特征。

步骤S5：基于专家词库对代码提交日志中的提交注释进行关键词提取、并获得此关键词在专家词库中的工作词属性，从而提取出指定的研发人员的工作效率和工作质量特征。

在本实施例中，专家词库内已经存储了一般代码提交日志中会出现的各种术语的工作属性定义，比如在专家词库中“修复”、“优化”、“fix”等词语属性定义为修复Bug，“#123”、“#124”等带#号数字属性定义为带需求编号，“update”、“更新”等词语属性定义为非有效描述。

而在本实施例中，工作效率和工作质量特征包括带需求编号提交比例、有效描述提交比例、修复Bug比率和开发并行度。根据计算各种属性的词语出现的频率则可以得到研发人员的工作效率和工作质量特征。

比如，某个研发人员提交注释中大量包含“修复”、“优化”、“fix”等词语，则其特征-修复Bug比率将比较高。

比如，某个研发人员提交注释中均包含需求编号，比如，提交注释中包含数字需求编号、#开头的需求编号，如“#123”、“#124”等，则“带需求编号提交比例”将比较高。

比如，某个研发人员提交注释中几乎都是“update”、“更新”或其它无实际意义的文本，如“ss”、“zz”，则“有效描述提交比例”将比较低。

值得说明的是，实际的判断高、低是由系统预设的基本值来确定的，即某工作属性的术语出现频次达到且超过设定值即为比较高，未达到基本值则判定为比较低，从而便得到了工作效率和工作质量特征。

比如，某个研发人员在同时期交叉对多个需求编号存在提交记录，则“开发并行度”比较高。具体的，研发人员早晨9:00一条提交记录为“#123 用户编辑功能实现”，9:10分一条提交记录为“#125 访谈安排功能实现”，10:00一条记录为“#123 用户头像上传功能实现”，下午一条提交记录为“#125 访谈中编辑访谈对象”；则当天该研发人员存在两个并行任务。

步骤S6：采用研发标签分析模型，对行为特征、工作效率和工作质量特征进行匹配，并将对应的研发人员分类到对应的标签中。研发标签分析模型包括但不限于早晨比较活跃标签、频繁提交代码标签、注释很规范标签等等。

比如，“早晨比较活跃”这一标签对应“早晨提交占比”这一行为特征中计算为“高”的分析结果；“频繁提交代码”这一标签对应的是“提交时间间隔”这一行为特征中计算为“短”的分析结果；“注释很规范”这一标签对应的是“有效描述提交比例”这一工作质量特征中计算为“高”的分析结果。

比如，“参与需求数量较多” 这一标签对应的是“开发并行度”这一工作效率特征中计算为“高”的分析结果。

比如，“良好的代码提交习惯”对应的是“频繁提交代码”和“注释很规范”这两项特征。

也就是说，工作标签是系统预设了其对应的行为特征及工作效率和工作质量特征，从研发人员的行为特征及工作效率和工作质量特征可以得到相关的工作标签。

步骤S7：基于研发人员画像模型，对标签进行计算和分类，将分类对应的研发人员群体填充到对应的研发人员画像类别。

本步骤中，研发人员的画像生成过程如下：

S701：基于欧几里德空间算法对研发人员的标签进行计算，获得评价指标计算结果；

比如，活跃度指标计算结果是指，某个研发人员具有多少个时间区间的活跃度标签，每取得一个时间区间活跃度标签，活跃度指标得1分。时间区间的划分由系统设定。

S702：判断所有标签的置信度；

比如，每在一个评估区间内存在一个“早晨比较活跃”的标签，该标签置信度指标得1分。

S703：在研发人员画像模型中进行范围搜索，如评价指标计算结果匹配到具体范围，将对应的研发人员群体命名为对应的研发人员画像类别；

比如，研发人员画像参考模型包括五个类别，分别为高贡献者、积极者、合格者、不合格者和待改进者。

其中，“积极者”的具体范围包括：活跃度指标>=1，参与需求数量处于高分布，每个标签的置信度指标>=2。

值得说明的是，本实施例中的“高”、“低”、及时间都没给出具体的标准，这些标准由后台管理直接定义即可。

S704：如空间分布计算结果匹配不到研发人员画像模型类别的具体范围，根据邻近算法找到画像模型中最近的范围，并使用该范围对应的类别名称、下划线及一个整数对空间内的研发人员群体进行命名；

比如，某个空间分布计算结果匹配不到任何具体的范围，根据邻近算法识别出最近范围的分类为“积极者”，则此空间内的研发人员群体将被命名为“积极者_0”。

S705：如一个画像类别有多个邻近空间分布计算结果，根据邻近距离，对最后一位整数进行递增命名。

比如，有两个空间分布计算的结果都邻近画像参考模型中的“积极者”，那么距离最近的空间内的研发人员群体将被命名为“积极者_0”，另一空间内的研发人员群体将被命名为“积极者_1”。

步骤S8，将所有的研发人员画像类别、标签、起止时间范围及生成时间推送到Web服务端，生成一个画像相册，并将各个类别以卡片形式填充到相册内。

比如，在2019年5月1日，使用研发画像系统对五位研发人员进行第一次分析，代码提交日志为2019年一季度所有数据，将生成一个时间戳为“2019.05.01”、名称为“基线”的画像相册，并自动分析出提交日志的时间范围为“2019.01.01-2019.03.31”。相册内包含一个积极者画像卡片和一个合格者画像卡片，其中积极者卡片上显示三位研发人员名称、标签和行为特征，合格者卡片上显示两位开发人员名称、标签和行为特征。

比如，在2019年5月3日，使用研发画像系统对五位研发人员进行第二次分析，代码提交日志为2019年二季度所有数据，将生成一个时间戳为“2019.05.03”、名称为“V1”的画像相册，并自动分析出提交日志的时间范围为“2019.04.01-2019.06.30”。相册内包含新的画像卡片和对应的研发人员名称、标签和行为特征。

按照上述实施例，便可很好地实现本发明。值得说明的是，基于上述结构设计的前提下，为解决同样的技术问题，即使在本发明上做出的一些无实质性的改动或润色，所采用的技术方案的实质仍然与本发明一样，故其也应当在本发明的保护范围内。

Claims (9)

1.基于代码日志对研发人员的产出水平评价的方法，其特征在于，包括以下过程：

步骤S1:从研发人员提交的代码日志中获取研发人员工作特征；

步骤S2:对工作特征按照设定的标准进行转化，得到研发人员的工作效率标签；

步骤S3：通过工作效率标签，按照设定的评价标准，评价研发人员产出水平。

2.根据权利要求1所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，工作特征包括研发工作效率和工作质量特征及行为特征。

3.根据权利要求2所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，研发工作效率和工作质量特征的获取包括以下过程：

建立专家词汇数据库，专家词汇数据库中包含常规代码日志中出现的各种术语的所属属性；

从代码日志中获取文本信息，提取文本信息中术语，基于后台专家词汇数据库获取术语所属工作属性；

对带工作属性的术语的出现频次计算，从而得到研发工作效率和工作质量特征。

4.根据权利要求2所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，行为特征的获取包括以下过程：

从代码日志中获取提交时间，并得到每次提交日志提交间隔时间，从而得到与提交时间相关的行为特征。

5.根据权利要求4所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，行为特征包括：早晨提交占比、下午提交占比、晚间提交占比、深夜提交占比、凌晨提交占比、平均提交间隔。

6.根据权利要求3所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，研发工作效率和工作质量特征包括带需求编号提交比例、有效描述提交比例、修复Bug比率和开发并行度。

7.根据权利要求1所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，上述步骤S3中，通过工作效率标签评价研发人员产出水平包括以下过程：

基于时间区间对标签进行计算，获得与标签相关的评价指标的分布结果；

得到每个研究人员关联的评价指标，根据评价指标对应的研究人员类型，实现对研究人员的评价。

8.根据权利要求7所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于， 在上述步骤S3中，还包括按照标准判断标签置信度。

9.根据权利要求1~8任一项所述的基于代码日志对研发人员的产出水平评价的方法，其特征在于，

对研究人员的评价以研究人员画像形式呈现，分别包括高贡献者、积极者、合格者、不合格者和待改进者，研究人员身份ID与其代码提交日志及最后生成的研究人员画像关联，研究人员画像生成后被推送至用户终端。