前言：由于其规模及复杂性，大企业更需要拥抱敏捷开发策略。通过本文了解如何通过敏捷配置管理环境来有效地协调成百上千的资源。

　　在我作为顾问的早期，很幸运我有机会接触一个使用了被称为极限编程（eXtreme Programming）方法的项目。这个项目的环境十分典型：二十个人，有限的复杂度与平台需求。后这个项目成功了。新方法帮助我们按时交付并且降低了缺陷。之后，我又经历了各种更具挑战性的敏捷环境，包括很大的项目团队（一百多人）和固定的成本花销。一种普遍的方案是他们全部是单一的项目团队，即使有些团队的规模很大。尽管具备了这些经验，我仍然不满意于敏捷开发为企业带来的好处 -- 尤其是关于配置管理的敏捷实践和技术 -- 直到我在两年时间内与财富 100 企业的项目团队一起工作后才发生了改变。

　　当我作为一名顾问进入到公司后，我发现这是一家不使用常规源代码控制、只有少量自动化构建或自动化单元测试的企业。我们花费了几个月的时间，利用持续的集成、短迭代、和各种其他的敏捷实践与技术，终建立了一个更灵活的项目团队。当项目成功后，团队成员可以帮助其他团队使用敏捷方法了。十八个月后，我们已经有了六个遵循主要敏捷配置管理实践的项目。每个项目团队具备自己的代码库，但是他们会互相共享组件、测试和构建流程。程序员会在内多次检入代码，尽快地增加自动测试，甚至写了几行代码后会重新编译。项目团队会在内多次运行他们自己的自动化测试组件和系统。企业开始从更健壮的代码库、更及时的交付、和更好的终产品中获益。

　　从那时起，许多大公司的开发团队都希望了解敏捷是否适合他们。他们一直认为敏捷是无序的、混乱的，并且风险很大。没有什么比事实更有说服力了。我自己的经验证明了敏捷实践和技术能够提供可靠的灵活的配置管理环境，而这正符合了大公司保持竞争力，满足质量的目标。

　　我将在本文中展示部分基本的敏捷配置管理构建模块，并详细介绍如何使用这些实践为大型开发企业带来收益。

　　开始之前：术语声明

　　术语对于专业的软件开发来说既有益处又有坏处。也是说，我们都利用术语来工作。不幸的是，我们往往使用它们的意思而使工作做得很糟糕。因此，在继续之前，我想首先花一些时间声明一下我将使用的术语。

　　由先出现的开始大型开发组织可以有很多种形式。例如，它可以是一个大型项目，包括了上百人，为了计划和开发的目的分解为许多个子系统和子团队。它还可以是一家开发企业，包括许多相互联系的系统和项目团队。更一般的说法是，它可以是任何被描述为 "企业"的开发组织。 大的开发组织意味着多个团队和大量代码行。这些大型组织常常拥有不同阶段的开发、产品，或接近退役的系统；任意的数据库、文件仓库和其他的数据源；一系列不同的项目方案和委托；含有各种需求和议程的一群有趣的团队。这些大型组织常常接近（或已经陷于)复杂性之中。

　　更高水平的，敏捷开发很容易定义。它描述了任意的坚持敏捷软件开发的宣称价值的开发方法（尤其是伪装成项目团队熟知的方法论）。1简短来说，这些值关注于个人和交互、工作软件和用户协作，它们承认改变是不可避免的甚至是有价值的软件开发部分。但是这一高级定义仅描述了敏捷团队的价值，而没有他们所做的内容。当我谈论敏捷所做的内容时，我是指敏捷团队尊循的实践和技术，诸如持续集成、自动化的单元测试和短叠代。敏捷社区中不断讨论着遵循敏捷实践却不使用敏捷值的团队是否能够被称为敏捷的。这些值是十分重要的，因为它们提供了适当的 Agie 实践和技术的实现指导。但是，我将会跨过这些争论，使用术语敏捷以鉴别敏捷团队使用的实践和技术。

　　然后，配置管理-- 可被描述为 "质量"的概念 -- 传统意义上具有多种不同定义。2大家似乎完全同意配置管理包括了鉴别系统条目和特定条目与系统的变化。一种狭义的配置管理的定义可以满足流行源代码控制系统的实现及使用。同时， 一种广义的定义也许涵盖了全部项目团队和所有工件，包括全部的确保系统正确操作的代码和行为，所有改变控件行为，和追踪团队每天的变化。我将在本文中对配置管理采用一种中立的定义，包括了程序员所做的组织系统组件，了解任意时刻的系统状态、管理演化、确保开发过程中正确的系统功能。

　　大企业对敏捷实践的需求

　　现在我们已经符合了讨论的标准，让我们看看它们是如何在一起工作的。首先，小型项目没有了质量不一和不正规的配置管理实践时，大部分读者可能都会同意大型开发组织都会需要正规的配置管理方法。这种认识在六年前被认为是十分大胆的，而我根据针对大型开发遇到的问题所做的观察得出的这一结论。当几十种（没有上百）产品组件正在运行，并且您与上百个（没有上千）开发者协作时，潜在的混乱、迟缓的开发周期、和很差产品质量的可能性是十分高的。大型系统变得过于复杂与迅速以至于不能靠手动系统加以维护了。因此在这些企业中，自动化、流程控制、管理变化、和团队协调对于保证开发质量是十分必要的。

　　其次，让我们讨论一下敏捷开发和配置管理的混合。当敏捷开发还是一种新兴的，软件开发专家为重视的破坏进度、开销溢出、项目失败特点的主题时，没有人谈论配置管理的敏捷方法。但是敏捷证明了它是一种极好的配置管理实践，因为敏捷团队需要健壮的灵活的代码库以响应不断变化的业务环境和客户需求。一种方式是在项目中经常性的集成代码（一般来所，集成几次）。另一种敏捷的重要原则是将测试作为一种有效的配置管理组件。在许多敏捷团队中，全部新代码都要经过自动化的单元测试，每次执行架构都会运行所有单元测试。未通过的单元测试将被视为与编译错误一样严重的问题。在任何好的配置管理流程中，敏捷团队都需要了解所有代码行的健康度。而且，他们努力保持对代码状态的控制。

　　后，是敏捷开发和大型开发组织。所有的大企业确实可从集成的敏捷开发部分获得收益。理所当然，有独特的大型开发组织的挑战，例如，与多个项目、系统、数据源连接的逻辑行为外的个人与团队间的通信与协作。但是无论是否遵循敏捷方法，大型组织都有其需要面对的问题。

　　敏捷开发能为大型企业提供什么？首先，敏捷能够通过自动化的实现任务以减少人类所犯错误并使得团队利用更少的资源作更多工作以提高团队效率。其次，敏捷能够帮助大型企业改进质量，更有效的处理回馈给开发成员的改变，从而更迅速的解决问题。第三，敏捷能够通过使用叠代计划、分析、开发行为 -- 这些可由系统根据所设计的代码自动化的产生 -- 替换庞大的（且很快过期的）需求文档，以进行更丰富更及时地沟通。

　　后，敏捷配置管理方法可以在项目级或企业级加以实现。不需要在这之前考虑一个组织，因为单个项目可以是一种实验性的或想法孵化器。同时，当在企业级实现了敏捷配置管理实践，那么企业必须为每个项目团队提供足够的灵活性与自主性，实现其佳解决方案。