禅道项目管理系统操作规范V103.docx

上传人:b****5 文档编号:6723050 上传时间:2023-01-09 格式:DOCX 页数:23 大小:1.09MB
下载 相关 举报
禅道项目管理系统操作规范V103.docx_第1页
第1页 / 共23页
禅道项目管理系统操作规范V103.docx_第2页
第2页 / 共23页
禅道项目管理系统操作规范V103.docx_第3页
第3页 / 共23页
禅道项目管理系统操作规范V103.docx_第4页
第4页 / 共23页
禅道项目管理系统操作规范V103.docx_第5页
第5页 / 共23页
点击查看更多>>
下载资源
资源描述

禅道项目管理系统操作规范V103.docx

《禅道项目管理系统操作规范V103.docx》由会员分享,可在线阅读,更多相关《禅道项目管理系统操作规范V103.docx(23页珍藏版)》请在冰豆网上搜索。

禅道项目管理系统操作规范V103.docx

禅道项目管理系统操作规范V103

项目管理系统(禅道)操作规范V1.0

编写人:

审核人:

前言

本规范用于公司使用禅道管理系统时的操作规范,明确各个角色按照本规范对项目管理进行操作和录入.实现公司项目组在项目、产品、研发、测试上的统一管理。

适用范围:

大研发体系各项目组

项目侧

一、创建项目

Ø项目副组长角色进入项目视图,点击右侧的”添加项目“链接。

图1

Ø项目添加的页面

项目副组长需要在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目、项目描述和关联产品,访问权限。

图2

注意事项:

●项目代号是一种隐喻,最终以合同号为准。

●团队名称,可以自己定义,比如叫做“XX开发团队”等等。

●在添加项目的时候,选择关联与之相关的产品,以便后续进行需求的关联。

●项目可以控制它的访问权限,分为默认、私有和自定义白名单三种。

二、组建团队

Ø项目组建之后要做的事情就是设置团队

图3

Ø进入团队管理页面

项目副组长需在“用户”列指定组建的项目团队成员,角色列可自定义也可用该用户的默认角色,并且需补充每个用户的可用工日和每天的可用工时。

图4

注意事项:

可用工作日和可用工时每天需要仔细设置。

通常来讲,一个人不可能每天8小时投入,也不可能一星期七天连续投入。

三、关联需求

Ø项目团队组建完毕之后,接下来产品经理角色要做的一个工作就是确定这期项目要做的需求,也就是关联需求。

图5

进入需求关联页面后,选择项目需要的需求并保存。

图6

四、需求分解:

关联需求确认之后,项目副组长或者研发经理的角色就需对关联的需求进行分解,分解成一个或多个任务。

分解时应完善所属模块、指派人、任务类型、相关需求、任务名称、任务描述、优先级、抄送给。

图7

注意事项:

●任务的分解由团队共同完成,因此需要进行线下讨论。

●需要将所有的需求都分解出来。

这里面包括设计,开发,测试,界面、研究、讨论、事务、和其他。

●要求任务分解时粒度越小越好,比如几个小时就可以完成。

●如果一个任务需要多个人负责,需继续考虑将其拆分。

●任务的类型需仔细设置,这个会涉及到需求研发阶段的自动计算。

●任务的分配由线下讨论后进行分配确认,这样可以最大程度上保证分配的准确性。

五、创建版本:

Ø项目需求分解之后,进入设计和开发阶段,开发完成后项目副组长或研发经理确认版本并创建版本,该版本为第一次的build和根据bug及新需求变动而创建的多个版本。

Ø创建版本需要设置对应的产品、产品名称编号、构建者、build打包日期、源代码地址、下载地址、上传发行包、并根据完成的需求或bug,选择对应的相关需求和相关bug、版本描述。

图8

六、提交测试:

Ø版本创建完成后,项目副组长或者研发经理根据项目初期定义的周期定时将版本提交测试.在创建的版本中点击”+”提交测试。

图9

Ø进入提交测试管理页面.需要设置提交测试的所属产品、所属项目、版本、负责人、优先级、起止日期、当前状态、任务名称、任务描述。

图10

七、文档管理

项目组成员在项目启动后,需将线下讨论的一些跟项目相关的需求和技术资料上传到禅道当中,以便项目成员传阅,文档可以是文件、链接和网页形式。

图11

八、项目维护

项目创建后,项目副组长角色根据项目完成情况,可以在维护当中选择开始、延期、挂起、结束、编辑几个按钮来维护项目。

但在维护过程中,若有变动,还需通过线下进行通知相关负责人。

图12

产品侧

一、创建产品

1.用项目副组长的角色登录禅道。

2.进入产品视图,然后点击页面右侧的“添加产品”链接,即可出现新增产品的页面。

3.如果系统中还没有添加产品,系统也会自动跳转到产品的添加页面。

图1

添加产品时,必须完善以下几项:

●产品名称,由项目副组长填写,属必填项.

●产品代号,相当于大家对这个产品的一个隐喻,可理解是产品名称的一个简称,是唯一的标识,属必填项.

●产品负责人,默认由项目副组长负责,负责整理和解释整个产品的需求,制定相应的发布计划,必填。

●测试负责人,项目副组长指定测试负责人,该项也可在项目正式立项后补充修改。

●发布负责人,由项目副组长牵头负责。

●产品描述,需对添加的产品加以简单描述,说明产品的背景.

●访问控制,要求设为私有或者自定义白名单权限.

二、创建需求

1.使用产品经理角色登陆,并且该角色应为该产品所在项目组成员.

2.进入产品视图。

3.在页面右侧,有“提需求”菜单,点击菜单,出现新增需求的页面。

图2

添加需求,要完善以下几项:

●所属产品,需明确当前添加需求是缩归属的产品,默认为当前产品的主模块

●来源,产品经理必须明确需求是从何种途径获取的.

●需求名称,需用简单的一句关键语句概括需求内容,尽量不不产生二义性,便于大家理解,属必填项.规则?

●需求描述,需对所提需求进行详细的描述,做到有层次,内容简洁凝练.

●验收标准,必须将需求中要实现的功能和要求罗列出来,作为产品需求的验收标准.

●优先级,必须为所提需求区分优先级.

●预计工时,也就是对这个需求做一下估计,完成大约需要多少小时,估计不准也没有关系,关键是在这个过程。

以避免产品经理不经过思考,随意添加需求的情况

●由谁评审,要求每个新需求都需评审,评审人由项目副组长牵头负责.

三、评审需求

在创建需求的时候,需求是必须评审的。

即使产品完全有一个人负责,也应该将需求存为草稿,后续再进行处理。

图3

评审需要完善以下项:

●评审时间,指明需求评审的时间.

●评审结果可以选择确认通过、有待明确、拒绝等操作。

如果选择“确认通过”,则需求的状态改为“激活中”,然后就可以关联到项目中进行开发了。

●如果选择“有待明确”,会保持需求的草稿状态,并将需求指派回需求的创建者头上,有其继续进行完善。

●如果选择了“拒绝”,则需要给出相应的拒绝原因,拒绝原因可以有:

图4

●由谁评审是记录的参与评审的人员名单,可以输入用户名来自动筛选。

一般来讲需求评审可以是一个线下的评审会议,在禅道里面记录下参与需求评审的人员即可。

四、变更需求

当产品经理需要变更需求时,点击变更按钮进入需求界面,并且变更时,必须完善“由谁评审”和“备注”两项,指明评审人和变更说明。

图5

图6

五、添加产品模块

添加完产品之后,就需要来设置产品的模块。

模块相当于对产品需求的一个分类,通过组织模块,可以让大家对产品有一个宏观的把握和认识,也方便对需求进行分类和整理。

设置模块的步骤:

1.使用产品经理角色进入产品视图。

2.选择要维护的产品。

3.点击菜单中的“模块”。

图7

添加模块,需要完善以下项:

●维护模块的时候是一级级进行维护的。

比如可以选择"我的地盘",然后维护它的子模块。

●左侧的数字是用来排序的,可以将通过调整模块的排序字段来调整它在模块树里面的位置。

●可以选择某一个模块编辑,编辑的时候可以修改它所属的上级模块。

六、文档

产品经理添加完需求后,由项目组成员将线下讨论以及相关产品的一些资料(比如需求文档)上传至文档管理模块当中,以便相关成员阅读和了解产品,在产品视图,点击页面右侧的“创建文档”,即可进入文档的创建页面.

图8

说明:

●文档共有文件、链接和网页三种类型。

●文件类型的文档可以上传一个附件。

●链接类型的文档可以是一个网页链接。

●网页型的文档可以直接使用富文本编辑器撰写。

七、建立计划

在需求建立并评审之后,应该建立一个计划,对于项目副组长自己而言,计划可以帮助他规划产品,制定发布的节奏,调整需求的优先级。

对于公司其他部门的同事以及外部的客户而言,发布计划可以让他们知晓产品的进展情况,以便做好相应的安排。

同时在项目关联需求的时候,计划可以帮助需求的关联。

关联

操作步骤:

1.进入产品视图,选择某一个产品。

2.点击“计划列表”

3.出现计划列表页面,点击页面右侧的“创建计划”,即可出现计划增加页面,并需要完善计划的名称、起止日期,并对计划进行概要性的描述。

图9

八、发布

项目结束后项目副组长的一个工作就是创建发布,通过创建发布,可以告诉公司其他相关的部门,他们可以在新版本产品的基础上开展工作。

同时也是鼓舞团队士气非常好的一个手段。

创建发布有两个前提:

1.该产品有关联过项目。

2.该项目有创建过版本。

操作步骤:

1.进入产品视图,选择发布列表。

2.然后点击“创建发布”,即可出现创建发布的页面,需要完善发布名称、版本、发布日期、选择相关需求和相关bug。

图10

●选择了版本之后,系统会自动计算这个版本所对应的项目中完成的需求和解决的bug,可以进行关联选择。

●如果系统自动计算的需求和bug不完整,需在描述字段里面补充。

开发侧

一、参加项目计划会议,领取分解任务

项目团队成员要参加产品的计划会议和项目的任务分解。

参加产品计划会议的时候,应当充分理解需求,并发表自己的意见,以确保自己对每一个需求理解都是正确的。

二、领取任务,并每天更新任务

研发经理指派给项目团队成员任务后,各成员开始每天的开发。

除了日常的编码工作之外,还应当每天花点时间在禅道里面更新下任务的状态以及消耗情况。

Ø领取任务

领取任务可以通过两种方式,一种是通过“指派”操作,一种是通过“编辑”操作。

如图1

图1

Ø更新任务状态和消耗

项目开始之后,每个人每天应当及时更新自己所负责的任务的状态。

禅道提供了几个快捷的操作按钮:

开始、完成、关闭、取消和激活,如图2。

禅道有一个可选流程,就是当任务完成之后,会自动指派回任务的创建者头上,这时候任务的创建者可以验证任务是否完成。

如果完成,则将任务关闭。

如果任务没有完成,则激活任务。

图2

除了更新自己负责任务的状态之外,还应该及时更新任务的工时消耗情况。

点击工时按钮,弹出记录工时页面,如图3。

图3

注意事项:

●日期、工时、剩余工时、备注需要认真填写,以便记录工作情况。

三、确认bug,解决bug

Ø确认bug

当测试人员提交了bug之后,开发人员需要及时查看并确认bug(一个工作日内),给测试人员一个反馈。

注意事项:

●优先级可确认bug解决的先后顺序。

●如果是1、2级的Bug或是遗留Bug备注中可从开发角度说明bug情况及解决难度时间等。

Ø解决bug

开发人员处理自己负责的bug后,在禅道中登记解决方案。

在项目视图中的bug列表,可对bug进行确认、指派、解决操作,如图4。

图4

在bug详情页面也可进行相关操作,如图5。

图5

解决bug的时候,需要填写bug的解决方案、解决版本,在备注栏说明详细情况,如:

如果是重复Bug需要填写重复的Bug号,如果是不予解决的Bug需要在备注栏说明原因,如果是已解决的Bug需要详细说明解决方案及影响范围并指派给相关人员,如图6。

图6

 

测试侧

一、创建测试用例

进入测试视图的“用例”,点击页面右侧的"建用例",即可进入建用例页面。

如图15

图15

注意事项:

●用例的适用阶段,指在哪些个测试阶段,可以用上这个用例。

可以进行多选。

●用例步骤可以非常方便在之后插入,之前插入,或者删除当前的步骤。

●不要把若干个测试用例作为步骤写到一个测试用例里面,预期结果不能有多个,因为这样不利于测试的管理和统计。

●相关需求必须选择,这样可以将用例和需求关联起来,执行用例后,需要关联bug,以便以后的统计分析。

●用例标题名规则:

以子模块+测试功能点命名。

二、执行用例

在测试视图中的用例列表,可对用例进行执行、查看结果、编辑、复制、提bug操作,如图16。

图16

点击执行按钮,弹出执行页面,选择测试结果后点击保存按钮可保存用例执行结果,如图17。

图17

注意事项:

●如果一个用例执行失败,点击提bug按钮,可以直接由这个测试用例创建一个bug,而且其重现步骤会自动拼装

●测试结果为N\A、阻塞、失败时,需要在实际情况中说明原因。

三、评审用例

当测试人员完成测试用例的编写后,需要在线下组织项目组人员评审用例,评审会议过后可点击编辑按钮按照评审结果修改用例。

注意事项:

●用例评审后按照评审结果修改用例,修改完成后需要再次通知相关人员查看用例。

四、管理测试任务

当开发人员申请测试之后,会生成相应的测试任务给测试人员。

测试人员要做的就是为这个测试任务关联相应的测试用例。

如果这个测试任务需要多人来配合完成,则需要将相应的用例指派给相应的人员来进行完成,或者自己领取相应的测试用例。

在测试视图中的测试任务列表,可对测试任务进行查看关联用例、关联用例、编辑操作,如图18。

图18

点击关联用例按钮,进入关联用例页面,如图19

图19

说明:

1、测试用例可以通过上面的搜索表单进行搜索。

2、用例默认是关联最新的版本,也可以点击下载框,选择之前的版本。

3、可以按照需求或者bug来进行检索。

在测试视图中的测试任务列表,点击查看关联用例按钮,可进入关联用例列表页面,如图20。

可以点选用例,将其指派给某一个人来执行。

可对关联用例进行执行、查看结果、移除、提Bug操作。

图20

五、提交bug

进入测试视图的“Bug”,点击页面右侧的"提Bug",即可进入bug创建页面。

如图9

图9

注意事项:

●项目和任务,以及相关需求,应该认真填写,这样可以将bug和项目,任务,需求关联起来,以便以后的统计分析。

●影响版本是必填的。

而这里面的列表来源,则是项目中的build。

●bug标题需要简单明了、突出重点;重现步骤应该详实准确(测试次数、测试环境必须描述清楚),确保开发人员可以重现该bug;bug类型及严重程度应准确分类,如有Bug截图需上传截图。

●bug提交完成后需要关联相关用例,以便以后的统计分析。

六、验证bug

当开发人员解决bug之后,就需要来验证bug,如果没有问题,则将其关闭。

如果bug仍然存在,则将其激活。

如图10

图10

注意事项:

●改变BUG状态时需要在备注栏中说明详细情况。

 

售后侧

一、录入在线bug

售后(客服)根据客户描述,进入测试视图的“Bug”,点击页面右侧的“提Bug”,即可进入bug创建页面。

如图1

图1

注意事项:

●产品模块、所属项目、影响版本、当前指派、Bug标题、重现步骤为必填项。

●bug标题需要简单明了、突出重点;重现步骤应该详实准确,确保研发工程师可以重现该bug;如有Bug截图需上传截图。

●Bug类型选择客户。

●Bug信息输入完成后,抄送给其他客服人员,点击保存按钮,即可提交该Bug。

●指派人为项目组提供的接口人。

二、跟踪bug

当研发工程师确认bug之后,售后(客服)根据其提供的大致解决时间跟踪查看bug。

如图2

图2

注意事项:

●需要每天定时跟踪上线bug,如果有未回复(备注)的未解决的bug,则需要和接口人联系。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 医药卫生 > 基础医学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1