类目

GoodTeamStudio使用禅道做游戏开发项目管理的规范说明分享

原创

发布：先知于 2016-11-02 15:53:00

最后编辑：潘仙芝于 2016-11-10 14:57:10

16204次查看

本篇目录

GoodTeam Studio是成都的一家游戏开发商，2009年初开始创业，是国内最早的Android游戏开发团队之一。

GoodTeam Studio官网：http://www.gts8.com/c1-Game/GTS-Game.html

以下是GoodTeam Studio使用禅道做游戏开发所做的一些规范说明。

作者罗聪翼。

很感谢作者的分享，也希望GoodTeam Studio使用禅道做游戏开发的经验能对大家的项目管理有所启发。

GoodTeam Studio禅道项目管理说明书

1. 概述

1.1. 文档目的

游戏在开发过程中需要考虑的项目管理流程，包括立项计划，需求分析，项目排期安排，里程碑版本分拆，发布计划，项目中的任务分解，版本出包管理，出包与测试配合，冻结功能后版本协同，基于版本和测试用例的测试任务协同，开发与运维的版本协同，配置文件的管理。

本套流程将使用禅道作为线上协同工具，其他工具功能类似，此处仅举例演示。

1.2. 定义/缩写

PRODUCT – 产品

PROJECT – 项目

S – STORY – 需求

T – TASK任务

TC – TEST CASE – 测试用例

TT – TTEST TASK – 测试任务

BUG – 缺陷

BUILD – 版本

DEBUG – 开发中的测试版本

RC – RELEASE CANDIDATE - 待发布版本

TRUNK – 最后的发布线上版本

QA – QUALITY ASSURANCE - 品质保证

QC – QUALITY CONTROL – 品质控制

2. 命名规范

在开发阶段和上线阶段，版本的命名应该有所区别。

2.1. 语言命名规范

对于不同语言，版本定义不受影响，唯一的变化是命名中的语言标示符，例如ARDCN_DEBUG_20130324表示安卓中文版，而对应具有相同功能的英文版本命名则为ARDEN_DEBUG_20130324。

2.2. 包命名规范

对于处于开发阶段，包命名基于项目，以打包时间来定义包名，并附加DEBUG作为开发版本标示，用日期为数字结尾。

例如ARDCN_DEBUG_20130324（01）表示在2013年3月24日打的第1个安卓中文开发包。当开发完成打包操作后，禅道需要建立对应的项目版本，并关联该包完成开发的需求，或者已经解决的BUG。

如果即将进入上线阶段，版本开发已经封闭功能，不再增加新的功能而只是修改BUG和调优，那么版本命名将修改为RC版本。

例如ARDCN_RC_20130324（02），表示为在2013年3月24日打的第2个安卓中文待发布包。这里的包开发进度会进入快速迭代的状态，直到版本稳定可用于提交发布。

3. 开发流程和周期

3.1. 开发流程

当版本通过测试可以上线后，那么该项目的最终版本将作为TRUNK版本建立在产品的里程碑上。

具体开发路线基于敏捷开发（SCRUM）设计，流程图如下图：

3.2. 开发周期

开发周期按照上线状态分为未上线开发期和在线版本开发期，如果按照需求来分，则以里程碑阶段来划分开发期。例如，在未上线阶段，可以使用快速迭代（SPRINT）的开发方式，以周为单位，在进入上线阶段后，可以使用长期项目，不超过4周。

3.3. 短期迭代中的版本管理

在短期快速迭代中，禅道项目以小标示为主要开发节奏，例如1.1.0和1.1.1，每个版本仅用于BUG修复、优化和小功能更新，因此产品需要快速开启禅道项目，可能会出现只有RC版本而没有DEBUG版本的项目。

短期迭代需要严格控制版本的建立和BUG的指派，避免出现垮版本后开发内容和测试内容复核脱节。

3.4. 长期项目中的版本管理

对于大版本开发，禅道项目以大功能为开发节奏，时间可以以多周计或者以上线更新为标准，例如1.1.2和1.2.0。那么这里的版本任务将以导入的方式新增，因为一个需求可能需要在多项目之间做长期开发和调试。

4. 项目角色

基于禅道对项目负责人的责任划分，包括以下几种

版本的管理统一归口产品经理，统一整理版本号和命名规范，并在打包前将配置更新至SVN，策划和运营需配合，同时告知研发主管打包复核。

5.1. 开发计划和版本的建立

版本由产品经理和项目经理讨论后，确定开发计划（PLAN）和开发版本（PROJECT）的关联，开发计划和项目的关系如下图。

而其中，每个版本的开发需求也将会由产品经理根据策划文档和技术评估，参考工作量和版本计划，分别关联在对应的版本中。

这里计划应该先于版本创建，所以当为指定版本关联需求的时候，需求将自动关联至计划中。

5.2. 里程碑版本的建立

当一个项目阶段完成后，需要创建里程碑版本（RELEASE），其中包含客户端、服务器端和资源包。版本的打包控制和存包控制主要由服务器端主程执行，其中文件名规范同文件命名，由产品经理和项目经理确认复核。

配置目录范例详见下表：

需求（USER STORY）的创建和关联由产品经理负责，全部需求统称为产品的需求集（PRODUCT BACKLOG），当产品经理完成对需求的整理后，具体需求的补充和文档描述由项目经理负责。而被关联至对应项目中的需求，将成为该项目的需求集（SPRINT BACKLOG）。

6. 需求管理

6.1. 需求的创建

需求可以分为以下几类：

1. 基于单个项目周期的需求

2. 基于多个项目周期的需求

3. 基于BUG反馈后新增的需求

4. 基于临时功能调整后变更的需求

这里，前两种需求均为固定设计的需求，在产品设计的初期就已经完成了创建，并且可以根据项目的版本计划做排期关联。

6.2. 需求的状态

需求基于产品的设计和版本计划，所以在创建需求的时候不需要考虑具体实现细节，所有的需求在根据计划和版本录入完毕后，再进入需求的设计和指派。需求的创建具体流程如下。

汇总需求的状态总共有四种状态，分别是草稿（DRAFT）、激活（ACTIVE）、已变更（CHANGED）和已关闭（CLOSED）。对应为需求的流程操作共有：创建（CREATE）、变更（CHANGE）、审核（REVIEW）、关闭（CLOSE）、激活（ACTIVE）。

其中，如果拒绝需求的评审，需要说明理由或是否满足以下情况

1. 不是BUG

2. 已完成

3. 已细分

4. 重复

5. 延期

6. 不做

7. 取消

8. 设计如此

最终，流程图如下：

6.3. 需求的阶段

需求的阶段属性是用于描述需求的关联关系，它可以被手动修改的，但是除了验收阶段需要手动操作，其他阶段内状态都会根据关联情况自动更新的。其中

需求的阶段主要用于辅助产品经理对不同阶段下需求的复核状态做确认，所以总的来说，需求的完整流程如下（这里计划不是必选项，因为计划是选择性创建的）

6.4. 需求的变更

需求如果在经过评审后需要做变更，那么需求的状态将会被修改为草稿，只有当需求评审再次通过之后，才能被激活进入开发阶段。但是需求变更会影响基于需求创建的任务和用例，那么变更流程如下

6.5. 需求的编写

需求描述可以参考INVEST原则，具体为INDEPENDENT, NEGOTIABLE, VALUABLE, ESTIMABLE, SMALL, TESTABLE，其中：

独立性（INDEPENDENT）：要尽可能的让一个需求独立于其他的需求。需求之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合需求和分解需求来减少依赖性。

可协商性（NEGOTIABLE）：一个需求的内容要是可以协商的，需求不是合同。一个需求卡片上只是对需求的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个需求卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（VALUABLE）：每个需求必须对客户具有价值（无论是用户还是购买方）。一个让需求有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个需求并不是一个契约而且可以进行协商的时候，他们将非常乐意写下需求。

可以估算性（ESTIMABLE）：开发团队需要去估计一个需求以便确定优先级，工作量，安排计划。但是让开发者难以估计需求的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者需求太大了（这时需要把需求切分成小些的）。

短小（SMALL）：一个好的需求在工作量上要尽量短小，最好不要超过10个理想人/天的工作量，至少要确保的是在一个迭代（SPRINT）中能够完成。需求越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（TESTABLE）：一个需求要是可以测试的，以便于确认它是可以完成的。如果一个需求不能够测试，那么你就无法知道它什么时候可以完成。

7. 项目管理

当需求被分拆至项目之后，项目负责人包括开发团队需要和产品经理一同进入需求的细分和项目的开发，这里的团队参与很重要，切勿由产品经理代做需求拆分。

7.1. 需求拆分为任务

当需求已经和项目关联完成后，项目负责人或产品主管需要和项目团队开展需求演示会（由需求发起者对需求做说明），并由开发人员做技术评估，评估完成后即可对需求进行任务的拆分。需求拆分中，需要考虑以下几个方面：

1. 任务的分解按照任务类型来分解，例如开发、测试、美术甚至部署环境等。

2. 同类型的任务分解以指派负责人为主。

3. 分解任务尽量保证可以在几个小时内完成，方便追踪。

4. 分解任务时，需要基本确定开发周期，需要资源。

7.2. 任务的指派和完成

当进入任务流程中，项目负责人或产品主管需要配合开发人员完成任务的开发，同时给出需求的复核反馈，其中对应流程如下

其中，任务在创建至结束的状态流程如下

这里的版本提交和测试提交分别详见后面的描述。

8. 版本管理

8.1. 项目阶段性版本

在阶段开发完成后，需要打包建立版本之前，由项目负责人（即策划）提交该版本的需求发布方案，由项目负责人确认版本的完成内容，并且完成第一个版本。这里的打包内容包含已经完成的需求（如果需求分解的任务全部完成，则需求状态将自动更新为已完成）和在该版本中修改的BUG。

当开发打出产品第一个项目的第一个APK包时，禅道上需要建立对应项目中的版本，该版本仅用于关联该版本在此项目中完成的需求。在后面的版本中，需要关联该版本包已经解决的BUG，包括测试已经确认和未测试（需要通过对打出的APK包验证后才能确认）。

作为项目的第一个版本，其中在开发中不会产生BUG，那么打包流程包含如下：

其中，已完成的需求将自动被关联至BUILD页面中，而部分完成的需求可以手动选择关联，但未完成的需求，则不应该关联至打包BUILD中。

建立版本之后，需要将该版本提交测试进行测试用例的关联和测试，测试人员需要将发现的全部BUG汇报在对应的测试用例上，并且关联对应的BUG、需求和任务。开发人员在接到BUG反馈后，可以快速定位开发阶段内的代码COMMIT时间，进入BUG修复阶段。例如已经打出的版本是ARDCN_DEBUG_20130324（01），那么测试的BUG需要全部关联在这个版本上。

当提交测试执行BUG修复，或者增加新的需求之后，DEBUG_BUILD02在打包的过程中，除了需要包含之前存在BUG的需求，还需要包含基于BUILD01的BUG。这里包的命名需要根据时间递增做调整，如果是当天的多个包，那么命名即为ARDCN_DEBUG_20130324（02）。该版本将作为下一个测试任务提交测试。

打包流程如下：

其中，已经完成并且复核无Bug的需求，就不需要关联到当前DEBUG版本中了，如果在上一个需求中报出的BUG已经被修复，那么就需要关联至当前BUILD中做测试验证。

当DEBUG已经结束全部需求开发后，版本将更改为RC版本，主要针对发布前的BUG修复，其中，打包流程如下：

当版本作为TRUNK结束此阶段的项目开发后，测试需要将新增的BUG报到下一个项目中，并且将版本指派给TRUNK。

8.2. 产品里程碑版本

产品的里程碑版本是指某一个项目阶段性结束，或者是以新版本发布为时间点所建立的版本。以禅道为例，该版本直接建立在产品视图下，以对应完成项目中得最后一个版本为基础版本，使用选择调用的方式，将其作为阶段性的TRUNK版本。

其中，所有在V1.0.1开发过程中产生的BUG都不会作为发布项目关联至最终产品发布版本。同时所有已发布的需求将在建立发布之后，自动修改状态为已发布。

需求是否需要关闭由产品经理在版本发布后，手动执行关闭操作即可。同时，在完成里程碑版本建立之后，产品经理需要建立或启动下一个阶段的开发项目，同时在开发端需要对代码做阶段性备份。

9. 测试管理

测试人员（TEST）即QC的主要工作是协助策划根据策划文档撰写测试用例，并验证开发提交的结果是否符合策划的设计预期，而品控人员（QA）则集中在最终游戏的品质，以维护公司的规范和指标为重要工作依据，那么将两者做对比如下：

9.1. 用例管理与开发相结合的主要为QC测试人员，QA流程另行规范。

在需求被创建之后，测试就需要为对应的需求创建测试用例。其中测试用例的依据是策划文档，用例的创建流程如下

其中，只有当需求通过评审后，才能创建测试用例，用例直接基于需求做分解。

9.2. 测试任务管理

在项目创建第一个版本后，项目主管需要将其以测试任务（TEST TASK）的方式提交测试，测试人员接到测试任务之后，除了关联对应需求的测试用例（TEST CASE）至该测试任务之外，还需要关联或者创建新的专项测试用例，用于完成测试任务中的额外需求描述。

其中，测试人员在得到测试任务后，除了选择对应需求和对应需求产生BUG的测试用例关联外，还需要考虑其他特殊的测试用例，例如为单独BUG创建的测试用例，以及用于性能适配等创建的特殊用例。

当测试任务创建完成之后，测试人员将启动测试任务，并逐条执行测试用例，了其中测试用例的执行流程如下：

其中，用例执行的三种结果

1. 通过：用例执行后结果和期望相符，保存用例结果即可。

2. 阻塞：当用例执行的前提条件无法满足时，用例无法继续执行，则需要标记为阻塞。

3. 失败：用例执行后结果和期望不符，需要在结果中提交对应的错误描述，保存后再页面上给出具体问题描述。

当全部用例均执行结束后，测试人员则填写对应备注然后关闭测试任务即可。

9.3. BUG 管理

在测试人员按照测试用例做测试验收的时候，如果测试结果和预期不符，那么测试需要将其作为BUG报给项目，并关联对应的需求或任务。

由于测试任务和需求以及BUG都事先做了关联，那么在填写BUG内容时，需要手动补充完善的内容包括：

1. 模块名称：用于定位BUG位于产品的具体位置

2. 当前指派者：BUG统一指派给项目经理即策划

3. 标题填写：标题使用如下模板【版本号】需求标题-问题描述，例如【1.1.0】发布商城数据-完成后返回错误页面

4. 重现步骤补充：如果重现步骤和测试用例的描述有区别，这里需要做步骤的补充，同时给出必要的截图

5. 相关任务：可选补充，关联对应需求下分解的任务

6. 类型和严重程度：BUG类型包括代码错误、界面错误、设计缺陷、配置相关、部署问题、安全问题、性能问题、适配问题、音乐音效等，严重程度；

如果提出的BUG不是基于测试用例，那么需要在填写BUG详情的时候手动补充全部关联信息。

提交BUG后的解决流程如下：

其中，测试需要先提交给项目经理即策划做评估，如果属于可修复BUG则指派给对应的服务端、客户端开发或美术，由开发做修复并提交计划至下一个BUILD中。如果该BUG属于新的功能需求，或者不能使用修复的方式解决，则执行转需求操作，并转入新建需求的流程中。如果不属于BUG，那么项目经理即策划将给出设计如此的反馈说明，指派回测试人员即可。

如果该BUG需要新的测试角度进行专项测试，那么在BUG指派开发的同时，则需要项目经理通知测试撰写对应的专项测试用例，这里建立的过程将自动关联BUG本身。

在BUG被修复后，开发人员需要在指派回测试人员的同时，填写为解决该BUG所创建的版本号（该BUILD可以提前创建但是不做内容关联，这里的版本创建流程禅道可能会在未来做一定调整），以及该对应的解决方案，其中包括：

1. 设计如此：该缺陷或问题属于设计范围，解决确认由项目经理在确认前给出。

2. 重复BUG：可能存在多名测试人员报出同样问题的BUG，那么关闭的同时需要给出重复BUG的ID。

3. 外部原因：由于断电断网等外部原因导致的BUG，如果设计者认为这属于非开发可解决的问题，那么可以选择该理由解决BUG，并且以新的需求等方式提出解决方案。

4. 已解决：通用的解决方案，需要注明大致的解决方案。

5. 无法重现：在测试的描述不清等情况下，开发人员无法通过重现步骤复现该BUG，那么可以选择该解决方案理由将BUG指派给提出该BUG的测试人员，由测试人员重新提交复现步骤。

6. 延期处理：如果该BUG不属于该项目内可解决的范围，或者属于下一个版本的开发计划，可以选择该方案回复。该BUG将在未来创建项目的时候，以导入的方式成为新项目的开发任务。

7. 不予解决：如果项目经理即策划或开发均评估任务该BUG不需要做修复，包括修复成本过高，设计上处于可接受范畴等情况，可以选择不予解决的方案回复。

那么当全部BUG都被标识解决之后，新的版本将会被执行打包发布，测试人员基于该新版本对BUG做验证测试，如果已经完全修复，测试人员即可选择关闭该BUG，否则打回开发人员重新修复，流程如下：

其中，在创建版本的时候，需要复核所有基于上一个版本提出的BUG修复状态，而复测需要在创建新的版本后做复测，复测完成后才能关闭，如果测试未通过，则需要激活并指派回项目经理。

10. 未完成任务和BUG管理

当一个版本完成开发之后，可能会依然存在没有完成的任务或者暂时没有修复的BUG，那么在项目经理创建下一个项目的时候，则需要将这些未完成任务和BUG重新导入至新的项目中，并由系统自动将对应的需求也关联在一起。

11. 版本对应的 SVN管理

11.1. 打包成果的SVN管理

当版本处于开发阶段时，版本号也是以DEBUG为标示打包时，需要将所有包打包存放在SVN上的DEBUG目录下。当需要进入发布测试阶段时，需要将包存放在SVN上的RC目录下。当测试全部通过，那么主程需要将最后一个RC包复制到PUB目录，并且提交给运维和市场部，用于服务器端发布和客户端升级。具体存放规则如下：