作者：张克强 作者微博：张克强-敏捷307
依据IEEE 828和CMM/CMMI，配置管理计划经常被觉得是一份文档。确实的，对于一个大项目而言。往往须要制定项目自身的配置管理计划。
但不是全部的组织都是软件外包组织，不是每一个项目针对的是不同的客户。
在非软件外包的高效软件开发组织中，推荐的配置管理计划应有三个层面。
首先是组织层面，一般，提供统一的配置管理服务，不会同意每一个团队自己搭建配置管理server。
所以对于组织级的配置管理服务要有所约定。约定的主要内容有：
怎样建立项目文档文件夹？
怎样建立产品级文件夹？
怎样建立代码文件夹？
配置项怎样命名？
配置库的备份和恢复怎样进行？谁来进行？
什么情况下拉分支？什么情况下合并到主干？ 关于分支主干要提供多种模式，或者放开限制，让产品线或者项目组选择。
怎样进行变更？ 一般应当在组织级进行定义和公布。假设放到项目层面。变更流程的制定太费功夫。当然有些大项目是有足够的预算和特殊情况须要专门定义项目级的变更。
对产品线和项目怎样开展配置审计？
有什么推荐的配置管理实践？
组织级配置管理规程或者指南的更新频率在每年一次左右。
其次是产品线层面。
对于特定产品线。已经存在大量的源码和文档，那么结合实际。这个产品线在配置管理存储时有哪些约定？
比方对代码配置项和非配置项有所说明。不要假设每一个团队新人都是代码配置管理达人，小心自以为是的新手增加一些自以为是的垃圾。尽管能够删除。但发现再删除。其本身就是成本。
比方哪些依赖项值得存储？
比方哪些区域是机密。权限另外管理
比方那些代码是核心代码。假设修改须要资深人员复核。
本产品线的主干和分支策略是什么？ 守护主干？还是先锋主干？无分支？还是单分支？还是多分支？
比方约定团队统一一致的工作环境：都把Java装在C:/java，把eclipse装在D:/eclipse
最后是项目层面。在有了上述组织级和产品线级的配置管理约定后，项目层面的配置管理计划中最关键的是须要明白人员、基线和项目特殊配置项。当中基线的安排必须与项目本身生命周期的选择相匹配，最重要而言，必须匹配于里程碑。
在这种三层结构下，为项目高效计，不须要单独写项目的配置管理计划，仅仅需把项目级的配置管理约定写入项目计划就可以，一般的篇幅不超过1页。