TechExcel自1995年成立以来，通过努力使得产品不断完善，应用生命周期管理解决方案DevSuite已经覆盖了软件开发的各个阶段，这也是业 内唯一一套由一个公司独立设计、开发的整体方案。多年来，公司的产品被世界上大多数著名的游戏公司采用，得到EA、Activision、Vivendi 等企业的肯定和认可，这些公司都与我们保持着紧密的联系与合作。
在过去的十年里，大部分的游戏公司和工作室采用瀑布或迭代开发。然而，随着客户需求的提高和市场竞争的日趋激烈，游戏制作团队规模越来越大，市场对游戏品 质的要求也逐渐提高。游戏制作人员开始意识到传统的管理方法已经不能满足需要，也意识到敏捷开发对项目研发管理的重要性。
敏捷开发起源于美国，作为一种管理方法，在从它的发源地引入到中国的过程中，不免会遇到许多本土化问题。
团队人员频繁变化，知识不易积累和共享
目前，对于很多软件和游戏公司，人员的频繁流动是困扰企业的很大问题。这个问题不管是在美国还是在中国都存在着。在优秀人员极度匮乏的中国游戏行业则表现 得尤为突出。游戏研发作为一个大型的软件项目，设计到很多知识和文档，包括游戏的剧情、元素，以及各种各样的美术资料。虽然很多团队都使用了一些版本控制 工具，但其功能都相对简单，只是单纯的文档管理，难以实现与开发和测试工作的关联，一旦有团队成员离职或发生其他紧急情况，让项目无障碍的继续工作下去将 遇到很大的困难。
团队沟通与开发文化
敏捷开发中推崇的很多价值观和方法，蕴含了很多美国文化在其中，如果不加修改，直接照搬到中国的开发团队中会引发一些问题。例如，敏捷开发中倡导面对面的 沟通。而由于文化和教育等原因，美国人多勇于自我表达、踊跃发言；而中国人比较含蓄，尤其是技术人员，频繁的面对面交流反而达不到好的效果。又如， 项目例会的目的在于为团队创造一个提出问题、解决问题的环境。在美国，大家认为“No question is a bad question”，而在很多中国的团队中，虽然大家有疑问，但不善发言，也不愿当面提出问题。
瀑布式开发有很多有点，但也存在一些问题，如缺乏灵活度，难以适应变化，无法预知未来。正因如此，一些团队开始尝试使用敏捷。敏捷开发能够弥补瀑布开发的一些不足，例如它强调团队间的沟通，使得项目有非 常大的灵活性，能够非常好的适应变更。同时，敏捷也带来一些问题，包括对大规模的团队没有给出明确的管理方法，这就使得对大型团队的开发流程难以控制，也 缺乏必要的文档积累。
基于ALM领域十余年的理论和实践经验，TechExcel提出了一套更为完善的敏捷开发方法——蓝图敏捷（Blueprint Agile）。它是针对现有方法的局限性提出的一个新的敏捷方法，融合了瀑布式和敏捷开发的特点。通过文档管理、知识共享、流程控制、团队角色分工管理和 需求变更等手段，实现了可扩展、可控制的敏捷开发，使得不同规模的团队、包括分布式开发团队都能成功应用敏捷开发。
所谓“蓝图”，是指在敏捷的过程中为团队设定一个明确目标，根据项目实时进展，始终围绕目标调整路线。“蓝图敏捷”对于开发团队，正如GPS之于汽车驾 驶，目标即类似于行车的目的地。有了明确的目标，才能计算出当前时刻最佳的路线，估算出所要花费的时间，提供参考使用的蓝图。在行进过程中，汽车敏捷前 行，若遇到道路施工等状况时，会绕道调整新车路线。在做出新的选择后，计算出最佳的路线和所花费的时间，根据新的位置，调整路线，更新蓝图。
图1：蓝图敏捷模型
在蓝图敏捷模型中，每一个迭代开发周期产生两个交付结果：产品设计团队交付、并不断改进“概念产品”；开发团队不断完善“可工作的功能模块”。在每一个开 发周期中，设计团队、产品经理与开发团队协同工作，实现增量交付；在不断迭代的过程中产品设计也能持续改进。对于开发的产品，需要每日构建，而且在每个迭 代周期结束时，都要有可交付的功能模块。通过概念产品驱动开发过程，可交付的功能模块激发设计团队改进产品需求，提高团队间沟通合作效率。同时，蓝图敏捷 在人员、沟通、过程、团队管理、和工具之间掌握平衡。
正因为蓝图敏捷是现有敏捷方法的一种升级，并汲取了瀑布式开发和敏捷开发的优点，使得它能够更好地满足游戏开发的需要。
团队内部和多团队的沟通协作
很多公司在实施敏捷的过程中，都是从部分团队开始试用，进而扩展到整个公司。在这个过程中，发现最初试用的小团队往往能成功地实施敏捷。当需要在公司范围 内大规模实施时，却常常会遇到前所未有的困难。例如，在实施敏捷过程中，通常会采用Daily Meeting的方法来沟通工作中遇到的问题。当一个游戏公司拥有多个项目组共同开发时，很可能会导致团队用于会议的时间过多，对游戏进度和问题的控制基 本依靠人为管理来完成。
蓝图敏捷的一个重要改进是帮助多个团队的开发组织实现敏捷开发。在蓝图敏捷模式中，多个团队都在统一的架构下工作，设计团队、产品经理和开发经理协同工 作。
图2：蓝图敏捷对多项目、多团队的支持
量化游戏设计
蓝图敏捷的另一个要素是对需求的量化。对于每一个软件或游戏，都是由很多User Story（基于用户或客户的需求，分解出的具有优先级、可测试、可评估的单元）和Tech Story（面向程序员、有具体细节的技术设计）组成的。在蓝图敏捷中，我们把这一系列故事看作一组由待开发的新功能、功能改进以及待修复缺陷等元素构 成；再用规范点单元（Specification，简称Spec）来表达这些新功能和功能改进；每一个Spec都是能够为最终用户所理解的有价值的单元。 以上就组成了蓝图敏捷中的“概念产品”。
同SCRUM相似，在蓝图敏捷中，我们沿用了产品Backlog和迭代Backlog的概念。在项目规划中，将量化的需求——Spec单元分配到相应的迭 代周期中，有助于制定准确的计划，项目团队可以有效安排和管理项目进度、资源分配、以及日常研发任务。一旦有Spec在某个迭代周期没有完成，可以将其分 配到下一个周期中。每一次迭代都产生可工作的功能模块，不断的激发创意和设计团队完善游戏产品，使其向一个正确的方向发展，不断完善游戏设计。
可控的需求变更
由于市场发生变化，项目也要随之改变，如游戏的规则、剧情和元素等。蓝图敏捷倡导有序变更，需求的变更需要经过一定的审批流程，确保相关人员能够同步查看 变更的需求与设计。同时，相关人员也能了解和评估变更可能带来的影响，避免变更对整个游戏项目的严重破坏，例如因为游戏后期的变更破坏整个游戏的平衡性。 在项目开发过程中，团队是否能够胜任随时的需求变更，并合理安排和控制这些变更，是团队保持竞争优势的关键因素。当团队可以快速响应变更，且能有效控制产 品开发质量，则实际产品将始终遵循概念产品框架，确保项目成功交付。
由于篇幅有限，对于具体如何量化和控制，如果有机会，我们将在今后的文章中，进行深入的讨论。
周铁人博士是资深的ALM领域的专家，倡导标准开发方法、ALM平台和项目团队三位一体的项目管理方法，以此来指导有序和高效的软件设计规划和开发过程。 他认为只有ALM平台能够帮助开发团队将标准开发方法落实到日常的工作中，使得每个团队成员的工作都遵循标准方法，帮助团队清晰定义敏捷目标和开发规划， 并对任何规模的开发项目实施敏捷开发，从而达到真正的敏捷开发。由他创立的TechExcel公司的ALM解决方案DevSuite，被全美前10大游戏 公司中的7家选择，TechExcel的理念和产品都是被游戏团队实战检验的、行之有效的管理方法和平台。
