谈谈产品开发团队的配置管理规则

作者：张克强    作者微博：张克强-敏捷307

在《源代码管理的新15条建议 》中的第7条建议提到：每个团队应当对代码配置项和非配置项有所说明，不要假设每个团队新人都是代码配置管理达人，小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除，但发现再删除，其本身就是成本。

在《高效组织的配置管理计划》也提到了产品线层面的配置管理，那么产品开发团队的配置管理到底应该是什么样呢？本文试图来探讨下。

首先说明本文探讨的产品开发团队的特征。这里的产品开发是指围绕某产品或者产品线开发，其产品的生命周期是长于一年以上，为了改进产品，不断有新的要求得到实现满足，也会发现产品的缺陷，需要在开发中解决。 这样的产品开发是不同于短期合同外包项目的，其产品开发团队将较长期的承担此产品（线）的运行维护，增强修改，开发建设。应当说，当前大多数团队是属于这样的团队。

什么是配置管理规则？

配置管理规则这个说法也许过于学术化，讲白了其核心就是文件如何存放和版本升级。而规则即是团队共同遵守的约定。比如在某目录下存放会议纪要，为了便于查找会议纪要的文件名以会议日期开头，格式是YYYYMMDD。

为什么需要产品开发团队的配置管理规则？

1，开发团队是多人组成，规则能够让所有人查询，有依据，协同提供效率

2，产品开发是长期过程，文件会越来越多，如果没有一定的规则，将造成文件遗失或者难以查找。

谁来制定团队的配置管理规则？

团队负责人应当为团队长远的信息资产负责，组织团队成员来商量团队自身的配置管理规则。

如果团队存在配置管理员这样的角色的话，那么配置管理规则的起草和维护当然首先是配置管理员的事情。

团队的配置管理规则有哪些内容？

对于软件开发团队，显然首要的，源代码管理是规则重点覆盖的内容。对于源代码管理，要回答如下典型问题：

1，选择什么样的源代码版本控制工具？如果组织已经选定，或者历史上已经选定，那么需要遵循。这是基础工具，一般不会经常变化，而变化必须经过慎重的考虑，当然往往的这是组织级考虑的内容。所以这个问题对于绝大多数团队而言，不是问题，因为已经有选定的工具。

2，对于源代码，选择什么样的主干分支模式？ 这是显著影响团队效率的选择，必须团队骨干一起来做决定，不同的主干分支模式适用于不同的场景，需要团队中此方面的达人来提供建议，如果团队内难以做决定，麻烦组织中的高手来设计本团队的主干分支模式也是应当的，甚至有组织邀请业界专家来为重要产品线设计主干分支开发模式，并制定规则。

3，对于选定的主干分支模式，有哪些操作注意点，具体而言比如如下问题：

3.1 什么情况下从主干拉出分支？

3.2 什么情况下合并分支到主干？

3.3 什么情况下从分支拉出分支？

3.4 什么情况下从主干合并到分支？

3.5 什么情况下从分支合并到分支？

3.6 什么情况下删除分支？

3.7 如果选择主干无分支，那么需要注意什么？有什么配套手段？

4，源代码检入时需要遵循什么规则？ 如何书写检入说明？ 是否需要与某个变更或者需求或者缺陷进行关联? 要先本地进行静态代码扫描？ 先进行code review？还是后进行扫描，或者code review

5，哪些区域的代码是信息安全高等级代码？ 访问级别比较高，团队外围成员需申请后才能访问？如何申请？ 

6，哪些区域的代码是核心代码？ 或者是红区代码，但凡此处代码修改，对应的测试范围需要扩大，关联到其它的系统？

7，为了协同工作，在工程师本地电脑上需要如何设置？

其次是文档，文档就存活时间而言，分为两类：第一类是其生命周期与产品相同；第二类是其生命周期与特定改进、事务或者项目相当，明显短于产品生命周期。

第一类文档可称为产品级文档，比如团队配置管理规则就应当是产品级文档，值得长期得到遵循并改进，此类文档典型有：

1，产品白皮书，产品介绍

2，产品功能目录，使用说明，系统功能树

3，产品应用架构，组件（系统，子系统、模块）结构图，组件（系统，子系统、模块）接口说明

4，产品性能架构，并发控制，处理高性能要求的架构模式

5，团队章程，团队改进建议

6，产品待办需求列表，原始需求

第二类文档可称为项目级文档，此类文档是大家最熟悉的文档，如下：

1，项目计划

2，项目需求规格说明书

3，项目会议纪要

4，项目测试计划

对于两类不同的文档，对于团队配置管理规则而言，产品级文档的处理是焦点，因为这是长期的文档。

团队的配置管理规则的好处

往大里说，团队配置管理规则处理的是产品信息资产，当然是值得精心制定并切实执行的。

往小里说，良好统一的协同工作平台能提升团队协作效率，让每个工程师顺畅的工作。