禅道项目管理系统使用规范.docxVIP

  1. 1、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多

禅道项目管理系统使用规范

一、标题命名规范

禅道项目管理系统提供模块名显示功能,通过以下操纵显示。

这样标题的命名规则上我们可以规定:#项目标签#【{创建时间}】《{产品/子产品}》{计划/需求/任务/Bug}

1.计划/需求/任务命名

命名格式:【{创建时间}】《{产品/子产品}》{计划/需求/任务/Bug}

例子:

《中国比特币》v1.8版研发计划

《App》v1.8版研发计划

《iOS》v1.8版研发计划

《Web》v1.8版研发计划

《iOS》找回登录密码(手机/邮箱)没有证件号输入项

2.测试用例命名

命名格式:功能模块-子模块-子模块

例子:

财务功能—人民币相关业务功能

财务功能—数字货币相关业务功能

用户注册登录功能

3.发布版本命名

命名格式:{项目/子项目}{版本号}({状态})

例子:

App1.8(研发中)

App1.7(已发布)

二、项目开发计划流程规范

1.创建产品

创建一个主线产品,若这个产品涉及多个平台,则根据父子关系创建树

规范事项:

规范事项:

1)需求只能由项目经理,产品经理,客服经理等人员建立。

2)需求尽可能绑定到开发计划中。

3)需求要指明所属的产品模块。

4)需求必须经由产品经理审核。

4)尽可能归纳多个需求点到一个记录中,可使用《XMind》等脑图工具整理出来,方便理解阅读。

5.创建任务

有了需求,我们就可以依照每个需求点制定日常的开发任务指派给下属。有时候有些简单的任务,可以不需要需求做支持。例如,一些文档整理任务。但我们尽量把任务归类好,要保证任务是在那个版本,那需求点而做的。保证Bugs出现时可查找到开发人员和原始的需求内容。

规范事项:

1)任务只能由项目经理等人员提出。

2)单个任务时间最好控制在1周内,尽可能细分任务,这样进度把控跟准。

3)开发人员每日要求简述任务进度和遇到的问题。避免低级问题造成任务阻塞。

4)只要任务关联上需求,在详细页面中可以看到需求内容。

5)任务描述尽可能清晰罗列工作要点和注意事项。

6)不要一个任务指派给多个人一起做,避免开发上的冲突。

7)为了区分任务是属于需求关联的任务,还是日常临时的任务,可用颜色区分,“默认颜色”为计划任务,“绿色”为临时任务

6.创建版本

开发计划中的需求都完成后,接下来就是安排测试工作,在测试前需要建立版本号。这样测试人员发现bugs,可以标记那个版本发现的。

规范事项:

1)版本只能由项目经理等人员建立。

2)最好不要有两个同时是“研发中”的版本,避免分支的代码混乱。

3)发布了的版本记得及时标记为“已发布”状态。

4)解决了bugs或完成了需求,及时在版本号上关联上。

7.创建测试

版本号创建后,接下来就可以测试了。建立好的测试用例,做好测试计划,测试质量直接影响到产品质量。长期维护的产品应该以测试推动开发,所以我觉得保证测试质量至关重要。

规范事项:

1)测试只能由项目经理等人员建立。

2)尽可能描述本次测试计划的要点和注意事项。

3)测试人员熟悉新功能后,尽力做到建立专业的测试用例,并关联到每次的测试计划。

4)测试用例的质量直接影响到产品质量,长期维护的产品应该以测试推动开发,所以我觉得保证测试质量至关重要。

8.测试/日常Bugs提交

当测试人员/客服发现时Bugs,最有效的解决就是提交到相关产品对应的Bugs中。避免口头交代问题造成遗忘及处理结果无法交代清楚。

规范事项:

1)Bugs任何人员都可建立。

2)Bugs的发现过程尽可能记录详细,需要账号或数据条件应该列明。

3)Bugs标记好发现的版本和所属产品,先指派给产品经理进行分析处理,无法解决再指派给项目经理,最后再指派给开发人员处理。

4)Bugs解决方案需要说明“原因”和“解决”,标明好解决版本,打包程序测试通过后,最后需要把版本关联所解决的Bugs,才能进行最后的发布。

文档评论(0)

182****6616 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档