禅道项目管理系统使用规范【精选文档】.pdf
禅道项目管理系统使用规范一、标题命名规范禅道项目管理系统提供模块名显示功能,通过以下操纵显示。这样标题的命名规则上我们可以规定：项目标签#【创建时间】产品/子产品计划/需求/任务/Bug 1.计划/需求/任务命名命名格式：【创建时间】产品/子产品 计划/需求/任务/Bug 例子：【20160907】中国比特币v1。8 版研发计划【20160907】App v1。8 版研发计划【20160907】iOSv1.8 版研发计划【20160907】Web v1.8 版研发计划【20160907】iOS找回登录密码(手机/邮箱）没有证件号输入项2。测试用例命名命名格式：功能模块-子模块子模块例子：财务功能人民币相关业务功能财务功能-数字货币相关业务功能用户注册登录功能3.发布版本命名命名格式：项目/子项目 版本号（状态）例子:App 1。8（研发中）App 1。7（已发布）二、项目开发计划流程规范1。创建产品创建一个主线产品，若这个产品涉及多个平台，则根据父子关系创建树规范事项：1）产品只能由超级管理员建立。2)每个主线产品，自身再细分不同平台的子产品.2。创建项目如果你已经创建了产品树，则新建一个主线项目后，它将会关联整个产品的树结构，如上图所示规范事项：1）项目只能由超级管理员建立。2）只要创建好产品体系,直接创建一个主线项目会有对应产品的子项目。3。创建工作计划为了更好维护项目，我们采用阶段性迭代开发方式。每个开发阶段都以唯一的版本号命名计划,每个阶段都合理汇总需求及要修复的bugs，尽可能地确定及控制每个阶段开发时间及人力成本。使项目开发能做到高效率与高稳定兼顾.1）由项目经理创建“计划”描述计划的版本号，工作概述，开发时间等。（时间尽量预松，以备摸索时遇到坑)2）为计划创建需求及关联需本次迭代修复的bugs 创建这个计划要实现的需求，及要在这次开发计划中修复的bugs 规范事项：1）开发计划只能由项目经理等人员建立。2）开发计划尽力做到小而精准，做好需求分析，做出符合用户需要的功能。3）开发计划中列明开发人员及职责，尽量不要一个人员同时在进行多个计划，避免其进度无法把握。4）开发计划的时间预估应该要合理，必须包含需求分析，原型设计，编程开发,功能测试等时间,时间安排不合理会造成偷工减料，Bugs 频繁出现。5）完成每个计划都必须写下计划总结，总结新技术和遇到的问题，提高团队效率。4。创建需求有了开发计划，我们就可以创建需求，把需求关联到计划中。有时候，可能会出一些特发奇想的需求，这些可以不纳入到计划中，可以作为临时任务完成.但我们还是尽可能把需求汇总好，归纳到计划中，这样才能保证项目稳定,降低成本.避免仓促粗糙的测试导致项目上线遇到严重问题，付出沉重成本。规范事项：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，才能进行最后的发布。
