游戏系统开发笔记（二）——开发流程和项目管理

http://blog.csdn.net/mooke/article/details/8654816

经验所限，并且对项目管理这块关注也比较少，所以暂时只能根据自己现在了解到的简单写写，以后等有了更多了解再回来完善一下。另外要说明的一点就是根据游戏类型不同，无论从开发团队规模还是流程管理上相信都会有很大不同，这里只针对传统端游项目说说。

--------------------------------------------------

        前一篇说到分工，游戏工作室一般分成几个组后是各个组都有独立的流程管理的，但是考虑到项目统筹方便可能会根据情况应用同一套管理手段。

        比如端游项目现在常见的开发流程一般是会采用敏捷迭代开发，对于通常都是工作室自己设计，自己实现，并且主打用户体验的游戏产品来说，敏捷方法中所提倡的诸如拥抱变化、快速原型、快速沟通的循序渐进式开发一般认为是非常合适的。

        常见的敏捷方法比如SCRUM、XP之类的，每种方法都有一系列要求，实际工作中各个工地可能会根据自身情况选择性的做一些事情，并不会100%的落实要求，至于具体这种删减是提高了效率还是破坏了流程我暂时就不得而知了。不过我个人看法是作为一套相对完善方法论，这些要求应当不是空穴来风了，每一项条款的添加都是经过实践和理论的探索得出的，本地化是没问题，可那应该是在对这套方法有相当的了解之后再去做可能会恰当点。

        根据我的观察，应该是程序和策划和测试三个组采用这种管理方式会适合些，而美术因为可能工作重复度高、工作量大不容易拆分所以还是瀑布开发。

        程序的工作内容主要来自三个方面：自己提出的优化需求、策划提出需要程序实现的需求、测试过程中发现的BUG

        如果按照敏捷方法（如SCRUM）来作安排，就需要一个backlog来暂存工作内容，这里一般记录大块工作项（小的工作通常和其他人工作密切关联优先级非常高，backlog其实跟外存似得）。再制作一个sprint（短跑的意思）表，其实就相当于内存缓冲区，程序要在一个sprint周期内解决其中的工作内容，这个周期结束后再从外存里读入任务到内存（backlog->sprint），评估各个任务需要的时间来填满（不是严格要求的，可能会预留一点时间来应对突发需求）这个sprint。一个sprint就作为一次迭代，如果流程利用的程度比较高的话，通常会对各个sprint作一个阶段性的开发规划，并且把其完成度作为把控项目进度的重要依据。

        一般来说一个组内还会有更小的拆分，比如根据负责的模块分拆出2-5人的更小的小组，这样在分配工作的时候每个人就有了一些选择的余地，根据要赶项目时间还是带新人，都可以有不同的分配方式。

        自由选择和自由估时带来的一个问题就是可能会有人偷懒的情况，所以敏捷方法中会有个每日“站立”短会的条款（站立很重要），每个人要简述自己昨日的工作及今天的安排，关于会议的组织细则这里不表。这样会给每个人带来一定的压力，促使每个人更好的完成工作。另外每期sprint记录存档后也可以作为绩效的重要依据，能者多可多劳，多劳者米就多。因此制度上会促使每个人进行自我管理，省去了管理者的琐碎沟通工作。一旦统一清晰流程在团队中形成，新进入的成员就比较容易掌握并在其中找到自己的位置了。

        这样一来项目管理的具体工作就分摊到各个组长（主程、主策、主美）的手上，而项目经理可以把更多注意力会放到项目监督和产品设计的方向上，另外也就有更多的精力可以出去“为了资源而奋斗”。