腾讯敏捷研发体系 --- 薛军

豆沙包

作者简介

薛军
腾讯P4项⽬目通道专家，敏捷教练
腾讯LBS产品中⼼心总监

我今天介绍的是《腾讯敏捷研发体系》，腾讯官方本身没有体系这样一个标准的说明，这个主要是我们过往在腾讯十几年的工作经历进行的一个总结。

到现在为止我在移动互联网从业已经15年了，有同学说10年才是移动互联网的元年，但是实际上我们手机上的业务很早就开始了，坦白来讲今天大家可以从事这行业，都是得益于2001年的时候移动推出的一个LBS业务，我们国家的网易腾讯搜狐新浪等才可以存活下来，因为之前所有的互联网公司都没有挣钱的方法。

所以在中国手机上的业务2001年就开始诞生了，大概分为三个阶段，01~05年是SP的时代，那个时候做手机上的业务，基本处于拯救了中国的互联网的阶级，05~09年那个时候是网站，10年到今天我们叫做移动互联网的时代，这阶段最典型的就是大家主要创业内容是做APP。但是个人的观点，这个时代在2017年已经结束了，18年开始算什么时代到目前还没有一个非常清晰的定论，但是总之给人感觉，APP时代已经过去了，它的研发成本和运营成本比较高，盈利的空间比较小。

这是我们的三个阶段，我们不同的经历实际上是互相影响的，这是不变的，变的是在企业的高速发展中我们做了产品管理和项目管理以及研发管理!

今天腾讯的研发体系是一个广义的，我大概从八个方面做一个介绍：

• 开放的环境
• 闭环的业务
• 完备的团队
• 灵活的模式
• 进化的工具
• 精益需求管理
• 有损质量管理
• 极速发布管理

开放的环境

这是我们的工作环境。

我们最右边有一个滑梯，一个是微信办公室设置的，出现之后国内纷纷效仿，我后来从滴滴和一些互联网金融公司了解到他们的办公室也有一个滑梯，好像没有一个滑梯都不是一个互联网企业了。

中间这个是我们办公的环境，它是一个开放性的空间。最右边的这个美女不知道有没有人听说，她叫做彭飞（音）姐，但是你在腾讯的男厕所碰到他一定不要奇怪，因为其实他是一个男生，他当年在碰讯内部说其实非常感激腾讯包容的环境，在腾讯没有人会取笑他，大家反而会以认识他或者与他有接触为荣。

闭环的业务

第二个维度就是朱啸虎和马化腾在朋友圈的互怼。

马化腾说token不算智能，必须双向通信才算，但是我们知道摩拜的锁你拿着手机一扫之后那个锁就开了，这个过程不是你的手机和车锁发生的通讯，而是你的手机到服务器之后再到车子，这个就是双向通讯，早期摩拜的车骑起来特别慢，特别累。

为什么累？因为你在帮它充电，早期摩拜为了给车锁充电，你一开始骑的时候就会很累。摩拜现在用的方法是前面的车框下面有一个太阳能板。总之我们强调的就是双向通信，当时马化腾说天天可以看实时数据，就是我们做一个业务，必须要可以实时看到这个业务的数据变化，这个也非常重要。我们基于此提出了一个概念，我们敏捷的团队做一个产品和业务的时候，需要注意这个业务可以做到一个闭环吗？就是你的团队做了一些事情和决策，开发了一些代码和功能，你要看到你的努力和数据产生的变化之间的关系，你要把它可以联系起来。

这个很关键，否则就是你很努力，但是你不知道怎么影响你的车。小黄车就有这个缺点，我们说共享单车的月卡费用提升，这样对用户有没有影响？频繁使用的用户有没有增加？这些数据要在后台统计，如果没有的话，团队就不知道这个决策是对还是错。

所以我们提倡的是一个团队能不能敏捷地做事，还有一个前提就是做的业务能不能形成一个闭环。否则团队开发了一个新功能，但是你不知道是对还是错，下个迭代就只有自己想象了。

我们特别强调业务自洽的闭环。

完备的团队

我们都知道，模型里面也一直在讲，通常我们的组织内部每个小组和部门都是按照不同的工种进行划分的，比如产品组和开发组，或者前台开发组还有后台开发组，测试组，还有运营组，做敏捷的时候我们提倡大家能够把做的这个闭环的业务所需要的各个角色的人员组成一个独立的一个敏捷小组，我们认为这样是最好的。

因为如果大家的组织划分是按照决策来划分，很多的事情决策效率是急剧下降的。比如有一天一个产品经理有一个想法，他和他的开发人员商量，我们下个迭代做这个功能，开发的同学就会说我很忙，我下一步做什么也不是我决定，你应该找我的领导，那产品经理想找技术总监或者技术小组长的时候，可能运气不好，比如刚好技术总监出差，或者校招，你只能打电话约，你约到了时间之后一去，最后他的结论就是你不应该和我开会，应该是你的组长开会，所以你还要把你的产品总监叫过来。

因为我们采用了传统的组织模式使这个东西的效率大大下降，所以你整个组织的效率是特别低的，所以我们提倡跨团队的决策。这个业务如果今天需要有测试人员的话，我就把测试人员引进来，如果需要哪个板块的人才我们就用哪个板块的人才。

当然对于很多公司来讲，短期内实现这么大的组织调整和变化是非常难的。早期我们是用虚拟的敏捷小组的形式，大家最起码可以开一个晨会，实现内部沟通，实际上腾讯的很多部门现在已经有这样的一种实际的操作，它的内部就是按照敏捷小组来规划的。

整个的大部门两三百号人下面就是小组，这是已经实现的，腾讯做了11年的敏捷，已经在这个过程中知道了敏捷的好处。

灵活的模式

灵活的模式是我们做敏捷的过程需要的工具和模块，但是有些组织和公司还处于敏捷的转型期，这个时候这么多模块是不是一下子全部采纳和改进其实未必，你完全可以根据企业、行业、组织及产品的特点来进行摘取。实际上在腾讯07年做敏捷转型的时候，一开始也不是照搬一个框架上来，当时也是经过培训之后，大家知道了这些概念后接下来就挑战大家，这么多东西你愿意先从哪一个开始尝试。

我记得当时挑了自动发布这块，先开始做的是网站部，他们先做了自动发布，为什么是他们先做？仔细想想其实很简单，因为他们部门的业务形态那个时候就是网页为主，就是各种各样的新闻，它做自动发布是最容易的，那个时候我们还在做手机的业务，07—08年的时候手机型号相当复杂，你把TOP10的手机型号都做了之后覆盖率才可以到60%左右，所以我们当时需要把它梳理清楚。

我们做敏捷的过程当中，大家不要拿着一本书或者哪个地方拿过来一个框架全盘吸收，一定要根据你的业务你的行业你的团队你的产品来选择，最简单的就是你的团队选，团队认为哪个最重要，就从哪个方向突破。

进化的工具

进化的工具就是说，团队规模是一个10人以下的团队就可以用一些简单的工具来做，如果人更多一点就需要全套的管理工具。总之，我觉得敏捷有一个特点就是敏捷实施起来一定要解决你的团队的问题，而不是听说敏捷很好，敏捷帮助很多企业做了很多的事，那是不可能的，一定是要依据企业业务和团队的特点逐步实施。

用好了一个能力我们再来看下一步引入什么能力。逐步的引入是最佳的。让每一个能力深深扎根在你的团队里面。事实上，我们当年一开始做敏捷的时候也听了很多的讲座，请了很多的大师，但是发现和落地的东西有很大的差异时，我们根据已经掌握的东西做，慢慢体会到了一些东西，领悟到了一些更多的功能。

所以产生敏捷的过程是一个逐步进化的过程。

精益需求管理

需求是非常难管理的事情。下图这是我们的精益需求管理，这是是一个标准的敏捷的流程。我们有一个两周的迭代，我们从这里面挑选一部分，将来发布出去。

我认为实际上需求管理，可能有三个层次：

第一个就是按照优先级排列需求。大家会说这个很容易，我们有高优先和低优先，其实最重要的不是你可以分优先，重要的是可以按照比例分。我们可不可以只有高优先级的需求？显然不行，如果这样做，你执行的过程当中，遇到困难你要按时交付就会有难度，你一定要按照一个比例来走，这个比例是一个三角形，这样的一个需求列表才是可行的。是你的需求的优先级按照一个三角形可以分布下来，当然经常产品经理不会答应。

第二个就是聚焦用户故事。虽然我们可以分优先级，大家看一下很多的APP每次版本发布之后，这个里面很多的产品经常写的都是优化了什么功能，解决了什么BUG，提升了什么效率，就是完全没有非常具体的功能点的描述。就是说我们做了迭代，但是迭代不够聚焦。没有一个清晰的聚焦，我们没有一个版本解决用户的问题，所以我们一定要仔细分析我们每个迭代做的功能帮助用户什么场景下解决了什么问题。

第三个就是关于抽凳子。这个意思是说比如一个产品很大，它会有一个产品组，有非常多的产品经理，这么多的产品经理因为大家平时要合作，所以我们会对这些产品经理进行分工，这个产品可能有8个方面和10个模块，我们会有一些各自分工，假设我们是两个月或者三个月6个迭代我们出一个大版本，那我们的项目经理可能会说我们下个季度的需求要规划了，麻烦各位产品经理把需求提供一下。

我们现在的问题就是请问这个项目经理说了这个话之后，三天之后收集上来的需求这10个产品经理会不会有1个或者2个不会提出需求？不会。

事实上10个产品经理都会努力地提需求，如果这个经理不提需求，他会觉得我管的这块没有用，会觉得没有价值，所以10个产品经理都会努力地用心地提出各种需求，假设10个产品经理都提出了这个需求，汇总之后，我们这个版本到底给用户提供了一个什么样的功能？如果我们的每个模块都有要改进的内容，那我们的测试人员怎么测，这个时候因为需求不集中，产品经理的分工导致了我们整个产品版本上的问题就非常严重，导致后期一系列的操作都没有办法得到保证。

所以你会发现这样做的话我们的难度会非常大，我们提倡的是在一个版本规划的时候，我们认为产品经理就不要预设分工了，这个我们叫做抽凳子，因为每个人屁股底下都有凳子他就一定会维护，所以我们弱化产品经理的分工，我们提倡迭代的时候从用户的角度思考我们到底应该做些什么，然后10个产品经理都有自己的观点，我们进行PK，10个经理提出了10个观点，我们互相PK，最终可能我们只挑选3个出来，接下来是由所有的产品经理聚焦在一起，来对每一个问题进行具体的分析。

这样的话我们通过抽凳子的方式使产品经理的分工弱化，从而让我们每一个大版本的聚焦都会更加的明显，所以说这一点实际上是我们认为这个在需求关系上的三个层次。

当然越往上就越难，但是只有这样我们才能使我们每一个产品的质量得到稳步的提升。

有损质量管理

我们都知道有损都是按照迭代运行，这个过程会出现的一个情况就是各种各样的延期，我们还是要坚持敏捷迭代运行的方式。迭代的刚性交付是一个非常好的方法，但是我们的质量管理按照传统的模式通过测试做的方式也会遇到一个很大的挑战，我们怎么解决？

我认为可以从三个方面解决。第一个就是解决质量问题的时候有一个观念要改变，就是传统思想上我们认为质量是靠测试保障的，实际上这个观念要改变，质量不是测出来的，而是开发出来的。

开发环节和开发过程是更为重要的，如果你的架构本身设计不合理，代码质量不高，测试人员要多大的精力才可以发现？一个不要紧，几个工作量就很大，并且一般会有交互影响。观念转变之后第一个方法是比较重视持续集成，它是一个XP的实践，为这是一个非常好的方法，比如说代码提交之后，我们就可以编译一个版本出来，接着我们会触发一些质量的扫描方式，这么多我举例说一下CPD的例子。

它是干什么的？它是用来检测以每个程序员为单位，昨天所有提交的代码里面有多大的比例是复用过来的。我们当时做了分析，把一段时间测试的BUG拿出来，研究这些BUG的特点，研究了相关的代码之后我们发现很多的BUG，大概40%都是由什么类型的代码引起的？

就是从复用过来的，程序员做一个功能，找到了这个代码，直接复制过来，至于这个代码里面有什么具体的机制，他就管不着了，当时我们发现这个情况之后，我们马上做了扫描，这个扫描是从代码静态的角度看这个事情，我们分析每个人昨天提交的代码，5行以上可以跑的代码占昨天的比例多高，统计之后第二天我会发一个邮件，凡是前10名的，把他压下来，这是人和人比较的一个过程。

所以假设小张第二天一上班，排名是第一，有60%的代码是复制的，那不好意思，你今天要自己重新做。如果他实在没有时间，第二天我们会抄送给他的领导，我们就是通过这种方式不断更新和分析，去找出对研发质量影响最大的地方，用一些很简单很有效的方法不断地做，积累几个月之后代码已经跑了很长的时间，没有人敢动，但是我们每一天都在不断提醒，这样我们的质量才可以逐步稳步提升。

这样可以帮助我们及时发现我们写的代码哪些是不好的，挑选出来要求改正，这是我们经常用的一个方式。

关于自动测试我认为业务如果足够稳定你做自动测试没有问题，但是如果你的行业竞争很激烈，功能每天都在波动和更新，你把你核心的一部分做自动测试就好了。

第二个我们会用showcase，我们提倡每一个闭环的功能出来之后，迅速对这个功能进行showcase，大家同时进行交叉体验，不同手机系统体验不同的版本，因为体验别人的版本你更容易发现问题。

从用户的角度发现问题，我们在发布之前我们已经从用户的角度发现了很多的问题，用户那边就不会有太大的问题。

第三个兜底的我们叫做灰度发布，就是永远不要把你的所有功能都给所有的客户用，任何的功能都应该是一个灰度的过程，所谓灰度就是你可以给万分之一或者千分之一百分之一用。

我们通过这三个方法就可以把我们的质量控制在一定的范围内。

极速发布管理

发布时我们希望越快越好，你每天发布十几次都问题不大，你可以做到的话，也是可以的。

我们有一个例子就是灰度的引擎，用户接入进来之后，我们进行用户的分流，所以可以导入一部分用户到新版本，一部分用户到旧版本。这样有一些好处，我2013年到腾讯的时候，喜欢户外，经常睡睡袋，并且全天的时间凌晨4点用户数量是最少的，所以我们10点睡觉，3点起床，观测到5点。那个时候我们只有靠人力寻找灰度的最低点，但是有了系统的架构支撑大白天就可以做。

以上就是我讲的八个关于腾讯的敏捷研发体系的点，当然是一个比较泛的概念，我们讲到了开放包容的环境，我们讲到了一些所需的工具和模式，以及我们讲到了需求质量还有发布方面的一些特点，希望可以帮到大家。