【配置管理】14、项目管理眼中的配置管理

  目的目地是为了创造一项产品或服务，因此，产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中，软件配置管理都是一项不可或缺的重要管理内容，特别是对于服务企业内部的信息技术部门来说，从产品生命周期出发，同时支持服务产品和软件产品，同时负责开发与运行，其管理复杂度很高，要想理顺各项工作的内部关系、理清各项工作之间的配合关系，都离不开配置管理这个基本手段，它是许多管理工作的“落地”部分。其实，配置管理并不是一个时髦的概念，在许多传统行业（例如制造业）中早已有之，软件行业只是在软件工程方法中继续延用了这一概念，它是一流软件开发企业所必备的基础设施。项目范围管理需要配置管理来落实段，是一个非常宽泛的概念，项目中只要是需要进行管理的任何特性，都可以纳入配置管理。配置管理不只是操作层面的问题，更是管理理念、管理方法的问题，是一个系统。

1.项目范围管理需要配置管理来落实

  在项目范围管理中，需要识别和控制项目的交付成果，要描述交付物应有的各种特性。这些交付物及其特性，就是配置管理中的配置项。从项目管理的角度，WBS只需要分解到可管理（Manageable）的程度，而配置管理则要求分解到最终可操作的程度，管理的粒度更为精细。因此，良好的配置管理机制，是项目范围管理得到最终落实的保证。
在许多软件开发项目中，项目范围管理涉及三个方面：业务需求、技术结构、投产服务。编写哪些程序模块，实现哪些功能，部署到哪些地点，这其实都是项目范围管理所要关注的内容，在配置管理中对应了产品的物理属性和功能属性以及服务的属性，都可以通过配置管理来识别、记录和跟踪。只有做好软件配置管理，才能真正把项目的范围管理做实。

• 1)业务需求决定了软件产品的功能特性，对软件产品的配置管理，首先就是对业务需求的管理。在业务需求中，要求软件产品所提供的各种功能和特性，包括界面风格、操作方式、处理流程、业务规则、数据逻辑等，也都是软件产品的配置项，这种对业务需求的分解、管理的过程，就是对业务需求中的配置项的管理过程。当项目中业务需求发生变更时，其实就是对这些配置项的变更管理。因此，在软件工程过程中，配置管理是需求管理的基本手段，通过科学、严谨的配置管理方法，对业务需求进行识别、分解、跟踪、控制，直接决定了对业务需求的管理能力。许多公司目前在需求管理方面还处于粗放型的管理，虽然基本能够满足项目管理的需要，但对于软件工程过程来说，管理粒度还比较粗，而且缺乏明确的配置项的定义，缺少有效的跟踪控制手段，还需要更精细的管理。
• 2)技术结构是软件产品的物理属性，软件产品的配置管理，也是对软件内部技术结构的管理。从技术方案到软件产品、再到产品内部结构，这也是项目范围不断分解、细化的过程。为了实现业务需求、满足产品外部特征的要求，软件产品应如何设计其内部结构，划分内部模块、定义模块接口、确定有多少个程序等等，产品分解到最后，每一个程序都作为一个单独的配置项进行管理，在开发过程中对于程序的修改都纳入配置管理，跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义，就是基于技术结构的配置项管理，是与软件结构设计相对应的，配置项的划分是否合理，使用起来是否灵活、方便，哪些可以成为公共组件（Component），其实反映的都是软件设计的思想。在有的软件企业中，配置管理不只是程序员的操作工具，它已经成为工程技术管理的重要手段，是由公司的总工牵头负责的。因此，配置管理是软件工程过程中技术管理的基本手段，起到对技术结构进行分解、识别、跟踪和控制的作用。
• 3)投产服务与软件产品的部署有关，是对项目服务特性的要求。运营企业中可能同时有多个应用系统，相互之间往往具有很高的耦合度，一项新业务的推出，往往需要多个软件产品配合修改和同步投产。因此，从业务角度来说，一个新的业务产品的实现，需要多个软件模块（产品）的支持，不同投产单位中这些软件模块（产品）的版本配合关系不同。那么对于运行中心来说，需要面临同时满足业务产品和软件产品的双重要求，既要保证业务产品的完整性和多样性，又要保证软件产品的一致性和兼容性。因此，对于投产管理来说，也有同样的配置管理的要求，是必须在企业级来考虑的。

2. 配置管理中的版本管理和变更管理

  配置管理中要记录、控制、报告各种属性（配置项）的变化状态，这就是配置管理中的版本管理和变更管理，有变更才有不同的版本，版本又成为变更控制的主要对象，这两者是紧密关联的。
  首先要澄清一下版本的概念。在配置管理中，每个配置项的每个状态都可以称为一个版本，配置项的演变过程就可以体现为一棵版本树。而我们平时经常说的版本，实际是指软件产品的版本，不是具体配置项的版本。一个软件产品版本是由众多配置项组成的，每个配置项最多只能选取它的一个版本组成一个特定的产品版本。因此，在我们平时谈到“版本”时，需要明确是配置项的版本还是软件产品的版本，否则容易在沟通中带来混淆。既然版本管理是配置管理中的一项内容，那么对于在软件产品版本管理中遇到的各种实际问题，就需要放在配置管理这个大背景中，基于配置管理的理论、方法和工具来考虑，才能逐步理清。
  项目中的变更管理是大家都已经很熟悉的工作，从概念上来说，变更管理也属于配置管理工作的一部分。在软件开发项目中，无论是功能需求的变更、技术需求的变更还是服务需求的变更，也都可以将变更要求与配置项建立对应关系，演变成为配置项的变更，配置项在变更前后形成不同的版本，这样就使得变更管理能够有的放矢。如果不能将变更要求落实到具体的配置项上，项目中许多的变更控制就难以具体落实。
  具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪，必要时还可以回退到以前的版本，例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。
配置审计是配置管理中的一项重要工作内容，有时被分为物理审计和功能审计，通过物理审计按照配置管理计划来验证所要求的各配置项的完整性，通过功能审计来检查各配置项的内容是否完全符合用户的要求。配置审计是配置管理工作中的重要一环，也是项目质量管理工作中的一项内容。

3. 项目与产品的矩阵关系需要配置管理来执行

  项目管理与产品管理的矩阵关系，其实是集成项目管理中必须要解决的问题。对于项目管理与产品管理之间多对多的矩阵关系，已经被普遍理解，但是在细化到操作层面时，这种矩阵式的配合关系有时还存在一定的混淆。
  企业中的软件开发部门首先要关注产品，通过基于软件产品的开发工作来实现业务需求，并负责对整个软件产品生命周期的管理。许多公司目前的实际做法是，在组织层面上，项目组实际的组织方式是，在项目组中有多个产品开发小组，每个小组负责某个或某些软件产品的开发工作，项目中跨产品的整体的业务需求、技术架构、系统测试、项目管理等工作，仍由项目组统筹管理。项目组内的产品开发小组，可以与其他项目、维护任务共享资源，可以从产品角度保证软件产品的兼容性和一致性。通过这种组织方式，可以平衡项目管理与产品管理之间关系的，产品经理和项目经理是这两个管理维度的具体执行者。
  对应这种组织方式，配置管理也需要支持矩阵式管理结构。对于属于项目管理的内容，可以针对项目建立配置库进行配置管理，包括项目级的业务需求、项目的整体技术方案、系统功能测试、项目管理过程等内容，而对于单个软件产品，则需要纳入产品配置管理的范畴，针对产品进行配置管理。这和产品文档与项目文档的划分思路是基本类似的。

  配置管理，其中对业务产品的配置管理，核心就是对业务需求的管理。这两类产品在配置管理中也会形成矩阵关系，某个业务需求的配置项，涉及若干个相关程序——技术配置项，一个程序也可以同时支持多个业务需求的配置项，形成多对多的关系。基于以上对项目和产品的配置管理管理的辨别，在实际操作中，将软件产品在某个项目中的分支，从产品的配置库中独立出来归入项目配置库进行管理的做法，或者把对应项目的配置项放在软件产品的配置库中进行管理，这两种做法都是有欠缺的。

  如果能够对两种产品都做好配置管理，并且能够建立起这样的矩阵关系，那么不仅在开发中很容易将整体的项目范围逐步细化到底，能够及时对各种变更的影响范围作出判断，做好变更控制，而且对于以后的维护工作能够提供很好的基础，有助于根据业务处理中的问题现象迅速定位到技术缺陷。

4.多项目并行开发需要软件配置管理的协调

  通常情况下，软件部门会同时承担众多的开发任务，都可能会同时需要修改同一软件产品。从软件产品的角度来看，就是并行开发的问题。在企业内部，基于同一产品的并行开发任务通常不会产生不同的软件产品，而是形成同一产品的顺序的多个版本，这就要对软件产品的并行开发做好配置管理，避免并行开发中的版本冲突，这是软件配置管理策略中最为复杂的部分，也是软件配置管理最大的价值所在。只有做好基于产品的配置管理，对并行开发加以协调和控制，管理好版本分支，才能灵活的处理好并行开发任务之间的产品版本的顺序关系。产品版本之间的顺序关系，与项目之间的依赖关系是相互影响的。哪个项目的业务产品需要先投产，那么与之相关的产品版本就要先形成，产品版本顺序一旦确定后，要重新调整版本顺序，就需要退回到最初的开发基线，恢复已经合并的原有分支，选择另外的分支重新进行归并，重新形成新的软件产品版本，这也会对项目管理产生很大的影响。
  在并行开发的情况下，企业级的配置管理系统，为并行开发任务之间提供了重要的沟通平台，这种沟通不是一般意义上的项目管理范畴中的协调，而是各项目之间针对产品版本关系对具体工程活动的协调，会对最终产品产生直接的影响，所以软件产品的版本策略是多项目并行开发中必须要关注的问题。因此，在多项目管理中，需要更加深入地关注到各个项目当中的工程活动之间的协调关系，工程类活动之间的依赖关系，往往是项目之间各种依赖关系的决定因素。