需求的拆分成基本的功能闭环进行迭代(以不引入或少引入测试的重复回归为标准),或许能比较有效的降低需求价值量的平均交付时长。 自测充分、减少bug数量,最终减少联调、测试回归的次数和时长,在一定的单测覆盖率要求以前,是收益大于成本的。 代码合并有时候冲突解决很麻烦,会导致一次部署的时间很长,且代码合并引入了更多次的测试回归工作(这可能是某些BU往主干开发分支发布走的原因之一)。所以基于业务的理解,进行应用的拆分,减少单个应用的并发数量,也可以提升研发效能。 在缺乏有效的项目管理的情况下,资源的相互等待可能是项目延期的一大因素,有时候某端开发完了,另一端资源没到位,一直不能联调提测。项目管理的同学对于资源目前的分工和瓶颈应该给上游及时的反馈。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。