本文章学习自:https://www.bilibili.com/video/BV1cf4y1x7HA
企业真实的研发流程,这个是半路转行的准程序员和在校大学生都比较关心的问题以及小型公司的程序员也会好奇大厂的流程是怎么样的。
如今互联网大厂的开发流程,这些流程虽然好,但也不是一蹴而就的,每个公司的体量不一样流程也不一样。
从最简单的流程来看一看这些环节是如何一步一步演进过来的:
许多客户只有一个简单的需求场景:比如:用户输入一些数据 根据公式给出分析建议 开发人员直接根据描述完成功能即可;
这套流程弊端很明显:那就是需求不明确,容易陷入到无限的扯皮中;
明确需求是软件开发的大树之根,这点没有做好,后面所作的一切都没有意义的。
初创的外包公司和个人接私活常实行这套流程,最后确认好的需求会写在合同中,一切按照合同中的需求项进行开发。
需求变更是开发人员最痛苦的事情,所以该环节会随着流程的完善而不断升级。
弊端:客户的需求一般是只有文字描述,在这种情况下,开发人员只是凭借自己想象进行编码,对需求的理解很容易产生偏差。
原型图设计:原型图就是产品的预览模型,用于展示产品的最终效果,可以有效的帮助开发人员理解需求。
小型的外包公司和个人接私活常实行这套流程,外包公司往往有一个设计师进行原型图设计。个人接私活,很多客户也会拿出原型图,然后让开发人员进行实现。
弊端:代码编写完毕后就直接将项目交付了,项目的各个BUG都是在客户使用中发现的,这时候需要开发人员进行多次修改才能将项目完整交付,和客户的沟通成本是非常高的,这种形式的交付往往非常耽误时间。
开发人员实现功能后交由专门的测试人员进行系统测试,测试完毕后由产品进行验收,验收无误才能进行交付上线
这套流程麻雀虽小,五脏俱全,每项流程都有专门的人员负责:
各个人员各司其职,当前环节没有问题后才会推进到下一环节,这时候流程的流转和推进要进行工程化管理
弊端:很多环节在没有准备充足的情况下就开始实施了,质量得不到有效的保障,不如:确定需求和原型就进行编码开发,如果在编码过程中发现技术方案不合理,此时变更会浪费大量的时间
接下来的流程演进基本就是各个中大厂的流程了,每个环节各个公司的取舍不太一样
产品需求评审:需求提出后,产品会拉上各个岗位的人进行产品需求评审,产品经理会将需求项写好,并且整理出低保真原型图、产品流程等,让大家能够对产品和需求有个概念,PRD在原型图上进行标注说明,大家根据原型图进行评审,争取弄清楚产品和需求的每个细节,并且提出自己的想法,各抒己见。
意见统一后,产品经理确定版本,然后各个岗位进行自己职责内的设计了。
概要设计完成后,就要对细节方面进行完善了,这个细节就是指功能的实现思路,比如一个简单的登录功能,编码时就是看着图开发了,这一块设计得越详细编码时就越轻松,同时测试人员也要对测试进行设计和思考,不然会遗漏功能点。
测试要进行测试用例的设计,测试用例可以帮助测试人员理清需求,为后续的测试提供可参考的依据,在测试过程中也可以反应测试的进度。
测试用例:是指需要测试的功能点
设计师也要进行交互设计和视觉设计,这个环节做出来的高保真原型图,基本就是产品的最终样貌。
当开发人员、测试人员、设计师把自己的内容设计完毕后又会凑到一块进行评审,看看互相对功能理解是否一致,产品经理也会看一下大家对需求的理解程度,避免理解产生偏差,这个环节就是对细节进行完善,改动一般不会太大,该环节完成后就是开发人员进行功能的实现,前后端也会进行联调,联调完毕后开发人员会自行测试一番,再交由测试人员进行测试。
弊端:再开发环节前做了充足的准备,但没有在开发环节后做充分的测试验收,产品上线后质量得不到保障。
在开发完成后,大厂一般会做代码review,组长和组员会对你的代码进行审查,在业务和技术都会获
得很多建议和意见,对开发人员成长最大的环节 。
开发人员提交测试申请,将代码交给测试人员发布到测试环境进行测试,因为测试的周期比较长,测
试环境没有问题后就可以将代码分支合并然后由测试人员发布到预发/沙箱环境。
沙箱环境:将系统接入真实的数据,但是系统只能内部访问,用户无法直接访问的,这个环节就是为
了保证上线前不出问题,所以模拟线上真实环境,看看系统能不能真的抗住真实数据,这一轮测试完成
后又可以将代码分支合并一次然后让产品经理验收。
从需求提出到需求结束还是很不容易的,中途历经多个环节要和多个部门岗位协调各种问题和难点都要面对,每个公司会根据自己的文化和人员配置业务方向以及需求大小做出调整,比如一些小的需求小的改动概要设计和详细设计就不会做了。
流程的最终目的是为了节省时间成本和人力成本,并且提高产品的质量,符合公司实际情况的才是好流程,小公司盲目采用大公司的流程反而会增加沟通成本,大公司明明流程老旧也不进行改进和变动,技术负债就会越来越多。