前一篇说到分工，这里再说说流程和开发管理。

组织形式

从公司角度来看一个游戏工作室是一个业务比较独立的研发部门，研发方面的大小事务（除了立项）拥有高度自治权。而从一个工作室角度来看，通常内部又由多个项目组组成，每个项目组才是真正解决项目问题，推动项目发展的基本单元。项目组和工作室之间的关系，就好比进程（部门）和线程（项目组）的关系，前者是一个资源单位，后者是执行单位。类似的，具体项目研发过程中的决策和执行基本上都会下放给项目组，项目组同样的对所负责的项目高度自治。

管理流程

国外的情况我不了解，国内的环境普遍是不太重视管理这块的方法论的。因此很多工地的开发管理通常没有特别固定的形式，更多的按照管理者的习惯和直觉决定，执行过程中遇到问题了再行调整。

另外，根据项目所处阶段的不同，研发节奏和管理的方式也可能会有很大的不同。

比如，处于研发期的项目，通常有以下特点：

1、以功能模块和milestone为主轴推进

2、普遍开晨会同步进度和问题

3、对工作进度delay的情况相对宽容

4、经常遇到项目方向上的调整（很多工作要推翻重来）

5、市场压力、不合理的进度预期导致疯狂加班

相对的，运营期的项目：

1、以各个版本为核心开展工作，各条版本线相对独立

2、节奏有所缓和，时间商量的余地更大（不绝对是这样）

3、从需求的提出到程序实现都更加谨慎，以稳定性为优先考虑

        整个互联网行业包括游戏最常见的研发管理方案是敏捷开发——比如SCRUM、XP之类的，每种方法都有一系列要求，实际工作中各个工地可能会根据自身情况选择性的做一些事情，不一定100%的落实（比如结对编程这种羞耻play）。

任务分配，最常见的还是主x来做，也有列出来看个人兴趣自己认领的，不过其实没啥意思，因为现在大多工地做的东西并无新意，甚至提的需求也是在用另一个游戏来描述的。不过不管怎样，一旦接受了一个版块，后续基本上就被绑定到这个上面了，相关或者类似的功能及修改，都是你的。

版本管理

研发期的版本管理通常都比较随意，运营期会正式一点，这里给一下运营期的版本管理参考，分2种来说。

第一种：分支上开发，在主干发布

优点：主干较为稳定，版本维护比较清晰，不容易出现版本内容漏放到主干的问题。

缺点：多条版本线并行时，会在测试->发布阶段冲突，要注意避让。

版本维护流程：由于Tag通常是不允许修改的，这时候要从Tag上出分支来改。

第二种：分支上开发，分支上发布

就不说优缺点了，实际上这种开发方式有个严重的问题——直接发布分支版本很有可能导致前面发布的版本内容被回退，这是绝对不可行的。

因此，在这个分支进入测试环节前，就需要把期间（拉分支之后合并到主干的其他开发内容）的所有版本合并进来，统一测试。必须要先合并把冲突问题都解决了再测，否则风险很大（难免会改动到相同的模块）。另外同样存在冲突的时间段——测试->发布阶段，这个过程同样是不允许处理其他发布的。总的来说，这种方案虽然也有小部分公司在用，但不是很好。

维护流程是差不多的。