美文网首页学习软件测试工具
禅道项目管理系统使用规范

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

作者: 蛊惑佬 | 来源:发表于2016-09-07 15:51 被阅读742次

    修订信息

    版本 时间 修订人 修订内容
    1.0 2016-09-07 麦志泉 创建文档

    一、标题命名规范

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

    E9ACEE6B-5E5B-4D17-BAC7-F02DD1E142D1.png 15934C93-12D4-4387-8B92-A4753F7C1D46.png
    这样标题的命名规则上我们可以规定:#项目标签#【{创建时间}】《{产品/子产品}》{计划/需求/任务/Bug}
    
    1.计划/需求/任务命名

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

    例子:
    【20160907】《中国比特币》v1.8版研发计划
    【20160907】《App》v1.8版研发计划
    【20160907】《iOS》v1.8版研发计划
    【20160907】《Web》v1.8版研发计划
    【20160907】《iOS》找回登录密码(手机/邮箱)没有证件号输入项
    
    2.测试用例命名

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

    例子:
    财务功能—人民币相关业务功能
    财务功能—数字货币相关业务功能
    用户注册登录功能
    
    3.发布版本命名

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

    例子:
    App 1.8(研发中)
    App 1.7(已发布)
    

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

    1.创建产品

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

    447B79FC-2F3E-40FC-99D0-584328FDDC1D.png
    规范事项:
    1)产品只能由超级管理员建立。
    2)每个主线产品,自身再细分不同平台的子产品。
    
    2.创建项目

    如果你已经创建了产品树,则新建一个主线项目后,它将会关联整个产品的树结构,如上图所示

    规范事项:
    1)项目只能由超级管理员建立。
    2)只要创建好产品体系,直接创建一个主线项目会有对应产品的子项目。
    
    3.创建工作计划

    为了更好维护项目,我们采用阶段性迭代开发方式。每个开发阶段都以唯一的版本号命名计划,每个阶段都合理汇总需求及要修复的bugs,尽可能地确定及控制每个阶段开发时间及人力成本。使项目开发能做到高效率与高稳定兼顾。

    1)由项目经理创建“计划”

    描述计划的版本号,工作概述,开发时间等。(时间尽量预松,以备摸索时遇到坑)

    4ADA85C0-F3F4-4203-BAE9-1D69A590FED4.png
    2)为计划创建需求及关联需本次迭代修复的bugs

    创建这个计划要实现的需求,及要在这次开发计划中修复的bugs

    BCF6410C-7CC0-430E-95C1-D2A62B7913EF.png 828C2BB4-A6A5-4028-9B9D-058EB0F5613D.png
    规范事项:
    1)开发计划只能由项目经理等人员建立。
    2)开发计划尽力做到小而精准,做好需求分析,做出符合用户需要的功能。
    3)开发计划中列明开发人员及职责,尽量不要一个人员同时在进行多个计划,避免其进度无法把握。
    4)开发计划的时间预估应该要合理,必须包含需求分析,原型设计,编程开发,功能测试等时间,时间安排不合理会造成偷工减料,Bugs频繁出现。
    5)完成每个计划都必须写下《计划总结》,总结新技术和遇到的问题,提高团队效率。
    
    4.创建需求

    有了开发计划,我们就可以创建需求,把需求关联到计划中。有时候,可能会出一些特发奇想的需求,这些可以不纳入到计划中,可以作为临时任务完成。但我们还是尽可能把需求汇总好,归纳到计划中,这样才能保证项目稳定,降低成本。避免仓促粗糙的测试导致项目上线遇到严重问题,付出沉重成本。

    40DC8000-645E-4E6D-83F8-FDED25866ABF.png
    规范事项:
    1)需求只能由项目经理,产品经理,客服经理等人员建立。
    2)需求尽可能绑定到开发计划中。
    3)需求要指明所属的产品模块。
    4)需求必须经由产品经理审核。
    4)尽可能归纳多个需求点到一个记录中,可使用《XMind》等脑图工具整理出来,方便理解阅读。
    
    5.创建任务

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

    2EBD1338-4D2B-42D2-B2A5-4625E33FEB86.png D8EDED8D-8AC3-435B-85E3-464C5C4AAB47.png
    规范事项:
    1)任务只能由项目经理等人员提出。
    2)单个任务时间最好控制在1周内,尽可能细分任务,这样进度把控跟准。
    3)开发人员每日要求简述任务进度和遇到的问题。避免低级问题造成任务阻塞。
    4)只要任务关联上需求,在详细页面中可以看到需求内容。
    5)任务描述尽可能清晰罗列工作要点和注意事项。
    6)不要一个任务指派给多个人一起做,避免开发上的冲突。
    7)为了区分任务是属于需求关联的任务,还是日常临时的任务,可用颜色区分,“默认颜色”为计划任务,“绿色”为临时任务
    
    6.创建版本

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

    1D201476-65F2-413C-868D-0515C2709A00.png 70B8D23B-35DE-4D1D-B105-06A7F81D49EF.png
    规范事项:
    1)版本只能由项目经理等人员建立。
    2)最好不要有两个同时是“研发中”的版本,避免分支的代码混乱。
    3)发布了的版本记得及时标记为“已发布”状态。
    4)解决了bugs或完成了需求,及时在版本号上关联上。
    
    7.创建测试

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

    C5BAFFFA-730D-4CCA-A720-AE0B8B370832.png
    规范事项:
    1)测试只能由项目经理等人员建立。
    2)尽可能描述本次测试计划的要点和注意事项。
    3)测试人员熟悉新功能后,尽力做到建立专业的测试用例,并关联到每次的测试计划。
    4)测试用例的质量直接影响到产品质量,长期维护的产品应该以测试推动开发,所以我觉得保证测试质量至关重要。
    
    8.测试/日常Bugs提交

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

    2745D872-22BC-4713-A5F7-EDD59DF25DE5.png FED15276-5CA1-4030-9555-CC2E2A160ECF.png 32CDDF30-1252-441B-99D3-11E9C408C65E.png
    规范事项:
    1)Bugs任何人员都可建立。
    2)Bugs的发现过程尽可能记录详细,需要账号或数据条件应该列明。
    3)Bugs标记好发现的版本和所属产品,先指派给产品经理进行分析处理,无法解决再指派给项目经理,最后再指派给开发人员处理。
    4)Bugs解决方案需要说明“原因”和“解决”,标明好解决版本,打包程序测试通过后,最后需要把版本关联所解决的Bugs,才能进行最后的发布。
    
    9.版本发布

    后期续写,To be continue...

    相关文章

      网友评论

      • ccef352489e4:hi,这个使用规范可以分享下发我不。

      本文标题:禅道项目管理系统使用规范

      本文链接:https://www.haomeiwen.com/subject/udyjettx.html