1  15后新版本禅道的安装升级
2  15后新版本禅道的新增功能
3  15后新版本禅道的界面变化
4  15后新版本禅道的最简使用
5. 15后新版本禅道的基本使用
5.1  新手引导
5.2  全局添加
5.3  接口库
5.4  配置飞书内的禅道单点登录
6. 按照角色使用15后版本禅道
6.1. 管理员
6.1.1  维护组织部门
6.1.2  维护用户
6.1.3  维护权限
6.2. 项目集负责人
6.2.1  创建项目集
6.2.2  添加产品
6.2.3  创建项目
6.2.4  管理人员
6.2.5  添加干系人
6.3. 产品经理
6.3.1  创建产品
6.3.2  维护模块
6.3.3  产品多分支/平台管理
6.3.4  维护计划
6.3.5  维护需求
6.3.6  需求的评审
6.3.7  创建发布
6.3.8  跟踪进度
6.4. 项目经理
6.4.1  维护项目和执行
6.4.2  维护团队
6.4.3  关联需求
6.4.4  分解任务
6.4.5  跟踪进度
6.4.6  瀑布项目的使用
6.4.7  看板项目的使用
6.5. 研发人员
6.5.1  参加产品计划会议,分解任务
6.5.2  领取任务,并每天更新任务
6.5.3  创建版本,提交测试
6.5.4  确认Bug,解决Bug
6.5.5  执行的综合、需求、Bug、任务看板
6.6. 测试人员
6.6.1  撰写用例
6.6.2  执行用例
6.6.3  提交Bug
6.6.4  验证和关闭BUG
7. DevOps 功能
7.1  Git/SVN版本库管理和查看代码
7.2. 集成GitLab
7.2.1  绑定用户,关联issue,进行构建
7.2.2  合并请求
7.2.3  禅道中GitLab的权限
7.3  集成Jenkins,进行构建
7.4  集成SonarQube
8  通用看板功能
9. 后台设置
9.1  集成禅道客户端
9.2  模型
9.3  自定义
9.4. 通知
9.4.1  邮件
9.4.2  Webhook
9.4.3  浏览器
9.4.4  设置
9.5  插件
9.6  二次开发
9.7  系统
9.8  导入Jira数据
9.9  登记菜单和权限
10. 权限维护和访问控制
10.1  项目集的权限维护和访问控制
10.2  产品的权限维护和访问控制
10.3  项目的权限维护和访问控制
10.4  执行的权限维护和访问控制
10.5  项目和执行的访问控制和数据关系

需求的评审

2022-01-03 13:26:05
先知
3647
最后编辑:LuLu 于 2022-04-02 10:46:15
分享链接

在创建需求的时候,有一个"不需要评审"的复选框,如果选中该复选框的话,需求的创建成功后状态是激活的。

但大部分情况下面,需求还是需要评审的。

  • 即使产品完全由一个人负责,也可以将一些不成熟的想法存为草稿,后续再进行处理。
  • 开发、测试在实际开发、测试工作中,根据具体的工作会发现一些需要优化的需求,他们提交的新需求需要评审。
  • 技术支持在和用户客户对接时,会从用户客户那获取一些新需求,他们提交的新需求也是需要评审的。
  • 凡是对需求标题、描述、验证标准和附件的修改,都应该走变更流程。变更之后的需求状态为已变更,也是需要进行评审的。

产品经理在禅道中如何评审需求,可以观看视频了解: https://www.zentao.net/redirect-index-20677.html



本文档我们将介绍需求的评审流程和方式。

一、需求评审的规则、流程、结果

需求的评审规则、流程、结果,我们可以在后台--自定义--需求里查看和设置。

评审规则:

评审结果:

评审的流程:
默认是开启评审流程的,不管是开启评审还是关闭评审流程时,可以设置强制评审。
强制评审中的成员,提交的需求,都必须走评审流程。

二、需求的评审人

创建和编辑产品时,我们新增了产品评审人的字段。

设置了产品评审人,那么在该产品下创建需求、变更需求时,需要评审时,默认的评审人就是设置的产品评审人。

评审人可以设置1人也可以设置多人。

设置好了评审人后,创建需求和批量创建需求时,由谁评审的下拉列表就只显示设置的评审人。


变更需求时,由谁评审也默认列出设置的评审人。

三、需求的超级评审人

禅道16.0版本开始新增了超级评审人功能。
超级评审人不受任何评审规则的限制,超级评审人有一票否决权。

超级评审人和评审人一样可以设置多人。

在后台--自定义--评审规则--超级评审人里,可以设置我们的超级评审人。

即便该需求之前由多人评审,且其中某一个评审人已评审拒绝,但是当超级评审人去评审该需求时,

不受之前的评审规则限制,最后都以超级评审人的评审结果为本轮需求评审的最终结果。

需求的历史记录也会记录超级评审人评审的时间、评审意见 以及结果。

四、需求的多人评审

需求在创建和变更时,由谁评审可以选择多人。之前只能由一人评审,现在可以实现多人评审一个需求。

多人评审需求时,设置了评审规则。需求是否评审通过根据评审规则和实际评审人的评审结果进行计算,最终得出需求的评审结果。

4.1 设置评审规则

评审规则可以到后台--自定义--需求--评审规则里进行选择。
我们提供两种规则:评审结果全部通过时该需求为评审通过(全部通过通过);评审结果半数以上通过时该需求为评审通过(半数以上通过通过)。

4.2 创建需求时的多人评审

单个创建和批量创建需求时,由谁评审可以选择多人评审。
单个创建需求时:

批量创建需求时:

成功创建多人评审的需求后,需求的状态为草稿。
当所有评审人都评审完成后,根据评审规则计算结果后,根据结果来判断是否需要更改需求的状态。

4.3 变更需求时的多人评审

变更需求时,也可以选择多人进行评审。

变更后的需求状态变为已变更,
当所有评审人都评审完成后,根据评审规则计算结果后,根据结果来判断是否需要更改需求的状态。

4.4  评审人评审需求,根据评审规则计算评审结果

多人评审的需求,由谁评审可以在需求详情页的需求的一生里查看到。

已评审的人员是置灰,鼠标悬停时提示为已评审,未评审的人员鼠标悬停时提示待评审。

接下来我们以3人评审一个需求为例,根据不同的评审规则来看需求的多人评审。

4.4.1 当评审规则为:全部通过通过

当三个人的评审结果都为确认通过时,根据评审规则计算,该需求的评审结果为确认通过,状态改变为激活。

当2个人的评审结果为确认通过,1人的评审结果为有待明确时,根据评审规则计算需求评审结果为评审不通过,依旧保持为草稿状态。

4.4.2 当评审规则为:半数以上通过通过

以下需求由3个人评审,2人评审结果为确认通过,1人评审结果为拒绝。

根据规则计算,系统判定该条需求的评审结果为确认通过,需求状态由草稿变为激活。

当2人的评审结果是不通过,1人的评审结果时通过,系统判定评审结果为不通过,需求的状态依旧保持是草稿。

4.4.3 其他情况
如果3人评审时,1人已评审,再编辑需求,删除掉剩下的2位评审人。
那么需求会根据已评审的的1人的评审结果就是该需求最后评审的结果。

五、需求的撤销评审

需求发起评审后,如果发现还有需求标题、描述、验收标准和附件还需求修改。

为了避免进行多轮次的评审。
我们提供了撤销评审功能,首先需要去后台--人员--权限的权限分组里分配撤销评审的权限。

在产品--需求列表中发起评审的需求的操作栏里显示撤销按钮。

点击撤销评审按钮后,评审和撤销评审按钮置灰。

需要重新变更,发起评审后,才可以继续进入评审流程。

需求的历史记录中会记录撤销评审和重新变更发起评审的历史信息。

方便进行操作的追溯和查看。

发表评论
评论通过审核后显示。