Scrum大型游戏开发管理第一篇——团队管理

定义Scrum的角色

Scrum中不再有传统意义上的产品经理、项目经理，而是使用了Product Owner、Scrum Master、Team和Stake holder这样的新角色，当项目组是从传统开发模式转变过来的时候，我们需要重新定义这些新的角色。

团队

这里所有的团队，是指Scrum中的团队，而非整个游戏项目组。在游戏开发中推行Scrum时，团队是人员结构中最大的改变。
对于传统Scrum而言，团队是一个跨职能团队，分析设计人员、开发人员、测试人员一起组成了一个团队，大家在弱化分工，每个人都参与设计、开发与测试中。之所以能够实现这种跨职能的团队，是因为在传统软件开发中，我们只写代码，文字和美术图片只不过是软件的一个完全可以忽略的方面，客户不会因为文字优美，界面漂亮而认同一款软件，他们要的是软件功能。再看看传统软件团队中的各种角色，都在和代码直接打交道，分析、设计人员往往都是程序员出身，白盒测试人员本身也是要写代码的，这使得在传统项目中所谓的分工是完全能被打破的。
对于游戏团队，尤其是大型网络游戏团队，实现跨职能团队有相当大的难度。游戏公司大多采用矩阵式结构，按照职能，会分为策划、开发、美术、测试等部门，根据项目再从各个部门抽调人手形成项目组。策划人员工作在文字上，美术人员工作在2D、3D图像上，均不和代码打交道，只有程序、测试人员，才在代码上工作。假象如果我们让策划、美工、程序、测试坐在一起，一同讨论数值大小，脚本动作，一起些策划案，编代码，写脚本，画模型，想必是件很疯狂至极的事情。大家都很希望能找来一大批又能策划有能编码还能画画的全才来开发游戏，不过现实是一个也找不出来。
老纪也没有找来这些全才，他的手下也是策划人员、程序人员、美工人员和测试人员，矩阵式的组织结构使来自不同职能部门的人组成了一个项目组。老纪很想组成一个大范围的跨职能的团队，但是发现不大现实：策划人员是需求提出者，更应该被归为Product Owner，美工团队有点像内部外包，定期反馈完成的作品。能组成团队的，就只有程序与测试人员了，于是老纪将所有的开发与测试人员组成了他的团队。
这个团队也可以是跨职能的，这里的跨职能是一个小范围的跨职能，是相对于传统的开发方法而言的。在传统的游戏开发团队中，每个程序都负责一个特定的功能模块，如有人专门负责生活技能的代码，有人专门负责聊天系统，大家都有明确的分工，不但程序如此，测试人员也是如此。对于Scrum的跨职能团队而言，我们希望能够打破程序、测试人员的分工，我们希望所有程序人员都能应对多个功能于模块的代码，测试人员也能了解多个模块的业务逻辑，这样，实际开发工作中，团队成员能够互相帮助，评估过程中，团队成员也能各抒己见，加深大家对于功能的理解，提高团队生产效率。
在很多游戏公司中，测试人员被分为两类，一类是和程序人员坐在一起，进行单元测试的人员，一般我们称为程序测试，另一类则是在体验服务器上进行功能、系统、压力、集成测试的人员，我们一般称为系统测试人员；在组织团队的时候一定要将这两类测试人员均放入团队中，共同作为团队的一部分。
老纪所在的游戏公司，代表了绝大多数游戏公司的组织架构情况，事实上，我们在几乎所有的实施敏捷的游戏公司和项目组中，都是用了和老纪相同的团队定义。

Scrum Master

Scrum Master是Scrum项目中的灵魂人物，按照Scrum中的定义，Scrum Master不再是一个执行管理技能的领导，而是一个秩序维护者、教练以及团队成员的第一助手。Scrum Master要为团队、Product Owner教授Scrum知识，维护Scrum秩序，必须要在整个项目组内有很高的威望，甚至要有能力调配测试、美工、策划资源，在T公司中，老纪是一位资历很深的项目经理，是项目组中的二号人物（一号人物是一名公司股东，并不过问项目具体事宜），因此由老纪来担当Scrum Master的职位。
当团队规模还很小的时候（项目初始阶段，5人不到的时候），Scrum Master还会兼职做一些开发之类的事情，当团队开始扩大到10人左右时，Scrum Master就要求为全职了，要一心一意的来维护这个团队。当团队继续扩大，超过10人以后，就要考虑分拆，使用Scrum of Scrum的管理形式；在传统的Scrum定义中，Scrum of Scrum是Scrum Master的议事厅，不再有Scrum of Scrum的Scrum Master，但是在游戏项目组中，我们必须要有一名能够统管全局的Scrum Master，他需要协调其他部门的资源，能够直接面对强势的主策划、制作人，告诉他们团队应该怎么做，不应该怎么做；这个Scrum of Scrum Master的最终人员，还是落回了优秀的项目经理的头上。
Scrum of Scrum 中，子团队的项目成员在每个Sprint中都有可能发生一些变动，但是一定要保证子团队中的Scrum Master不要经常发生变动，这样对于保障团队开发效率是极为不利的。

Product Owner

传统敏捷项目中，Product Owner大多是由原来的产品经理负责，也就是直接对产品负责的人来。Product Owner要负责维护Product Backlog，为Product Backlog排序，为团队逐条讲解Product Backlog，解答团队的疑惑。
按照最简单的映射关系来看，Product Owner应该非游戏主策划莫数，他直接对游戏负责，总管游戏需求。不过游戏项目和传统软件项目差别很大，简单的映射关系是没法成立的。
传统Scrum要求我们只能有一个Product Owner，对于传统的不太大的敏捷项目来讲，只有5-9名项目成员，User Story最多也不过百十余条，1名Product Owner足以应付。但是在大型网络游戏开发中，当游戏开发到后期时，动辄会有上千份策划文档，其中过百页的文档少说也有百余份，如果将这些策划文档整为User Story，会有几千条，如果让一个主策划来维护这个海量的Product Backlog，恐怕所有的主策都会被吓跑了吧。现实中的状况是：策划人员（包括主策在内），共同在维护庞大的策划库。
因此我们应当将全部策划人员一同作为Product Owner组，这个组内，每个策划人员维护游戏中的一部分功能的策划案，主策划作为Product Owner组的总负责人。Product Owner组共同讨论游戏功能的分割，创建并维护游戏Product Backlog，计划会上，每个策划分别讲解他所负责的Backlog 条目，并在团队开发过程中帮助团队成员解答疑问。在Sprint结束后的评审会议中，全体策划人员也都要参加评审，给出自己的评审意见。
虽然Product Owner的范围方面我们做了很大的改变，但是对于Product Owner的职能、Product Owner应当遵守的纪律，我们没有做任何的变动。对于Scrum而言，最大的风险就是我们实施了Scrum But。

Scrum of Scrums

随着游戏项目的进展，项目组会逐渐扩大，老纪所领导的项目组，最初只有10个人，5个策划，4个程序，等到了游戏内测阶段，项目组已经发展为90多人，近30名策划，近40名程序与测试人员，20名美术人员和几名产品组成员。
按照我们关于团队的定义，老纪的开发团队在后期已经达到了40人的规模，关于团队的规模，传统Scrum一直认为5-9人是一个最佳范围，团队过小，管理成本会过高，团队过大，则不利于团队的沟通，降低团队工作效率。在40人团队规模下如果要继续有效的使用Scrum方法，唯一的办法就是分拆团队，采用Scrum of Scrum的方法。
当开发团队规模较小的时候，如不超过10个人，我们可以采用一个Scrum团队的管理方式，项目经理即为Scrum Master。如果团队扩大到10人以上以后，那我们就不得不拆分团队了。其实拆分团队并不困难，当团队扩大以后，自然就形成了一个分割，如某一些人专门负责技能与任务的开发，另一些人则专门负责副本的开发与维护，这样我们就可以把开发内容有紧密关联的团队成员组成一组，人数控制在5-10人左右，在这个组内再任命一名技术、管理能力均衡的成员作为这个小组的Scrum Master，管理所在的子团队，同时听命于项目经理。



当我们刚刚开始在T公司实施Scrum的时候，老纪手下只有4名程序员，他是Scrum Master。当团队扩大到12个人的时候，老纪将团队分拆为两个子团队，一个团队专门做帮会系统，4个固定人员，1个临时帮忙的成员，老纪选择了一名最早加入该项目组的成员作为这个子团队的Scrum Master。其他7个人组成另外一个子团队，负责帮会系统以外的其他开发工作，依然由老纪作为Scrum Master。
在团队分拆过程中，最容易发生的问题是按照工作职能划分子团队，如：逻辑程序员一组，脚本程序员一组，测试人员一组；这是万万要不得的，我们费尽千辛万苦才淡化了团队分工，形成了跨职能团队，如果以这样的错误方式进行的分组，我们的工作岂不是全都白费了？
随着老纪的团队扩大和项目的进展，老纪后来又对团队作了几次分拆与合并。团队的重组在每个Sprint之间进行，每次重组都是和团队成员协商后的结果，子团队的Scrum Master也基本没有更换过。Scrum of Scrum的团队形式从项目的第4个月开始持续到现在已经1年多了，运转非常良好。
策划人员的数量在游戏团队中占有了相当大的比重，当团队扩大时，策划人员必然也会要进行分组。传统策划分组是按照游戏功能模块进行分组，如会被分为技能组、副本组、阵营组、任务组等，每个组会有一个组长，负责管理本组工作，并向主策划汇报工作进度。当我们采用了Scrum方法后，策划人员在决定分组的时候，应当和Scrum团队进行沟通，尤其在团队实行Scrum of Scrum之后，策划人员的分组，应当尽可能和团队的分组保持一致，一组策划人员最好能够和一个Scrum子团队对应，并形成一个相对较稳定的Scrum组合，有利于提高团队工作效率。