敏捷 SCM
敏捷 SCM 概念本身可能是由 Brad Appleton 和 Stephen Berczuk 在他们的书 Software Configuration Management Patterns 中 和 SCM portal CM Crossroads 中被首次进行了详细地讨论。 2 其中一个观察是：
配置管理在利用平衡且有效的 SCM 过程集方面成为关键的“支柱”并且也是敏捷开发方法的标准。“敏捷倡导者”着重强调在敏捷项目上应用瘦的及轻型的配置管理（CM），这将需要更少的打扰/入侵（Grady Booch 所谓的低摩擦），以使敏捷项目能够成功，而与此同时配置管理有不能太小（由于过度反应）以至于导致项目失败。
与我刚才的观点一致的是，虽然敏捷项目上的 SCM 趋向于更加轻型且更少的可见性，但是 SCM 本身是此类项目的关键需求。也许不一致的是，大多数敏捷项目采用入门级或轻型的 SCM 工具，例如 CVS、Subversion，或 BitKeeper —— 这些工具有局限性但基本上拥有满足敏捷项目的功能。它们也是趋向于较小的影响并且重视开发经验的工具，而不是对一个严格控制过程的遵循。
然而，理论上，您没有理由不能使用 SCM 工具来支持敏捷开发实践。您当然不必要使用工具的所有特性，并且大多数工具允许某种程度上的过程定制化，从重量级到轻量级的，以及两者之间的任意程度。有了企业级工具，例如IBM Rational ClearCase，一些组织总想使用所有的“突出特性”来定义重量级的 SCM 过程，只因为该工具提供支持。然而，这样的过程对满足您项目的需求是不必要的。要找到正确的过程和定制级别，您应该首先确定并定义您的需求，这意味着确切地了解您的开发过程是什么，或者应该是什么，然后确定 SCM 如何提供支持。
一般来说，SCM 是关于开发过程“管理”的，换句话说，SCM 允许项目保留控制措施，而与此同时又能够允许开发人员在过程中拥有创建的自由度。利用敏捷开发方法，开发人员拥有高度的自由和权利来实现变更。然而，持续集成和测试驱动的开发实践的一个结果是，它们实际上形成了一个规划良好的并且几乎自治的 SCM 方法。例如，在每个代码变更时，敏捷开发人员必须首先撰写一个单元测试，然后撰写足够的代码使测试能够工作，随后按照需要的重构以完成该变更。提交（或检入）代码变更，并且代码变更的单元测试成为集成套件中的一个部分。通过集成构建机制编译和执行完整的单元测试套件，可以直接可视化地看到变更的所有副作用 —— 所有找到的问题都能够立即修改。
在敏捷 SCM 中，该管理模型是日常开发活动的正常部分，并且因此对开发人员是相当透明的。要更详细地了解此管理模型，让我们看看 SCM 的一些不同的特征，以及如何典型地实现它们来支持敏捷开发方法：
分支。敏捷项目实现简单的分支策略，典型的是活动开发线（Active Development Line） 3 和版本预备线（Release Prep Line）。活动开发线由开发人员用来提交他们的变更并且持续集成构建通过此方法来执行。版本预备线是用于在客户使用之前稳定化或工程化一个版本的，通常不允许开发人员向它提交变更。
工作区。开发人员拥有一个单个私有的工作区，最初指向活动开发线最新版本的集合。在开发人员开始致力于新的特性或变更请求时，并且就在他们向活动开发线提交变更来检查集成问题之前他们的工作区以最小量更新着。
标签。如传统的 SCM 一样，标签放置在代码版本集合重要的里程碑上，在每个版本构建上至少有一个标签，以便在必要时能够重新产生构建环境。
构建和集成。成功的敏捷开发的关键因素是自动化的构建过程。构建过程监控关于提交的活动开发线，在一个较宽松的限期自动地执行集成构建和单元测试。该构建成功或失败的通知是敏捷团队中关键的通信因素。
变更控制。如早先讨论的一样，一个隐含的授权过程伴随着敏捷开发团队，授权开发人员做出基于客户优先级的变更，或者在必要时重构。请求要么记录在变更控制系统中，要么对于更不正式的项目来说，特别是在极限程序设计项目中，记录在卡片上或活动挂图上。
虽然这些 SCM 特性典型地处在敏捷过程中，但是它们很可能根据特定项目所需的敏捷程度而“调整”。例如，一些项目也许不能构建在每个提交上，取而代之的是计划一个单个的每日或每夜的集成构建。还有，项目不是独立存在的，它们通常是组织中许多项目中的一个。企业组织中常常混合有敏捷和传统的计划驱动的项目，并且因此一个已知的项目可能存在于特定的市场区段中。该企业环境常常是决定选择哪个 SCM 工具集并且所选工具集需要支持哪些额外的管理方面的最大的因素。
