产品
协作&沟通
看板
思维导图
在线文档
企业微信集成
规划&跟踪
敏捷需求规划
迭代计划&跟踪
缺陷跟踪管理
测试计划&用例
任务&工时管理
构建&交付
代码集成
持续集成&交付
应用&扩展
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单独辅导沟通,帮助其提升。 这样有助于团队树立榜样,建立好的团队文化和氛围。