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

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

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

演讲视频：

https://www.bilibili.com/video/BV17N4y127sa/?aid=876506736&ci...

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

大家好，我叫叶凯威，来自紫龙游戏公司，很高兴能在这里与大家进行分享。今天分享的主题是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更新状态与工时录入规范，就能随时获取最新的管理进度信息。并且每个项目的项目经理会每日更新开发进度，将开发计划同步到工作群中。

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