谈研发过程管理关键功能和对象(12.24)

这篇文章谈下如果我们要新开发一个配合DevOps平台使用的研发过程管理模块，那么需要具备的一些关键功能和关键对象分析，在前面DevOps和外围协同的时候我们也讲到，DevOps平台可以和类似禅道等研发项目管理平台进行对接，实现研发项目和过程管理，而如果全新开发一个子模块可以理解为禅道功能的一个裁剪。

我们首先来看下华为云的DevOps平台提供的关于研发管理能力

参考： https://support.huaweicloud.com/qs-devcloud/devcloud_qs_0202.html

可以看到，里面的核心对象包括了项目，需求，任务，迭代几个个关键要素。即首先进行项目规划，然后录入需求，对录入的需求进行拆分，细化到细粒度的用户故事，然后对用户故事进行拆分为具体的任务。同时一个项目可以规划多个迭代，这个迭代则映射到具体的项目版本，同时将具体的需求或任务添加到不同的项目版本中。整个思路基本和scrum敏捷方法论一致，也体现了关键的对象间的协同。

整个概念里面暂时没有看到产品的概念，也没有看到对变更和缺陷等的管理。

我们再来看下另外一个敏捷开发项目管理平台ones.ai提供的功能

参考： https://ones.ai/index.html

由于这个平台本身就是一个敏捷研发管理平台，因此功能来说相对更全。其中项目管理部分包括了产品管理，项目管理，需求管理，任务管理，迭代管理和缺陷管理。

整个逻辑仍然是scrum敏捷方法论的思路，创建产品版本，规划具体的迭代版本，将多个迭代关联到具体的产品版本上面。同时录入具体的需求，对需求进行拆分，将需求关联到具体的迭代版本上。同时需求还可以和具体的测试用例管理，需求本身还可以进行任务拆分。

整个平台重点是增强了测试管理，缺陷管理方面的能力。同时增加了产品版本的概念。产品版本和迭代版本是两个完全独立的对象并相互关联。同时在该平台还增加了项目集功能，可以将多个项目规划到一个项目集中进行统一的管理和跟踪。

关键对象和关系分析

对于研发过程管理，可以看到关键对象包括产品，项目，项目集，迭代版本，需求，任务，测试用例，缺陷，项目团队，这也是敏捷项目管理的核心业务对象。

产品一般指我们标准化的产品研发，产品本身也会有版本，但是产品版本如何升级，同样是需要规划的研发项目，在研发完成后进行了产品版本升级。因此项目既包括了对内的研发项目，也包括了对外客户的项目。基于一个标准产品我们会接很大对外项目，很可能都涉及到定制。

比如我们接到中国移动的项目，基于我们标准产品进行定制，那么这个时候首先要建立中国移动这个项目，项目和产品之间建立关联。项目本身最好还有大版本和小版本的概念，项目的小版本对应到具体的迭代版本。录入具体的需求，在需求录入完成后开始规划迭代版本，将具体的需求规划到迭代版本中。同时迭代版本本身属于一个项目或项目大版本。

通过前面几个步骤基本的产品，项目，需求，版本间的关系已经建立，接着重点就是具体的工作和任务。

对应需求可以拆分为多个任务，当然任务是独立的独立，可以关联到具体的需求，也可以独立存在不关联到需求。在任务创建完成后需要确定任务的开始完成时间，工作量评估，然后进入到具体的任务跟踪。

整个scrum是需求和用户故事驱动，因此需求录入完成后，需要基于需求进行测试用例的编写，一个需求可以对应多个测试用例，然后在开发完成后基于测试用例进行测试发现缺陷，那么缺陷自然关联到测试用例，同时也关联到具体的需求。

一个客户项目往往可能涉及到我们多个产品，因此一个客户项目最好规划为一个项目集，即将多个项目版本纳入到一个项目集中进行管理。这样后续分析的时候可以从项目集维度进行统一的分析和度量。

所有上面的对应后面都会方面我们进行研发过程度量分析使用。

关键功能和差异分析

首先项目和项目版本的概念分离，即项目版本即对应到迭代版本或迭代这个对象上面。

一个产品可以对应多个项目，项目可以是内部研发项目，客户是我们自己，也可以是外部项目对应具体的客户。当是内部研发项目的时候，研发完成后往往升级产品版本。

项目创建的时候重点是给出项目的执行周期，项目对应的客户，项目对应的产品，项目中的团队成员等关键信息。在项目规划完成后，规划具体的项目版本，比如南方电网ESB项目V0.1版本，南方电网ESB项目V0.2版本，

具体的需求注意不挂接在项目下面，而是必须挂接到项目版本下面。

对于版本启用大版本和小版本，注意大版本是可以直接发到客户的版本，小版本为内部版本，当然小版本还可以规划为小版本和迭代版本两个版本段。

我们来看下具体的场景，当前已经有了标准的ESB V1.0产品版本，当我们接到南方电网ESB项目后，我们首先要录入南网ESB项目，同时录入一个V0.1项目版本。然后我们将需求先录入到产品下面，录入到产品下面的意思就是一个需求可以规划到该产品下面不同的项目版本中。

我们来分析下，如果录入了20个需求点，其中5个是标准化产品需求，15个为定制需求，同时15个定制需求我们准备分三个迭代版本来进行实现。基于上面这个场景，具体操作应该是：

1. 选择ESB产品，在产品中录入具体的15个已经拆分后的需求功能点

2. 新创建研发项目V0.1版本，新创建南网项目V0.1, 0.2和0.3版本

3. 分别将上面的20个需求纳入到具体的四个项目版本中

4. 对于南网项目单独拉一个分支，同时注意对于研发项目版本的修改需要merge到南网项目分支上

这个梳理清楚后，我们再来看关键的需求到任务的关系。

我们举个简单的例子来看，服务实例查询是一个独立的需求功能点，那么针对这个功能点就需要拆分任务，在这里我们建议增加一个批量添加任务的功能，即针对一个需求功能点，往往存在需求，设计，编码，测试设计，测试执行，或者开发会进一步分为前端开发，后端开发。我们只需要选择存在哪些步骤，然后基于这些步骤来自动创建相应的任务名称。同时任务和人员有匹配，如果任务类型在该项目下只有一个该类型人员，则可以直接将任务默认安排到该人员。即实际可能拆分完成后为：

服务实例查询-需求开发 — 张三

服务实例查询-编码 — 李四

服务实例查询-测试用例编写 — 王五

服务实例查询-测试执行 — 王五

我们再来看下scrum里面的敏捷看板管理，一种最简单的方法就是userstory，todo, doing, done几个关键状态进行管理，而实际上我们可以进行更细化的开发过程状态跟踪。即需求故事，待开发（任务清单），开发中，测试中，完成几个关键状态。

即我们可以设计为在编码任务，团队人员领取任务后即进入中开发中状态，在开发人员反馈任务完成的时候直接进入到测试中状态，在测试人员反馈测试执行任务完成后进入到已完成状态。跨泳道流转的主体为userStory。

测试人员具体具体的用户故事点进行测试，测试发现的缺陷录入到缺陷管理模块中，缺陷自然挂接到具体的需求，同时能够关联到具体的项目和项目版本。方便我们后面进行质量分析和项目度量。