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

更多深度文章，请关注云计算频道：https://yq.aliyun.com/cloud

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研发效能平台和对外云效平台的产品负责人，阿里巴巴速卖通业务的技术质量负责人，技术质量架构师。精通研发质量效能平台产品，在敏捷研发、持续交付、研发团队管理等方面有丰富的经验。