团队

    这里所有的团队，是指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。