羅聰翼：使用禅道做遊戲開發項目管理的敏捷實踐分享
本篇目錄
作者：羅聰翼
很感謝作者的分享，也希望他的敏捷開發實踐經驗以及使用禅道做遊戲開發項目管理的規範能對大家的項目管理有所啓發。
一，劃邊界
柳傳志總結過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.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目錄，並且提交給運維和市場部，用于服務器端發布和客戶端升級。具體存放規則如下：
其中不同語言包的打包管理放置在同成果目錄下即可,只需要按照語言和打包需求重命名文件夾。
11.2. 版本配置文件的SVN管理
由于開發版本和線上版本的區別，DEBUG、RC和TRUNK版本在配置文件上需要做區分。
在DEBUG和RC版本中，打包主要用于验证需求开发，而不需要做线上的维护，因此版本配置文件管理需要主要集中在游戏本身的配置文件，多个版本之间可以不增加VERSION CODE和资源版本号等文件。而打包对应表需要保存DEBUG和RC打包成果的对应关系。
在TRUNK正式版本更新中，由于打包主要用于更新線上版本，因此版本號和資源包等需要基于線上的版本做自增加，同時版本記錄由統一的文檔管理，存放在PUB目錄下。而打包對應表則需要保存RC和PUB打包成果的對應關系。
12. 執行流程
12.1. 産品经理
産品经理创建産品，産品命名使用”【类型】産品名_平台语言”，例如【研发】我是海盗王_安卓中文，计划命名使用”上线类型几期”,例如”删档内测1期”,其流程如下：
産品经理提出需求，需求命名为动名词，例如调整对话框的样式，其流程如下:
当开发和测试都完成，并且发布的RC版本达到上限要求后，産品经理会执行发布流程，命名模板为”版本名称_版本号“，例如ARDCN_CB1.0.1，流程如下：
在完成上一个项目之后，産品经理需要创建新的项目，并且导入未完成的BUG和任务，流程如下：
12.2. 項目經理
項目經理由策划担任,其完善需求的流程如下：
当评审通过后,項目經理需要和团队一起开启需求分析会,并拆分需求,流程如下:
其中,任務標題模板使用”【類型】需求-任務描述”，其中類型中，開發使用【R】，策劃使用【D】，美術使用【A】，例如【R】主城界面-添加旗幟飄揚效果。
当开发完成并且已经进入测试后，項目經理需要和测试共同配合验证需求和任务的完成情况，流程如下：
所有的BUG都会由測試人員统一录入后指派给項目經理，处理流程如下：
12.3. 開發主管
開發主管为任务的第一接收人，由主程或主美担任。在接到任务后，其对任务的工作流程如下：
当开发完成后,任务会指派回来，開發主管需要对任务和完成情况做验收，流程如下：
當全部開發任務都完成後，需要進行版本創建,命名模板爲”版本類型版本號_日期“，其中版本類型包括DEBUG和RC，例如”DEBUG1.1.4_20140401”，由主程創建版本,流程如下:
版本創建完成後，需要以測試任務的方式提交測試，測試任務命名模板爲“版本號測試類型“，例如“DEBUG1.1.4_20140408功能測試”或“RC1.1.4_20140409回歸測試”，提交測試任務流程如下：
當測試提出BUG後，由項目主管執行BUG分發，接收後處理流程如下：
12.4. 開發人員
開發人員在接到任务后,执行任务流程如下：
在出现BUG的情况下，BUG会由開發主管指派过来，处理流程如下：
12.5. 測試人員
測試人員在需求立项之后,需要根据需求创建测试用例,用例标题命名模板为”需求-测试目的”,例如主界面-角色信息验证测试,创建用例流程如下：
測試人員在接到测试任务后，需要将对应的测试任务关联上去并执行测试，如果测试用例对应的需求有变更，还需要更新测试用例，流程如下：
當測試發現錯誤或問題後，需要報BUG，標題模板爲“【版本號】需求名稱-錯誤描述，如【1.1.0】玩家封號-查詢玩家報錯，報BUG流程如下：
当开发完成了对BUG的修复后，開發主管会重新打包，提交的测试任务中会包含之前报上去的BUG，此时测试对新版本不仅要完成新增需求的测试，还要完成BUG的复核测试，流程如下：
