本篇目录

作者：罗聪翼
很感谢作者的分享，也希望他的敏捷开发实践经验以及使用禅道做游戏开发项目管理的规范能对大家的项目管理有所启发。

一，划边界

柳传志总结过3句企业要素，“搭班子、定战略、带队伍”，其中两大要素就是和人有关：搭班子和带队伍，知易行难，是科学更是艺术。实践中每个人对事的理解不一，例如项目的目标和结算在老板和员工心目中也是不一样的，管理者看结果，专业的事情留给实践者，而引导员工如何落地就一定要重过程。

整理一下，启动一个项目的第一步就是立项，如何确定产品的方向和目标，如何把控项目进度，如何驱动产品迭代，以及如何调动团队积极性等。去年在团队上最深刻的反思，就是“和程序作斗争，而不要和程序员作斗争”。

3大要素也适用于过程，立项是基于产品去明确目标，而落地则是基于时间来考虑过程，同样包含5 个关键步骤：选方向、定目标、控进度、带团队和排干扰。

1，方向

6年前从加入初创公司踏入了创业之路，那时我们的模式很原始很作坊，一切立项都是几个人坐下来各自描述心中的想法，当一个点子获得认可，大家一拍脑袋，“我靠这事靠谱！做出来一定呲皮！”，紧接着就挽起袖子开干。

那时手机游戏没现在这么复杂，4个人1个月就能做出一款3D游戏，完成后上传商店，默默的盼望点击和下载量爆涨，大部分结果最后都证明草率的立项只会是大家的一厢情愿，心中的那股情怀也在这种不断被现实打脸的过程中消失殆尽。

15年开始再做产品时，我们总结了之前的经验，开始尝试花掉6个月的时间去调研和思考方向，其中3个月会做各种各样的Demo，一切妥当之后才会搭弓上箭，3个月做出第一版，上线验证开始迭代。所以，方向成为了整个项目中最重要的一件事，无论是基于产品，还是基于过程。

为产品定方向，基本上是在考验创业的领导人和你对合伙人的认识，无论是经典常用的SWOT还是5W2H分析，产品定方向是启动一切之前最大的赌注。这里我不做展开，先将视角回归在过程，起码需要团队坐下来讨论并同步这么几个事情：

方向和愿景：用最简单通俗的语言描述产品的价值
机会和趋势：不管市场是红还是蓝，了解对手甚至BAT为什么做或者为什么不做，明白了缝在哪，然后才知道怎么去拼
用户画像和用户需求：针对用户谈价值需求，例如聊天记录可以同步到云能方便用户切换使用场景，不一定提商业价值，例如用户可以加入会员提升同步上限
已知的解决方案和机会：我们和隔壁的公司和隔壁的隔壁的公司都在做这件事，那么优势是什么
团队的利益点：明确大家的优势和做完之后收获的成长和利益，不仅仅包括分钱
团队的弱点：提出问题和困难，预估一些需要众人去啃的硬骨头
时间结点：市场和资源的时间结点在哪，决定了大家手上的船票登上的是艘大船还是小船，还是自己划水跟着船前进
上线计划：对游戏有封测、内测和公测，对APP呢，比如开个发布会
核心衡量指标：成不成总要有个依据来支撑项目前进，用户量？流水？企业估值？

2，目标

也许是和外企的经历有关，以前我对目标的认识就是KPI（Key Performance Indicator/关键绩效指标），可完整可量化的业绩指标（基于SMART）。在实践中，我不断思考以何种形式来将目标量化，例如代码质量是否可量化，内存调优是否可量化，兼容性测试是否可量化，美术资源压缩优化是否可量化，这个思维影响了我很长一段时间，回顾看看，发现自己一直奔波在过度依赖理性数据来执行判断。

几个月前和HR聊到目标时，他给了我另外一个思路，PBC（Personal Business Commitment/个人事业承诺），相比KPI，更适用于一些难以量化的场景，特别是针对研发这样输出价值难以量化的对象。前者是自上而下的目标分解，而后者是在理解目标之后自下而上的主动承诺。当一件事呈现双向性的时候，不管你在团队中处于什么样的角色，信息都能实现同步的传达，一线工程师不会和产品总监的当前工作计划产生隔离，团队就不会那么容易产生跑偏和脱节。

换而言之，实现目标达成的最佳工具和手段，就是去掉沟通的障碍，降低通达的成本。有个验证团队是否拥有一致目标的方法，你问一个团队负责人他某一个下属的工作职责是什么，不多不少就3条，他说完后你记下来，接着你去问这位下属，你的工作职责是什么，也是3条，完了两边一对，如果内容不一致，那么团队的沟通在目标达成上一定存在问题。这个方法我屡试不爽。

这种继承式目标加关键结果导向的方式，实际上刚好匹配了Google的OKR（Objectives and Key Results/目标与关键成果）模式，它驱动了Google从40人发展到40000人，且大而有序。

3，控进度

以前做单机游戏，左手边坐的策划，右手边坐的主程，3个人有问题随时转头。当后来开始牵头网游项目，团队从3个人一下扩张到20人，算上运营和客服，小30个人的团队，此刻传统的沟通方式和协同就出现了大量的问题。信息不同步，需求和缺陷的杂糅，版本管理混乱到无法回滚，根源其实就是进度的失控。

复杂庞大的项目执行起来最重要的一环就是控制进度，借助 SCRUM思路来指导，实践中采用包括将单Sprint细分为2周，每天强调沟通的站立会，目标都是在确保每个环节都能可控，但信息流是庞大的，一旦有产品上线，在研版本和在线版本，反馈需求和运营需求，产品计划和市场计划，客服追踪和巡检测试，如果一切都需要靠手动和人脑去关联，会崩溃的。

流程中因为有了阶段划分，就一定会有检查点，不论是里程碑的发布，还是研发阶段性接入进入调优阶段，持续和梯度改进才能体现迭代的意义。

4，带团队

我曾尝试去这样假设，如果一个项目团队是因为发起人或者精神领袖的个人光环而凝聚在一起，一旦这个人离去，这个项目会怎么办？

为了验证，我实践了这个假设，对于一个初创型的团队，完全去中心化真的是作死。我尝试用规则来稳定和平衡，但事实证明，相同的价值观和缘分是让团队凝聚起来的首要前提，否则小团队这般，未来如何才能大而有序？

SCRUM中强调的一点是主动和自觉，包括任务都应该是自由领取而非强制指派，构建小而美的团队不能仅仅只靠核心团队，否则这是在人为的在团队中划成了两派，一派核心成员为了理想和目标奋斗，一派成员就是打工心态，这样的团队很难成事。

团队的成员结构也造就了团队的独特，在初创阶段还不可能使用大规模团队的管理方式，所以需要结合实际情况找到最佳的迭代节奏，先慢后快，还是先紧后松，一切都需要根据实际情况来调整。

当前几个迭代跑动顺利之后，项目的权限就需要开始逐步下放，例如项目经理就需要成长为Scrum Master，产品经理细分到产品甚至成为模块的Owner，团队成员从team member到team leader的成长，需求的拆分由技术主管交棒给团队成员，至于之前提到的考核，也可以化零为整，调整为团队的共进退，而不是个人的独立考核。

敏捷不提倡单兵英雄主义，但一定需要给到团队反馈和信心，所以有几个会议需要在过程中强调议程和参与者，包括站立沟通会，需求完成后的演示会议，复盘总结会，提高团队的参与感和成就感。

5，排干扰

干扰来自于各方面，包括：优先且紧急，不优先且紧急，优先且不紧急，不优先不紧急。当发现团队忙的昏天黑地，但成绩却十分缓慢或者依然存在大量延期，大可回头看看规划过程时，是不是在将有限的兵力去实现无意义或者并不是最重要的任务。

举个栗子，老板有一天走过来，说我需要做个什么巴拉巴拉，你看这么重要的事情，尽快完成！有时这种指令的传达会出现多头管理，那就是其实本来大家都清楚时间不够了，但因为这是老板说的，所以研发人员有时会自告奋勇地表现一下，没问题可以加！然后偷偷调整了开发计划。项目经理听到就不干了，说这样计划就不对了，但员工说这是老板要求的，项目经理就去找老板理论，老板说既然你来了那就你来安排吧，项目经理说做可以，请等待N周，老板不干了说你太不重视我需求了！吵着吵着，项目经理离职了，挣了表现的员工因为项目延期也没捞到什么好处。别笑，这栗子还真事，成都某幼教产品团队，老板和产品经理是夫妻，项目经理干的里外不是人，库房里产品堆积如山，据说2016年的目标是响应国家号召：去库存。

元旦前我面试了一位应聘者，她在某财务软件公司任职期间负责研发团队的QA工作，她有个思路我很赞同，那就是将需求的价值和人力的投入估算出研发的ROI（Return On Investment/投资回报率），用于评估研发的性价比，当然参数还包括了时间成本等。之前她就发现团队效率特别低，之后开始找原因，发现产品需求来源于深圳公司，人员协同靠远程，因为成都这边只是研发团队，上一个需求还没消化，下一个需求又来了，有时需求专业度较高，还得从深圳派行业专家过来给程序员培训！当初选择在成都建研发中心是理解这边人员成本低，可是纳入公式后发现，同样的成本去深圳少雇佣几个贵的程序员，研发周期反而更短，最终成研所在ROI面前完败，整体部门被裁掉。

这两个小例子，其实都是希望证明一点，小而美的团队需要更紧密的协作和更一致高效的步伐，管理者的心态需要转变为服务者，需求的归口和权利的下方应该提前约定。敏捷不是不接受变更和插入，而是需要协调一个共同认可的方式进行。一个项目经理最厉害的时候就是这个团队不需要你了，作为Scrum Master应发挥的是教练角色，而不是保姆角色，这样才能构建一个有自我组织的团队。

二，实施

敏捷开发宣言告示了我们将思路付诸实践的重点：

部署实施敏捷其实有很多方式，借助部署指南，最传统的方式是卡片和看板，借助沟通来完善项目燃尽，评估方式还有打估算扑克这种神器。选定方案前摸索了大量工具，我试用过 worktile，project，redmine，灰狐协作，Jira（最难用没有之一）， tower，最终选择了禅道。

接下来，就分享下经历了3年反复修订的敏捷实践吧（终于可以祭出这张图了 ¯\_(ツ)_/¯）

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目录，并且提交给运维和市场部，用于服务器端发布和客户端升级。具体存放规则如下：