基于CC/CQ实施的基本思路

一个客户几年前买了CC/CQ, 并参加了几天培训. 交流时问起部署CC/CQ的一些基本思路. 我发现很多CC/CQ的用户经常会忽略一些基本的研发管理思想, 而局限于工具成面, 在使用模式上也比较教条. 下面是和客户交流的要点:

 

1. 版本数据存储怎么规划?

 

ClearCase通过PVOB来实现一组VOB的关联. 很多公司一个研发产品一个PVOB, 或者一个研发组织一个PVOB. 其实只有与同一PVOB关联的VOB才能相互引用的, 因此, 如果一个产品对应一个PVOB, 那么跨产品之间的引用和关联就很难实现.

 

其实一个公司的软件产品从规划上可分为多个产品线, 一个产品线可包含多个组件, 而通过组合这些不同的组件的不同版本形成不同的产品版本. 而VOB只是组件的存储容器, 一个VOB包含一个或多个组件更多的是从性能, 安全性以及可管理性等角度来考虑.

 

根据上述思路, 假设一个公司具有JAVA和.NET两个产品系列,  则可建立两个PVOB, 分别为PVOB_JAVA和PVOB_NET, 让后在规划component, 很多企业component的概念很弱, 其实部署CC时多考虑这个问题, 为以后提高软件的可重用性打下了基础.

 

那产品这个概念和 CLEARCASE中的什么对象对应呢? 其实就是UCM Project. 下面详细介绍.

 

2. 如何组织产品开发?

 

如果版本数据存储规划考虑的事软件产品的静态特性, 那如何组织产品开发是考虑软件产品的动态特性.  每个产品的开发都有其开发规划, 比如ClearCase当前是7.0.0.0版本, 产品管理团队会明确什么时候发布7.0.1.0, 什么时候发布7.1.0.0以及什么时候发布7.0.1.1. 每一个在规划中的发布版本就是一个UCM Project.  如果你发现UCM Porject太多, 可以利用Folder来组织.

 

3. 关于流的策略?

 

考虑到开发过程扩展性, 建议还是采取多流比较好. 也就是有一个集成流,并可创建一个或多个开发流程. 我的建议上开发流不宜太多,  除非有足够的理由, 项目团队就在单流上开发, 大家用快照试图就可实现隔离了.

 

4. 在提交前一定要合并别人的开发成果.

 

在提交前, 把别人的开发成果获取, 并在自己的视图中进行冲突检测是比较好的习惯. 如果你是用快照视图, 在checkin前最好执行update, 如何你需要做deliver, 最好先执行rebase.

 

5. 一定要让管理人员使用ClearQuest.

 

很多CQ的用户定义了比较好的变更或缺陷管理流程, 但总觉得执行效果不好, 大家爱用不用, 领导也看不到CQ的价值. 其原因是忽视为领导定义一些统计报告, 并帮助领导理解这些统计报告所体现的含义. 比如, 为领导定义一张按责任人统计的报告, 并告诉领导, 通过这张报告你可以知道谁现在承担的工作比较多, 谁比较少. 由于领导基于这些报告来进行决策或绩效评估, 下面干活的人就很自觉地更新相关信息了.