内部分享:阿里巴巴B2B高效研发管理实践

2017年1月13日举办的【云栖计算之旅】线下沙龙第4期研发管理专场,阿里巴巴技术质量架构师范之岳带来了题为阿里巴巴B2B高效研发管理实践的演讲。本文主要从互联网无线研发的问题与挑战开始讲起,重点讲解了阿里工程效能技术平台,包括云效平台等,最后对阿里一线PL的职责进行了思考。一块儿来了解下吧。
安全

如下是精彩内容整理:网络

互联网无线研发的问题与挑战架构

B2B技术部这几年来面对了不少的问题与挑战,具体以下:并发

对于不一样管理者来讲,他们的诉求是有区别的。对于创业团队来讲,一开始只有三到五我的,须全民皆研发、全民皆测试、全民皆运维,你们一块儿考虑怎么将业务发上线,而且拉来更多的用户,考虑不到工程效能、效率的体现和度量等问题。但当业务增加上去以后,团队就会扩大,团队层次区分出来,业务迭代快速,项目并行量大,业务很难快速交付到用户手中;并且,研发团队变大,项目资源管理成本就会提高、透明度低;用户体验要求高,测试成本增加迅速,人肉测试多,应用增加迅速,环境构建复杂,验证难度增长;不少创业公司都用无线,包括大型公司,阿里全部的海外B2B、外贸B2B都有对应的APP,就会带来手机预算大、手机设备杂、手机测试难等问题;对于大型组织来讲,咱们要和业务方以及不一样研发团队打交道,研发过程当中各角色协做成本高;还有金融、保险等传统产业的互联网研发思惟的转变。框架

对于老板来讲,业务老板尤为关心研发团队在干什么,业务何时发布,技术老板关心团队的效率如何,怎么砍业务需求,人手够不够,产品质量如何等。对于开发、测试、运维工程师们来讲,他们但愿想怎么发就怎么发,随时随地发布需求,高效高质的发布,不要倒排。运维

老板但愿更多集中式的资源与需求管理,研发者们但愿有敏捷化的工程实践支撑,包含研发过程到最终上线的过程。微服务

那么,敏捷框架是否是解决这些问题最终的方案呢?性能


事实上不是,当敏捷思想在中国普遍传播时,更多的是一种理念。全部开发者、业务方、需求方对于敏捷的理解要求是很是高的,有时候落实下去形式上很敏捷,但交付速度并无变快,敏捷还提倡轻文档轻流程,致使有些公司搞了很久敏捷什么文档没有留下来,敏捷只是一种思想,解决不了实质性工程效能问题。单元测试

若是你的组织作了敏捷转型,一个Scrum团队将业务人员、开发人员、测试人员以及运维人员都归入一个团队,就能够解决互相推卸责任的问题,但两个Scrum团队间没办法解开耦合,会出现协做上的问题,敏捷解决不了这样的问题。测试

技术债与服务化

对于工程效能的实现,须要有平台来支撑持续集成、快速发布、持续交付等,这种须要工程效能平台的前提是咱们的系统自己,若是是几百万行代码、几十个交付模块的大应用,就算有再好的持续交付通道平台也无济于事,由于小业务改动须要大应用发布,项目无法并行起来,没法轻快!


近几年,阿里在作服务化的改造以及微服务的实践,微服务改造应用的拆解、去耦合是全部持续交付目标的前提。

工程效能技术中台


技术中台支撑整个研发管理、研发行为、持续交付通道。技术中台分为两部分,综合管理有对应的产品支撑,它对应到老板们想要的东西;研发工程效能对应到一线研发工程师的诉求,它自己也进行了分层,上层就是直接的应用,好比分层自动化、无线适配、远程真机以及性能测试等,下面的服务层咱们有持续集成服务、自动化服务、测试数据服务、测试环境服务,对于B2B技术部如今使用的平台,只要拉出代码一键便可部署完项目须要的整个环境。

技术中台管理闭环


咱们但愿建设从需求规划——立项——部署环境、持续集成——最终的验证测试——再集成——进入准生产环境——全自动化验证——最后发布是上线,上线后要作业务的数据盘点,整个过程是闭环,咱们但愿每一个节点都有对应的产品支撑,通过三四年的建设,大部分的节点咱们已经都有产品作支撑,高效优质且透明,无线工程目前也在起步阶段。

云效平台


上图为云效平台持续交付通道图,对于项目上的各类并发的小需求,咱们会有前台分圈的概念,把一些有相关业务耦合的应用模块放在同一个分圈里面,不一样分圈的业务模块能够作独立的发布。为何要作分圈呢,就是有时候咱们作自动化验证时,须要把关联度放在一块儿来验证,因此A、B、C、D就会有独立分圈的发布通道,不一样的分圈作完自动化验证后,就会直接进入到自动化生产环境中去,达到持续发布效果,它是有必定条件限制的彻底自由的独立发布,这个限制主要仍是出于质量保障,质量保障基本基于全自动化验证。

差别化的研发流程策略

阿里B2B技术部很是强调差别化的研发流程策略,咱们把重点的大型项目和小型需求是分的很开的,目前,咱们测试与开发的配比基本达到1比10,因此咱们确定作不到全部的变动、全部的项目都有测试同窗直接来接手,但不表明没有那样的测试行为。

大型项目:对于重点大型项目,咱们有测试人员直接进入,走分迭代的瀑布式项目流程,Milestone的保障,每一个节点都有要求输出,好比文档评审等;

小型需求、bugfix: 小型需求的改动量不大,若是开发有足够的分析结果证实需求不须要测试人员参与,但并不意味着不须要测试,项目里的持续集成是一键触发测试过程,而后在发布以前和别的需求合完代码后,还有一道全自动化流程保障,能够跑单元测试、接口测试、UI测试、安全测试等,只有在失败的时候测试人员才会介入查看问题;

核心应用:对于业务来讲,不一样的应用承担不一样的业务,经过流程限制的发布窗口,分层自动化的要求很是高,咱们要将核心应用和非核心应用区分开;

核心服务:经过流程限制的发布窗口,让核心服务关联的自动化范围。

阿里一线P Leader的职责与思考

阿里对于一线的研发管理者都是专业技术出身,业务、管理、技术三块缺一不可,阿里是一个业务导向的公司,只有依靠中台,才能快速的支持上层的改变,若是业务想要什么,你作什么出来,你会发现研发成本很是高。只有把业务和技术结合在一块儿思考,才能作到最好,阿里不少架构师、P Leader都要进行这样的思考,P Leader更多的是要与业务挂钩,团队的考核、团队的方向、团队的目标和建设都是由P Leader来作的。

范之岳:2011年加入阿里巴巴。担任阿里巴巴B2B研发效能平台和对外云效平台的产品负责人,阿里巴巴速卖通业务的技术质量负责人,技术质量架构师。精通研发质量效能平台产品,在敏捷研发、持续交付、研发团队管理等方面有丰富的经验。

更多相关内容:

互联网产品一站式研发协同的快速开始

【推荐】如何使用好阿里云的网络安全隔离?深刻分享阿里云ECS安全组实践经验

相关文章
相关标签/搜索