1. 前言
项目当前版本（假设为1.0）开发完成之后，会提交给测试组进行测试，然后，开始进行下一个版本（假设为2.0）的研发工作。
但是，测试组测试周期可能要一两个月，期间会不断的反馈 Bug 到系统里，等项目当前版本（1.0） Bug 修复完成之后，再进行下一轮的测试。
这时，项目新的版本（2.0）功能开发进行中，每个人都已经有自己的开发任务了，时间也排好了，应该怎么安排？
还有，在 A 功能模块上修复 Bug，而同时又在 A 功能模块上开发新的功能，代码合并可能会冲突等等问题怎么处理？
2. 权衡任务调整的利弊
因为测试反馈 Bug 数量不是一个可控的事情，有时第一轮测试完成，都没几个 Bug，有时第一轮测试就反馈好几十个 Bug，完全可以衍生新的任务，评估个两三天去处理。
所以，如果你打算，暂停或推迟当前版本（2.0）的开发任务，而去执行修复上个版本（1.0）的 Bug 的任务，很有可能收益不大，因为可能都没有几个 Bug 让你修复。
但是，如果你完全对第一轮反馈的 Bug 不管不顾，又会影响到测试组的测试进度。
3. 基于测试周期的任务调整
上面说的，虽然测试反馈 Bug 的个数是不可控的，但庆幸的是，测试周期是明确的，比如第一轮具体是什么时间段，第二轮又是什么时间段，这些都是前期沟通好的，虽然偶有变数，但是大体上问题不大。
在这个基础之下，项目负责人就要根据测试轮次结束的时间，对当前反馈的 Bug 情况，进行任务上面的调整，比如第一轮测试反馈了 50 个 Bug，然后按功能模块划分清楚，以及哪些功能模块对应的负责人是谁，修复这些 Bug 需要多少工作量，新增一条修复 Bug 的任务在项目当前版本（2.0）计划中。
4. 测试环节的漏洞
但是，如果 Bug 特别多，花费了大量的时间，甚至影响到了当前版本（2.0）的开发进度怎么办？
这个时候，是否需要延长修复 Bug 的任务呢？
缩短开发的任务时间呢？
加加班？
这些方式可以解决这个问题，但是，治标不治本。
因为在这个功能到测试组介入参与测试时，其实，已经有过三个环节，对功能进行测试了。
一个是功能开发人员自测，编写测试用例，然后对开发的功能点一一测试。
另一个是功能开发任务验收，这个验收的工作就是根据功能开发人员提供的测试用例，验收人自行跑一下这个测试用例，看下有没有什么问题。
最后一个是项目负责人内测，就是项目当前版本（1.0）结束，要给测试组提测之前，把全部功能都测试一遍。
上面这三个环节，为什么不能发现和解决掉一些很明显的 Bug，而一定要测试组测试时才发现？
5. 优化测试流程
理想状态下，每一轮测试都不应反馈那么多 Bug 的，然后需要排两三天的时间去处理的，通过一两天差不多了，甚至在开发当前功能时抽个一天的时间解决掉就行。
所以，回答项目开发中应什么时候去修复测试反馈的 Bug 这个问题，那就是做好下面的流程：
- 功能开发人员自测
- 功能开发任务验收
- 项目负责人内测
然后，等测试哪一天测试完成之后，评估一下反馈的 Bug 数量，补充一条修复 Bug 任务，同时，变更当前的开发任务时间。
理论上来说，这条修复 Bug 的任务时间也就一天左右，最多也就两天了，除非出现突发的不可控因素。
如果反馈的 Bug 特别多，需要的修复时间也很长，意味着上面三个环节压根没有做到位。
6. 代码合并问题的处理
这个问题，其实可以等版本 1.0 的测试全部通过，发布至线上环境之后，再把 1.0 的代码合并到 2.0 的分支（即当前的 `Dev 分支），解决掉冲突就可以了。
7. 整体流程
