作者:张克强 作者微博: 张克强-敏捷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,项目测试计划
对于两类不同的文档,对于团队配置管理规则而言,产品级文档的处理是焦点,因为这是长期的文档。
团队的配置管理规则的好处
往大里说,团队配置管理规则处理的是产品信息资产,当然是值得精心制定并切实执行的。
往小里说,良好统一的协同工作平台能提升团队协作效率,让每个工程师顺畅的工作。
作者:zhangmike 发表于2014-8-23 18:05:10
原文链接