产品
协作&沟通
看板
思维导图
在线文档
企业微信集成
规划&跟踪
敏捷需求规划
迭代计划&跟踪
缺陷跟踪管理
测试计划&用例
任务&工时管理
构建&交付
代码集成
持续集成&交付
应用&扩展
T魔方
第三方集成
解决方案
轻量协作
敏捷研发
DevOps持续交付
客户案例
支持
在线帮助
上手视频
帮助文档
使用手册
新鲜Show
服务支持
客户服务
小微扶持
合作伙伴
95716
中文
中文
English
Beta
登录
注册
行业案例
black;王者荣耀国际版;自研游戏项目管理经验
扫一扫分享此案例
扫一扫分享此案例
扫一扫分享此案例
从2008年起，腾讯高级项目经理 !!#e69138 张瑨烨!! 先后担任了QQ飞车、天天飞车、极限三国、AOV的项目经理，已有接近10年的自研游戏项目开发经验，现任职腾讯Arena of Valor(王者荣耀国际版)高级项目经理。 以下是根据其多个项目的经验，总结出的在腾讯自研比较通用的模式。具有一定代表性，但肯定不适用于所有，仅供参考哈。 ## 自研游戏项目的一般流程 ### 1 版本和迭代 在开始一个项目之前，我先说下版本和迭代的概念：  __版本__ • 版本所实现的组合特性决定其整体价值； • 应从全局的视野规划版本的内容，确保版本的各部分内容组合能实现价值最大化，避免局限于单一功能的实现而忽略全局。 __迭代__ 在确定迭代时要注意以下三点： • 一个版本包含多个迭代； • 每个迭代都实现版本的主要特性； • 之后迭代是前面迭代的优化或增量实现。 我经历过的几个项目，由于规模较大（都是50人以上的团队），一般都是一周一个迭代，采用“3+2”或者“4+3”的版本节奏，即 __3-4个迭代用来开发，2-3个迭代用来测试__ 。如果是小型的轻量级项目，也可以采用3天开发，2天测试这样在1个迭代就能闭环完成的形式，将会更加敏捷。由于我没有参与过这样的项目，所以本文主要介绍规模较大项目的管理方式。 ### 2 版本研发流程 版本研发流程概括来说就是： !!#e69138 需求评审 > 迭代开发 > 研发测试 > 运营测试!! 几个环节不断循环的过程。  下图是将流程按照角色和阶段进行分解，可以清楚看到每个阶段不同角色需要做哪些事情。  将需求的工作流梳理出来，这些流程都可以在TAPD中进行自定义，通过TAPD便可以实现不同角色对于同一个需求的流转。  介绍完总体流程，我将针对迭代周期的各个环节的实践，谈谈自研游戏项目该如何进行高效管理。  ## 一、需求评审 ### 1 需求方向评审 在每个版本开始前，我们内部会先对该版本要做的需求进行方向评审。 !!#e69138 我们一般是在当前版本在进行迭代开发时，来规划N+2版本的需求方向，同时策划写N+1版本的策划案。!! 策划和运营确定需求方向，开发根据需求方向预估大致规模，允许有较大误差。  随后召开核心组会议，综合需求的 !!#e69138 优先级和开发成本!! ，进行需求初筛。 通过筛选后的需求，才会安排策划写策划案。 这样做主要是为了 !!#e69138 避免资源的浪费!! ，以往每个版本的需求总会超量，有时甚至要拖走一半的需求。通过需求方向评审，我们可以将需求超量控制在20%-50%以内。 ### 2 需求编写 无论大小需求甚至是小优化项，一旦确定要做都要写策划文档。  TAPD的需求模板功能，可以为系统功能、运营需求等配置不同模板，规定好每个需求要覆盖的内容和字段。 比如我们的策划在些需求时，都要写 !!#e69138 设计目的、术语表、系统概述、详细设计、美术需求和数据上报!! 等内容，并且标注 !!#e69138 需求优先级、用户感知度!! 等信息。 这样能够保证策划内容的质量，避免遗漏。 ### 3 需求管理 随后在需求列表建立Backlog来管理需求。  通过需求分类实现 !!#e69138 版本、需求池!! 的管理，并且在列表中排列需求的优先级。 ### 4 需求评审 需求评审又分为需求预审和需求评审会。 __需求预审__ 需求预审阶段，要督促开发提前阅读策划案。线下点对点沟通，可以提升评审会效率。 !!#e69138 有争议和风险的内容在需求单的评论中标注，作为评审会重点议题讨论。!! __需求评审会__ 需求评审会上，主要是对需求进行拆分和工时估算。 __（1）需求拆分__ 大的功能需求要进行拆分，拆分时主要注意以下三点：  • 单个需求（story）关键路径最好不超过一个迭代周期，控制在2-3天为宜； • 所拆分的子需求合集应该覆盖父需求所有部分， !!#e69138 遵循MECE（Mutually Exclusive Collectively Exhaustive）原则，做到“相互独立，完全穷尽”!! ； • 每一个子需求要以产品视角可验收作为基本标准。 __（2）工时估算__ 由程序和美术进行任务分解及工时估算。  • __预估工时__ ：客户对于完成需求或任务所估计的时间，以人时或者人天为单位（根据项目中度量单位的设置决定）。 分配工时之后，需要通过总工时来衡量整个版本的工作量是否合适，能否在一个版本中完成。 确认之后，便可以将整个版本中的需求，按照优先级等拆分到迭代中。 ## 二、迭代开发 ### 1 迭代启动会（IPM会议） __角色__ PM、程序、美术、技术美术、策划 __输入__ • 客户端、服务器和策划已更新上一个迭代的任务/需求状态 • 策划已准备好版本内容及初版迭代目标 __活动__ • PM召集特性团队（客户端、服务器和美术）参加迭代计划会 • 策划与程序确定迭代完成的story、任务和迭代目标 • 程序提出临时/正式资源需求及 __截止日期__ • 客户端和服务器确认 __联调日期__ ，并在TAPD任务上标注 • 美术确定技术美术资源合入时间节点 • PM根据资源需求和策划意见确定迭代美术资源优先级 • PM在TAPD调整迭代Story、任务列表 __输出__ 迭代目标 任务列表-TAPD ### 2 创建并规划迭代 在TAPD上创建迭代，将确定要做的需求拖入迭代。  当需求拆分不合理或开发进度延期时，可能会出现需求有任务没完成，需要跨迭代，此时建议将整个需求移到下个迭代中，以便于任务的跟踪和需求的完成度的整体验收。 ### 3 分配任务和确认工时 给程序分配任务，并且确认每个任务的预估工时是否合适。  ### 4 需求跟进：状态流转 在迭代开发过程中，各环节需要通过TAPD上需求的状态流转，来实现对需求的跟进。  测试和运营在需求下填写测试重点，程序完成需求后进行状态流转，并通过“源码”功能提交关联代码。 ### 5 需求跟进：更新任务 程序根据实际情况更新任务的花费和剩余工时。 这个环节一般都是难点所在，PM需要提醒程序及时更新任务状态，最好能够培养程序的更新习惯。  • __花费__ ：在一个需求或者任务上已经花费的工时。 • __已完成工时__ ：一个需求/任务上所有“花费”的总和。 • __剩余工时__ ：为完成需求/任务还需要的工时，在默认情况下，“剩余工时”等于“预估工时”减去“已完成工时”。当剩余工时为0时，此时需求/任务工时完成，进度达到100%。 • __进度__ ：对象的进度 = 已完成工时 / （已完成工时 + 剩余工时） * 100 ### 6 需求跟进：工时花费报告 TAPD的报表中提供了工时花费报告。  回顾一周工时的消耗情况，查看明细可以看到具体完成的任务情况。 工时开销不足的同学为主要风险点，重点沟通跟进；工时开销超量的同学，可以提出表扬。 ### 7 Show Case 会议 __角色__ 核心组、PM、需求Owner __输入__ • 程序已完成自测 • 策划已验收当前迭代完成的Story • 策划已配置好资源及数值 策划已更新Story最新状态 • 程序和美术已更新任务最新状态 __活动__ • PM确定特性组展示的顺序，并准备会议环境，一般安排每周五下午定时showcase • PM召集核心组成员参与showcase • 需求Owner向核心组介绍迭代目标，展示当前迭代成果 • PM记录、整理反馈意见和变更，会后与需求Owner一并将反馈转化为需求/任务/Bugs录入至TAPD中 __输出__ 反馈意见及变更 __!!#ff0000 Q&A!!__ __需求变更和紧急需求该如何管理？__ 以下是我们一般的做法，供大家参考： • 所有需求一旦通过评审，不允许更改。 • !!#e69138 所有的需求变更另立新单!! ，同时需要开发参与做工时估算。 • 在迭代开发期所有的需求变更都等同于新需求，按照紧急需求处理。 • 所有紧急需求在完成工时估算后， !!#e69138 超过0.5-1天的需求，需上升给核心组，进行审核!! 。 • 核心组评估紧急需求的风险、成本和进度的影响， !!#e69138 给予对应的资源支持或者调整发布计划!! ，未通过的紧急需求放到下个版本处理。 ## 三、研发测试 ### 1 转测试要求 创建版本号和基线号，所有需求都必须由特性Owner验收通过后方能转测试。 ### 2 创建缺陷 利用TAPD的缺陷模板功能，为缺陷单添加基本的模板字段，这样能够提高沟通效率，方便开发快速定位和解决问题。 比如，我们就要求提BUG时，必须要填写 !!#e69138 测试环境（机型、接入点、包名、大区、帐号、时间）、操作步骤、实际结果和预期结果。!! 不符合要求的缺陷单一律打回。 ### 3 管理缺陷 在管理缺陷的过程中，会使用TAPD中的“缺陷统计报表”来推动BUG修复进度。  ## 四、运营测试 !!#e69138 国内项目!! 的运营测试重点是渠道平台能力测试和iOS预审。 国际项目则需要覆盖本地化测试，和覆盖区域的专项测试。 !!#e69138 运营测试!! 一般在研发版本稳定后才开启，只有稳定的版本测试才有价值。 ## 五、版本总结 版本总结每个版本发起一次，提出一些开放性问题，比如，这个版本中做得好的地方（Well），以及做得不够好需要改进的地方（Less Well），让大家匿名反馈。 针对正向反馈进行公开表彰，改进建议则由leader单独辅导沟通，帮助其提升。 这样有助于团队树立榜样，建立好的团队文化和氛围。
