如何用JIRA和confluence来做公司的流程最佳实践？（一）

lsekfe

　公司归流程规范背景：
　　该中心属于公司的技术部，包含产品+研发+测试+运维人员总计300左右，公司有一定的流程规范，也是通过[url=]JIRA[/url]流转，但是只使用到了JIRA的最基础的任务功能，任务里面只包含了经办人以及任务的简单描述，产品经理对接营销中心以及其他业务部门的需求，然后将需求转化给到开发同事进行开发、[url=]测试[/url]，运维上线，如此迭代。产品和开发的对接以口头沟通为主，书面产出内容较少，公司上线频繁，一周2-3次发布，上线申请采用纸质申请审批。
　　调研各领导、各角色组长的规范诉求：
　　1、优先保证系统的稳定性，避免出现线上BUG。
　　2、提升整体的工作效率，能知道每个人的工作情况、质量情况。
　　3、各岗位的工作职责更加明确，比如需求阶段产品经理应该做到[url=]需求分析[/url]、需求评审、需求优先级排序、需求价值提供等。
　　4、控制发布频率，最好一周一次常规。
　　5、各阶段的数据都能留痕。
　　6、加强过程质量的控制。
　　结合背景+诉求，梳理流程
　　根据领导的要求以及各组长的诉求，开始梳理流程，主要梳理从需求接收到需求上线全生命周期管理。
　　1、针对需求受理，实时受理，受理时需要了解业务方的提报背景、具体的改造点，期望上线时间等。
　　2、需求分析，由产品经理针对所有受理的需求进行挖掘和分析，然后将需求[url=]记录[/url]在系统上，系统上必须包含需求的背景、提报部门、需求的目的、需求的预期价值以及需求涉及的商户，期望完成点，记录完成后汇总所有的需求，由业务线负责人进行优先级排序，然后根据排序组织跟对应的开发、测试开展评审，评审前必须输出需求文档。
　　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版中修复了。注意没有修复版本的问题会被归类到'未规划'。，迭代的过程可以使用。
　　项目模块：一个项目模块是这个项目中问题的逻辑分类集合。每个项目都可以根据你企业组织的要求设置多个模块 (也可以不设置模块)。我们对他的应用主要是不同业务线里面系统子模块。