如何使用云效中的工作项规则配置_云效（老版）-阿里云帮助中心

工作项

需求、缺陷、任务统称为工作项，代表项目中需要处理的具体事务。

工作项工作流

需求状态：待处理 > 处理中 > 已完成 > 已取消（用户可自行配置）

任务状态：待处理 > 处理中 > 已完成 > 已取消（用户可自行配置）

缺陷状态：淘宝采用的缺陷生命周期模型从2008年就确定了，并且没有变化，状态如下：

New: 新增加的、需要解决的BUG。

Open: 正在定位问题，或正在解决中，或已经解决但未部署生效。

reopen：重新打开、激活，需要解决的BUG。

Fixed: BUG已经解决，并且修改后程序已部署生效。

Closed: 验证后，此BUG可以关闭。

Reopen: 此BUG需要再解决。

Later: 此BUG不在本项目的工作范围内，在后续版本中修复。

Worksforme: 不能在当前环境中重现。

Duplicate:和其它BUG描述现象重复。可以配置选择Duplicate状态时必填关联的缺陷ID。

Invalid: 属于测试人员对测试需求的理解错误。

External: 问题是由其他外部的原因引起，需要由外部处理。

ByDesign：属于按照产品设计实现，不是问题。

Wont’fix：问题确实出现过，但是由于产品改动已经修复或者功能废弃，问题目前已不需要解决

缺陷的状态精简一下分为三类：待处理、已处理、已关闭。我们为了细化区分这三大类，人为地增加了状态。状态其实应该是这样的一个级联分类：

待处理：New、Open、Reopen

已处理：Fixed，Wont’fix，Later，Worksforme，Duplicate，Invalid，External，ByDesign

已关闭：Closed

已处理中的8个状态都可以视为问题处理人对此问题的处理意见。我们暂且叫它为：解决方案。

有效BUG：

1、解决方案为 Duplicate、Invalid、ByDesign的BUG是无效BUG，其余情况均为有效BUG（New、Open、Reopen、Fixed、Wont’fix、Later，Worksforme、External）;

2、如果一个BUG被Reopen多次，则以最后一次的解决方案来判断是否是有效bug。

经过以上调整，我们就有了以下规则：

1、所有缺陷最终都应该由缺陷验证者或者与之平级权限的人变更到Closed状态。非Closed状态的都被认为是活动的缺陷。

2、解决者可以将“待处理”状态的缺陷置为任意“已处理”状态。

状态流转图如下图：

再用文字来解释一下上图的一个经典流程：

1、测试（验证者）发现了问题。提交一个问题。（状态为New)

2、开发（解决者）去解决。先Open或者直接选择一个解决方案。

3、测试通过就关闭它。如果验证后不正确，那就Reopen。再返回到步骤2。

工作项跟进的过程中，常常遇到一些流程跟进的问题。例如，你可能苦恼于需求状态总是更新不及时，数据统计不准确；你可能苦恼于制定的流程规约难以落地，例如需求评审通过后要记录一堆字段，有的需要指给开发，有的需要进行第二次评审等。

为了将大家从手动更新工作项的痛苦中解救出来，云效上线了流程自动化功能。让你可以专注于需求评审、专注于代码开发、专注于变更发布。需求状态将会随着你的行为自动进入待评审、开发中、已完成等状态。流程更加智能，统计数据也能更加准确啦！

我们通过规则配置来实现工作项流程自动化。
我们提供了需求开发过程中的几个关键事件：需求发起评审、需求评审通过、工作项关联了变更、工作项关联的变更全部发布上线。
我们提供了一些可自动执行的操作：状态自动变更、弹窗填写属性、属性自动变更。
通过自由组合事件和操作，可以配置出想要的自动化流程。
可支持如下场景：
1. 需求发起评审时，状态自动变为评审中。
2. 需求评审通过时，状态自动变为评审通过，并自动指派给开发TL。
3. 需求关联了变更时，状态自动变为开发中。
4. 需求关联的变更全部发布后，状态自动变为已完成。
此外，我们还提供了两条系统默认的规则：父工作项完成时自动关闭子工作项；子工作项完成时自动关闭父工作项。
规则默认是继承自父项目，如果想要自己配置，打开自主配置开关即可。