一些开发制度的思考

经历过几家游戏公司，稍微总结了下一些项目开发流程，并且根据此提供一些自己的看法。当然我没有读过特别的管理书籍，或者敏捷开发之类的，纯粹是自己的想法。

经历过一家小公司，里面一个游戏项目程序就一个人，负责所有的东西和各种接口（因为有和平台合作），这个就不细说了；

经历过一家中小公司，基本是一个人负责多块，如果负责的块出问题也是属于你管(只要你人还在或者没人交接你的工作)

经历过一家大公司，模式比较有意思，不同的周期换了2-3种。规律性如下：

1期：轮转制，原则上每个人都可以负责不同的模块，以增强熟悉度

2期：通过指派的功能来开发。原则上不以某人熟悉某块来分功能

3期：小组式，小规模的程序对小规模的策划组，打分支的版本进行

1，2期的轮转制好处就是熟悉不同的代码，但是3期的小组制出后，我有了个更进一步的想法。安排如下：

分成N个小组，每个小组3人左右。大概会有2-3组。每个组都有一名小组长，分任务模块的时候以组为单位，以熟悉度为优先。小组之间成员或者组长可以按个人意愿进行互换，前提是当前小组内有可以接你班的人。从代码质量的管理上好处如下：

1：每个人经手的代码周期长，可以随时进行改进，反正这块也是你负责的。不像“1期”性的轮转，做完就了事

2：每个模块的熟悉人手变多，至少有2个以上，这样防止人员的流失

当然，也有个最大的不好，官多，意味着你的指挥权下降；也意味着内部的不稳定。呵呵。所以首先看这种方法是否适合领导人的把权欲望。 

说到这，想起我以前思考的一个学习群模式：

一个群10个人以下，并且主题很明确；

拉人的模式如下，由群主邀请一个自己熟悉的人（假设为A,并且2人水平差不多），然后由A邀请一个自己熟悉的人，以此类推，最终不得超过10个人；

有空位的情况下，允许有旁听生；

每个群有个小群主，记录本群的名单给总群主，方便名单更新和调配；

为什么邀请要通过介绍的形式呢？最主要的目的还是增加每个人的交友面，而允许旁听生是想让他们珍惜这种机会，

而邀请自己水平差不多，并且10人以下就是为了使整个信息的针对性更强

我觉得我自己做不起来这个，没有那种奉献的热情。如果谁组织了，请M偶。。。