如何用JIRA和confluence来做公司的流程最佳实践?(一)

发表于:2021-6-15 09:22

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:waihou    来源:知乎

  公司归流程规范背景:
  该中心属于公司的技术部,包含产品+研发+测试+运维人员总计300左右,公司有一定的流程规范,也是通过JIRA流转,但是只使用到了JIRA的最基础的任务功能,任务里面只包含了经办人以及任务的简单描述,产品经理对接营销中心以及其他业务部门的需求,然后将需求转化给到开发同事进行开发、测试,运维上线,如此迭代。产品和开发的对接以口头沟通为主,书面产出内容较少,公司上线频繁,一周2-3次发布,上线申请采用纸质申请审批。
  调研各领导、各角色组长的规范诉求:
  1、优先保证系统的稳定性,避免出现线上BUG。
  2、提升整体的工作效率,能知道每个人的工作情况、质量情况。
  3、各岗位的工作职责更加明确,比如需求阶段产品经理应该做到需求分析、需求评审、需求优先级排序、需求价值提供等。
  4、控制发布频率,最好一周一次常规。
  5、各阶段的数据都能留痕。
  6、加强过程质量的控制。
  结合背景+诉求,梳理流程
  根据领导的要求以及各组长的诉求,开始梳理流程,主要梳理从需求接收到需求上线全生命周期管理。
  1、针对需求受理,实时受理,受理时需要了解业务方的提报背景、具体的改造点,期望上线时间等。
  2、需求分析,由产品经理针对所有受理的需求进行挖掘和分析,然后将需求记录在系统上,系统上必须包含需求的背景、提报部门、需求的目的、需求的预期价值以及需求涉及的商户,期望完成点,记录完成后汇总所有的需求,由业务线负责人进行优先级排序,然后根据排序组织跟对应的开发、测试开展评审,评审前必须输出需求文档。
  3、研发同时针对需求进行评估,评估需求实施需要花费的工时、实现方式等,同时针对需求进行分析和拆解,拆解到对应的子模块。
  4、测试人员针对需求进行评估,评估测试的工作量,另外针对测试过程中有问题必须提交缺陷记录,上线之前所有的缺陷都必须要关闭。
  5、所有的需求上线前都必须经过测试通过以及产品验收,验收后提交上线申请,上线申请将去除纸质化,采用系统完成,提高发布申请效率,同时节约成本,也便于管理。
  6、运维针对提交的内容进行发布,发布后必须通过测试、产品验收,验收通过后由产品经理通知对应的需求提出方(业务方)。
  7、以上内容均需要通过线上系统操作。
  制定方案,开始实施
  根据以上的流程方案,我们开始找寻工具并制定方案,在具体实施的过程中,需要解决以下问题:
  1、需求有大有小,一个需求可能涉及多个人来开发,那么在系统里面支持一对多的情况。
  2、需求阶段、开发阶段、测试阶段都有不同的界面要求(就是不同的阶段要出来不同的页面内容),系统工具需要能做支撑。
  3、在需求研发的过程中,还会衍生其他的相关工作,包括缺陷的提交,包括UI设计等,因此系统里面也需要将这些工作体现。
  4、过程质量的控制需要度量指标,这些指标都是在过程中体现,在过程中系统是否支持必填操作。
  5、发布申请需要线上化,那么每次发布的内容需要跟运维的发布系统打通。
  基于以上的问题,我们开始做系统工具的筛选,之前市场上主流的是TB、禅道以及JIRA,我们综合评估下来JIRA最适合我司,最重要的一点是JIRA支持自定义工作流,而根据我们上文的要求,我们的流程都是需要自定义的且我司已有JIRA的使用经验。
  工具确定下来后,我们根据要求然后输出工作流以及页面内容,跟各组长确认后进行配置。
  一、整体需求工作流
整体的需求管理流程
  二、根据整体的工作流固化到JIRA工具上
  JIRA系统基础功能/结构:
  项目:项目是根据你的企业组织需要定制的,是问题的集合。一个项目可以代表一条业务线,一个软件研发项目,一个需求管理系统等等,我们使用是定义为业务线的需求管理。
  问题类型:可以用于跟踪多种不同类型的问题。系统管理员可以根据需要添加。JIRA系统缺省提供的问题类型如下:BUG、task,Improvement,由于我司需求管理的需求,我们使用是按照产品工单、技术需求、开发测试子任务、UED工单等。
  工作流:根据自己的需求可以设置不同的工作流程,跟问题类型对应,我们针对每种问题类型都定义了对应的工作流。
  界面方案:根据自己的需求可以设置不同的界面,如果是非系统默认的需要去创建新的字段。
  优先级:在 JIRA 系统中用优先级来表示问题的严重级别。系统管理员可以在 JIRA 系统中添加优先级,JIRA 系统缺省的优先级为'紧急','严重','一般','次要',也支持自定义替换。
  角色:JIRA 作为一个缺陷跟踪管理系统,可以被企业管理人员,项目管理人员,开发人员,分析人员,测试人员和其他人员所广泛使用,可根据公司的需要自定义。
  版本:在一个项目上,一般会有多个版本,如:1.0alpha、1.0beta、1.0、1.2、2.0。影响版本— 可以清晰地反映出这个问题在哪个版本中出现错误。例如, 一个软件的缺陷可能影响了产品的1.1和1.2版。修复版本— 可以反映出报告的问题将在哪个版本,或已经在哪个版本中修复了。例如, 软件缺陷影响了产品的1.1和1.2版,这个缺陷已经在2.0版中修复了。注意没有修复版本的问题会被归类到'未规划'。,迭代的过程可以使用。
  项目模块:一个项目模块是这个项目中问题的逻辑分类集合。每个项目都可以根据你企业组织的要求设置多个模块 (也可以不设置模块)。我们对他的应用主要是不同业务线里面系统子模块。

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号