跨职能流程图（垂直）

测试小组1测试v1.0

v1.0需求评审

多版本并行开发实例

单版本开发实例

v3.0需求评审

研发与测试分三个小组分别评审三个版本需求

测试完成申请发布

单版本需求分析

是否通过

提交测试

测试组2提交bug

需求评审

发布完成进入下一个迭代的开发

是

v3.0版本

测试小组2测试v2.0

研发分成三个小组对三个版本打分支进行开发，代码合并时候存在风险，高版本依赖低版本的基础功能，低版本功能不完善，高版本同时开发工作会受到影响

v1.0版本

否

研发单版本需求

单版本的优点：1.按照版本规划，所有研发测试都为一个版本交付工作，工作关系比较简单，沟通成本比较低不存在多版本代码冲突的情况2.版本质量比较高，风险小，基本能按照计划准点上线单版本的缺点：1.主观感觉同时在处理的是一个版本进度相对较慢多版本并行优先：1.主观感觉同一时间做了很多需求，多版本并行缺点：1.版本之间代码，需求冲突风险很高2.拆分版本要重新测试存在风险，影响整体上线进度3.开发合并代码，引起冲突比较高总结：单版本合理安排需求可以弥补进度上的缺陷，准时上线风险小，版本风险在可控范围内 多版本并行开发，版本间冲突风险大，拆分与合并代码风险不可控，真实并行开发，同等数量的需求，单版本发布上线的速度比并行开发快，质量可控，风险相比小很多

因为提测时所有分支在一个测试环境测试，现在上线，先上线1.0版本，需要把1.0版本代码单独拿出来，这时候拆分完成，测试需要重新对1.0版本进行验证，拆分出现的bug，开发投入更多的时间修改本不应该出现的bug，其他两个版本拆分也是如此

研发小组研发v3.0版本

测试小组3测试v3.0

v2.0版本

研发小组研发v1.0版本

测试分成3个小组分别测试三个版本，如果出现v3.0提测进度比v1.0快，而又依赖1.0版本功能，测试工作无法正常进行，造成资源浪费，正常开发的1.0版本功能在3.0版本已经优化去掉对应模块，造成研发资源浪费

拆分支单个版本上线

每完成一个迭代开发测试线上，再进入下一个版本研发测试，然后上线工作，周而复始

测试组1提交bug

v2.0需求评审

各版本存在互斥的现象，比如版本1.0需求在还没有开发情况就同时在版本3需求变更掉，代码上极易冲突，后面的版本要依赖前面版本功能情况导致版本3无法和版本1同时进行

测试组1提交bug，开发针对v1.0修改，花费时间很多，改动地方很大，然而同时开发v3.0这个模块已经去掉，这个bug不复存在，版本v1.0开发还不得不花费大量的时间修复同时上线不存在的功能

测试组3提交bug

研发小组研发v2.0版本