这是研发范围和时间“信息透明化”系列的第三篇文章，在《研发范围和时间的“信息透明化”之Redmine统一平台》中我们讨论了信息透明化的一种实现平台Redmine，在《研发范围和时间的“信息透明化”之协作与流程》中我们对如何基于一个产品/项目和一套信息管理平台进行信息透明化管理的协作与流程做了详细阐述。对研发信息透明化而言，现实中情况可能会比较复杂：

• 由于历史遗留问题等因素，团队中可能会使用一种以上的平台进行研发信息和过程管理。不管使用何种以及多少平台，通过确定各个平台之间的信息传递接口，仍然需要确保研发过程信息的闭环。
• 对于多项目并行开发的研发团队而言，由于涉及到项目之间、团队成员之间的快速协调和合作，要做到完全的信息透明化难度很大，但通过合理的梳理信息结构、同步时机等手段，我们仍然希望能在多个项目之间尽量保持信息的透明性。

本文主要针对以上两种情况对现有协作与流程模型进行扩展，还是使用Redmine作为主要实现工具，但基本的思路和模式同样适用于其他各种平台。

一、基本概念和规则

1.      角色定义

多项目多平台下协作流程涉及的角色没有变化，主要包括：

• PM：项目经理，通过产品规划、方案设计和功能分解等管理客户期望
• DEV：研发人员，项目线具体需求的研发
• QA：测试人员，负责项目线需求的质量控制、服务发布

2.      工具平台

在工具平台上，我们可以使用多个具体的信息化工具来实现团队协作。本文中我们假定使用Redmine和Quality Center作为我们主要的研发过程管理工具：

• Redmine：范围/时间控制和项目、研发团队协作统一平台
• Quality Center：缺陷跟踪统一平台

其中Redmine关注与研发范围的透明，而Quality Center关注与系统缺陷的透明。相较于在《研发范围和时间的“信息透明化”之协作与流程》单独使用Redmine进行研发范围和系统缺陷的透明，这两者通过互相配合构成了研发过程的闭环。使用两种不同平台可能是因为历史原因、对工具专业性的要求，或者是团队组织结构上研发部门、质量保证部门等职能部门内部的考虑，而具体工具可能也不限于Redmine、Quality Center或者其他类如Jira等各种信息平台。

另外，作为整个流程的闭环管理，以下工具通常作为辅助：

• 邮件：过程数据记录、流程阶段性成果和最终闭环达成的消息传递机制。
• Jenkins：系统构建、版本控制和服务发布统一平台
• OneNote：项目日历，用于形成多项目下项目线-研发线对项目的版本和发布时间的统一认识

3.      目标版本

在多项目环境下，目标版本面向客户和用户，作为服务交付的阶段性成果和依据推动项目实施，并在院方现场、项目线、产品线、运营线和研发测试线之间达成统一认识。目标版本由项目生命周期下的版本号和发布机制下的版本类别组合以形成唯一的对内/对外版本信息。

1）项目生命周期下的版本号

项目生命周期下版本号的统一格式为X.X.X，其中第一位表示系统主版本号（区分是否正式上线、项目阶段等），第二位表示系统有重大功能调整，第三位表示系统有微小改动和优化。

按项目生命周期，具体可分为两种类型：

• 系统完整上线前的版本：统一以0.X.X命名，表示该版本尚未正式完整上线
• 系统完整上线后的版本：统一以1.0.0开始命名，表示该版本已正式完整上线，后续根据项目推进的阶段和需求进行版本递增

2）发布机制下的版本类别

按发布机制，目标版本可以分为三种类型：

• 预览版：预览版主要面向客户演示，不需要通过内部测试流程即可发布，由项目经理负责质量把控
• 提测版：提测版面向内部测试流程，作为研发过程的阶段性成果，由研发人员提交给测试人员
• 发布版：发布版面向终端用户，作为项目线-研发线协作的交付物，有测试人员交付给运营团队进行服务上线发布

二、研发线-项目线工作模式

多项目环境下涉及的研发线和项目线是一对多的关系，即一个研发团队要面临的是多个项目的并行研发工作。从两条线的协作关系而言，我们要找到一个共同视图确保大家对项目的计划和工作达成统一。我们可以采用一下策略：

1.      工具使用

1）OneNote

OneNote作为项目线和研发线在时间上的统一视图，采用以下策略进行应用：

• 版本管理策略：内容上统一使用目标版本进行命名和管理
• 更新策略：项目经理根据项目进展和研发的反馈定期/不定期进行更新和梳理，确保给研发线及时提供项目日历视图
• 同步策略：每周一项目线和研发线进行信息同步

2）Redmine

Redmine作为研发线的主视图，采用以下策略进行应用：

• 版本管理策略：配合OneNote上项目线的具体目标版本，使用“目标版本”功能进行研发版本管理，确保项目线和研发线对各项目目标版本的统一认识。
• 更新策略：研发人员根据研发情况实时进行更新，确保给项目线提供实时研发视图
• 同步策略：通过每天Stand-upMeeting等工程实践进行信息同步

2.      工作模式

1）   根据项目情况确定目标版本(PM)

PM根据项目的具体实施情况确定下一次该项目需要发布的目标版本和范围，并把目标版本和期望完成时间录入OneNote项目日历。

2）   OneNote上协商确定目标版本(PM+DEV)

通过OneNote，PM和DEV协商确定目标版本的完成时间，在完成的范围和时间上达成平衡和一致。

3）   针对目标版本召开需求评审会议(PM+DEV+QA)

根据目标版本下的需求范围召开需求评审会议

4）   Redmine上创建系统版本号并录入Feature(PM)

根据需求评审会议结果，PM在Redmine上录入系统版本号(格式为VX.X.X)，并创建相应的Feature

5）   Redmine上创建Task并完成开发(DEV)

DEV把Redmine上Feature拆分成Task并完成开发工作

6）   验证目标版本完成情况(PM/PM+QA)

对于预览版，PM验证目标版本的完成情况；对于提测版，QA根据既定的内部测试标准流程主导目标版本的测试工作，PM进行配合

7）   OneNote上更新目标版本完成状态(PM)

三、多平台下研发流程闭环管理

上一小节对多项目环境下如何在项目线和研发线之间达成以目标版本为基本粒度的信息透明，本小节针对某个项目中的某一个目标版本的开发过程进行说明，探讨多个平台下的研发信息传递机制及其透明性的具体展现方式。

作为产品交付的依据以及测试流程的源头和目标，多平台下研发流程闭环管理关注Redmine上的Feature，即围绕Feature的生命周期展开工作，以PM创建Feature作为起点，以Feature的关闭作为闭环流程的终点。Quality Center中或其他工具平台下各个缺陷的管理作为测试过程中的中间产物不是闭环流程的目的，但也在其中的一个重要环节，需要站在整个工作流程的角度进行管理。。

上图中各个状态的转换责任人如下：

• 新建：由PM‘新建’Feature
• 已解决：当该Feature对应的Task均已完成，由Submitter负责设置状态为‘已解决’。这里的Submitter是研发人员中提交测试责任人，负责整理提交测试范围。
• 测试中：当QA收到Submitter的提前请求，设置Feature状态为‘测试中’
• 已关闭：当QA确认该Feature下对应的QualityCenter上的缺陷均已解决，设置Feature状态为‘已关闭’

1）  新增Feature到Redmine(PM)

PM根据项目需求将功能分解成Feature并录入到Redmine上

2）  Fearure开发(DEV)

DEV将Feature分解成Task并完成Feature下相关Task的开发工作

3）  更新Feature完成状态(Submitter)

当Feature下相关Task都已完成并需要提交测试前，Submitter负责将Feature状态设置成‘已解决’，表示Feature(s)已可提交测试

4）  提交测试请求(Submitter)

Submitter负责整理本次测试的Feature范围并通过一定的媒介告知QA，并提供Jenkins上服务包的下载地址以及本次提测可能包含的注意点。

5）  更新Feature测试状态(QA)

QA收到Submitter的提测请求后更新Redmine上对应点Feature的状态为‘测试中’。

6）  Feature测试并在Quality Center上记录缺陷(QA)

QA进行测试，测试过程中的缺陷通过QualityCenter进行管理。

7）  发送测试结果邮件(QA)

QA完成测试并发送Feature级别的测试结果邮件，如果某个Feature已经通过测试，则在Redmine上关闭改Feature；如果未通过测试，则保持Feature状态为‘测试中’，表示该Feature还需要进一步的解决和测试。

四、小结

对多项目、多平台下研发信息的透明性，本文从两个角度进行了梳理和抽象：首先项目线-研发线协作流程为不同工作线上的团队提供统一的项目研发视图和工作模式，围绕完成目标版本这一项目实施目的展开具体工作，确保信息的透明性和有效传递，避免因项目线和研发线信息不同步造成的项目延期和资源浪费。其次，确立明确的信息闭环管理思想，通过多种工作平台下信息传递和交互使相关干系人明确测试范围、时间节点和结果；明确相关干系人职责和分工，每一步均能定位到责任人，并保证过程的可跟踪和可追溯性，为回顾提供数据依据。

多项目、多平台下的研发信息管理难度很大，本文提供的思路和工作模式很大程度上需要团队具有较强的执行力，而且各个团队的项目、工具等具体情况可能有很大区别，可以根据本文中的一些讨论进行过程的裁剪。

研发范围和时间的“信息透明化”之多项目多平台下的协作与流程