2.2.1.2 多开发流模式

    项目中有多个不同的开发流，每个开发流都是一个独立的分支，如果项目需要还可以建立多层次的分支，支持并行开发，适于超过10人，较复杂的项目。如果项目极复杂，可以分为多层开发流与集成流，如图二。优点：可以并行开发，每个Stream都相当于一个独立的开发环境，每个人之间的工作不会互相产生干扰；可以通过Policy的设置更好的进行配置管理。

    缺点：不同的Stream之间的Deliver与Rebase会产生问题；在merge时也有可能会产生问题，而且对Word等二进制文件的merge支持不好；在修改完成之后，每个Stream上的修改只有deliver与Rebase才能被其他的stream应用，不能及时反映变化；Policy的设置较复杂。

    在多开发流模式下可以根据需要将某个stream设置为只读模式。

    建议：可以根据需要建立一个多开发流模式的Project，但是在初期阶段不设立开发流，在进行详细设计阶段后再建立相应的开发流。

 

    2.2.1.3 Project组模式

    Project组模式是以上两种模式的组合，适用于产品类项目，在这种类型中，设立一个主干Project，针对不同的客户或不同的变更，在相应的baseline上建立新的共享流Project去处理，而不是在多开发流中的Project新建一个开发流。如果其中某个客户的要求或变更比较复杂，也可以建一个多开发流的Project进行处理。

    优点：可以根据任务的实际情况灵活处理变更等，而且如果发现对所有用户都需要的变更可以在主干上修改并发布到各个子Project上，也可以在一个子Proejct上修改，经验证后再发布到其他子Project，对于有长远规划的产品非常适合。

    缺点：如果在最初架构师考虑不周，Component划分不合理在后期会比较困难；不同Project之间的Deliver需要更复杂的Policy，需要配置管理工程师极有经验。 

 

    2.2.2 Activity的命名准则

    建议对不同类型的工作可以通过Activity的命名直接区分，建议如下：

    新加功能为：Feature_功能名

    变更的执行：CR_变更号

    注：如果变更中涉及到文档的修改，则文档修改也应用此Activity

    修改Bug：Bugfix_BUG号

    注：BUG号来自ClearQuest

    文档：Doc_文档名

    注：在变更及Bugfix中文档的修改activity应用变更的activity

    计划的更新：Plan_Tracking_时间

    另一建议为选用ClearQuest为缺陷管理工具，并将ClearCase与ClearQuest集成，这样所有的Activity可以通过ClearQuest获得。

    2.2.3 Deliver与Rebase的准则

    项目中需要明确Deliver与准则，包括什么情况下可以Deliver，Deliver前是否全部文件都Check in，是否可以向非本项目的Stream进行Deliver等，这些需要根据实际情况确定，但是为了尽量避免冲突，建议在Deliver前要求进行Rebase。