我虽然没有直接从事SCM工作（我负责组织并起草软件工程化方面的相关标准规范），但经过两年的学习对SCM有了一些认识：SCM最重要的作用就是将个人的劳动成果转化为团队的成果，利用SCM工具提高软件的重用，提高工作效率，减少不必要的重复劳动等等。
规定一定的流程是不可缺少的，来实现对对软件版本的控制、软件变更管理等等。

香飘何方的理解让人对软件开发的过程有一定的了解，不愧是对工程化方面有研究的人，但是对于SCM我还是有点稍微不一样的个人理解：

将个人的劳动成果转化为团队的成果这个应该是项目经理关注更多的东西，提高软件的重用这个应该是系统工程师更需要关注的东西，当然我这里不是说只是项目经理或者是系统工程师才需要关注这些东西，作为项目组的成员都需要对这些进行关注，只是大家的侧重点不一样。提高工作效率，减少不必要的重复劳动，对于不同的角色来说有着不同的定义，对于系统架构师来说就是基于构件，可重用，面向对象的体系结构设计，对于项目经理来说可能是资源的利用，进度的安排，而对于SCM来说就是通过版本控制和变更控制来达到此前的目的。

当然上面的只是我个人愚见，而我现在也在学习工程过程方面的知识，还望香飘何方以后多多指教，呵呵。

见笑了！
引用流水先生对SCM的一种解释：“软件配置管理是围绕软件资产的管理。
啥叫软件资产呢，就是设计文档啦，源代码啦，可以跑的程序之类的。
那么，有什么要管理的呢？让我们把它和图书馆的图书管理做个对比。
它们有一些相似点。
首先，图书馆图书管理管的是图书资产，软件配置管理管的是软件资产，它们管的都是信息资产。
其次，图书管理，需要把图书进行分类，以便检索，需要图书存放在合适的地方，以便存取，还要防止虫吃鼠咬。
软件配置管理也类似，需要把软件资产——主要是源代码什么的，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。
再次，在图书馆，要记录谁借出了哪本书，还没还。
而软件配置管理中也类似，需要记录谁借出了什么文件。
不过，跟图书管理不同的是，软件开发人员借出文件，常常是为了修改它。
软件配置管理要记录谁修改了什么文件，为什么修改，等等。”

这种解释比较符合我对SCM的理解。当然，理解归理解，当真正做的时候太艰难了。

W.FF说“将个人的劳动成果转化为团队的成果这个应该是项目经理关注更多的东西，提高软件的重用这个应该是系统工程师更需要关注的东西，当然我这里不是说只是项目经理或者是系统工程师才需要关注这些东西，作为项目组的成员都需要对这些进行关注，只是大家的侧重点不一样。提高工作效率，减少不必要的重复劳动，对于不同的角色来说有着不同的定义，对于系统架构师来说就是基于构件，可重用，面向对象的体系结构设计，对于项目经理来说可能是资源的利用，进度的安排，而对于SCM来说就是通过版本控制和变更控制来达到此前的目的。”说得没错。SCM贯穿于软件整个生命周期，利用SCM工具给整个项目的每个参与者提供一个可供选择的平台，再将所用的配置项配置管理起来，供后续人员再利用等等。这都是一个SCM管理人员主要做的事情。

这都是个人理解，正确与否尚未确定，本人所在单位是国企，这两年一直在开展软件工程化工作，任务艰巨，路途艰难，也在期待专家指导:loveliness: :loveliness:

其实图书馆的例子只是体现了SCM的配置项标识和变更的审计，这两方面确实体现得比较贴切，但还是有一些重要的东西并没有体现出来，比如说变更控制（可能自己眼拙没有看出来）。

审计是在配置项建立前期还不稳定时采取的措施，此时配置项变化过多，频率过高，所以不需要太大力度的控制变更，不用CCB决定。所以只需要记录变更时间，负责人等信息以便于变更的跟踪。到了建立后期，变化少了，频率降低了，项目组确定整个配置项比较稳定的时候，这个时候就利用基线的概念建立对配置项的管理，这里也是图书馆例子没有体现的。在基线管理的时候，如果发生变更了，就走变更控制流程，由CCB进行商议。

所以我觉得用图书馆管理作为SCM的范例还是不太全面。当然，依旧是个人愚见。

这个配置项的准则， 不空洞理论，比较实际~~
谢谢斑竹

大家讨论的很激烈阿，觉得图书馆的例子的确与配置管理在某些方面很类似，只是没有包含基线方面的内容。
配置管理工作是非常关注基线的，关注各配置项之间是否保持一致。
另外，我觉得基于活动的配置管理更能体现出配置管理的价值。在某个配置项发生变更的时候，我们总是需要知道该配置为什么要变更以及基于相同原因变更的配置项还有哪些。

配置管理的重点在哪里，要很明白的说真的不太好表达啦，总之配置项是它的重要组成部分吧，不过我做配管有些日子了，居然对配置项的概念还有标识的定义还是有点模糊，真是惭愧哎，大多都是自己一边做一边看资料摸索的，呵

个人比较同意 二楼make 的说法

变更管理最终的落脚点不就是配置项的管理么？

11楼把问题说得很清楚了