Jira中的全流程开发管理
1. 使用人员说明
- 需求相关：PO
- 开发相关：开发负责人，分系统负责人，开发人员
- 测试相关：测试人员，业务人员
2. 工具中的字段说明
2.1 Issue Type 事件类型说明
在创建一个Issue（事件）的时候，需要首先选择Issue Type（事件类型），该类型分为以下六种，具体分类及操作人员如下：
BR（业务需求）
记录原始的业务需求，包括：服务台收集的优化需求，DT/PM收集到的修改现有功能的业务需求，以及新的功能中业务提出的需求。每个业务需求由服务台/BT/PM定义并增加到Jira的Issue中，并分解为一个或多个产品需求PRD。
PRD（产品需求）
每一个PRD类型的Issue记录一条产品需求，该产品需求的粒度以可实现的最小功能为参考，工作量需少于5人天。PRD由业务需求分析得到并关联到上级的BR，由BT/PM定义并增加到Jira的Issue中，指派给开发负责人（PM/子系统负责人）。
Task（任务）
任务类型服务于开发团队，IT PM/ IT 子系统负责人接收到PRD，拆分为开发任务task或者Subtask并指定给相关的开发人员进行开发。该任务或子任务由IT PM/ IT 子系统负责人增加到Jira的Issue中，并跟踪其执行。
Subtask（子任务）
同task，可由PRD直接拆分为Subtask。
Bug（缺陷）
缺陷分为两类，一类是服务台或其他渠道收到的业务提交的缺陷，二是SIT及UAT出现的缺陷。缺陷由缺陷发现人增加到Jira的Issue中，一般是服务台或测试人员，其他人员也可以提交缺陷，缺陷提交后指派给相关开发人员。如果不确定开发人员，指派给开发负责人或子系统负责人。
Test（测试）
测试为编写测试用例的类型，可以针对某一个Component，PRD进行测试用例的编写、测试用例的执行及缺陷提交。
2.2 Status（状态）说明
状态说明了当前Issue的处理状态，默认为：TO DO （待定）。状态分为：TO DO（待定），Progressing（进行中），Resolved（已解决），Done（已完成），Reopen（重新打开），Pending(搁置)，Feedback（反馈）。
用户可以通过浏览Issue页面中的状态操作按钮，改变当前的状态，操作为【open】【progress】【reopen】【pend】【resolve】【Feedback】【Close】。状态如下分类：
- TO DO（待定）
每一个新建的Issue初始状态都为TO DO。
- Progressing（进行中）
Issue（事件）指定给解决人之后，修改状态为Progressing，表示该Issue正在解决的过程中。
- Resolved（已解决）
当解决人把指定的Issue解决完成后，修改状态为Resolved，表示该Issue已经解决完成，可以进行测试或验证了。
- Done（已完成）
测试人员或验证人员（通常是PM），确认该Issue正确后，修改状态为Done，表示该Issue已经被验证完成，是一个合格的Issue。原则上，解决人不能够直接close指定给自己的Issue，必须由指定给自己的reporter来验证。
- Reopen（重新打开）
验证不通过的Issue，修改状态为reopen，表示该问题仍未解决，可以指回给解决人继续解决。
- Pending(搁置)
无法处理，暂时搁置的问题，修改状态为pending。
- Feedback（反馈）
解决人对问题有疑问的问题，修改状态为Feedback，并指回给reporter。
2.3 Priority(优先级)说明
在Jira中针对于BR/PRD/Bug定义了4类优先级，分别是：P1，P2，P3，P4。
- 需求类：BR及PRD
需求的优先级是指需求被实现的紧急程度，分为P1,P2，P3,P4四个等级。对于需求的优先级要考虑多个维度，如：产品价值，时间关键性，减少风险及技术成本等。优先级是相对而言的，区分可参考如下分类：
P1
- 缺失该功能会造成严重的问题和恶劣的影响
- 该需求与核心用户利益相关
- 能够解决大量用户的高频问题，提升基础体验
P2
- 缺失该功能，在一定时间内可控，但长期会有糟糕的影响
- 该需求与大部分用户权益相关
- 需要加大投入，直到用户需求基本被满足。
P3
- 具备该功能解决很多问题、产生正面的影响
- 该需求与效率或成本有关
- 需要有投入，但是不能占用P1，P2上投入的资源，也是建立产品用户忠诚度的重要因素。
P4
- 具备该功能，在一段时间后可以有良好的效果
- 该需求与用户体验有关
- 属于矛盾、错误、无关型需求，资源具备的情况下可对产品进行完善。
- 缺陷类：Bug
缺陷的优先级指缺陷必须被修复的紧急程度，分为P1,P2，P3,P4四个等级。
P1
重要且紧急的缺陷，必须被立即解决
P2
较为紧急的缺陷，需要在5-10个工作日解决的问题
P3
重要不紧急的缺陷，缺陷需要正常排队等待修复或列入软件发布清单
P4
不重要不紧急的缺陷，可以在资源充足时被纠正。
2.4 Bug severity（缺陷严重程度）说明
缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷的严重程度分为：致命，严重，一般，轻微，建议。
致命
- 不能执行正常工作功能或重要功能，或导致系统瘫痪(死机)
- 严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启动该软件不属于更正办法）
- 服务器出现内存泄露
严重
- 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
- 包括用户使用当中出现页面级异常
- 连接错误
- 统计数据错误
- 语言翻译错误
一般
- 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能
- 包括用户界面不一致
- java script 脚本错误
- 文字错误
- 其它错误
轻微
- 页面显示格式不规范
- 不符合用户的使用习惯
- 影响体验的问题
- 其它错误
建议
- 使用过程中可以提升体验的问题
- 后续可以新增加的功能
3. 项目设置
3.1 Component/s（组件/子系统）
Component定义了系统的组件/子系统，便于较大系统的任务分配及缺陷管理。该功能需要具有管理员权限的人员设置，见图2-1。
图 2-1 设置Component
设置完成之后，在创建Issue时，可以选择已经设定好的Component，见图2-2。
图 2-2 选择Component
3.2 Sprint（冲刺/阶段性任务）
Sprint定义了一个冲刺/阶段性任务，包含在这个时间周期内要完成的Issue，一个Sprint可以一次发布也可以发布多次，不作具体要求。见图2-3
操作方法：
- 选择左侧菜单【Backlog】
- 右侧，点击【Create Sprint】，创建一个Sprint
- 点击Sprint名称，修改名称，Sprint名称的定义：项目关键词+Sprint a.b.c.d ，a.b为当前需求的版本号，c为1位大的功能增加或变更顺序号，d为2位顺序号，举例：备件项目的一期需求1.0对，大的功能发布顺序号为3，在该大的功能点已经完成10个Sprint，当前的Sprint名称是：DTSSCM Sprint 1.0.3.11。
- 将下方的Issue拉入到Sprint任务列表中
- 开启一个Sprint，点击【Start Sprint】开启一个Sprint，同一时间内，只能有一个Sprint被开启。
图 2-3 创建Sprint
3.3 Versions（版本）
- 在Release中可以定义发布版本，版本的建立操作如下：
- 点击【Release】，进入发布页面，见-图 2-4 创建Version
- 填写版本信息，版本号的定义：V a.b.c.d ，a.b为当前需求的版本号，c为1位大的功能增加或变更顺序号，d为2位顺序号，举例：备件项目的一期需求1.0对，大的功能发布顺序号为3，在该大的功能点已发布的次数为25次，应到目前的版本号是：V 1.0.3.26。
- 如果是测试版本可以在后面添加：V 1.0.3.26-QA，生产版本：V 1.0.3.26-PRO，UAT版本：V 1.0.3.26-UAT。
- 点击【Add】，添加一个版本信息
- 将发布的Issue加入到version中，在Backlog页面，点开左侧Version，将Issue拖拉到version中，见-图 2-5 添加发布内容
图 2-4 创建Version
图 3-5 添加发布内容
- 在Release中可以发布版本的操作如下：
- 在Release页面，在列表中选择要发布的版本，此时该版本的Progress应该全部是绿色，表示所有的发布Issue都已经被验证完成了
- 选择要发布的版本记录，点击右侧【Action】，如-图 3-6 版本发布
- Action有5个选项，分别是：Release(发布)，Build and Release(构建和发布)，Archieve（实现），Delete，Edit。在这五个选项中，点击【Release】，发布该版本
- 发布完成后该版本状态变为Released，发布完成
图 3-6 版本发布
3.4 Tests Cycle（测试周期）
在Test中可以定义测试周期，测试周期是对测试的管理，包括用例，时间，结果，Bug等。一个测试周期执行通过后，说明系统整体是可靠的，可使用的，可以上线的。
一个测试周期要验证的用例包括：此次修改的PRD下的测试用例及相关功能的主流程用例验证。测试周期的操作流程：
- 左侧菜单【Tests】，显示Tests页面，选择【Cycle Summary】中的【+】，进入添加Cycle页面，如-图 3-6 进入Tests
- Create new Cycle页面中，填写相关信息：如-图 3-7 新建Cycle
- Version：分两类，Unschedule和发布版本，Unschedule可以定义Component的测试内容，发布版本可以定义此次发版中需要覆盖的测试内容
- Name ：Unschedule中可以用组件名称及模块名命名，其下还可以再分folder层，作为细分目录。发布版本中可以按照版本号+第N轮来定义
- Description：包含此次测试周期的描述，包括测试类别：SIT(上线前)，SIT（上线后），UAT等。还需要包括此次测试周期包含的主流程Cycle名称
- Build：构建版本号
- Environment：环境，包括测试，UAT，生产等
- From，To：此次测试周期的时间范围
图 3-6 进入Tests
图 3-7 新建Cycle
- 添加Folder子目录，子目录可以做到更细的拆分，Component下可以再细分模块，及主流程，如-
- 添加Tests测试用例，可以有三种方式添加：
- Individually：按照单个的测试用例添加
- Via Search Filter：按照筛选条件添加
- From Another Cycle：按照其他的Cycle添加，把其他Cycle中的用例添加过来
图 3-8 新建Tests/Folder
图 3-9 新建Tests/Folder
- 执行Test Cycle，选择左侧的Cycle，显示测试用例，【Select All】,并点击【E】运行用例，进入运行页面，如-图 3-10 执行Test Cycle
图 3-10 执行Test Cycle
- 测试执行页面，选择执行状态，添加Bug，进入下一个用例的测试，直至执行完成。
图 3-11 执行结果Test Cycle
- 使用流程
4.1 业务需求类
业务需求类包括两类：服务台或BT/PM收集到的优化或修改需求，以及BT/PM收集到的新的业务需求。该部分需求，前一类，可以直接在Jira中录入用户提出的BR，并新建对应的PRD进行产品需求分析，另一类需要在Confluence中定义详细的产品需求，并把产品需求对应到相应的BR中。
-
-
- 新增BR（业务需求）
-
BR类型的Issue记录原始的业务需求，包括：服务台收集的优化需求，DT/PM收集到的修改现有功能的业务需求，以及新的功能中业务提出的需求。
- 参与人员：服务台或BT/PM
- 具体操作：在Jira中，服务台或BT/PM将业务需求，创建一个Issue，选择类型为：Busineess Requirement ，选择Component，填写相关信息，并将其指派给BT/PM，提交该Issue。按图操作即可，见-图 4-1 新增BR
图 4-1 新增BR
4.1.2 新增PRD（产品需求）
PRD类型的Issue记录一条产品需求，该产品需求PRD由业务需求分析得到，并关联到上级的BR，由BT/PM定义并增加到Jira的Issue中，指派给开发负责人（IT PM/子系统/组件负责人）。
另外，还有一类需求时IT基于系统优化提出的，也可以以PRD类型添加，Link到对应的设计方案。
- 参与人员：BT/PM IT leader
- 具体操作：
- 在Jira中，按照BR的记录，将对应的产品设计需求，创建一个Issue
- 首页选择【create】，选择组件，输入概要信息summary及Description描述
- 选择【Plan】页，建立该PRD与BR的关系，使用关系：【 is subtask of 】，选择要关联的业务需求BR
- 必须填写到期时间：Due date，时间为上线时间。
- 选择指定人，指定给子系统/组件负责人，或者不明确的部分指定给IT PM。
- 点击【create】创建一个PRD。见-图 4-2 新增PRD
- 将该PRD关联到Confluence中的需求页面，在Issue的浏览页面，选择【more】中的【Link】，进入link页面，如-图 4-3 选择Link
- 进入到Confluence中，找到需求页面，复制页面地址，如-图 4-4 复制页面地址
- 在Jira的Link页面，添加复制的页面地址到：Confluence Page页面，点击【link】，如-图 4-3 添加Link。
图 4-2 新增PRD
图 4-3 选择Link
图 4-4 复制需求地址
图 4-5 添加Link
4.1.3 新增task/Subtask（开发任务）
任务部分管理从开发承接到BT/PM的PRD并进行开发的过程，需要根据每一个PRD的要求及时间要求进行开发任务的分解和执行。新功能的开发需要比到期时间due date至少提前1天，给测试预留时间。
- 参与人员：IT PM / IT 子系统/组件负责人
- 具体操作：
- 在Jira的Issue浏览页面中，找到需要完成的PRD，在菜单【more】中选择【Create sub-task】，创建一个subtask子任务类型的Issue，如-图 4-6 Create sub-task
- 在创建页面填写信息，如下是必填项：
- 选择组件Component
- 填写概述Summary，详细描述Description
- 选择指定完成人
- 选择到期时间due date，新功能要比PRD到期时间至少提前1天
- 点击【Create】，创建该开发子任务。如-图 4-7 Subtask信息
- 查看PRD中的信息，有添加完成的子任务及状态，如-图 4-8 查看Subtask信息
图 4-6 Create sub-task
图 4-7 Subtask信息
图 4-8 查看Subtask信息
-
-
- 新增Test（测试用例）
-
Test测试提供支持PRD测试的功能，可以针对某一个Component，PRD进行测试用例的编写、测试用例的执行及缺陷提交。
- 参与人员：测试人员
- 具体操作：
- 创建测试用例有两个入口：
一个是直接在页面【Create】一个类型为Test的Issue，这样可以关联到PRD，由PRD关联到组件；
另外一个是，从类型为PRD的Issue中菜单【more】中的【Create Zephyr Test】，选择组件，创建跟组件关联的测试用例。如-图 4-9 创建Test
图 4-9 创建Test
- 填写测试用例信息：
- 在Jira中编写测试用例
- 选择组件Component
- 填写概述Summary，Summary的内容为：组件中的模块Mod1 / 模块的分功能Func1 / 用例概述+三位顺序号，如：库存调账/新增库存调账/符合要求的输入001
- 填写描述Description，可填写用例的前提条件及说明信息
- 编写用例，填写：步骤，数据及期望结果
- 点击【Add】添加用例信息
- 添加用例信息后点击【Create】，创建一个测试用例，如-图 4-10 添加Test信息
图 4-10 添加Test信息
- 在Jira中增加一个测试用例，链接到Testlink中的测试集
- 选择组件Component
- 填写概述Summary，Summary的内容为：组件中的模块Mod1 / 模块的分功能Func1 / 用例概述+三位顺序号，如：库存调账/新增库存调账/符合要求的输入001
- 填写描述Description，可填写用例的前提条件及说明信息
- 编写用例，填写：
步骤：Testlink地址
数据：Testlink中的项目名称/测试集1/测试集2
期望结果：如Testlink，可空白
- 点击【Add】添加用例信息
- 添加用例信息后点击【Create】，创建一个测试用例，如-图 4-11 添加Test信息链接Testlink
图 4-11 添加Test信息链接Testlink
- 用例添加完成后，点击左侧侧边栏的【Tests】，进入Tests页面，可以查看用例情况，以及组件下的用例。如-图 4-12 查看Test
图 4-12 查看Test
4.1.5 新增Versions（版本发布）
Release及Version提供了对发布版本的管理，可以在Release页面直观的看到定义完成的一次版本发布的执行情况，是否进入可发布阶段。
- 参与人员：BT/PM
- 具体操作：
- 创建一个Version，在Release中定义一个版本Version
- 在Backlog页面中，将要发布的内容从Sprint列表中拖到发布版本中，如-图 4-13 添加发布内容
- 可以在Release中查看发布内容的完成情况，如-图 4-14 查看版本执行情况
图 4-13 添加发布内容
图 4-14 查看版本执行情况
4.1.6 执行task/Subtask（开发任务）
- 参与人员：开发人员
- 具体操作：
- 指定任务为Subtask，查看Summary中有上级PRD的编号链接，如-图 4-14 执行Task/Subtask。
- 点击编号，可以打开本任务关联的PRD，查看本任务的需求，在Confluence中的需求说明书，如-图 4-14 执行Task/Subtask
图 4-14 执行Task/Subtask
图 4-15 查看PRD 需求文档
- 开发人员完成指定到自己的开发任务，参考PRD中关联的Confluence中的需求文档，需要在评论区留言，说明已经按照需求文档的要求来进行开发，如-图 4-15 添加评论
图 4-15 添加评论
- 开发完成后，修改Issue状态为Resolved，并将该任务指回给任务分配人。
4.1.7 检查PRD（产品需求）
- 参与人员： IT PM / IT 子系统/组件负责人
- 具体操作：检查开发任务完成情况，如果一个PRD的子任务全部为Resolved，将子任务状态修改为Done，并将完成的PRD修改状态为Resolved，将PRD指派给测试人员进行测试。如-图 4-16 检查PRD完成情况
图 4-16 检查PRD完成情况
4.1.8 执行PRD Test（功能测试）
- 参与人员：测试人员/服务台
- 具体操作：
- 对指派给自己的PRD，按照PRD中关联的用例（relates to的test类型的Issue），执行测试；
图 4-14 查看用例
- 执行用例，进入用例页面，点击上方菜单的执行【Execute】
图-4.15 执行用例
- 进入选择版本和测试周期页面，选择当前版本号及周期（有版本号），指派人，或者直接选择：Execute ad Hoc(执行一个临时的测试周期)，点击执行，如-图 4-15 执行用例
图 4-15 执行用例
- 按测试用例执行测试，如果是功能用例直接编写在Jira中的，按照测试步骤执行，如果测试用例在Testlink中的，按链接地址的目录执行测试。测试结果有5类，PASS通过，FAIL失败，WIP进行中，BLOKED阻塞，UNEXECUTED未执行，选择实际结果进行填写
- 记录执行结果：不通过的用例，提交Bug，并指给开发人员进行修改，后续对bug 进行跟踪；通过的用例，设为Pass，不满足测试条件的用例，设置为Blocked。如-图 4-16 执行结果
- 测试PASS的用例，将状态设置为Done，如-图 4-17 关闭测试用例
- PRD中的用例全部通过后，返回到该PRD，将其状态修改为Done，指回给任务分配人员。，如-图 4-18 关闭PRD
图 4-16 执行结果
图 4-17 关闭测试用例
图 4-18 关闭PRD
4.1.9 执行Release（发布）
该发布版本中所有的Issue状态为Done时，可以启动版本发布。版本发布首先要进行上线前测试，该上线前测试跟项目的不同有的是SIT的延伸，有的是业务进行的UAT测试，不管是那种测试都要涉及到场景及此次发布可能引起的其他流程的验证活动。
- 检查发布状态
- 参与人员：IT PM / IT 子系统/组件负责人
- 具体操作：此次发布中的PRD及Bug全部为Done时（内容条为绿色），说明可以进行发布。
- 上线前测试（UAT或SIT流程）
- 参与人员：测试人员/服务台或者业务人员
- 具体操作：
- 测试负责人点击左侧菜单【Test】，进入项目的Test页面，在当前版本下创建一个测试周期，将相关主流程或场景的用例添加到该测试周期中，见章节3-4.有一些用例可能在验证PRD时测试通过，看情况是否重新执行
- 执行该测试周期的内容，选择要发布的版本，页面右侧会显示包含的用例,选择【Select All】，点击【E】，执行全部测试用例，如-图 4-19 执行测试周期
- 针对每一个用例选择测试结果，并提交Bug
- 测试用例通过后，Test页面下的该测试周期显示为绿色，说明流程已经全部验证完成，通知IT PM 可以上线，如-图 4-20 上线测试完成
- 此处说明，如果有遗留的Bug可以不影响此次上线，经过讨论可以不必要求测试周期全部显示绿色，也就是说测试中可以有用例没有通过
图 4-19 执行测试周期
图 4-20 上线测试完成
- 发布
- 参与人员：IT 开发人员
- 具体操作：将系统按顺序部署到正式的生产环境
图 4-21 上线发布
- 上线后测试
- 参与人员：BT/PM 测试人员或者业务
- 具体操作：在生产环境执行上线测试周期的内容，确认无误后，上线发布完成
4.2 Bug类
Bug类的Issue包括两部分，一部分是服务台/BT收到的用户反馈问题，另一部分是测试过程中发现的问题。这部分的流程直接指派给开发进行处理，无需进行需求分析。
4.2.1 新增Bug（缺陷）
- 参与人员：服务台/测试人员，以及其他发现问题的人员
- 具体操作：
- 点击页面【Create】创建一个Bug 类型的Issue事件，或者从Test测试用例的Execute执行中，创建一个Bug
- 选择组件
- 输入Summary概述，输入Description描述
- 选择优先级：P1/P2/P3/P4，选择问题严重程度：致命/严重/一般/轻微/建议
- 指定修改人员，指定人默认为组件负责人，如果明确实际修改人直接指派给修改人，不明确可以按默认
- 点击【Create】创建一个Bug。
图 4-22 创建Bug
4.2.2 执行开发（修改Bug）
- 参与人员：开发人员
- 具体操作：开发人员完成指定到自己的Bug，完成后修改状态为Resolved指回给任务分配人，进行验证，通常是测试人员。
4.2.3 检查BUG修复（缺陷）
- 参与人员：服务台/测试人员，或者业务
- 具体操作：验证已经Resolved的Bug类Issue，如果通过将状态改为Done，如果不通过，将状态改为Reopen，重新指回给开发人员进行修改。