jira操作流程
19）点击为角色添加用户，在用户或组输入花名后，再选择作用，选择完成后再点击添加即可。注意：如果是一个项目多次迭代更新，每次迭代更新为一个版本，依次顺延，默认从1.0版本开始。17）模块设置：根据项目实际需要可以按照功能划分，也可以按照人员划分，也可以按照前后端划分。15）优先级：因为优先级之前就已经设置好了直接默认即可，如需修改请联系管理员添加，此处优先级只可查看，不能编辑和切换。1.规范jir
一、目的与范围
1.1目的
1.规范jira在项目管理过程中的使用，保证项目任务信息完整，能全面、实时地反馈项目实际进度及状态。
2.明确jira使用过程中职责，为各级主管在项目管理过程中实施检查提供依据。
1.2范围
在立项之初确定纳入jira管理的各个项目。
二、职责和权限
2.1职责
| 角色 | 职责 |
| 公司各级领导 | 1.审核项目目标完成情况，重大事项决策； 2.关注项目进度。 |
| 项目经理 | 1.提出需求，负责项目目标的制定； 2.根据项目目标组织制定目前期预估计划，组织项目各阶段活动，最终完善项目总体计划； 3.提出任务变更； 4.监督与检查项目目标完成情况，发现风险，规避风险； 5.查看项目计划偏离度等。 |
| 开发主管 （研发负责人） | 1.配合项目经理，确认各阶段项目开发完成情况； 2.根据项目需求及目标制定开发计划，组织完成开发计划； 3.根据开发计划进行任务分解，建立jira开发任务，提出任务变更；（包括建立各阶段jira任务，目前只有开发主管才有创建jira项目的权限。） 4.负责安排及跟踪开发任务执行； 5.检查督促组员及时录入任务进度和工作量等数据。 |
| 测试主管 | 1.配合项目经理，确认各阶段项目测试完成情况； 2.根据项目需求及目标制定测试计划，负责制定测试计划，对项目需求进行测试验证； 3.根据测试计划进行任务分解，建立测试任务，提出任务变更； 4.负责安排测试任务执行； 5.检查督促组员及时录入bug和汇报工作任务进度； 6.在项目管理过程中，监督jira的规范使用； 7.检查各项目任务的执行情况，是否有逾期或长期不处理的问题； 8.检查bug录入情况； 9.发出QA提醒及不符合项记录，跟踪解决。 |
2.2用户管理和权限设定
| 角色 | 权限 |
| 各级领导 | 1. 查看所有项目目标完成情况； 2. 查看所有项目全部信息。 |
| 项目经理 | 1. 建立、分配、检查、修改所属项目的开发前期及发布各阶段任务； 2.查看所属项目任务完成情况。 |
| 开发主管 | 1. 建立、分配、检查、修改所负责项目的开发任务； 2.查看所负责项目的任务、日志。 |
| 测试主管 | 1. 建立、分配、检查、修改所负责测试的项目的测试任务； 2.查看所负责测试的项目任务。 |
| 开发人员 | 1. 查看、执行项目范围内的任务； 2.填写任务日志，更新任务信息及工作量信息。 |
| 测试人员 | 1. 查看、执行测试的项目范围内的任务； 2.填写任务日志，更新任务信息及工作量信息； |
三、各个阶段操作规范
3.1立项阶段
| 角色 | 操作 | 说明 |
| 各级领导 | 1.查看、指导项目目标的建立。 | |
| 项目经理 | 1.制定项目目标，并将其作为项目任务录入至jira； 2.每周更新项目进度，作为项目周报供领导查看。 | 建立项目周报汇报任务，每周更新 |
| 开发主管 | 1.制定开发目标，并将其作为项目任务录入至jira； 2.每周更新工作进展，作为开发周报提供领导查看。 | 建立项目周报汇报任务，每周更新 |
| 测试主管 | 1.制定测试目标，并将其作为测试任务录入至jira； 2.每周更新工作进展，作为测试周报提供给领导查看。 | 建立项目周报汇报任务，每周更新 |
3.2开发前期各个阶段
| 角色 | 操作 | 说明 |
| 项目经理 | 1.每周更新项目目标的进度，向领导汇报项目目标完成情况； 2.需求、设计、计划各阶段工作任务的建立录入至jira，通知经办人执行任务； 3.查看任务的进展，发现问题，规避风险； 4.检查任务日志更新情况。 | 该阶段由项目经理主导，负责各任务录入及监督执行 |
| 开发主管 | 1.每周更新开发总体工作进度，向项目经理汇报整体开发部分的工作完成情况； 2.配合项目经理进行需求、设计、计划的任务完成，同时更新jira任务日志及工作量情况。 | |
| 测试主管 | 1.每周更新测试总体工作进度，向项目经理汇报整体测试部分的工作完成情况； 2.配合项目经理进行需求、设计、计划的任务完成，同时更新jira任务日志及工作量情况。 3.检查使用测试工具和jira规范情况，发出QA提醒并监督改正情况。 |
3.3开发阶段
| 角色 | 操作 | 说明 |
| 项目经理 | 1.每周更新项目项目目标的进度，向领导汇报项目目标的完成情况； 2.查看任务进度，并及时发现问题，规避风险。 | |
| 开发主管 | 1.每周更新开发进展，向项目经理汇报开发进度及完成情况； 2.在jira上建立开发任务，组织协调开发组成员执行开发任务、填写工作日志； 3.检查开发组成员所填写的任务日志，提出任务变更。 | 该阶段有开发主管主导，负责各任务录入及监督执行 |
| 测试主管 | 1.每周更新测试进展，向项目经理汇报测试进度及完成情况； 2.组织制定测试用例，进行用例评审，并录入metershpere，以便后续查看； 3.检查测试用例完成情况； 4.检查使用测试工具和jira规范情况，发出QA提醒并监督改正情况。 | |
| 开发工程师 | 1.执行开发任务，填写任务日志及工作量。 | |
| 测试工程师 | 1.编写测试用例，并在metershpere上更新测试用例完成情况，并填写工作量； |
3.4测试阶段
| 角色 | 操作 | 说明 |
| 项目经理 | 1.每周更新项目目标的进度，向领导汇报项目所处的阶段，目标完成情况； 2.查看任务进度，并及时发现问题，规避风险。 | |
| 开发主管 | 1.每周更新开发进展，向项目经理汇报开发进度及完成情况； 2.组织协调开发组员执行bug修改任务，填写工作日志； 3.检查开发组成员所填写的任务日志及工作日志，提出任务变更。 | |
| 测试主管 | 1.每周更新测试进展，向项目经理汇报测试进度及完成情况； 2.在jira上建立测试任务，组织协调测试组员执行测试任务，填写任务日志； 3.检查测试组成员所填写的任务日志及工作量，提出任务变更。 | 该阶段由测试主管主导，负责各任务录入及监督执行。 |
| 开发工程师 | 1.执行bug修改任务，填写任务日志及工作量。 | |
| 测试工程师 | 1.执行测试任务，填写任务日志及工作量； 2.在jira上录入bug，并指派相应开发人员解决； |
3.4发布阶段
| 角色 | 操作 | 说明 |
| 项目经理 | 1.每周更新项目目标的进度，向领导汇报项目所处阶段，目标的完成情况； 2.查看任务进度，并及时发现问题，规避风险； 3.跟踪项目发布阶段的进展，发布成功后通知相应客户验收。 | 该阶段由项目经理主导，负责各任务录入及监督执行。 |
| 开发工程师 | 配合项目经理完成发布阶段的上线任务 | |
| 测试工程师 | 对已上线的项目进行线上验证 | 若不能验证，请及时与项目经理沟通 |
3.5上线维护阶段
| 角色 | 操作 | 说明 |
| 项目经理 | 1.实时跟踪并反馈客户反馈的问题 | 该阶段由项目经理主导，负责各任务录入及监督执行。 |
| 开发主管 | 1.组织安排开发人员解决上线问题，并监督检查任务的解决情况。 | |
| 测试主管 | 1.组织安排上线问题的测试任务，并提交bug到jira，指派开发人员解决； 2.bug修复后指派测试及时验证，若没有问题，及时发布上线。 |
3.6一般要求
1）任务日志中需清晰准确的描述：日期、进度、工作量、描述。每天下班前填写当天日志。
2）由于需要精准统计项目实际工作量，需要各级主管将项目的虽有任务均纳入jira中管理。任务可分为文档类任务、代码类任务、测试类任务、评审类任务。
3）一般情况下，维护中的项目也应统一纳入jira管理。
4）项目经理、开发主管、测试主管。在jira上单独建立一条项目任务，每周在jira上更新任务进展，作为周报输出。
四、jira的基本概念
4.1jira的基本概念-问题
| 名称 | 解释 |
| 项目 | 问题所归属的项目。 |
| Key | 问题唯一的标识编号。 |
| 主题 | 简要说明问题。 |
| 类型 | 查看下面的类型列表。 |
| 状态 | 当前问题在生命周期（工作流）中所处的处理状态。 |
| 优先级 | 这个问题相对于其他问题的重要程度。 |
| 解决结果 | 如果问题被解决或者关闭了，说明问题解决的结果。 |
| 影响版本 | 表明问题发生在哪个版本中。 |
| 修复版本 | 表明这个问题已经在哪个版本中被修复。 |
| 模块 | 表明这个问题影响哪个模块。 |
| 标签 | 为问题添加分类标签。 |
| 环境 | 发生问题的软硬件环境。 |
| 描述 | 详细描述问题的现象。 |
| 经办人 | 谁来负责这个问题。 |
| 报告人 | 谁提交的这个问题。 |
| 关注者 | 有多少人关注这个问题。 |
| 到期日 | 希望这个问题在何时之前解决。 |
| 创建日期 | 问题提交的日期。 |
| 更新日期 | 问题被最后一次编辑的日期。 |
| 解决日期 | 问题被解决的日期。 |
| 预估时间 | 原预估时间是估算的解决这个问题需要耗费的时间。 |
| 剩余时间 | 剩余估算时间，根据预估时间与实际工作时间计算出来的解决这个问题还需要的大概时间。 |
| 实际工作时间 | 为解决这个问题，登记的实际的实际工作时间的总和。 |
4.2问题类型
| 问题类型 | 描述 |
| Epic | 适用于大型用户故事的事务类型，需对其加以细分。 |
| 改进 | 对现有功能或任务的改进或完善。 |
| 故事 | 适用于一种用户故事的事务类型。 |
| 缺陷 | 影响软件正常功能的问题。 |
| 任务 | 需要完成的任务。 |
| 新功能 | 未开发的产品新功能。 |
| 子任务 | 问题的子任务 |
4.3解决结果
| 解决类型 | 描述 |
| Fixed（已解决） | 报告的问题已经被解决 |
| Won‘t Fix（无需解决） | 报告的问题不需要解决 |
| Duplicate（重复） | 报告的问题与其他已提交的问题重复 |
| Incomplete（不完整） | 问题描述不完整 |
| Cannot Reproduce（无法重现） | 无法重现问题，或资料不全 |
4.4优先级
| 名称 | 描述 |
| Blocker（紧急） | 程序无法运行 |
| Critical（严重） | 数据丢失，系统经常崩溃 |
| Major（一般） | 一般性错误 |
| Minor（次要） | 程序次要功能出现错误，或可通过其他手段解决 |
| Trivial（无关紧要） | 不影响程序运行的错误，如拼写错误等 |
4.5问题状态
| 名称 | 描述 |
| Open（开放） | 提交的问题还没有开始解决 |
| In Progress（处理中） | 提交的问题已经开始处理 |
| Resolved（已解决） | 解决方案已经被提出，但解决结论未获认可，等待问题报告者确认。确认的结果是“Reopend”或者“Closed” |
| Reopened（重新打开） | 被解决或被关闭的问题没有彻底解决，需要重新开始 |
| Closed（关闭） | 提交的问题已经被解决并关闭 |
| 待处理 | 提交的问题等待开发处理 |
| 研发定位 | 研发开始处理问题 |
| 研发定位审核 | 研发定位完成后提交给研发负责人检查 |
| 修改实施 | 研发负责人审核通过后，研发开始修改问题单 |
| CMO归档 | 研发提交代码后，需要CMO进行代码检查 |
| 问题挂起 | 问题单暂时不解决，后续再解决 |
| 测试挂起 | 测试暂时不可验证，后续再验证 |
五、操作流程
5.1创建项目
1）使用管理员账号登录，点击右上角创建项目按钮。
2）进入到创建项目类型选择页，根据相对应的项目需求，选择相对应的项目类型。
3）点击下一步，进入到项目管理详情页，继续点击选择。
4）点击选择之后，进入项目管理填写页面，填写相应的项目信息。
5）点击提交进入到项目落地页，点击项目设置，进入到项目设置详情页。
5.2项目设置
1）点击左上角汇总，能够看到所有项目信息。
2）点击详情，能够更改项目创建时的信息。
3）点击重新索引项目，可以重新创建索引，默认即可。
4）点击删除项目，刚刚创建的项目会被删除，请谨慎操作。
5）点击问题类型，再点击操作，可以选择编辑问题类型和使用不同的方案。
6）先点击编辑问题，跳转到问题类型方案页面，可以选择各种问题的类型方案。
可以根据相应的项目，自行选择即可。
7）再点击使用不同的方案，跳转到方案选择页，可以根据相应的项目选择相应
的类型方案。这里有三种选择，①选择已存在的问题类型方案②选择一个与
现有项目相同的方案③创建一个新方案。
8）点击单个问题类型，然后再点击编辑可以针对于单个问题类型进行编辑。
Epic、改进、故事、缺陷、任务、新功能、子任务单个问题类型操作都相似。
9）点击工作流，选择添加现有的工作流。
10）现有的工作流很多，我们一般缺陷就选择QA工作流，其它问题类型，我
们一般选择PD工作流。这里是之前创建好的工作流，也可以自己点击单个问题类型创建工作流。
11）点击切换方案，可以选择以前项目的工作流进行关联。
12）界面：一般默认即可，也可以根据项目需求进行编辑或者切换不同的方案。
14）域：域一般默认的即可，也可以根据项目实际需要进行编辑或切换不同的使用方案。
15）优先级：因为优先级之前就已经设置好了直接默认即可，如需修改请联系管理员添加，此处优先级只可查看，不能编辑和切换。
16）版本设置：输入版本名称，开始日期和发布日期即可。有说明可以添加上，若无可以不用添加。写好了直接点击添加按钮即可。注意：如果是一个项目多次迭代更新，每次迭代更新为一个版本，依次顺延，默认从1.0版本开始。
17）模块设置：根据项目实际需要可以按照功能划分，也可以按照人员划分，也可以按照前后端划分。可以填写相应的主管，也可以填写默认经办人。默认经办人则为bug处理的默认人员。
18）用户和角色：点击编辑默认按钮，可以编辑默认的项目负责人和默认经办人。
19）点击为角色添加用户，在用户或组输入花名后，再选择作用，选择完成后再点击添加即可。Administrators为管理员，可以进行项目设置和添加角色。Developers为开发人员，只能对bug进行操作，一般都默认为此权限。
20）剩下的全部按照默认来即可，无需设置。如有需要可以自行设置。
5.3问题单流程
- 测试（QA）在jira上提交bug后，此时bug状态为待处理。默认指派给对应的开发负责人，由相应的开发负责人去自行分配。
- 开发负责人分配后，由相应的开发去进行定位，此时状态为研发定位。
- 研发定位成功后，提交给研发负责人审核，此时状态为研发定位审核。
- 研发负责人审核审核通过后，此时状态为修改实施。
- 研发负责人审核不通过，返回给研发重新定位。（此处需要增加一个备注输入框，填写打回的原因。）
- 开发修改实施完成后，就提交代码给CMO人员进行审核（CMO人员由研发负责人指定人员）。此时状态为CMO归档。
- CMO归档不通过返回修改实施状态，此处需要增加一个备注输入框，填写打回的原因。此时状态为修改实施。
- CMO归档通过后，jira上问题单上会自动生成代码提交的连接地址。此时状态为待验证。
- 测试验证通过后，此时状态为已关闭。
- 测试验证不通过，此时状态为重新打开。
- 测试暂时不能验证，此时状态为测试挂起。
- 待处理的问题，可以进行直接验证。
- 研发定位和研发定位审核过程中，因为时间来不及，或者说暂时不需要处理，可以将该问题单挂起，后续再处理。此时问题单状态为问题挂起。
- 测试验证问题单时，因为部署、环境（测试、线上）等原因引起暂时不能验证的问题单，暂时可以挂起。此时问题单状态为测试挂起。
希望对您有所帮助，谢谢~
DEVPOD社区，旨在打造高质量的DevOps工具知识库。包括商业工具：Atlassian Jira，Confluence，Jfrog，极狐， CodeBeamer等。开源工具栈如：Gitlab，ArgoCD， Jenkins等。 致力于帮助企业建实现云原生时代DevOps转型。
更多推荐
16
0- 0
已为社区贡献2条内容
所有评论(0)