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

这是研发范围和时间“信息透明化”系列的第三篇文章，在《研发范围和时间的“信息透明化”之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等project实践进行信息同步

2.      工作模式

项目线-研发线的协作从确定项目某个详细目标版本号開始，到该目标版本号验证完毕作为结束。即环绕项目的目标版本号的生命周期展开工作。结合OneNote和Redmine两大工具平台，项目线-研发线工作开展模式的流程图例如以下，通过这一工作模式首先确保项目线和研发线上的信息透明，当中背景为红色的流程须要通过会议进行协商和交互：

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)

PM依据目标版本号的验证结果在OneNote上设置目标版本号的完毕状态

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

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

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

一个正常流程下的Feature具有四大基本状态，包括各个状态转变过程的Feature完整生命周期例如以下：

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

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

结合Redmine上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还须要进一步的解决和測试。

至此一个完整的多平台研发流程闭环结束。也意味着下一个闭环流程開始启动。

四、小结

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

多项目、多平台下的研发信息管理难度非常大，本文提供的思路和工作模式非常大程度上须要团队具有较强的运行力，并且各个团队的项目、工具等详细情况可能有非常大差别。能够依据本文中的一些讨论进行过程的裁剪。