整理下开发周期的计划心得：
一. 需求合并提测，主--子两个发布计划的策略
背景：
开发任务多而杂，部分紧急需求，外部依赖多不确定因素多。
开发团队代码质量欠缺，技术债务多，代码改动和其他合并需求等操作引起问题概率大
应对：
开发质量尽量保证，还有问题的情况下，给测试营造更容易测试的氛围.
需求按照合并版本提测 ：提测后减少代码的合并等操作，测试过的代码除了改bug不会有大的改动，引发未知新问题概率低。测试可以除了提测内容有时间覆盖所有主流程防止被改出老问题，发布后不会有重大生产问题
分主子两个发布计划： 小任务，紧急任务和上个版本遗留已经测试充分的 可以放到子发布提前计划，子发布计划代码check严格一些，测试时间相对少，改动尽量保证质量，review更仔细。
主任务：有时间做大开发任务，时间长，测试时间也更充分。
分两次发布避免风险全部放到最后延期后果严重，子任务把最急的发布掉，后面延期影响也小。
环境分配：
每个任务冒烟开始占用测试-pre环境（测试pre外部依赖只有一套环境），子任务优先级高。
二 单个需求走流程，最后合并代码发布策略
每个需求走 开发-》冒烟-》测试-》（合并代码）验收发布流程
每个需求具备发布条件 搭乘最近的发布计划，合入代码发布。
两种方式对比：
方式一特点： 通过版本封闭需求的方式减少代码合并引起bug，通过测试覆盖主流程兼容了开发质量偶尔不足的确定，兼容性强。 缺点是 需求响应相对慢，但是有子任务可以响应一定的紧急需求。
方式二特点： 需求响应快，需求单独走完流程就可以就近发布，测试任务不重复和浪费。 缺点是代码合并频繁浪费时间，且容易合并代码出问题，也可能A，B需求单独没问题，合入一起有问题。 测试没有覆盖主流程，pre环境容易测试出问题（pre不充分容易生产出问题）
三 超长期开发计划
大型开发任务，难度较大，开发周期长。
开发 -》 验证-》测试-》-》调整-》开发-》验证-》。。。。。-》正式测试-》试用发布。
期间会拆分一些内容测试和验证，验证效果，可以调整方向也可以分散风险。