CN113988707A - 风险识别方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供一种风险识别方法、装置、电子设备及计算机可读存储介质，涉及计算机、人工智能、大数据技术领域，能够自动识别任务执行过程中存在的风险，提高风险识别的准确率并节约人力成本。其中，一种风险识别方法，由电子设备自动执行，所述方法包括：获取预设信息，所述预设信息包括以下至少一项：任务的基本信息、执行所述任务的用户的信息、用户维护所述任务的过程中产生的维护信息和所述任务的执行信息；根据所述预设信息确定所述任务执行过程中的风险；提示用户所述风险。本申请实施例应用在敏捷开发过程中。

Description

风险识别方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及计算机、人工智能、大数据技术领域，尤其涉及一种风险识别方法、装置、电子设备及计算机可读存储介质。

背景技术

敏捷开发以用户的需求为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子任务，各个子任务的成果都经过测试，具备可视、可集成和可运行使用的特征。

看板是一种基于精益思想的软件开发方法。看板的初始目的在于可视化工作，让每个人看到所有工作项的进展和相应的优先级，提高工作透明度。看板拥有简单的管理方法，直观的显示方式，因此在现代应用开发过程中使用非常广泛，许多软件开发团队选择使用看板进行软件开发。

目前，敏捷开发过程中使用看板进行软件开发。软件开发过程中，主要由敏捷教练跟踪敏捷组成员每日工作内容、遇到的问题、任务执行进展等。任务执行过程中存在的风险均需要敏捷组成员或敏捷教练进行人工识别上报，这种识别方式过于依赖敏捷组成员或敏捷教练个人经验，无法高效准确的识别出潜在风险。

发明内容

本申请提供一种风险识别方法、装置、电子设备及计算机可读存储介质，能够自动识别任务执行过程中存在的风险，提高风险识别的准确率并节约人力成本。

为达到上述目的，本申请实施例采用如下技术方案。

第一方面，提供一种风险识别方法，由电子设备自动执行，该方法包括：获取预设信息，该预设信息包括以下至少一项：任务的基本信息、执行所述任务的用户的信息、用户维护所述任务的过程中产生的维护信息和所述任务的执行信息。根据所述预设信息确定所述任务执行过程中的风险，提示用户所述风险。

示例性的，所述任务的基本信息、执行所述任务的用户信息和用户维护所述任务的过程中产生的维护信息从电子看板系统自动获取；所述任务的执行信息从测试管理平台自动获取；

本申请提供的风险识别方法，通过获取任务的基本信息、执行任务的用户的信息、用户维护任务的过程中产生的维护信息和任务的执行信息，根据获取的这些信息自动化确定任务执行过程中可能存在的风险，并提示用户，能够提高风险识别的准确率并节约人力成本。

在一种可能的实现方式中，所述预设信息包括用户维护任务的过程中产生的维护信息和任务的执行信息。其中，维护信息包括用户维护任务过程中不同时间点产生的问题的数量；任务的执行信息包括执行任务过程中不同时间点产生的问题的数量。

相应的，所述根据预设信息确定任务执行过程中的风险，包括：根据从第一时间点至第二时间点产生的问题数量确定累计问题数量随着时间变化是否收敛，若不收敛则确定所述任务存在问题收敛风险。

其中，第二时间点晚于第一时间点，第一时间点至第二时间点之间的任意时间点产生的问题数量为执行任务过程中所述任意时间点产生的问题的数量以及用户维护所述任务过程中所述任意时间点产生的问题的数量之和。

在该实现方式中，判断任务执行和维护过程中产生的问题数量随着时间变化是否收敛，如果收敛，则表示该任务存在的问题可控，如果不收敛，则表示该任务存在的问题不可控，存在蔓延的可能，需要及时控制该任务存在的问题。通过该实现方式自动确定任务是否存在问题收敛风险，提高风险识别的准确率并节约人力成本。

在一种可能的实现方式中，所述预设信息包括：任务的基本信息和执行任务的用户的信息。其中，任务的基本信息包括任务周期和第一任务工作量；执行任务的用户的信息包括执行任务的用户的数量。

相应的，所述根据预设信息确定任务执行过程中的风险，包括：根据所述任务周期和所述执行所述任务的用户的数量，确定第二任务工作量。若第二任务工作量与第一任务工作量的差值在预设误差范围外，则确定存在周期风险。

示例性的，所述第二任务工作量、任务周期和所述执行所述任务的用户的数量之间满足如下关系：第二任务工作量＝任务周期*执行任务的用户数量。

在该实现方式中，根据任务周期和执行任务的用户的数量，确定第二任务工作量(实际的任务工作量)。若该第二任务工作量与第一任务工作量(预期的任务工作量)的差值在预设误差范围外，则确定存在周期风险，也即按照实际分配的执行任务的用户的数量无法如期完成任务，需要增加用户数量来确保任务能够如期完成。通过该实现方式，自动确定任务是否存在周期风险，提高风险识别的准确率并节约人力成本。

在一种可能的实现方式中，所述任务为测试任务，该任务包括多个待测试案例。所述预设信息包括：任务的基本信息、执行任务的用户的信息和任务的执行信息。其中，所述任务的基本信息包括待测试案例总数、要求的测试时长。任务的执行信息包括已测试案例数量、已测试时长。执行任务的用户的信息包括执行任务的测试人员数量。

相应的，所述根据预设信息确定任务执行过程中的风险，包括：根据所述已测试案例数量、已测试时长和所述测试人员数量确定第一值。若第一值与第一标准值的差值在预设误差范围外，则确定存在测试进度风险。

示例性的，所述已测试案例数量、已测试时长、所述测试人员数量和第一值之间满足如下关系：

所述待测试案例总数、要求的测试时长和第一标准值之间满足如下关系：

在该实现方式中，根据已测试案例数量、已测试时长和测试人员数量确定第一值。若第一值与第一标准值的差值在预设误差范围外，则确定存在测试进度风险，也即按照当前已分配测试人员的测试速度无法预期完成测试任务，需要增加测试人员或者增加每个测试人员需完成的测试案例的数量。通过该实现方式，自动确定任务是否存在测试进度风险，提高风险识别的准确率并节约人力成本。

在一种可能的实现方式中，所述预设信息包括用户维护任务的过程中产生的维护信息。相应的，根据所述预设信息确定所述任务执行过程中的风险，包括：根据用户维护任务的过程中产生的维护信息确定第二值；若第二值小于第二标准值，且与第二标准值的差值大于预设阈值，则确定任务存在关注度风险。

其中，第二值为用户维护任务过程中平均每天产生的维护内容条数的平均值，第二标准值为用户在维护目标历史任务的过程中平均每天产生的维护内容条数的平均值。目标历史任务为与当前任务相似度满足一定条件的历史任务。

或者，第二值为用户维护任务过程中产生的维护内容总条数；第二标准值为用户在维护目标历史任务的过程中产生的维护内容总条数。目标历史任务为与当前任务相似度满足一定条件的历史任务。

在该实现方式中，根据用户维护任务的过程中产生的维护信息确定第二值。若第二值小于第二标准值，且与第二标准值的差值大于预设阈值，则确定任务存在关注度风险，也即用户对任务的关注度不足，需要增加关注，例如：增加维护的条数、增加提出的需求的条数等。通过该实现方式，自动确定任务是否存在关注度风险，提高风险识别的准确率并节约人力成本。

在一种可能的实现方式中，在根据所述预设信息确定所述任务执行过程中的风险之后，所述方法还包括：生成风险评估报告，所述风险评估报告中包括风险类型以及风险详细信息。

第二方面，本申请提供了一种风险识别装置。该风险识别装置可以用于执行第一方面或第一方面中任一种可能的实现方式所述的方法。

根据第二方面，在第二方面的第一种可能的实现方式中，可以根据上述第一方面至第一方面提供的任一种方法，对该风险识别装置进行功能模块的划分。例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。

第三方面，本申请提供一种电子设备，该电子设备包括存储器和处理器。上述存储器和处理器耦合。该存储器用于存储计算机指令。当处理器执行该计算机指令时，电子设备执行如第一方面至第一方面中任一种可能的实现方式所述的方法。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面至第一方面中任一种可能的实现方式所述的方法。

第五方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面至第一方面中任一种可能的实现方式所述的方法。

可以理解的是，上述提供的任一种风险识别装置、电子设备、计算机可读存储介质、计算机程序产品等均可以应用于上文所提供的对应的方法，因此，其所能达到的有益效果可参考对应的方法中的有益效果，此处不再赘述。

附图说明

图1为电子看板系统的结构示意图；

图2A为本申请实施例提供的一种风险识别系统的结构示意图；

图2B为本申请实施例提供的另一种风险识别系统的结构示意图；

图3为本申请实施例提供的看板管理服务器或风险识别装置的结构示意图；

图4为本申请实施例提供的一种风险识别方法的流程示意图；

图5为本申请实施例提供的另一种风险识别方法的流程示意图；

图6为本申请实施例提供的任务的累计问题数量随着时间变化的发展趋势图；

图7为本申请实施例提供的又一种风险识别方法的流程示意图；

图8为本申请实施例提供的又一种风险识别方法的流程示意图；

图9为本申请实施例提供的再一种风险识别方法的流程示意图；

图10为本申请实施例提供的一种风险识别装置的结构示意图。

具体实施方式

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例中，“至少一个”是指一个或多个。“多个”是指两个或两个以上。

在本申请实施例中，“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

为便于理解本申请，对本申请涉及到的术语进行解释：

一、敏捷开发：

敏捷开发以用户的需求为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子任务，各个子任务的成果都经过测试，具备可视、可集成和可运行使用的特征。敏捷开发的具体流程如下：

1、梳理产品需求。

在开发之前，存在一个需求列表，该需求列表定义了软件开发产品需要具备的特性和功能。实际应用中，一般由产品经理来定义该需求。在定义需求的同时，还需定义需求的优先级。

2、制定迭代计划。

一般规定两周(10个工作日)为一个迭代。在迭代开始之前，需要召开迭代计划会制定迭代的计划，把产品需求按照优先级排序，由产品经理为敏捷开发团队成员讲解各个产品需求。敏捷开发团队成员根据需求的复杂程度评估每个任务的工作量，当前n个任务的工作量之和约等于团队总工时时，那么这个迭代就把产品需求中前n个任务作为该迭代的任务。

敏捷开发团队需要把迭代计划和预估的时间输入看板中，看板划分成三大块：未开始、进行中、已完成。当然，所有迭代计划的状态开始都处于未开始状态。

3、迭代执行。

在迭代进行期间，由敏捷开发团队成员认领看板上的任务，并在看板上更新任务的进度、执行任务过程中遇到的问题以及计划执行的任务。

4、迭代总结。

对迭代执行过程中的问题以及迭代执行后产生的结果进行总结。

二、看板：

看板是一种基于精益思想的软件开发方法。看板的初始目的在于可视化工作，让每个人看到所有工作项的进展和相应的优先级，提高工作透明度。看板包括物理看板和电子看板。

如图1所示，电子看板系统100由多个部分组成：

1、看板显示终端110，例如：LED显示屏，数码显示屏，全点阵显示屏，LCD液晶屏，平板电视等。看板显示终端110用于显示敏捷开发团队的日常信息，包括但不限于任务信息、敏捷团队的基本信息、任务进度信息等。

2、看板数据采集终端120，主要用于收集现场的数据，包括光电、按钮、收集器、条码、移动终端、个人电脑(personal computer，PC)端等现场的装置。数据采集终端120采集的数据可直接在看板显示终端110显示或者将采集的数据发送给看板管理服务器130，经看板管理服务器130处理后在看板显示终端110显示。

3、看板管理服务器130，主要用于发布看板信息，设置看板参数及其它有关电子看板系统的一切内容及数据。看板管理服务器用于接收看板数据采集终端120采集的数据，并进行处理后通过看板显示终端110显示。

看板拥有简单的管理方法，直观的显示方式，因此在现代应用开发过程中使用非常广泛，许多软件开发团队选择使用看板进行软件开发管理。目前，敏捷开发过程中使用看板进行软件开发管理。敏捷开发团队通过看板记录敏捷开发团队每日任务进度，工作计划等，敏捷组成员可以通过线上看板了解组内各成员的工作内容及风险问题。现有的这种软件开发管理，主要由敏捷教练跟踪敏捷组成员每日工作内容、遇到的问题、任务执行进展等。任务执行过程中存在的风险均需要敏捷组成员或敏捷教练进行人工识别上报，这种识别方式过于依赖敏捷组成员或敏捷教练个人经验，无法高效准确的识别出潜在风险。

为了解决上述问题，本申请实施例提供一种风险识别方法、装置及系统，通过获取任务的基本信息、执行任务的用户的信息、用户维护任务的过程中产生的维护信息和任务的执行信息，根据获取的这些信息自动化确定任务执行过程中可能存在的风险，提高风险识别的准确率并节约人力成本。

本申请实施例提供的风险识别方法应用于风险识别系统，在一种实现方式中，如图2A所示，该风险识别系统200包括电子看板系统100和测试管理平台300。其中，测试管理平台用于管理敏捷开发团队的日常测试工作，记录任务的相关信息，以及执行过程中的数据，如进度，周期等。电子看板系统100用于对接测试管理平台210，获取测试管理平台产生的数据，如任务的时间进度、完成进度，产生的问题数等，并根据这些数据结合电子看板系统本身的数据，如任务的基本信息、执行任务的用户信息以及用户维护任务过程中产生的维护信息识别任务执行过程中的风险。在该实现方式中，由电子看板系统100执行本申请实施例提供的风险识别方法，更具体的，由电子看板系统100中的看板管理服务器130执行本申请实施例提供的风险识别方法。

在另一种实现方式中，如图2B所示，该风险识别系统200包括电子看板系统100、测试管理平台210和风险识别装置220。其中，风险识别装置220分别与电子看板系统100和测试管理平台210连接。风险识别装置220用于分别从电子看板系统100获取任务的基本信息、执行任务的用户信息以及用户维护任务过程中产生的维护信息等，以及从测试管理平台210获取任务的时间进度、完成进度，产生的问题数等，并根据从电子看板系统100和测试管理平台210获取的数据识别任务执行过程中的风险。示例性的，该风险识别装置220具体可以是服务器、通用计算机、专用计算机、计算机网络或者其他可编程装置等，本申请实施例对风险识别装置的具体类型不作任何限制。

本申请实施例提供的风险识别方法适用于图2A所示的看板管理服务器130或者图2B所示的风险识别装置220。

图3示出了看板管理服务器130或者风险识别装置220的结构示意图。

看板管理服务器130或者风险识别装置220包括一个或多个处理器310、一个或多个外部存储器320、一个或多个通信接口330以及显示器340。

处理器310、外部存储器320和通信接口330通过总线相连接。处理器310可以包括通用中央处理器(central processing unit，CPU)、微处理器、特定应用集成电路(application-specific integrated circuit，ASIC)，或者用于控制本申请方案程序执行的集成电路等。

一般，处理器310中可设置有内部存储器，可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统以及应用程序代码等。在一些示例中，存储数据区存储有获取到的任务的基本信息、执行任务的用户的信息、用户维护任务的过程中产生的维护信息和任务的执行信息。此外，内部存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器310通过运行存储在内部存储器的指令，执行风险识别装置的各种功能应用以及数据处理。在一个示例中，处理器310也可以包括多个CPU，并且处理器310可以是一个单核(single-CPU)处理器或多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路或用于处理数据(例如计算机程序指令)的处理核。

通信接口330，可用于与其他设备或通信网络通信，如与测试管理平台通信等。

显示器340用于显示风险评估报告，包括风险类型以及风险详情信息等。

可以理解的是，本申请实施例示意的结构并不构成对看板管理服务器130或者风险识别装置220的具体限定。在本申请另一些实施例中，看板管理服务器130或者风险识别装置220可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请实施例提供的一种风险识别方法可以由电子设备自动执行，示例性的，本实施例可以应用于看板管理服务器130或者风险识别装置220。如图4所示，该风险识别方法可以包括：

S401、获取预设信息。

其中，所述预设信息包括以下至少一项：任务的基本信息、执行所述任务的用户的信息、用户维护所述任务的过程中产生的维护信息和所述任务的执行信息。

可选的，任务的基本信息包括任务的执行周期、任务的类型、任务的工作量等。当该任务为测试任务时，任务的基本信息还包括该测试任务包括的测试案例的个数等。

示例性的，当任务为购买理财产品的任务时，该任务的执行周期为30日，任务的类型为项目类，任务的工作量为100人天。当任务为测试任务时，该任务的执行周期为20天，任务的测试工作量为10人天，测试案例200条。

执行任务的用户的信息包括：执行任务的用户的总数量、执行任务的用户的分工、不同分工的用户的数量等。示例性的，以敏捷开发团队执行某个任务为例，对于该任务，敏捷开发团队中执行该任务的用户包括提出任务需求的人员、开发人员、测试人员等，根据维护该任务的不同用户的分工，该用户信息包括执行该任务的用户的总数量、用于维护任务需求的用户的数量、用于维护开发进度以及实施任务的具体内容的开发人员的数量、执行测试任务以及维护测试进度的测试人员的数量。

用户维护所述任务的过程中产生的维护信息包括：用户维护所述任务的过程中产生的问题的类型、数量、测试方案等。

可选的，任务的基本信息、执行任务的用户的信息、用户维护所述任务的过程中产生的维护信息可从电子看板系统获取。

任务的执行信息包括：任务的实际执行时长、进度。当任务包括测试任务时，由于测试任务一般包含多个待测试的案例，因此，测试任务的执行信息包括已执行案例数。

可选的，任务的执行信息可以从测试管理平台获取。

S402、根据所述预设信息确定所述任务执行过程中的风险。

根据步骤S401获取的信息自动分析任务执行过程中的风险。

S403、提示用户所述风险。

可选的，在一种实现方式中，通过生成风险评估报告提示用户任务执行过程中的风险。其中，所述风险评估报告中包括风险类型以及风险详细信息。

当存在风险时，自动生成风险评估报告，在该风险评估报告中阐明风险类型和风险详细信息。示例性的，当存在问题收敛风险时，在该风险评估报告中写明风险的类别为问题收敛风险，该风险对应的风险详细信息可以包含如图6所示的该任务的累计问题数量随着时间变化的发展的趋势图。

本申请实施例提供的风险识别方法，通过获取任务的基本信息、执行任务的用户的信息、用户维护任务的过程中产生的维护信息和任务的执行信息，根据获取的这些信息自动化确定任务执行过程中可能存在的风险并提示用户，能够提高风险识别的准确率并节约人力成本。

下文针对不同类型的风险及不同类型风险的自动识别方法进行介绍：

一、问题收敛风险

问题收敛风险用于判断任务实施过程中存在的问题是否可控。

为了识别问题收敛风险，需要获取如下信息：用户维护任务的过程中产生的维护信息和任务的执行信息。其中，维护信息包括用户维护任务过程中不同时间点产生的问题的数量；任务的执行信息包括执行任务过程中不同时间点产生的问题的数量。

因此，如图5所示，步骤S401、获取预设信息，可具体实现为：

S501、获取用户维护任务的过程中产生的维护信息和任务的执行信息。其中，维护信息包括用户维护任务过程中不同时间点产生的问题的数量；任务的执行信息包括执行任务过程中不同时间点产生的问题的数量。

相应的，所述S402、根据所述预设信息确定所述任务执行过程中的风险，具体可实现为：

S502、根据从第一时间点至第二时间点产生的问题数量确定累计问题数量随着时间变化是否收敛，若不收敛则确定所述任务存在问题收敛风险。

其中，第二时间点晚于第一时间点，例如：第一时间点可以为任务开始执行日期，第二时间点可以为任务当前执行日期。第一时间点至第二时间点之间的任意时间点产生的问题数量为执行任务过程中所述任意时间点产生的问题的数量以及用户维护所述任务过程中所述任意时间点产生的问题的数量之和。其中，执行任务过程中产生的问题的数量可从测试管理平台获取，用户维护任务过程中产生的问题数量可从电子看板系统获取。例如：任务开始执行日期为2021-10-25，当前执行日期为2021-11-08，那么对于2021-10-25至2021-11-08之间的任意日期，如2021-11-01产生的问题数量为2021-11-01这一天任务执行过程中产生的数量以及用户这一天维护任务过程中产生的问题数量之和。

任务的执行周期可以为几天、几周或几月等。问题数量和任务执行时间点之间存在对应关系，通过统计不同时间点产生的问题数量可以得到累积问题数量随着时间变化的发展趋势，如果该趋势表明问题数量随着时间变化趋于平稳，则表明累积问题数量随着时间变化逐渐收敛，则表示该任务存在的问题可控。如果该趋势表明累积问题数量随着时间变化仍持续上升，则表明问题随着时间变化不收敛，表示该任务存在的问题不可控，存在蔓延的可能，需要及时控制该任务存在的问题。

示例性的，如图6所示，为在2021-09-26至2021-10-20期间一个任务中累计问题数量随着时间变化的趋势，可以得出累计问题数量随着时间变化先是逐渐增长后趋于平稳，则表明累计问题数量随着时间变化而收敛。

本申请实施例提供的风险识别方法，判断任务执行和维护过程中产生的问题数量随着时间变化是否收敛，如果收敛，则表示该任务存在的问题可控，如果不收敛，则表示该任务存在的问题不可控，存在蔓延的可能，需要及时控制该任务存在的问题。通过该实现方式自动确定任务是否存在问题收敛风险，提高风险识别的准确率并节约人力成本。

二、周期风险

周期风险用于判断在一定周期内实际执行的任务工作量与预期工作量之间的差值是否超过风险可控的门限，进而判断任务是否能在预定周期内如期完成。

为了识别周期风险，需要获取如下信息：任务的基本信息，主要是指任务周期和第一任务工作量(或者又可称之为预期任务工作量)。执行任务的用户的信息，主要是指执行任务的用户的数量。

因此，如图7所示，S401、获取预设信息具体可实现为：

S701、获取任务的基本信息和执行任务的用户信息，其中任务的基本信息包括任务周期和第一任务工作量，执行任务的用户的信息包括执行任务的用户的数量。

相应的，所述S402、根据预设信息确定任务执行过程中的风险，具体可实现为：

S702、根据所述任务周期和所述执行所述任务的用户的数量，确定第二任务工作量。

其中，第二工作量是指实际的任务工作量。

可选的，所述任务周期、执行任务的用户的数量和第二任务工作量之间满足如下关系：

第二任务工作量＝任务周期*执行任务的用户数量。

S703、若所述第二任务工作量与第一任务工作量的差值在预设误差范围外，则确定存在周期风险。

如果第二任务工作量与第一任务工作量的差值在预设误差范围外，则表明该任务存在周期风险，也即按照当前分配的用于执行任务的用户数量，无法按照预定的周期完成任务，则需要增加执行任务的用户的数量。

示例性的，理财购买任务的工作量为100人天，也即需要100人1天完成该理财购买任务，预设的误差范围为-10％～10％。若实际执行该任务的用户的人数为3人，执行周期为25天，那么，根据任务周期和执行任务的用户的数量，可以计算得到第二任务工作量(实际的任务工作量)为25*3＝75人天，第一任务工作量与第二任务工作量之间的偏差为

该取值位于-10％～10％这一误差范围外，则存在周期风险，需要增加用户数量以保证任务能够如期完成。

本申请实施例提供的风险识别方法，根据任务周期和执行任务的用户的数量，确定第二任务工作量(实际的任务工作量)。若该第二任务工作量与第一任务工作量(预期的任务工作量)的差值在预设误差范围外，则确定存在周期风险，也即按照实际分配的执行任务的用户的数量无法如期完成任务，需要增加用户数量来确保任务能够如期完成。通过该实现方式，自动确定任务是否存在周期风险，提高风险识别的准确率并节约人力成本。

三、测试进度风险

当任务为测试任务时，还可能存在测试进度风险。为了自动识别测试进度风险，需要获取以下信息：任务的基本信息，测试任务一般包括多个测试案例，因此，该任务的基本信息主要包括待测试案例总数、要求的测试时长。任务的执行信息，主要是指已测试案例数量、已测试时长。执行任务的用户的信息，主要是指执行任务的测试人员数量，例如：敏捷开发团队投入的测试人员的数量。

因此，如图8所示，步骤S401、获取预设信息，可具体实现为：

S801、获取任务的基本信息、任务的执行信息和执行任务的用户的信息。其中，任务的基本信息包括待测试案例总数、要求的测试时长。任务的执行信息，包括已测试案例数量、已测试时长。执行任务的用户的信息，包括执行任务的测试人员数量。

相应的，所述S402、根据所述预设信息确定所述任务执行过程中的风险，具体可实现为：

S802、根据所述已测试案例数量、已测试时长和所述测试人员数量确定第一值。

可选的，所述已测试案例数量、已测试时长、所述测试人员数量和第一值之间满足如下关系：

S803、若第一值与第一标准值的差值在预设误差范围外，则确定存在测试进度风险。

其中，所述第一标准值根据待测试案例总数、要求的测试时长和所述测试人员数量确定。所述待测试案例总数、要求的测试时长、测试人员数量和第一标准值之间满足如下关系：

若第一值与第一标准值的差值在预设误差范围外，则表明当前任务存在测试进度风险，也即当前的测试进度偏慢，无法在要求的测试时长内完成测试任务，需要加快测试进度，如增加测试人员的数量，或者增加每个测试人员的测试案例的数量等。

示例性的，测试任务包括的测试案例总数100，要求的测试时长为20天，敏捷开发团队投入的测试人员的数量为5个，已测试案例数为80，已测试时长为15天，预设误差范围为-10％～10％，根据这些数据，可以计算得到

第一值与第一标准值的差值为

该误差位于-10％～10％这一误差范围内，因此不存在测试进度风险。

需要说明的是，实际应用中除了测试任务存在进度风险，还存在任务整体进度风险。任务下达后有需求分析、开发、测试三部分，通过标准值1:2:2和任务实施周期来计算出各阶段的时间，如任务周期为25天，则需求分析5天，开发10天，测试10天，通过电子看板系统记录的各阶段的输出信息来判断当前进度是否正常，如需求分析需要输出用户故事，开发需要输出测试版本代码，测试需要输出测试报告。

本申请实施例提供的风险识别方法，当任务为测试任务时，通过任务中包括的待测试案例总数、要求的测试时长和所述测试人员数量确定第一标准值，通过已测试案例数量、已测试时长和测试人员数量确定第一值，并将第一值和第一标准值比较，若第一值与第一标准值的差值在预设误差范围外，则自动识别出该任务存在测试进度风险，无需人工判断或识别该风险，进而提高识别测试进度风险的准确率并节约人力成本。

四、关注度风险

关注度风险是反映用户，例如敏捷开发团队对任务的关注情况，例如：关注度过低，则存在关注度风险。

为了识别关注度风险，需要获取以下信息：用户维护任务的过程中产生的维护信息。

示例性的，对于敏捷开发团队执行的某个任务而言，敏捷开发团队不同角色会在电子看板系统进行数据维护，如敏捷开发团队中的需求人员会维护具体需求，开发人员会维护开发进度以及具体实施内容，测试人员会维护测试进度及测试内容。敏捷开发团队维护的这些内容都可以称之为维护信息。

因此，如图9所示，步骤S401、获取预设信息，可具体实现为：

S901、获取用户维护任务的过程中产生的维护信息。

相应的，所述S402、根据所述预设信息确定所述任务执行过程中的风险，具体可实现为：

S902、根据用户维护任务的过程中产生的维护信息确定第二值。

可选的，所述第二值为每天产生的维护内容条数的平均值。敏捷开发团队每次维护某个任务都对应产生一条维护内容，例如：需求人员维护的一条需求信息可以称之为一条维护内容，类似的，开发人员每次维护的开发进度以及具体实施内容也可以称之为一条维护内容，测试人员每次维护的测试进度以及测试内容也可以称之为一条维护内容。通过计算一段时间内，敏捷开发团队对于该任务的所有维护内容的条数的平均值，得到所述第二值。

可选的，所述第二值为用户维护任务过程中产生的维护内容总条数。如上文所述，敏捷开发团队每次维护某个任务都对应产生一条维护内容，通过计算维护该任务的过程中，敏捷开发团队对于该任务的所有维护内容的总条数，得到所述第二值

S903、若所述第二值小于第二标准值，且与第二标准值的差值大于预设阈值，则确定所述任务存在关注度风险。

可选的，与所述第二值对应，若所述第二值为每天产生的维护内容条数的平均值，则第二标准值为用户在维护目标历史任务的过程中平均每天产生的维护内容条数的平均值，所述目标历史任务为与当前任务相似度满足一定条件的历史任务。

可选的，与所述第二值对应，若所述第二值为预设时间段内产生的维护内容的总条数，则第二标准值为用户在维护目标历史任务的过程中在与预设时间段对应的时间段内产生的维护内容的总条数，所述目标历史任务为与当前任务相似度满足一定条件的历史任务。

如果对于某个任务而言，每天产生的维护内容条数的平均值小于第二标准值，且与第二标准值的差值大于预设阈值，则表明用户对该任务的关注度过低，存在关注度风险，需要提醒敏捷开发团队增加对该任务的关注度，如提醒需求维护人员更新该任务的需求，或者提醒开发人员更新开发进度，或者提醒测试人员更新测试进度等。

上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对上述设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。可选的，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

示例性的，如图10所示，本申请实施例提供一种风险识别装置100，所述装置包括：

获取单元1001，用于获取预设信息，所述预设信息包括以下至少一项：任务的基本信息、执行所述任务的用户的信息、用户维护所述任务的过程中产生的维护信息和所述任务的执行信息。

处理单元1002，用于根据所述获取单元1001预设信息确定所述任务执行过程中的风险。

提示单元1003，用于提示用户所述处理单元1002识别的所述风险。

在一种可能的实现方式中，所述预设信息包括用户维护所述任务的过程中产生的维护信息和所述任务的执行信息；其中，所述维护信息包括用户维护所述任务过程中不同时间点产生的问题的数量；所述任务的执行信息包括执行任务过程中不同时间点产生的问题的数量。

所述处理单元1002，用于：根据从第一时间点至第二时间点产生的问题数量确定累计问题数量随着时间变化是否收敛，若不收敛则确定所述任务存在问题收敛风险。

其中，所述第二时间点晚于所述第一时间点，所述第一时间点至所述第二时间点之间的任意时间点产生的问题数量为执行任务过程中所述任意时间点产生的问题的数量以及用户维护所述任务过程中所述任意时间点产生的问题的数量之和。

在一种可能的实现方式中，所述预设信息包括：所述任务的基本信息和所述执行所述任务的用户的信息；其中，所述任务的基本信息包括任务周期和第一任务工作量；所述执行所述任务的用户的信息包括执行所述任务的用户的数量。

所述处理单元1002，用于：根据所述任务周期和所述执行所述任务的用户的数量，确定第二任务工作量；若所述第二任务工作量与所述第一任务工作量的差值在预设误差范围外，则确定存在周期风险。

示例性的，所述第二任务工作量、任务周期和所述执行所述任务的用户的数量之间满足如下关系：第二任务工作量＝任务周期*执行任务的用户数量。

在一种可能的实现方式中，所述任务为测试任务，所述测试任务包括多个待测试案例；所述预设信息包括：任务的基本信息、执行所述任务的用户的信息和所述任务的执行信息；其中，所述任务的基本信息包括待测试案例总数、要求的测试时长；所述任务的执行信息包括已测试案例数量、已测试时长；所述执行所述任务的用户的信息包括执行所述任务的测试人员数量。

相应的，所述处理单元1002，用于：根据所述已测试案例数量、已测试时长和所述测试人员数量确定第一值；若第一值与第一标准值的差值在预设误差范围外，则确定存在测试进度风险。

示例性的，所述已测试案例数量、已测试时长、所述测试人员数量和第一值之间满足如下关系：

所述待测试案例总数、要求的测试时长、测试人员数量和第一标准值之间满足如下关系：

在一种可能的实现方式中，所述预设信息包括用户维护任务的过程中产生的维护信息；

所述处理单元1002，用于：根据所述用户维护任务的过程中产生的维护信息确定第二值；

若所述第二值小于第二标准值，且与所述第二标准值的差值大于预设阈值，则确定所述任务存在关注度风险。

其中，所述第二值为所述用户维护任务过程中平均每天产生的维护内容条数的平均值，所述第二标准值为用户在维护目标历史任务的过程中平均每天产生的维护内容条数的平均值，所述目标历史任务为与当前任务相似度满足一定条件的历史任务。

或者，所述第二值为所述用户维护任务过程中产生的维护内容总条数；所述第二标准值为用户在维护目标历史任务的过程中产生的维护内容总条数，所述目标历史任务为与当前任务相似度满足一定条件的历史任务。

本申请实施例提供的风险识别装置，通过获取任务的基本信息、执行任务的用户的信息、用户维护任务的过程中产生的维护信息和任务的执行信息，根据获取的这些信息自动化确定任务执行过程中可能存在的风险并提示用户，能够提高风险识别的准确率并节约人力成本。

本申请实施例还提供了一种电子设备，包括：存储器和处理器；该存储器用于存储计算机程序，该处理器用于调用该计算机程序，以执行上文提供的任一实施例中提及的动作或步骤。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当该计算机程序在电子设备上运行时，使得该电子设备执行上文提供的任一实施例中提及的动作或步骤。

本申请实施例还提供了一种芯片。该芯片中集成了用于实现上述风险识别装置的功能的电路和一个或者多个接口。可选的，该芯片支持的功能可以包括基于图4、图5、图7、图8、图9所述的实施例中的处理动作，此处不再赘述。本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可通过程序来指令相关的硬件完成。所述的程序可以存储于一种计算机可读存储介质中。上述提到的存储介质可以是只读存储器，随机接入存储器等。上述处理单元或处理器可以是中央处理器，通用处理器、特定集成电路(applicationspecific integrated circuit，ASIC)、微处理器(digital signal processor，DSP)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。

本申请实施例还提供了一种包含指令的计算机程序产品，当该指令在电子设备上运行时，使得电子设备执行上述实施例中的任意一种方法。该计算机程序产品包括一个或多个计算机指令。在电子设备上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

应注意，本申请实施例提供的上述用于存储计算机指令或者计算机程序的器件，例如但不限于，上述存储器、计算机可读存储介质和通信芯片等，均具有非易失性(non-transitory)。

在实施所要求保护的本申请过程中，本领域技术人员通过查看附图、公开内容、以及所附权利要求书，可理解并实现公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。

尽管结合具体特征及其实施例对本申请进行了描述，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。

Claims (12)

1.一种风险识别方法，其特征在于，由电子设备自动执行，所述方法包括：

获取预设信息，所述预设信息包括以下至少一项：任务的基本信息、执行所述任务的用户的信息、用户维护所述任务的过程中产生的维护信息和所述任务的执行信息；

根据所述预设信息确定所述任务执行过程中的风险；

提示用户所述风险。

2.根据权利要求1所述的风险识别方法，其特征在于，所述预设信息包括用户维护所述任务的过程中产生的维护信息和所述任务的执行信息；其中，所述维护信息包括用户维护所述任务过程中不同时间点产生的问题的数量；所述任务的执行信息包括执行任务过程中不同时间点产生的问题的数量；

所述根据所述预设信息确定所述任务执行过程中的风险，包括：

根据从第一时间点至第二时间点产生的问题数量确定累计问题数量随着时间变化是否收敛，若不收敛则确定所述任务存在问题收敛风险；

其中，所述第二时间点晚于所述第一时间点，所述第一时间点至所述第二时间点之间的任意时间点产生的问题数量为执行任务过程中所述任意时间点产生的问题的数量以及用户维护所述任务过程中所述任意时间点产生的问题的数量之和。

3.根据权利要求1所述的风险识别方法，其特征在于，所述预设信息包括：所述任务的基本信息和所述执行所述任务的用户的信息；其中，所述任务的基本信息包括任务周期和第一任务工作量；所述执行所述任务的用户的信息包括执行所述任务的用户的数量；

所述根据所述预设信息确定所述任务执行过程中的风险，包括：

根据所述任务周期和所述执行所述任务的用户的数量，确定第二任务工作量；

若所述第二任务工作量与所述第一任务工作量的差值在预设误差范围外，则确定存在周期风险。

4.根据权利要求3所述的风险识别方法，其特征在于，所述第二任务工作量、任务周期和所述执行所述任务的用户的数量之间满足如下关系：

第二任务工作量＝任务周期*执行任务的用户数量。

5.根据权利要求1所述的风险识别方法，其特征在于，所述任务为测试任务，所述测试任务包括多个待测试案例；所述预设信息包括：任务的基本信息、执行所述任务的用户的信息和所述任务的执行信息；其中，所述任务的基本信息包括待测试案例总数、要求的测试时长；所述任务的执行信息包括已测试案例数量、已测试时长；所述执行所述任务的用户的信息包括执行所述任务的测试人员数量；

所述根据所述预设信息确定所述任务执行过程中的风险，包括：

根据所述已测试案例数量、已测试时长和所述测试人员数量确定第一值；

若第一值与第一标准值的差值在预设误差范围外，则确定存在测试进度风险。

6.根据权利要求5所述的风险识别方法，其特征在于，所述已测试案例数量、已测试时长、所述测试人员数量和第一值之间满足如下关系：

所述待测试案例总数、要求的测试时长、测试人员数量和第一标准值之间满足如下关系：

7.根据权利要求1所述的风险识别方法，其特征在于，所述预设信息包括用户维护任务的过程中产生的维护信息；

所述根据所述预设信息确定所述任务执行过程中的风险，包括：

根据所述用户维护任务的过程中产生的维护信息确定第二值；

若所述第二值小于第二标准值，且与所述第二标准值的差值大于预设阈值，则确定所述任务存在关注度风险；

其中，所述第二值为所述用户维护任务过程中平均每天产生的维护内容条数的平均值，所述第二标准值为用户在维护目标历史任务的过程中平均每天产生的维护内容条数的平均值，所述目标历史任务为与当前任务相似度满足一定条件的历史任务；

或者，

所述第二值为所述用户维护任务过程中产生的维护内容总条数；所述第二标准值为用户在维护目标历史任务的过程中产生的维护内容总条数，所述目标历史任务为与当前任务相似度满足一定条件的历史任务。

8.一种风险识别装置，其特征在于，包括：

获取单元，用于获取预设信息，所述预设信息包括以下至少一项：任务的基本信息、执行所述任务的用户的信息、用户维护所述任务的过程中产生的维护信息和所述任务的执行信息；其中，所述任务的基本信息、执行所述任务的用户信息和用户维护所述任务的过程中产生的维护信息从电子看板系统自动获取；所述任务的执行信息从测试管理平台自动获取；

处理单元，用于根据所述获取单元获取的所述预设信息确定所述任务执行过程中的风险；

提示单元，用于提示用户所述处理单元识别的风险。

9.根据权利要求8所述的风险识别装置，其特征在于，所述预设信息包括用户维护所述任务的过程中产生的维护信息和所述任务的执行信息；其中，所述维护信息包括用户维护所述任务过程中不同时间点产生的问题的数量；所述任务的执行信息包括执行任务过程中不同时间点产生的问题的数量；

所述处理单元，具体用于根据从第一时间点至第二时间点产生的问题数量确定累计问题数量随着时间变化是否收敛，若不收敛则确定所述任务存在问题收敛风险；

其中，所述第二时间点晚于所述第一时间点，所述第一时间点至所述第二时间点之间的任意时间点产生的问题数量为执行任务过程中所述任意时间点产生的问题的数量以及用户维护所述任务过程中所述任意时间点产生的问题的数量之和。

10.根据权利要求8所述的风险识别装置，其特征在于，所述预设信息包括用户维护任务的过程中产生的维护信息；

所述处理单元，具体用于根据所述用户维护任务的过程中产生的维护信息确定第二值；

若所述第二值小于第二标准值，且与所述第二标准值的差值大于预设阈值，则确定所述任务存在关注度风险；

其中，所述第二值为所述用户维护任务过程中平均每天产生的维护内容条数的平均值，所述第二标准值为用户在维护目标历史任务的过程中平均每天产生的维护内容条数的平均值，所述目标历史任务为与当前任务相似度满足一定条件的历史任务；

或者，

所述第二值为所述用户维护任务过程中产生的维护内容总条数；所述第二标准值为用户在维护目标历史任务的过程中产生的维护内容总条数，所述目标历史任务为与当前任务相似度满足一定条件的历史任务。

11.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机指令，所述处理器用于执行所述计算机指令，以执行权利要求1-7中任意一项所述的方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行权利要求1-7中任意一项所述的方法。

Images