|
在团队分拆过程中，最容易发生的问题是按照工作职能划分子团队，如：逻辑程序员一组，脚本程序员一组，测试人员一组;这是万万要不得的，我们费尽千辛万苦才淡化了团队分工，形成了跨职能团队，如果以这样的错误方式进行的分组，我们的工作岂不是全都白费了?项目管理者联盟
随着老纪的团队扩大和项目的进展，老纪后来又对团队作了几次分拆与合并。团队的重组在每个Sprint之间进行，每次重组都是和团队成员协商后的结果，子团队的Scrum Ma ster也基本没有更换过。Scrum of Scrum的团队形式从项目的第4个月开始持续到现在已经1年多了，运转非常良好。项目管理者联盟
策划人员的数量在游戏团队中占有了相当大的比重，当团队扩大时，策划人员必然也会要进行分组。传统策划分组是按照游戏功能模块进行分组，如会被分为技能组、副本组、阵营组、任务组等，每个组会有一个组长，负责管理本组工作，并向主策划汇报工作进度。当我们采用了Scrum方法后，策划人员在决定分组的时候，应当和Scrum团队进行沟通，尤其在团队实行Scrum of Scrum之后，策划人员的分组，应当尽可能和团队的分组保持一致，一组策划人员最好能够和一个Scrum子团队对应，并形成一个相对较稳定的Scrum组合，有利于提高团队工作效率。training.mypm.net
对于软件开发领域来讲，变更始终是最让人头疼的东西，大家对于如何消除变更，如何控制变更，提出了很多很多的理论与方法。无奈变更这东西就像是个打不死的小强，倔强的与软件开发一起生存了半个多世纪，到了现如今的网络时代，不但没有被压制住，反倒更加猖獗了。那么在小强最繁荣的游戏圈里面，大家是如何面对变更的呢?项目管理者联盟
整体而言，游戏行业(尤其是网络游戏行业)对于变更是又爱又恨的，很纠结，很痛苦。因此在网络游戏行业中，变更管理也不是简单的放任或者控制，而是要权衡各方面的因素，让变与不变维持在一个平衡点上。一句话概括其管理方式就是：胡萝卜+大棒政策。club.mypm.net
游戏公司中对于变更的两种意见转自项目管理者联盟
主变派：策划、制作人;观点：变化乃游戏生存之本项目管理者联盟
变化是网络游戏生存之根本，大家评判一个网络游戏发展势头的最重要的标准有两个：在线人数与更新频率。一个更新频率趋于变缓的游戏，基本上可以说是快进入消亡期了。追逐玩家们不断变化的口味，引领游戏圈的新潮流，创造更高的吸金效率，这些都是以不断的变化为基础的。项目管理者联盟
因此，游戏必须变。不让游戏发生变化，就等于是要了游戏的命。就算是限制变更，也相当于扼住了游戏赖以生存的咽喉。service.mypm.net
不变派：开发团队，项目经理;观点：变化是浪费，是隐患service.mypm.net
说到底，游戏还是个软件，单机游戏也好，网络游戏也好，无非都是运行在计算机上的软件。变更对于软件开发而言，灾难性的，这一点所有软件开发人员都深有体会，变更会导致大量的重复工作，严重影响开发进度;会对已完成的所有工作产生冲击与影响，带来更多的不可预期的Bug;没有被良好重新设计的变更，甚至会直接威胁到软件构架的稳定性，为将来埋下极大的隐患，等等。这些软件本身的问题，同样也适用于游戏开发。项目管理论坛
更要命的是，频繁的变更会让开发团队感到强烈的挫败感，自己辛辛苦苦做好的东西，没过几天就被彻底改掉了，感觉自己就像是做了很多没有用的东西一样，长此以往，开发团队将会士气受挫，导致开发效率低下。项目管理者联盟
看来矛盾是不可避免了。那么到底听谁的呢?听策划的，还是听开发的?按照大自然物竞天择的自然规律来判断的话：谁强，听谁的。service.mypm.net
谁更强?策划，还是程序?如果我在这里挖个坑，盖个楼的话，邀请大家来评价一下的话，我相信会相当的火爆。项目管理者联盟
实施证明，策划与程序，都很重要。项目经理博客
变更的分类，哪些可以变?哪些不能变?PgMp.mypm.net
如果我们根据变更是否会对开发工作产生影响来对游戏需求变更进行分类，我们可以整体上分为两种变更：1.对当前的游戏开发工作产生直接影响;2.不会对当前的游戏开发工作产生直接影响。
当前的工作，是指正在开发、测试、美术人员手上处理，或者进入到当前迭代周期内待处理的工作。发生直接影响，则是指会打断当前正在进行的开发工作，比如一个游戏需求：玩家自定义聊天频道功能，现在这个需求已经到了程序手中，开始编写代码了，这时候如过策划人员发起变更，就会对当前工作产生直接的影响。而如是另一种情况：这个需求目前还在策划阶段，还没有送到程序员与美术人员的手中，这时候策划人员发起需求变更，不会对当前的开发任务产生直接影响，因为现在还根本没有人在开发这个功能。pmp.mypm.net
如果我们仔细分析一下程序人员反对变更的理由的话，我们会发现，其实程序人员仅仅是反对会产生直接影响的变更，而对于那些不会产生直接影响的变更，则不是很反对。那些不产生直接影响的变更，虽然也会对现有的工作产生一些间接的影响，但是影响不会很大，这个问题我们会在后面来讨论。项目经理博客
胡萝卜+大棒项目管理论坛
基于上面提到的变更的分类方法，我们可以得到这样一个变更管理的方法：项目管理者联盟
当一个需求(或者策划案)还处在策划阶段，还没有被送去开发与实现的时候，我们允许这个需求发生改变，甚至允许它发生任何的改变，没有任何限制。而一旦这个需求被送去开发与实现了，那么我们将不再允许这个需求发生任何改变，需求与设计将会被锁定，开发人员将会按照锁定的版本进行开发。service.mypm.net
如果在开发过程中，策划人员实在忍不住要提出变更，那么他仅有两个选择：PgMp.mypm.net
1，要求项目经理彻底终断掉该需求当前的开发工作，将该需求从当前的开发列表中取消，待其将需求变更修改好后，再重新纳入到下一轮开发计划中;training.mypm.net
2，等待已经送交开发的需求开发完成，在已经完成的基础上提出修改(作为一个新需求)并纳入到下一轮的开发计划中。项目管理者联盟
|
