抛开具体开发的游戏产品，如何评定一个游戏开发团队的开发技能的高低？
有人说：主程的技术/技术美术的技术，决定了开发团队技能的高低。
有人说：整个团队最差的人的技术，决定了开发团队技能的高低。
但是对团队开发技能的评定，不应当局限于个人的技能高低上。
铁打的营盘流水的兵，一个团队的开发技能成熟度应当被团队以制度-软件-反馈的形式确定下来，并有效地迭代和演进。可看这样的例子：
A团队：每当产品经理拿到新的需求，就火急火燎地找到主程序，然后就是一个马拉松式的会议大家讨论怎么实现。结束后，主美术开始把活儿分配下去，主程序开始定架构修改方式....美术组的成员开始手工一个一个制作模型，完毕后发送到主美术手动检查；程序组开始写代码，今天崩了这里、明天崩了那里.....（不太能想象的，请直接打开小林的妹抖龙，看小林上班的情况，就是成熟度模型的反例）
B团队：当产品经理拿到新的需求，开始整理需求并写入团队需求池。同时召集主程和主美开始一次短暂会议，目的在于保证对需求的理解一致。随后主程召集程序团队按照Scrum流程进行迭代，程序团队成员提交代码需要经过自动化代码审核、自动化代码格式规范，经过自动化构建和测试后，才能进入版本库。主美分发任务后，美术组成员按照任务内容，在技术美术定制的插件辅助下完成美术资源设计，并提交到团队的统一平台上，主美进行异步审核....
不需要讨论，明眼人一眼能够看出——B团队的开发成熟度比A团队成熟度强很多。那么，怎么才能走向B团队？
成熟度模型——不只是CMM
任何一个合格的软件工程专业毕业生都会学到著名的CMM模型：软件开发能力成熟度模型。游戏开发作为软件开发的一个门类，首先应当符合CMM模型的定义和描述；其次也需要考虑到游戏开发中美术参与的重要性，因此我提出了一个覆盖软件开发和美术设计的成熟度评估和改进思路。
CMM定义了5个级别：初始级、可重复级、定义级、受控级、优化级。抛开敏捷开发与传统瀑布流之争，CMM定义了一家软件企业的软件开发能力在研发过程中逐步成熟的过程以及下一步需要改进的地方。具体而言包括：
个人认为，作为小型游戏企业，能够到达CMM2-3级，已经是极为专业、优秀的软件开发团队。建议软件开发团队以2为目标进行组织。如果能够完全按照敏捷开发的一个流程（如Scrum）进行实践，则基本能够到达2.5的级别。
技术美术成熟度模型TAMM
斗胆提出这样一个概念，表示一个小型游戏开发团队中，通过技术和美术的结合，在美术资源创作、关卡设计、美术工作流设计上的成熟程度。由于考虑到美术本身的复杂度，因此不再按照级别直接进行划分，而是提出三个行为：
B1工作流行为：通过技术美术、主美和主程的配合，根据团队的整体软件选型、工作习惯和工作流程，设计工作流中的每个阶段，并通过开发软件插件、自动化工具，自动化地完成工作流中的大部分流程。
B2定制行为：技术美术、主美和主程配合，根据当前项目的具体需求，在原有B1基础上，扩展需要的独特工具，服务于特定需求
B3创造性行为：美术组成员按照自身创造性，人工地完成的具体工作。
随着整体美术成熟度的提高，原本由B3主导的工作，会逐渐转化为B2。同时随着项目的增多，基于特定项目的B2会逐渐被总结、统一为B1。即：一个特定的小型游戏团队，通过评判B1、B2、B3行为的比例，能够得出技术美术成熟的程度。
结合
我认为，通过有效结合CMM和TAMM，能够系统评估一家小型游戏企业的开发能力，并指出整个企业对自身开发流程、开发方式的提升方向。
