王海龙：赶集网的敏捷实践

个人简介 王海龙毕业于北京航空航天大学软件工程专业。2014年2月加入赶集网负责技术部整体的软件质量保障、软件敏捷实践以及内部技术平台开发工作。之前曾在百度，淘宝网，阿里巴巴，用友软件等多家企业从事高级技术管理工作，研究领域在移动及社区方向。之前曾在百度主导并建立了公司级用户反馈分析平台UFO,以及Crash分析平台batsdk，以及百度内部用户测试客户端-尝鲜平台。

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 各位InfoQ的网友大家好，现在我们是在QCon北京的现场，作客我们专访间的是赶集网高级质量总监王海龙先生。第一个问题我想问的是，这些年的从业经历里，让你印象比较深刻的人和事有哪些能谈谈吗？

王海龙：我能想到的只能有两件，第一件事情，我最早刚毕业的时候是在用友。用友软件是一家传统企业，在2006年的时候，我进入互联网去了雅虎，当时走的时候我这边的老大也是比较支持，那个事情对我来讲印象特别深刻。因为是从传统行业转到互联网行业，但从最终的结果看，我很庆幸进入了互联网的大潮，并且跟着时代不断前进。虽然说这种事情不是很典型，但是我会觉得是一个蛮关键的点。第二件事情，我在阿里巴巴的时候，那时阿里巴巴的CTO叫吴炯，吴炯在退休时做了一个界面的演讲，他提了一些说法，我觉得对现在来讲影响力也比较深。他说我们一定要做一个技术管理者，因为技术的生命会很长。他还开玩笑说，你看我在的时候，阿里的总裁换了好几波，但我还在，所以说技术的生命力永远是强大的。这件事情当时来看可能不算什么事儿，但是一直在影响着我，我觉得做管理不要做成一个纯管理者，还应该把握住技术的核心，做一个技术管理者，这样有助于个人的发展。

   

2. 在你加入赶集网之后，建立了一个移动测试平台，你能不能跟我们分享一下这个项目的筹建过程？

王海龙：讲一下这个筹建过程吧，在刚进入赶集的时候，其实内部还是一个比较初始化的状态，基本都是黑盒测试为主，全是手工的，这个时候我们面临的挑战来自于内部，也来自于外部，一部分是自己内部的人员，他们之前都没有做过这块技术，所以我要拉起一支核心的技术团队来搞定这个事情，在当时来讲会是比较难的一个过程。第二个方面来自于外部，比如内部团队的一些挑战和大家的整体意识。比如我在最开始就谈我们要做一些自动化的事情，可能赶集之前都没有人去做过这个事情，所幸赶集内部的技术氛围比较好，不管当时CTO罗剑也好，还是对口的研发总监，大家都比较支持这个事情，所以推动这个事比较顺利，但是具体的实施步骤更重要，选择突破点，让整个团队和周边的决策者认可你们做的事情是有价值的，后面的推动就会非常好。当时我们的重点是选择了整个业务的痛点，将构建平台作为切入点，当这个事情做完后，整个团队都会有一个信任点。大家说：‘海龙，我们觉得你们这个事情对我们有帮助，你后面做的事情我们都很乐意支持。’

   

3. 这个项目大概做了多久之后才算是基本完成？

王海龙：这个其实分几期，如果说构建的话，我们其实从外面招了一些专业的人做这个事，当时用了差不多一个月的时间搞定这件事，而之后的整个迭代是一个月上线一个功能，周边团队对我们的反馈也越来越好，某个功能上线了，他们觉得很好，问我们能再做一个功能吗？我们又做了一个，他们也觉得很好。还会有周边的团队说，我们是不是也可以用这个功能，这就进入了一个良性循环。

   

4. 在赶集网你是怎么推进敏捷化项目改造的？你强调敏捷开发，你是怎么在这方面做一些推进工作的？

王海龙：整个事情是天时、地利、人和，我在进赶集的时候，跟那边的CTO罗剑有一些沟通，他对这件事比较认可，老大的层面比较支持，还有一些典型的机会和典型的场景来推进这件事。一个是从整个内部来讲，面临一个转型期，因为赶集之前从一个中小规模的公司，转变成一个中大规模的技术架构，他们遇到了很多痛点，比如说线上的服务不稳定，内部的架构太复杂，这样就有了机会，大家都在想，是不是可以用一些方法让架构变得更清楚，让我们的开发过程变得更有效率，质量更好，这个过程我们跟他们去沟通，是不是可以采用一些敏捷的方式去做这方面的事情，周边团队就建议我们试试。但是具体的过程中还是要选择突破口，最重要的一点，这个事情是一个互利的过程，你要让周边的团队得到甜头，那么大家还是乐于去解决这个问题。如果你说得非常好，说这个东西怎么怎么好，敏捷可以帮你做很多事实，但是大家用起来的感受，除了增加负担并没有解决实际的问题，那就没有人会支持你。

   

5. 你们最早进行敏捷开发的项目是移动端的App吗？还是其它的项目吗？

王海龙：最开始，我们是找了两个团队，一个是移动端的App，另外一个是在PC端。这个其实有一个标准，一方面是说业务重要，因为它要有典型性；另一个是说，对口研发经理认可我们的理念，他也愿意帮助去推，否则就是业务再好，但是不是对方目前关心的重点，这件事情可能也推不动。如果是典型业务，也有对口部门支持，就找关键的人来做关键的事，见到效果，这部分其实也是一个不断跟团队适应的过程，可能你做了很多事情，但是宣传的不好，大家会不知道，我们会不断去宣传我们做到的这些成绩，来得到周边团队的认可，扩大这个影响力。让大家都觉得这个事情确实是有帮助的，慢慢形成一个氛围。

   

6. 是不是现在大部分产品都在用你这个方式进行开发？

王海龙：对，其实去年的时候很难，我们也没有扩到特别大，当时就是重点突破，抓了一两个方面，见到明显的成果，在去年做完之后，内部的反响非常好，所以今年内部的很多团队都来找我们，说我们一定要做敏捷开发。我们今年面临的问题在于，一个是整个技术部门的指标，我们能不能够把整个赶集变成一个全敏捷团队。另一个是人才，我们现在基本上做敏捷支持的教练不够，所以我们还经常处于不能响应的状态。

   

7. 微软有一个SDL产品生命周期的管理方法，我们之前谈到了敏捷，还有一个是软件质量保障，你在赶集是怎么做这个软件质量保障工作的？能谈谈具体的产品或者项目吗。

王海龙：那我谈对质量保障的理解吧，这样可能会更好一点。传统来讲，会有一个生命周期，我们产品从开始阶段、立项到设计，然后上线，最后完成这个周期。但是互联网时代，这个周期会慢慢变得越来越模糊，因为迭代的速度越来越快，质量的要求也没有传统软件那么高，这时候你就会遇到一个问题，到底什么样的质量是我们应该去坚守的，这件事情我们遇到的挑战会跟以前有非常大的差别。很多时候它是一个模糊态，包括跟产品经理去沟通，比如说我们遇到的几个关键问题，必须解决，但产品经理说这个问题是不是可以不改，如果对用户的影响不大，那是不是可以先发布出再修复。这个也是一个在不断破译的过程。在新时期，你必须找到一个方法，怎么能够平衡质量和产品业务之间的关系。基于这个方式，考虑为什么会做成现在这样的保障体系，包括我们会往灰度去走，往云端的分析去走，其实最重要的是形成一个质量的闭环，它是一个持续改进的过程，快速发布，质量可控，然后在下一版中继续迭代、评估，形成一个不断滚动的过程。

   

8. 下面一个问题，在你的从业经历中，你是怎么平衡当技术以及作为一个管理者这两者之间互相转变的关系的？

王海龙：这个问题还是比较典型的，我觉得每个管理者都会遇到，其实最大的难度来自于最开始你自己做事的时候，因为大家都会看到，你做得还不错，技术还可以，你是不是可以往下走一步，带人，做一个初级管理者，这个时候遇到的问题是最多的，我是应该继续做技术，还是放下一部分工作，然后去做一些管理工作。这个在最开始我也会有一些痛苦的过程，但是慢慢意识到这个问题，其实人多了以后，意味着你可以做技术的资源更多了，更重要的是你做技术的理念要升级。比如说，以前我是一个人把所有事情都搞定，但现在的情况，你就可以管大方向，把最重要的东西解决掉，而把其他的工作留给各个团队的其他角色，大家一起来完成。如果这个OK的话，接下来可以把一些重要的功能放给你团队的关键骨干去做。相当于你要有一个逐步放权的过程，但是对整体技术的把握，你仍然要对他们有一个非常严的控制，你对行业的判断和整个技术的理解要不断的升级，去抓最上层的东西，而不是关注在最下面，逐步把发展机会让不同层级的骨干也有一个上升的空间，我理解是这样一个过程。所以最终会自然而然地变成，你做的技术工作会比以前少很多，但事实上你会发现，你仍然负责最核心的技术工作，只是说很多时候我们困惑，技术和管理不能平衡，其实很大程度是在于你是不是在做你当前这个层级的技术工作。

   

9. 其实很多时候技术管理是这样，他逐渐去做管理了，不做技术了，但是我也见到有一些CTO，甚至CEO，比如说LBE的张勇，他现在还在coding，还会有这样的人，这种可能是比较少数的。

王海龙：我觉得这件事也是一个选择，因为CTO有很多种，像做将军的有一些是属于战将型的，就是喜欢冲锋在前的；还有一种是决策型的，培养出很多战将在前面冲，他在后面指挥，获得更大的成果，我觉得这部分很依赖于每个人的性格。像我自己的话，我比较擅长沟通，对整体的把握会比较敏锐，所以整个技术管理的过程，每个人会根据自己的特点，逐步形成一个自己的技术管理风格。

   

10. 之前58的老大做节目招聘人，你应该听说过，当时招一个安全工程师，开月薪八千，于是所有的黑客们不知道为什么，就把整个58的后台全给弄出来，口令、密码全给弄到外面去了，当时大家圈里都说，其实大家也别只看58的笑话，其他这些也都一样，大家加班加点在搞这种安全的事情，你来赶集之后，你们在安全方面做了哪些工作？

王海龙：安全这部分其实是有另外一个团队来做的，但是我进入之后，我会跟安全团队结合的更紧密一点。安全是两个层面，一部分是解决关键问题，另外是在广度层面解决普遍的软件代码中是不是有易于被攻击的点。我们主要展开的内容是跟他在广度方面的合作，有的时候在整个软件层面，我们已经确定的一些关键点是不应该有安全性问题的，这部分会表现成一个规则，我的写法应该是怎么写，我们会跟安全团队一起去检验这个规则，比如在测试过程中去做检验，或者把他们的部分上到我们的自动化平台，大家在整个团队中是一致的，不可以有一般的安全性问题。至于那种关键性的爆点，这部分其实还是依托应急团队。 另外一部分还是依托于本身安全团队会有一个比较牛的人来解决这个事，像我们那边也是，安全工程师虽然比较少，但是也是业界非常有名的，虽然他们很低调，但是很多问题都已经解决掉了。

   

11. 也就是说你们的产品在发布之前，会首先对它进行一些测试，甚至上到你们的自动化测试平台上再测一遍然后才发布。如果突爆一个漏洞，这时候就是应急团队来进行修复了。

王海龙：对，这也是应急专家那边去专门解决的问题。