紫龙游戏解锁 Jira 与 Perforce 的游戏开发行业实践

近日，在龙智携手 Atlassian 与 JFrog 共同举办的“大规模开发创新：如何提升企业级开发效率与质量”的线下研讨会中，紫龙游戏上海研发中心高级项目管理主管叶凯威为大家带来了精彩演讲， 分享紫龙游戏的项目管理工具与流程，以及他们使用 Jira 与 Perforce 的实践心得。

叶凯威

紫龙游戏上海研发中心高级项目管理主管

演讲视频：

演讲文字回顾（有删减）：

大家好，我叫叶凯威，来自紫龙游戏公司，很高兴能在这里与大家进行分享。今天分享的主题是 Jira 赋能游戏开发工业化，主要是 Jira 在我们紫龙游戏的规划中承担的角色及具体实践。

今天的分享主要分为两部分，第一部分项目管理的工具与流程，第二部分会结合第一部分，分享Jira与Perforce的使用实践。

项目管理的工具与流程

首先分享项目管理工具的核心思想。首先，最重要的是流程先于工具。Jira 作为一个工具，应当服务于项目管理流程，保证流程的 100%执行和高效执行。

其次是工具保证信息传递与处理效率。第一，工具保证信息传递给目标对象；第二，保证信息传递的准确性和完整性；第三，保证信息处理高效及时（尽量自动化代替手动）。

最后是数据的结构化。数据需要有结构化的表达和存储，才能根据项目管理流程的需要进行定向数据统计、处理和分析。例如，我们会在 Jira 工单中添加功能范畴标签和职能标签。功能范畴标签指的是此工单与某功能模块相关，职能标签指当前工单由哪一职能来执行。根据这两个标签，可以统计出基于某个版本、某个功能模块中某个职能共有哪些任务需要完成。

紫龙上海研发中心的项目管理流程大致分为三个阶段。第一阶段称之为瀑布式开发期，在整体版本生命周期的时间长度中大约占比 60%-70%。第二阶段称之为敏捷式开发期，主要处理版本初期未考虑到的优化需求的开发。第三阶段称之为质量迭代期，主要处理当前版本的剩余缺陷。

瀑布式开发期大致分为三个流程。首先是版本目标确认，此阶段要求每个项目的负责人在版本初始阶段整理出需要在此版本中实现的一系列 Feature，其次项目制作人发送邮件到公司管理层以进行审批、确认。在此基础上，我们会基于确定的版本范围来整理具体的开发计划。

Jira 使用实践及其与 Perforce 的结合使用

主要分为四个部分。第一部分是 Feature List 制定与项目计划生成，第二部分是项目计划与 Jira 系统同步，第三部分是 Jira 工单执行，最后是贯穿整个开发流程的 Jira 日报与项目计划日报。

• Feature List 制定与项目计划生成

在 Feature List 制定与项目计划生成过程中，主要会面临两个痛点：

1. Feature List 需要多人协同整理编辑，频繁由专人进行整合，整理效率低；

2. Feature List 拆分出的 WBS 任务项数量很多，项目经理需要手动将任务项誊写到 Project 文件中。

基于这两个痛点，我们的解决方案有两种。第一种是采用在线表格协同编辑，第二种是开发了一个 Excel 插件，基于固定格式的 WBS 任务项，可直接输出 Project 文件，节约时间。

• 项目计划与 Jira 系统同步

在项目计划与 Jira 系统同步过程中，一开始，我们基于在 Project 中排好的开发计划，需要人工手动在 Jira 中创建与开发任务对应的工单及相关依赖关系。这将导致大量的人力、时间被耗费，并且导致工单创建不及时。基于这个痛点，我们开发了 Project 插件，可自动将 Project 中的开发任务导入 Jira 建单，从而使实际开发计划中的任务与 Jira 中的子任务一次性同步，确保项目计划的有效性。

• Jira 工单执行

接下来，我将具体介绍紫龙在 Jira 工单使用执行的具体实践。首先是使用的工单类型。

在瀑布式开发期，我们重点处理 Story（对应 Feature）和 Breakdown（对应 Feature 拆分出的 WBS 任务）类型工单。

在敏捷式开发期，我们重点处理 Task（对应小优化需求）和高优先级 Bug 类型工单。

在质量迭代期，我们重点处理次优先级 Bug 类型工单。

Story 使用实践

在实际处理 Story 时，我们遇到了策划未经管理层审核，自行添加 Feature List 之外的新 Feature 需求，创建新的 Story，从而导致版本范围不可控的情况。为解决这一问题，我们在 Jira 中设置了一个权限：只有项目经理可以创建 Story。

△ Jira 中除项目经理之外的用户无创建 Story 选项

Task 使用实践

接下来是 Task 使用实践。以下是比较重要的一下实践，后续我也会具体讲解：

• Task 支持根据应用场景，配置常用的固定工作流

• Jira 中设置权限：只有职能 leader 可以创建 Task

• Task 通过职能标签进行跨流转，默认转给职能标签负责人

• Task 状态变为已解决，自动转给对应功能范畴标签所负责的 QA 负责人

• Jira 中设置权限：只有 QA 才能关闭 Task

• 版本状态变为开发需求冻结后，新增 Task 自动转给项目负责人确认

第一流程痛点是，团队在使用 Task 时，可能遗漏处理个别环节。例如在游戏开发过程中，音频部门会遗漏某个角色的音效。音频属于生产流程中最末端的环节。根据这一目的，我们开发了 Task，能够支持具体的应用场景、可配置常用的固定工作流。

第二个流程痛点是，所有策划都在提 Task，且未经过 leader 审核，存在一部分不合理或必要性不高的需求。基于这一痛点，我们 Jira 中设置了相应权限：只有职能 leader 可以创建 Task，达到控制 Task 合理和调性的目的。

△ Jira 普通用户无创建 Task 选项

第三个流程痛点是，策划想开发团队提 Task，绕过职能 leader，相当于直接给开发团队中负责开发的人员提需求，导致对应的职能表不支持，无法整体控制开发质量以及管理团队工作安排。我们的解决方案是在 Task 中增加职能标签。一般用户只能通过修改职能标签进行跨职能流转。当此标签发生变化，Jira 系统可根据规则默认转给职能标签负责人，实现了整体生产环节的可控。

第四个流程痛点是，Task 变为已解决之后，未转给 QA 进行测试便关闭，存在质量隐患。我们的解决方案是将 Task 变为已解决，自动转给对应功能范畴标签所负责的 QA 人员。还可以在 Jira 中设置权限——只有 QA 才能关闭 Task，确保所有的 Task 都经过技术人员进行有效测试。

△ 系统自动将职能标签改为“QA”，并且将经办人改为负责对应功能范畴标签的 QA 人员

第五个流程痛点是，在开发需求冻结后，仍然有不少 Task 提出，影响版本最终交付。针对这一痛点，我们在 Jira 版本中设置了“开发需求冻结”状态，在此状态产生变化时，新增 Task 会自动转给项目负责人，由其确认是否有必要进行开发。这将大大减少不必要的 Task 开发需求，以及确保项目顺利进行。

△ 系统自动将状态改为“待确认”，将职能标签改为“制作人”，并且经办人也随之修改

Bug 使用实践

接下来是一些 Bug 的使用实践。

• 非 QA 或新人 QA 提报的 Bug 工单，自动转给功能范畴标签的 QA 负责人审核是否符合规范；

• Bug 通过修改职能标签进行跨职能流转，默认转给职能标签负责人；

• Bug 状态变为已解决，自动转给对应功能范畴标签所负责的 QA 负责人；

• Bug 在已解决状态下，被 QA 打回给开发，则会记录被打回职能及原因；

• Jira 中设置权限：只有 QA 才能关闭 Bug。

我将主要介绍加粗部分的实践，因为其他实践与 Task 类似，故而省略。

在生产过程中，我们会发现非 QA 或新人 QA 提报的 Bug 工单不规范，缺少复现步骤、日志等必要信息，影响开发人员修复 Bug 的效率。我们的解决方案是将非 QA 或新人 QA 提报的 Bug 工单，自动转给功能范畴标签的 QA 负责人，由他们来审核是否符合规范。这将从源头确保 Bug 工单中的信息有效性。

△ 系统自动将状态改为“待确认”，将职能标签改为“QA”，并且经办人也随之改为负责对应功能范畴标签的 QA 人员

另一个问题是，许多已解决状态的 Bug 转给 QA，但 QA 测试后发现实际并未修复，极大影响 Bug 修复效率。针对这一点，我们的解决方案是发现 Bug 在已解决状态下但实际未修复，则被 QA 打回给开发，并记录被打回职能及原因。当打回次数到达一定阈值时，可从 Jira 后台拉取数据进行分析。例如哪个功能模块的 Bug 经常被打回、哪个职能修复的 Bug 经常被打回等，从而帮助识别出现问题的环节。

与 Perforce 配合使用

接下来是 Jira 工单与 Perforce（Helix Core）配合使用的实践。在没有使用 Perforce（Helix Core）之前，我们会发现几个问题。首先是版本控制系统中签入的提交没有遵守统一的规范，导致质量参差不齐。第二个问题是签入没有工单对应的提交，缺少主要 leader 确认及 QA 测试，存在质量隐患。第三个问题是可能签入不属于当前分支的提交。因为在游戏上线后，需要管理较多的版本，开发人员容易选择错误的版本。

基于以上三个问题，我们选择使用 Perforce 版本控制系统 Helix Core，并且配合了二次开发使用，能够有效解决问题。

以下是详细流程规范。

开发人员在 Perforce 签入前需要先向 leader 发起 review，否则无法签入。同时，需要人工的工作由 leader 承担，可由机器执行的检查工作由后台持续集成的专业流水线承担，例如代码编译检查、文件命名检查和 Unity meta 文件检查等。

我们还要求 Perforce 签入注释必须有 Jira 单号、版本、功能范畴标签、职能标签，否则无法签入；Jira 配置版本与 Perforce 分支的映射关系，签入注释如果使用错误版本的 Jira 单，也无法签入。

• Jira 日报与项目计划日报

再聊一下 Jira 日报与项目计划日报，它会贯穿整个开发的生命周期。我们在 Jira 日报中遇到的流程痛点是：项目经理需要每日手动统计 Jira 中各类工单变化信息，并向干系人发送日报邮件，统计工作机械重复。为此，我们写了 Jira 每日自动发送日报邮件的脚本，在脚本中定义好需要统计的信息，再由 Jira 配置执行。

我们的 Jira 日报中包含版本中最重要的几个节点、日期、其他规定等。以及可以进行布置开发计划中承担主要开发任务的 breakdown 工单类型。我们会按照细分的职能统计每个职能下的完成数量、完成率和延期任务。

这是基于 Task 的总结。我们会统计当日 Task 变化以及当日总数等。以及我们在做一个新的尝试，增加了各职能待解决 Task 数量的统计。不仅如此，还能统计需求从寒冷变为冻结状态后新增的 Task 数量。

从这张图中可以有效关注到需求中 bug 的变化。

我们会列出截止当日优先级较高的 Task 与 bug 列表。

再说一下项目计划日报。在以往，项目经理需要人工向开发团队逐项确认计划执行进度，每次核对耗时长，难以每日执行并及时发现问题。为此，我们开发了一个 Project 插件，支持即时将 Jira Breakdown 工单进度数据同步回 Project 中，从而确保只要监控好 Jira 更新状态与工时录入规范，就能随时获取最新的管理进度信息。并且每个项目的项目经理会每日更新开发进度，将开发计划同步到工作群中。

以上是我今天的分享，谢谢大家！