传统的软件交付过程是指在编程序改代码之后,直到将软件发布给用户使用之前的一系列活动,如提交、集成、构建、部署、测试等。传统软件交付流程通常包括4个步骤:首先,业务人员会诞生一个软件的想法;然后,开发人员将这个想法变为一个产品或者功能;经过测试人员的测试之后提交给用户使用并产生收益;最后,运维人员参与产品或功能的后期运维。传统软件交付流程可能存在的问题包括以下3个方面。
(1)业务人员产生的需求文档沟通效率较低,有时会产生需求文档描述不明确、需求文档变更频繁等问题。
(2)随着开发进度的推进,测试人员的工作量会逐步增加,测试工作的比重会越来越大,而且由于测试方法和测试工具有限,自动化测试程度低,无法很好地把控软件质量。
(3)真实项目中运维的排期经常会被挤占,又因为手工运维烦琐复杂,时间和技术上的双重压迫会导致运维质量难以保证。
因为存在以上问题,所以传统的软件交付经常会出现开发团队花费大量成本开发出的功能或产品并不能满足客户需求的局面。由此可以总结出传统的软件交付存在2个层面的困境。
(1)从表现层来看,传统软件交付存在进度不可控、流程不可控、环境不稳定、协作不顺畅等困境;
(2)表现层的问题其实都是由底层问题引起的,从根源上来说,存在分支冗余导致合并困难,缺陷过多导致阻塞测试,开发环境、测试环境、部署环境不统一导致的未知错误,代码提交版本混乱无法回溯,等待上线周期过长,项目部署操作复杂经常失败,上线之后出现问题需要紧急回滚,架构设计不合理导致发生错误之后无法准确定位等困境。
整理不易动动你发财的小手点个“在看”哦!
您的支持是我坚持的动力,谢谢
领取专属 10元无门槛券
私享最新 技术干货