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