《配置管理》的开头

lifegame

应扬帆兄要求，把《配置管理》这章第一节的草稿贴出来，征求大家的意见。
--
第一节：配置管理概述

1、为什么需要配置管理

在医疗信息化项目中，也许会出现这样的一些问题。有时，之前刚刚修改过的软件缺陷，或者前不久已经实现了的客户化需求，在最新版本里竟然消失了。有时，面对好几个科室甚至好几家医院同时提出的问题，需求人员和开发人员忙得不亦乐乎，但一些关键的问题却石沉大海，客户一直得不到回复。有时，发现一个共性的问题，需要大规模地升级系统，但由于各个科室安装的工作站太多，每个科室可能还有一些特殊的用户设置或者客户化补丁，到底哪些工作站适合升级，以及如何升级，才既能修复问题，又不影响系统稳定运行？有时，为了实现信息集成以及更加顺畅的工作流，需要对某个已经上线运行的系统进行修改，但是负责开发这个系统的程序员已经离职，负责维护这个系统的开发人员又找不到当时的代码，或者在磁盘备份上好不容易找到了某个版本的代码，却无法编译。所有这些问题，都跟配置管理有关。

很多人会觉得配置管理的工作很虚。在项目经理看来，配置管理无非是管好各种文档，以及记录一下将要发布的版本；在开发人员看来，配置管理无非是每天例行的签入签出，以及定期的集成和构建；在实施人员看来，配置管理无非是记录和报告各种服务器和工作站的硬件设置和软件安装情况，不厌其烦，又枯燥无味。

的确，配置管理并不能像编写程序那样给项目带来直接的价值，但它最重要的意义之一在于让包括编写程序在内的各种原本不可见的工作任务可视化（用配置管理的术语，我们叫做配置项识别），这种可视化正是团队沟通协作，以及项目质量、风险，进度和成本控制，甚至包括量化审计的基础。正是配置管理所包含的这些看似简单和重复的工作，却为项目的顺利运行提供了坚实的保障。

2、什么是配置管理

配置管理的主要任务是对项目中不断变化的各种工作产品进行记录、控制和报告——这些工作产品可能包括需求和设计文档、每一台服务器和工作站、甚至细到每一个代码文件、以及记录用户操作喜好的个性化设置文件——其目的是确保这些工作产品之间的关联一致性和质量完整性。对于整个项目周期来说，配置管理是一个重要的支持性工作，它是项目走向精细管理的必经之路。

传统意义上的配置管理，包括配置项识别、变更控制、配置状态报告和配置审计几大部分。在一些理论模型[ITIL]中，配置管理可能会跟变更管理、发布管理分开进行描述。但他们之间是密切相关的：变更的评估必须在配置管理相关的状态监控活动，以及涉及多方协作的流程控制之内进行，而变更的实施一般也是通过发布管理活动来执行的。因此，本章的讨论范围是包括了变更控制和发布管理在内的完整的配置管理。

当然，在具体的项目实践中，不同的医疗信息系统提供商，或者不同医疗机构中的IT服务部门，对配置管理工作内容的定义都略有不同。他们通常在传统的配置管理基础上，增加了配置管理工具的应用、维护、培训和支持，软件的集成、构建和版本发布，甚至包括制作软件自动安装包等工作内容。本章的讨论，以配置管理的核心任务，即配置项识别、变更控制、配置状态报告和配置审计为主，并分别针对不同规模的医疗信息化团队的特点，对配置管理的实施策略进行探讨。

3、如何做配置管理

在一些人的印象中，实施配置管理，就意味着某些文档必须按照指定的格式来写，某些代码必须在指定的时间和地点（目录）上签入签出。原来开发人员发现代码中的一些技术性的小问题，可能马上就动手修改，现在却要经过层层审批。原来需求人员听到客户的一个抱怨，可以直接把怨气泄到技术人员头上，责令他们赶紧修改，现在不仅要讨论来讨论去，还要在各种文档上进行繁琐的记录，甚至还要邮件通知一些以前认为似乎没有必要告知的那些人。难道配置管理真的就是这种繁琐枯燥，既增加项目成本，又拖长客户响应时间，还让人觉得碍手碍脚的过程累赘吗？

其实，信息化项目比传统的工程领域项目更加容易失败的原因之一，就在于很多信息化的工作产品的不可见性。比如，如果是某个机械零件长了或者短了几个毫米，不管是工程师还是管理者都能肉眼直观看到。但如果是在设计数据库的时候遗漏了一个外键约束，或者是不小心使用了另外一个版本的编译器，使得同一段代码编译出来的程序略有不同，有时可能难以觉察（除非是专业的测试工程师，利用精心设计的用例，经过相当长一段时间的测试）。为了化解这些风险并防范于未然，IT工程师和管理者们必须使用一些过程和方法来保证这些零部件在集成起来的时候能够正常工作，并且满足客户需求。配置管理就是这些过程和方法中非常基础又十分重要的一个。

因此，配置管理并不是空穴来风，只是我们由于每天都在使用它，所以渐渐淡忘了而已。比如我们经常使用的“版本”这个词，就来自于配置管理，它是识别配置项变化的重要工具。又如我们常常谈到的“需求变更”。其实任何变更都是发生在一个基准基础上的变化，没有基准，变更根本无从谈起，而这个基准就是配置管理需要特别关注的“基线”。

下文（本章第二节）将详细说明配置管理的具体方法。当然，这些方法得以实施的前提是高层的理解和支持。因此在信息化项目中，主要负责沟通的项目经理，有责任让你的领导，客户，以及团队的所有成员，理解相关的配置管理理念、策略、流程和工具，这是配置管理以及其他相关工作得以开展的必要前提。

4、谁来做配置管理

在很多理论模型[RUP]中，都有一个配置管理员或者配置管理工程师的角色。因此，很多人会习惯性的认为项目中配置管理的工作都应该由这个角色来完成。同时，配置管理的工作本身看起来确实没有开发或者测试工作那样有技术含量，所以这个角色常常由一些年轻的工程师担当。另外，开发团队一般总是聚在一起，比较好管理，实施团队则是经常出差，在客户现场安装硬件和软件，并进行必要的客户化设置，所以配置管理就先在开发团队里面做起来，保证发布给实施团队的版本没问题就行了。以上这些错误的决策，常常会导致配置管理的失效，并最终让项目陷入混乱。

笔者认为，在开发团队中，配置管理工程师必须具备以下几种素质。一、编程经验，知道软件是怎么一步步开发出来的，这是不可回避的基础；二、对开发方法进行反思的习惯，以及系统思考能力，这是配置管理的基本素养；三、了解配置管理工具的使用和维护，并为项目提供支持，这点可以通过学习来实现。对于职责跨越开发团队和实施团队的配置管理，还需要了解实施团队的工作方式。当然，对流程进行系统思考的能力，始终是为团队制订和优化配置管理策略，帮助团队提升工作效率、服务质量和客户满意度的核心能力。这些，都不是一个新人能够轻易做到的，但如果让一个资深工程师或者项目经理去兼职做这些工作，又会让人觉得有点成本太高。但有时，这点成本是值得的。下文（本章第三节）的案例中，我们会详细讨论在不同规模的团队中，配置管理的运行模式。

其实，在众多不成熟的小型团队中实施配置管理的一个关键，在于向大家灌输一个观念：即配置管理不是配置管理员一个人的事，而是需要整个团队共同参与。配置管理也不仅是一种管理方法和流程，更是一种工作习惯。这种习惯要求每个人工作的时候，都要考虑到不同成员之间工作产品的相关一致性和完整性，都要考虑到自己的工作是否会影响团队最终交付的产品或者服务的整体质量。因此，养成这种习惯，无论对于一个团队还是对于个人开发者，都将受益匪浅。笔者认为，这也是把作坊式团队打造成正规工程团队的一个很好的切入点。

扬帆

我觉得这个章节规划写得也简洁明了,一并帮梁工贴出来吧!

第十六章、项目配置管理

章节目录

l
第一节：配置管理概述 (LL，1000-2000字)
（针对国内医疗信息化现状和面临的问题，介绍配置管理的基本思想）

n
为什么要做配置管理

n
什么是配置管理

n
如何做配置管理

n
谁来做配置管理

l
第二节：配置管理的基本方法 (XB，3000-4000字)

n
识别和管理配置项：配置项、版本、分支、基线等基本概念

n
变更控制：流程、模版、表格

n
配置状态报告和审计：流程、模版、表格

n
配置管理的过程、人员和工具：CM计划、CME职责和组织、工具选型

l
第三节：配置管理的常用策略和案例分析 (3000-4000字)

n
针对创业型（医疗信息化）团队（LL）

n
针对成长型（医疗信息化）团队（LL）

n
针对成熟的（医疗信息化）团队（XB）

l
本章小结 (LL，<500字)

n
在项目中务实地实施配置管理

主要参考资料

l
CMM/CMMI

l
IBM Rational (RUP, Clear Case)

l
ITIL（浦东图书馆 F49/4463《基于ITIL的IT服务管理基础篇》）

l
www.SCMLife.com：《未雨绸缪：理解软件配置管理》