开发周期计划心得

整理下开发周期的计划心得:

一. 需求合并提测,主--子两个发布计划的策略

背景:

开发任务多而杂,部分紧急需求,外部依赖多不确定因素多。

开发团队代码质量欠缺,技术债务多,代码改动和其他合并需求等操作引起问题概率大

应对:

开发质量尽量保证,还有问题的情况下,给测试营造更容易测试的氛围.

需求按照合并版本提测 :提测后减少代码的合并等操作,测试过的代码除了改bug不会有大的改动,引发未知新问题概率低。测试可以除了提测内容有时间覆盖所有主流程防止被改出老问题,发布后不会有重大生产问题

分主子两个发布计划: 小任务,紧急任务和上个版本遗留已经测试充分的 可以放到子发布提前计划,子发布计划代码check严格一些,测试时间相对少,改动尽量保证质量,review更仔细。

主任务:有时间做大开发任务,时间长,测试时间也更充分。

分两次发布避免风险全部放到最后延期后果严重,子任务把最急的发布掉,后面延期影响也小。

环境分配:

每个任务冒烟开始占用测试-pre环境(测试pre外部依赖只有一套环境),子任务优先级高。

二 单个需求走流程,最后合并代码发布策略

每个需求走 开发-》冒烟-》测试-》(合并代码)验收发布流程
每个需求具备发布条件  搭乘最近的发布计划,合入代码发布。

两种方式对比:

方式一特点:   通过版本封闭需求的方式减少代码合并引起bug,通过测试覆盖主流程兼容了开发质量偶尔不足的确定,兼容性强。   缺点是 需求响应相对慢,但是有子任务可以响应一定的紧急需求。

方式二特点:  需求响应快,需求单独走完流程就可以就近发布,测试任务不重复和浪费。   缺点是代码合并频繁浪费时间,且容易合并代码出问题,也可能A,B需求单独没问题,合入一起有问题。 测试没有覆盖主流程,pre环境容易测试出问题(pre不充分容易生产出问题)

三 超长期开发计划
大型开发任务,难度较大,开发周期长。

开发  -》 验证-》测试-》-》调整-》开发-》验证-》。。。。。-》正式测试-》试用发布。

期间会拆分一些内容测试和验证,验证效果,可以调整方向也可以分散风险。

原文地址:https://www.cnblogs.com/thinkqin/p/13978590.html