- 双流联动
将特性分支与用户故事Story一一绑定之后，就可以实现 需求与代码的关联关系了。接下来就可以实现所谓的双流联动了，也就是代表了需求生命周期的管理流与代码的工程流
这两个流之间进行联动。
需求 | 提出 | 排期 | 开发 | 测试 | 发布 | 上线 |
|---|---|---|---|---|---|---|
分支 | 拉特性分支 | 提交代码 | 分支冻结 | 分支删除 |
上表中，需求有提出、排期、开发、测试、发布、上线等几个状态，是一个比较简单的管理流程。
而从代码分支的角度来看，有分支拉取、代码提交、分支冻结和删除等操作。如果说团队在完成需求的排期操作时，可以借助于DevOps平台自动拉取一个特性分支并将两者绑定，进而实现所谓的双流联动。例如，当这个特性分支上有代码提交时，则可以自动触发将对应的需求从已排期的状态转变到开发中的状态。读者可以结合团队的分支模型和需求状态流转的约定，寻找合适的自动化时机点。
- 精准效能分析
需求与特性分支绑定带来的好处还不止这些。也可以通过这部分的工作实现对开发人员行为的细致分析，进而实现对团队工程效能的更自动化、更真实的分析。
例如，以下是一些从特性分支上的代码提交分析中可以得到的：
1开发周期：
特性分支上第一个commit到最近一个commit的时间间隔。这代表了真实的这个需求的开发周期。当然，这里有一个纪律约束是，如果这个需求在后续的测试中发现有bug,那么开发人员修bug的代码也应在这个特性分支上提交。
当然，如果要计算需求的前置时间等数据，也可以参考需求各状态流转的耗时。通过双流联动之后，可以认为需求管理流的状态流转相对之前人工拖动要及时和准确地多了。
2（流效率）有效开发时间占比：
有commit的工作日/开发周期。 如果测试反馈比较慢的话，那么在开发的commit和bug修复的commit的日期中间，会有一段时间的空档期。如果需求不是一把开发完，而是有等待、闲置等等，也会从这个指标中反应出来。
也就是这个指标可以看出以下的问题:
a)这个story的开发过程是否顺畅，中间有没有停顿
b)测试是否左移，质量反馈是不是够快。
3 Story的代码规模：这个特性分支上的增量代码量
4 Story的参与人数：committer 人数
5 Story的代码覆盖率：这个特性分支增量代码的覆盖率
