有效的团队协调：共享代码库和链式构建
每天的项目环境中往往需要团队间共享代码，使用通用库，甚至共享一个又一个的构建流程。例如，一个项目也许需要包含其它项目的构建与测试行为。这可能包括获得共享库的更新版本以确保其它项目的改变不会影响团队的代码，或是保证团队代码库德变化不会影响另一个项目代码的功能。而且，项目间可以共享随时更新的核心资源。这种资源可以包括通用类或类似于测试工具与测试数据生成器等。这种情况在大型企业中十分普遍，它们会自然而然的形成，不需要企业自身的协调。
敏捷方法为开发团队提供了更有效合作、实时通信以保证项目进展的机会。通过提供构建成功/失败的快速反馈，开发者能够在最恰当的时候检测与解决问题。
为了在大型开发组织中更加有效，敏捷实践必须在单个团队级别上实现，但是应由企业级配置管理非常好的实践支持。当执行企业级敏捷配置管理方法时，团队必须负责起多项任务。第一，必须允许基于实践的可靠的敏捷配置管理执行。第二，必须使得流程对于其他团队可见。第三，适当的时候必须包括自身构建与测试行为的系统构建流程。最后一步不需要程序员在每天的工作中完成，但它必须由一个自动化流程尽可能多的执行（理想情况下，从一天一次到一周一次之间）。当其他系统出现问题时，必须快速解决。
为帮助所有团队执行敏捷配置管理， CM 组织还将负有不同的责任。这些任务属于共享的服务实体（常常被称为 Engineering Services Groups)。这种企业会提供一个通用的、用户友好的工具集获平台，所有团队可通过它们完成与共享源代码控制、构建、和测试行为。这种平台包括诸如源代码控制、构建、和测试系统的组件。而且，企业应在 敏捷配置管理实践的执行中提供支持与引导，提供一组可重复使用的 CM 流程或非常好的实践推荐以实现一致性和可靠性。最后，企业必须确保每个团队必须具有足够的 CM 流程控制的能力。这看起来有点像在搞平衡，但是对于有效的软件交付来说是有必要的。最终，仍然是团队构建软件，企业的工作是帮助每个项目获得最大的成功。
支持分布式团队和组织
许多敏捷方法论确实没有考虑分布式团队的情况，但是这一大企业中的普遍特征不会被希望改变软件开发产业的进步所忽视。尽管缺乏具体的关注，但是敏捷配置管理方法仍然对于具有分布式团队环境的项目和企业来说十分有效。
为了从敏捷配置管理方法中获益，分布式的项目和企业必须平衡部分敏捷配置管理实践的固定实现，尤其是固定的源代码控制使用、持续集成、和自动化测试。我们不能夸大经常检入和稳定构建维护的重要性，因为被时区或地理位置分开的团队成员需要访问完成的可操作的系统版本。当某些部分损坏或过期后，没有其他位置的团队成员可以帮你一把。
为了给分布式项目维护敏捷配置管理解决方案，必须检查源代码控制，包括构建脚本和本地环境设置。在任何一个位置的改变都必须自动复制到其他的开发场所。这是因为分布式团队协作和大系统的复杂性决定的。一旦开发过程中系统仅在一处开始出现离奇的行为时，也许需要花费很长时间才能找到问题的根源，而这一问题仅仅是因为没人会想到引起如此问题的服务器或虚拟机的设置。
除此之外，与数据库相关的所有部分都需要被复制与共享。这可以通过定制所有数据库的改变和检验源代码控制实现。 4 它还可以通过某种数据库复制的形式实现。最后，项目必须解决连接或开发行为必须执行的第三方系统的问题。每处场所都必须具有访问相同系统的能力。
有两种普遍的实现分布式和敏捷配置管理环境的方法。第一种就是建立一个单一的开发环境，它可被所有开发团队连续访问。这种环境包括 -- 至少 -- 单一的源代码控制系统，全部数据库和连接系统，执行持续集成的能力。这种解决方案适合于工作在临近时区且具有可靠网络访问能力的团队。第二种方法是构建概念上的单机开发站点。每个团队具有一个完整独立且相同的开发环境，包括源控件，数据库，附加的系统安装，和持续集成安装。每天的复制计划必须保证所有站点的代码，数据，和环境的同步改变。同步行为必须尽可能的自动化。而且，自动化测试必须有规律的编写与执行。如果没有执行每天的复制和完整测试（就是说，如果没有同步化操作），企业也许不久会发现自身处于梦魇中。最后，项目和企业可以使用中立的解决方案，即部分敏捷配置管理环境集中实现，而剩余部分由各个站点单独实现。例如，企业具有通用的源代码控制和构建系统，但是在不同开发场所维护本地数据库实践和其他第三方系统。
通过灵活的工具与流程集成的可扩展性
如果在创建良好构建流程和自动化前进行了充分的考虑与准备，那么它会成为十分有用的开发资产，这些设施能够（应该）在多个项目间做到平衡。大企业的低效源自于为每个软件项目创建一个新的构建系统。结果是以专门的硬件资源和配置管理人员支持多个定制的构建程序。这样就使得大型企业不能根据规模效益从资源池、人员和非常好的实践知识中获益。
如果企业计划在任意规模实现敏捷实践（意味着在多个团队、项目和/或操作平台上同时进行 编码-构建-测试-部署周期），那么应当仔细思考这些系统如何通信、交互以创建平滑的编码-构建-测试-部署周期。如果跨团队的，跨系统的整合不是全部开发策略的因素，那么团队常常会发现隔阂，等待周期，和函数间的错误通信会造成开发进度的迟缓。如果没有追踪和收集每个阶段信息的设施，那么团队很难确定系统真实的健康度和发布状态。
集成应包括来自核心开发系统的工作流自动化和信息共享（或者至少是抽取）。工作流自动化包括包括任务的次序与安排，并且应包括基于规则的改变任务执行与前步成功或失败告知的能力。当决定您的集成方法时，团队应考虑产业标准方法(XML，等)以构建适应需求改变和开发应用的灵活的解决方案。
如需浏览 IBM Rational Build Forge 如何在大型开发组织中快速实现敏捷方法，点击这里。
注释
1您可以在http://www.Agilemanifesto.org 中找到敏捷声明。
2如果需要阅读详细资料的文章，请浏览 Bard Appleton on the CM Crossroads Wiki 所作的针对配置管理所收集的定义： http://www.cmcrossroads.com
3 本文调整了书中的部分内容，Integrating Agile Development in the Real World 更详细的描述了这些实践。
4 要想了解更多有关建立与管理数据库的信息，请阅读我的文章 "Agility and the Database." 它位于 http://www.peterschuh.com/articles.html
参考资料
您可以参阅本文在 developerWorks 全球网站上的 英文原文。
您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
