禅道操作流程规范资料.docx
- 文档编号:30201507
- 上传时间:2023-08-07
- 格式:DOCX
- 页数:22
- 大小:1.51MB
禅道操作流程规范资料.docx
《禅道操作流程规范资料.docx》由会员分享,可在线阅读,更多相关《禅道操作流程规范资料.docx(22页珍藏版)》请在冰豆网上搜索。
禅道操作流程规范资料
操作使用流程规范
产品篇
创建产品
添加产品时需要注意的地方:
∙产品名称:
根据内部公司内部系统定义相关层次进行识别和命名;
比如:
行业--易行通通用—收银台平台--会员金融—签约
产品代号:
统一命名为该系统在svn上面的名字,易行通(neverstop)
∙产品负责人负责整理和解释整个产品的需求,制定相应的发布计划。
∙测试负责人,可以指定默认的测试负责人。
这样可以适用于公司人比较多,提交bug不知道该给谁的情况。
∙发布负责人主要的职责是创建发布。
(统一指定为该系统开发负责人)
∙访问控制,则可以控制访问该产品的人员列表。
比如可以将某一个产品设为私有,只有产品添加者、产品负责人、测试负责人、发布负责人以及该产品的项目团队才可以访问。
(统一为私有产品)
创建需求
1.进入产品视图。
2.在页面右侧,有“提需求”菜单,点击菜单,出现新增需求的页面。
创建需求需要注意以下几点:
∙需求的标题是必填项。
∙所属计划和模块,可以暂时保留为空。
∙需求审核那块,我们选上不需要审核,这样新创建的需求状态就是激活的。
只有激活状态的需求才能关联到项目中,进行开发。
(建议直接勾选上不需要评审)
∙需求可以设置抄送给人员,这样需求的变化都可以通过email的形式抄送给相关人员。
∙可以设置关键词,这样可以比较方便的通过关键词进行检索。
评审需求:
本期暂时不涉及到需求评审过程----待完善
需求变更:
凡是对需求标题、描述、验证标准和附件的修改,都应该走变更流程。
变更之后需要评审的需求状态为变更中。
如果不选评审,变更完成之后直接变成激活。
如下图:
∙编辑操作是无法修改需求的标题、描述、验收标准和附件的。
∙在变更需求的时候,如果选择了“不需要评审”,则需求状态自动变成激活,不需要再走评审流程。
∙如果该需求已经在开发,测试过程中,那么在变更需求的时候,会列出该需求的影响范围:
确认需求变更
当需求变更被确认之后,研发团队和测试人员需要确认需求的变更。
任务确认需求变动
Bug确认需求变动
由于用例维护是在线下,暂时不做考虑。
需求的注意事项
需求的写法
有默认的需求模板:
作为一名<某种类型的用户>,我希望<达成某些目的>,这样可以<开发的价值>
在这个模板中,总共有三个元素:
角色,要做的事情,价值或者原因。
我们平时在写需求的时候,往往会忽略角色和价值原因这两个元素,只关注了要做的事情。
其实这有很多的问题。
不进行用户角色的划分,会影响对产品功能的设计和定位,从而导致产品往往是给一个用户角色开发的,就是产品经理自己。
:
)而忽略开发的原因或者价值,会让开发人员感到困惑。
他们可能并不理解你这样做的原因或者目的,不理解的需求实现起来自然会有问题。
需求和原型图、需求设计文档的区别
原型图或者需求设计文档是一个整体,可以给人宏观的把握。
这是原型图的优点。
比较直观。
原型图是一个整体,所以就没有办法进行分解。
你不可能分解成,做页面导航条,做页面的中间部分等。
没有分解,所以原型图也就没有办法进行优先级的排序。
比如页面部分,有的很重要,有的不重要。
但在原型图里面是体现不出来优先级的。
没有分解,自然也就无法进行跟踪。
你没有办法得知原型图完成了多少。
需求设计文档规定的比较细致,会让产品经理陷入太多的细节,对整体的把握会减弱。
所以,两者都需要进行相应的梳理和编写。
然后将原型图作为设计文档,上传到对应产品相关的文档库中,和需求点相互配合,这样就解决了相关问题。
产品模块的维护
添加完产品之后,就需要来设置产品的模块。
模块相当于对产品需求的一个分类,通过组织模块,可以让大家对产品有一个宏观的把握和认识,也方便对需求进行分类和整理。
在内部,就只分一个模块,以该ui产品的产品名进行命名,如果其他产品有需要,可以根据产品的定位进行维护。
项目篇
建立项目
一、创建项目
1.1进入项目视图,点击右侧的”添加项目“链接。
1.2出现项目添加的页面
在这个页面设置项目名称、代号、起止时间、可用工作日、团队名称、项目目标和项目描述等字段。
其中关联产品是可以为空的。
注意事项:
项目名称:
HY_易行通_20150206类似的格式(PS:
发现不合格的会删除)
关联产品:
在添加项目的时候,可以选择关联与之相关的产品,以便后续进行需求的关联。
项目权限:
项目可以控制它的访问权限,内部统一设置为私有
二、组建项目团队
项目组建之后要做的事情就是设置团队;
当项目创建成功之后,可以根据提示设置团队。
或者从项目视图中的团队菜单,也可以进行项目的团队管理。
当团队设置完毕之后,整个项目的可用资源就已经确定了:
起止时间确定了,参与的人员也确定了。
下面就是来确定项目中要做的事情了。
确定项目要完成的需求列表
项目团队组建完毕之后,接下来要做的一个工作就是确定这期项目要做的需求。
这项任务其实是整个团队,包括产品在内,共同完成的。
一、关联产品
如果在创建项目的时候,已经关联过产品,可以忽略这个步骤。
1.以项目经理身份登录。
2.进入项目视图。
3.点击“关联产品”按钮。
然后点选该项目相关的产品即可。
二、关联需求
1.在关联需求的时候,可以按照优先级进行排序。
2.关联的需求状态必须是激活的(评审通过,不能是草稿)
组织进行任务分配
一、新建任务
通过关联需求进行任务创建
分解任务
∙如果需求和任务的标题是一样的,可以通过”同需求“按钮快捷的复制需求的标题。
二、任务分解的几个注意事项
1.需要将所有的任务都分解出来。
这里面包括设计,开发,测试,美工,甚至包括购买机器,部署测试环境等等。
没有需求可以直接创建。
2.任务分解的粒度越小越好,比如几个小时就可以完成。
3.如果一个任务需要多个人负责,继续考虑将其拆分。
4.事务型的事务可以批量指派,比如需要让团队里面的每一个人都写个项目总结,可以选择类型是事务,然后批量指派给团队里面的所有人员。
5.任务的类型请仔细设置,这个会涉及到需求研发阶段的自动计算。
6.任务的分配最好是自由领取,这样可以最大程度上调动大家的积极性。
使用指派也是可以的。
7.任务的分解最好是由团队共同完成,不要由项目经理一人包办。
三、任务分类预览
开发篇
领取任务,并每天更新任务
当项目的任务分解完毕之后,项目团队成员需要将分配到的任务(或者领取自己喜欢做的任务),开始每天的开发。
除了日常的编码工作之外,还应当每天花点时间在里面更新下任务的状态以及时间消耗情况。
一、领取任务
领取任务可以通过两种方式,一种是通过“指派”操作,一种是通过“编辑”操作。
二、更新任务状态
项目开始之后,每个人每天应当及时更新自己所负责的任务的状态。
提供了几个快捷的操作按钮:
开始、完成、关闭、取消和激活。
开始、完成和取消没有什么歧义。
解释下关闭和激活。
有一个可选流程,就是当任务完成之后,会自动指派回任务的创建者头上,这时候任务的创建者可以验证任务是否完成。
如果完成,则将任务关闭。
如果任务没有完成,则激活任务。
这个流程是可选的,不是必须的流程。
三、更新任务的消耗
除了更新自己负责任务的状态之外,还应该及时更新任务的工时消耗情况:
最初预计,即创建任务的时候的最初预计。
该字段在任务开始之后,不应该再进行修改。
这个字段当任务结束之后,可以和已经消耗字段进行对比,以纠正自己的估计。
已经消耗,则是你在这个任务上所有花费的工时数。
预计剩余,则是你预计这个任务完成大约还需要多少时间。
如果预计剩余为0,则表示任务完成。
这里面需要特别强调的是,最初预计≠已经消耗+预计剩余。
一定要每天更新自己所负责的任务,因为燃尽图的绘制,就是通过预计剩余这个字段来计算的。
解决bug
提交测试之后,测试人员展开测试,便会有bug产生。
这时候研发团队的一个重要职责便是解决bug。
里面bug的处理流程比较简单:
测试人员提交bug=>开发人员解决bug=>测试人员验证关闭,这是比较正常的流程。
还有一个流程是激活流程:
测试人员提交bug=>开发人员解决bug=>测试人员验证未通过=>激活bug=>重新解决=>验证关闭。
开发人员所需要做的事情便是处理自己负责bug,并在禅道中登记解决方案:
测试管理模块
1.项目视图中的bug列表
首页我的bug列表
2.bug的详情页面也可以找到“解决”操作的按钮。
3.解决bug的时候,需要填写bug的解决方案。
附:
bug的解决方案
总共提供了其中解决方案:
bydesign=>设计如此,无需改动。
duplicate=>重复Bug,以前已经有同样的bug。
external=>外部原因,非本系统原因。
fixed=>已解决;
notrepro=>无法重现,无非重现bug。
postponed=>延期处理,确实是bug,但现在不解,放在以后。
willnotfix=>不予解决
这其中“已解决”和“延期”的bug视为有效bug。
确认bug
当测试人员提交了bug之后,如果开发人员来不及解决这个bug,这时候可选的一个操作是确认这个bug,给测试人员一个反馈。
bug列表页面会显示是否已经确认过。
需要说明的是,如果一个bug被解决之后,也会自动变成已确认。
测试篇
提交bug
直接来看步骤:
1.进入测试视图的“Bug”或者在项目里面有bug模块。
2.点击页面右侧的"提Bug",即可进入bug创建页面。
说明:
1.项目和任务,以及相关需求,应该认真填写,这样可以将bug和项目,任务,需求关联起来,以便以后的统计分析。
2.影响版本是必填的。
而这里面的列表来源,则是项目中的build。
如果这个地方没有build的话,则需要到项目中创建一个build。
3.重现步骤应该翔实准确,确保开发人员可以重现改bug。
验证bug,关闭
当开发人员解决bug之后,就需要来验证bug,如果没有问题,则将其关闭。
激活bug
如果开发人员解决bug之后,验证无法通过,则可以将bug重新激活,交由最后的解决者去重新解决。
还有一种情况就是bug关闭之后,过了一段时间,bug又重现了,也需要重新激活。
激活bug的时候,指派给会自动设置成为最后的解决者头上。
找到自己需要的bug
使用注意事项:
在项目过程中会收到很多邮件怎么办?
解决办法。
选择邮件,创建收信规则
然后选择移动到那个文件夹。
即可
处理之后,现在看起来是不是整洁多了。
每天任务、bug列表提醒:
这样是不是让你很清楚的知道自己有那些事情要做呢?
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 操作 流程 规范 资料