手游团队协作中的各司其职！

一、名词：

项目：本文中讨论的项目都是软件项目，并不假定为外包项目，也包括公司内部的项目。
里程碑：项目不同阶段应该实现的目标。里程碑有2个要素：成果与时间点。
版本：里程碑成果的别称，由多个文档组成，可能包括：源码，可运行代码，版本说明文件等。
任务：项目的每个里程碑的实现都是由多个任务组成；任务分前置任务，后置任务，并行任务；前置任务和后置任务是相对当前任务在时间先后顺序上的关联任务。
任务阶段：为了方便管理，将一组任务合称为一个阶段，并有阶段目标；
角色：项目中从事特定任务的团队成员，一个角色可以由一个人担当，一个人可以同时担当多个角色，但这会出现由于该人时间分配的牵制，影响任务执行。

二、迭代开发：

任何项目都没有一次开发就能满足最终用户需求的，或者最终用户需求的不断变更，也致使项目的不断改善以适应这样的变化。这两类变化（不断逼近用户需求，和用户需求变更）都导致版本的不断更新，这个现象统称为迭代开发，迭代就是里程碑的别称。

理论上，只有用户需求不再变更，或开发团队不愿意再满足这个变更了，项目才算终结，在项目终结前，项目是有N次迭代组成的，只是不同项目的N值大小不同。

任务是项目开发中最小的粒度单位，它由3个基本要素组成：描述，执行，验收。每次验收未实现描述，则需要再执行，直到达到描述的任务要求。如果任务描述变更了，则需要总结后变更为新任务。任务本身的变更也可以定义为更小粒度的迭代。

三、项目管理的目标：

PM(Project Manager项目经理)是履行项目管理职能的角色，负责完成项目规定的目标。在确定目标前，PM需要根据管理原则确定项目的周期，人员构成，里程划分，成本控制等要素，配合商务部门或客户对项目投资和风险因素进行考虑。

原则1：用最少的时间，满足目标；
原则2：用最少的投资，满足目标；
原则3：软件项目的主要成本是时间成本，时间越少成本越低；
原则4：单次迭代的时间越短，单次成本越少，总成本越少；
原则5：迭代次数越少，时间约少，成本越低；

根据软件项目管理原则，PM的项目管理手段包括，以下几点：

1、提高任务3个要素间的反馈速度，提高单次迭代效率；
2、任务描述准确，无二义性，避免无谓的迭代次数增加；
3、挑选任务执行能力强团队成员，提高单次迭代效率，降低迭代次数；
4、提高验收人员的责任心，提高单次迭代效率，降低迭代次数；
5、通过改善硬件环境，提高个人和团队的工作效率。

四、团队协作平台应当具备的功能

为了满足PM的管理需要，增加团队协作的能力，提高项目开发效率，建设团队协作平台可以降低团队管理中“人治”的成分，形成各司其职的团队氛围，为降低项目风险提供了硬件保障。

团队协作平台是一套基于B/S架构的，能在企业内部和网络虚拟团队中应用的项目管理系统。它的功能包括：

1、任务粒度管理：将项目按照：里程碑、任务阶段、任务、任务3要素，逐级细化的任务树管理功能，方便PM核查整个项目每个任务的细节。
2、版本管理：项目不同阶段成果的集中管理，不同版本除成果外，其相关的素材资源也能方便地查找和获得，方便团队成员间的资源共享。
3、工作台：按照时间，罗列每个人当天的任务、接口人以及成果提交地等信息的页面，可以向前，向后查询历史和未来的工作任务，起备忘功能。
4、绩效统计：核查每个人，每个任务工作效率的中心，包括：
   a，延期统计：任务完成周期的延期
   b，迭代次数增加统计：未完成任务目标或变更造成的迭代次数增加的统计；
   c，责任确认：依照任务3要素，对不同岗位责任的确认，随上2个统计一起进行；
   d，统计比例：单个任务，总项目，同类任务比例
5、权限管理：用户管理，角色管理等，用于定义项目各成员职责的管理职能

衍生功能：

6、会员中心：查看个人简历，联系方式，参加项目记录（角色/任务，项目组成员评价），会员搜索功能，项目受邀（接受/拒绝）功能。
7、项目中心：发布项目，发布岗位、项目组加入申请
8、产品中心：Demo版本/Release版本下载和说明中心。由项目组PM提交，汇集

平台上角色的设定：

1、PM：负责建立项目组，邀请成员，管理和分配任务，版本管理和资源组织，绩效统计，发布产品。
2、执行人：任务描述多为PM兼任，但PM也可以委托他人进行任务需求的描述，这样任务描述也成为一个执行人。系统分析，编码，测试等，都是执行人。各个执行人间的关系，依照任务3要素（描述，执行，验收）进行关联。
3、客户：作为特定里程碑的验收人员对待，开设客户帐号，提交反馈意见

[注]BugTrace：作为特殊任务存在于特定类型的里程碑里，如：Alpha到Beta，Beta到Release；不同里程碑测试方向不同，反馈方法也不同，依各行业情况定。

五、手机游戏团队协作案例：

依照上面的团队协作原理，下面提供手机游戏团队的协作案例，辅助协作平台的开发。

1、角色：手游团队由PM，策划，美工，配乐，程序，测试(QA)组成。

2、里程碑：策划、执行策划、Demo、Alpha、Beta、Master Release；
   其他机型适配版(根据适配机型不同，确定其Release前的里程碑复杂度，如同类机型性能差别不大，可以直接出Release版本，而差别很大的，和开发新版没有区别)；
   其他市场本地化（依据不同地区或运营商，完成不同平台，不同语言的版本移植），如同机型适配的操作。

3、任务流程细节：
   a, 策划：由策划根据市场情况，确定游戏目标，而后全组讨论或征求客户意见确定立项前，不设置时间点。
   b, 立项：只是一个状态，只有在反复推敲，确定目标后，策划才开始撰写执行策划，设置时间点。执行人是策划，验收为PM。
   c, 执行策划：是策划阶段的成果，是指导全组工作的基础。PM进行任务描述（图量表，配乐表，功能点），这些描述都是基于稳定的游戏引擎基础上的。
   d, 程序，可以按照传统的软件开发流程，进行系统设计，模块划分，设计说明书，编码，测试。也可以由1个程序员依照功能点逐一实现。
   e, 美术，根据图量表，完成特定规格尺寸发色数的图片文件
   f, 配乐，根据配乐表，完成MIDI格式文件（由于其接口简单，与项目组关联不大，也不是手机游戏的主要关注点，因此相对独立，可并行进行）
   g, 游戏编辑器，由程序利用美工素材，以及自己的游戏引擎，整理出游戏编辑器，提供给策划设计游戏地图，辅助美工完成动画拼接等工作，编辑器和游戏引擎都归属引擎开发范畴，纯粹的软件开发行为。
   h, Demo: 第1次可以运行的游戏，通常选择一款最流行的机型，如Nokia S60平台，7610就是首选。
   i, Alhpa: 程序，美工，配乐，策划，同时完成剩余任务，由程序整合Alpha版本。
   j, Beta: Alpha版本经过策划/PM/客户的修改意见，将游戏性方面的内容进行确定，没有明显的游戏逻辑问题，游戏要素全面后，达到Beta版本水平。
   k, Master Release: 在首款适配机型平台上进行性能和稳定性测试，达到设计要求，经用户评审测试通过的版本。
   l, 基础适配移植：通常手机游戏都要做多种版本，才能满足市场需要。如不同尺寸，不同平台；而第1批发布的是几款主流适配机型，如Nokia S40，MotoV600，E398，索爱K700等。不同系列，移植复杂度不同，由PM确定目标。
   m, 程序，完成编码移植。自我检测能否达到Beta版标准。
   n，美工/配乐/策划，辅助程序完成游戏资源的修改。
   o，Beta版本测试，由团队内测和客户验收测试达到Release标准。

4、手游任务中3要素角色沟通效率如何提高？
   a，执行策划后，PM需要依靠经验，尽量准确地完成图量、配乐、地图等游戏资源的空间占用约定，避免机型适配中，变更需求导致的迭代增加。
   b, PM应当熟悉引擎，能给予程序在编码上的建议，程序也应当熟悉各个适配机型的性能、内存、空间等限制，在编码之初，能对编码进行必要的规范。
   c，编码规范，注释详实：为不同程序进行适配移植时，减少理解消化代码的时间。
   d, Alpha版本，程序能自我检测，策划/PM反馈也要充分，均可减少迭代次数；
   e, 有条件真机开发，可以提高设备兼容性测试的效率；减少迭代次数；
   f, 版本定义严格，测试和反馈不找后帐，适配移植中不对Game Play的内容进行调整，只做设备相关的测试和检测。
   g, 客户GamePlay的建议时机在Beta版内测试通过后。
   h, 客户验收，只在Realse内测通过后，

5、手游项目中的文档：
   a, 策划案：word格式
   b, 执行策划：word格式
   c, 任务表：图量表、音量表、功能点：Excel格式，
      包含：需求，执行人，执行情况、验收人、验收意见、未通过执行、未通过验收；
   d, 迭代任务表：根据任务表验收意见，和需求变更的新任务表
   f, 测试任务表：Alpha版本需求改进，Beta的性能改进都使用此表
      包含：Bug描述，修改人，改进情况，验收人，验收意见。
   g, 版本描述：Beta版本完毕后的各文档的总结和整理。
   h, 工程环境：源码、资源、工具/Realse版本
   i, 用户手册：PDF/WORD格式
   j, 产品介绍：PPT；游戏截图/动画：Gif；游戏视频：avi/wmv；
   k, 宣传海报：JPG/PSD格式