配而论道——从大禹治水看软件配置管理

    经常和软件企业探讨软件配置管理的相关问题，发现很多人有一个比较大的误区——即将配置管理从整个软件开发体系中割裂出来就事论事的进行探讨。因此常常会针对这个问题进行一些探讨，现将相关内容稍作总结如下：

换个角度看配置管理

    关于配置管理的定义不同的标准体系都会有其自己一套标准定义，在这些各不相同且用词生涩（往往是不良翻译的结果）的定义前我们往往会一阵阵的犯迷惑——到底什么是配置管理？因此我们有必要先搞明白一个最基本的问题，到底配置管理是干什么的。
    首先，让我们忘记教科书上那一长串由英文翻译过来（通常因为缺乏逗号断句而读起来非常拗口）的关于配置管理的定义吧，让我们以目标驱动的思路来看看配置管理到底是要干什么？——其实很简单，配置管理的目的就是控制变更， 而对变更的处理模式的不同将直接衍生出完全不同的配置管理体系——而这一切又和软件开发模式和选用的生命周期密切相关。所以，在规划企业软件配置管理体系之前一定要确认相关的开发模式及变更控制的策略。否则，生搬硬套的结果难免会打造出穿着汗衫打领带的奇异造型。
   那接下来让我们看看关于变更的哲学观及其对配置管理的影响：

关于配置管理的哲学观

    经典的软件过程对待变更显然采用的是禹的父亲鲧治水的方法——堵，他告诉我们：变更是危险的，所以必须严格受控，所有可能变更的元素（即配置项）必须被造册登记（配置项标识），并将其圈禁于若干固定的区域内（基线化），而所有变更，尤其是跨区域的变更（涉及基线的变更）必须遵循严格的审批流程（变更控制流程），而变更完成后必须重新将其圈禁于相应的固定区域内（基线更新）。
    显然，要满足这一一套体系，我们的配置管理体系必须具备对于变更的纵向（需求—设计—代码—测试）和横向（相互关联的需求和需求之间或代码和代码之间）的双向可追溯性。而这种可追溯性的有效性是保证整个配置管理体系有效运作的基石。不幸的是，在大多数情况下，我们还只能通过人力而非自动化工具来保持这种可追溯性，这也是经典配置管理体系最大的风险所在。（永远不要相信CMMI评审过程中咨询公司提供的那张名为“需求跟踪矩阵”的Excel表格可以被真正的用起来，建议在评审过后直接将其放入“回收站”）

    而以敏捷为代表的现代软件过程体系则高调宣称：“拥抱变化吧”（这听起来让人心情愉悦，不过建议在拥抱以前做好充分的准备，要不然十有八九要摔一大跟斗），在充分总结了经典软件过程的众多失败案例后（一如鲧的儿子——禹当年所做的那样），其采用了禹当年的治水策略——疏导，他认为变更是不可预期的，在大多数情况下，采用追溯的方式来控制变更是成本高昂缺效果有限的。因此，既然管不了，就让该来的就来吧（因此就有了“拥抱”一说）。但是，就这样扒开口子放任洪水（缺陷）泛滥吗？显然不可能，一如禹当年的“疏导”策略，敏捷类软件过程体系的配置管理跟专注于如何及时发现和修复变更导致的各种缺陷，于是就有了每日构建、测试驱动、小迭代开发等等一系列的最佳实践。因此基于这种模式的软件配置管理体系的重点应该在于：灵活而有效的并行开发管理体系（选择适当的分支结构模式和控制策略）；有效的自动构建和发布体系等等。

    当然，上述两种配置管理模式都有其适用的环境，相对来说对于对缺陷的容忍度为零或接近于零的项目（如军工或航天项目），或是需求明确而稳定且变更较少的项目可以选择第一种配置管理模式。而那些需求不明确或变更频繁的软件项目则无疑更适合于后者。