王速瑜谈腾讯敏捷研发方法与平台

个人简介 王速瑜，腾讯科技（深圳）有限公司R&D研发总监，现负责腾讯敏捷产品开发技术的实践和推广及研发基础平台的管理工作。熟悉Java、Microsoft.net、Lamp等技术。对互联网大规模应用技术、高性能网格技术，SOA等有非常浓厚的兴趣和深入的实践，喜欢 Open Source，关注Ruby、Erlang的发展并积极实践。

敏捷中国大会是国内敏捷技术领域最高水平的大会。今年的敏捷中国大会（AgileChina 2009），以Pragmatic Agile为主题，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。

   

1. 刚才听了您的讲座非常不错。那么我首先想问一下，作为腾讯这样的产品公司，有很长的历史了。怎么会突然会想到转变到敏捷这样一种方向上来，推动力是什么，这是第一个问题；如果说腾讯是敏捷，他的敏捷最大体现在哪些方面？

其实当时引入敏捷也是由腾讯所处的行业决定的，就是互联网行业，因为互联网产品的要求它有个很大的特点──就是要快，你要尽快的交付到用户手里面去，这是刚才讲的用户价值的一个体现，这是一个方面，就是他要求产品发布出去（周期）要短。那第二个其实还有一点就是用户的需求是海量的，或者说是不确定的，你很难去捕获一个很明确的用户需求，他不像传统的项目，我到了一个企业去实施，很容易去找用户沟通他的需求。但是互联网是不适合这样的，所以这种不确定性也决定了我们要去做这样一种敏捷的尝试。那还有一点就是，因为互联网的产品他的用户是海量的，就他这种发布的过程其实也是需要有一些敏捷体现的，你怎么样把这个产品发布的更好一些，更容易到用户的手里去，然后他有什么样的一些策略能够让用户去感受到这个产品的变化，这些都会去决定。其实还有就是一些关于研发人员的问题了，因为像互联网的产品，他其实属于一种信息行业的产品，他可能更多是靠创意，所以他有很强的创新性，那这种创新性是依赖于团队人员的素质。但敏捷他所强调的一些理念其实很符合这种素质，比如说，让人更好的去沟通，更好的去协作，因为你有这样的一些素质以后，你让这种人员有更好的一些Idea的产生，所以这些东西都综合决定了腾讯是需要去敏捷的。那当然，其实腾讯在最早做这个事情的时候，还是用了一些IPD（Integrated Product Development）的方法，就是华为的一些方法。但也是发现华为的这个过程太重了，他不太适合腾讯去开展这种比较轻量的产品的开发。所以那个时候，我们就开始去研究敏捷方法，包括研究他怎么样到腾讯这边来实施，那最早也是从Thoughtworks这边咨询一个项目开始的，当时也是请了Thoughtworks到那边到公司去做了一个三天的培训，就是把Thoughtworks的敏捷方法做了一个完整的介绍，包括SP的一些具体的实现，我们都去做了一些学习。然后当时也是觉得这个方法对于一些小团队，就是一些互联网的整个Web 2.0的产品的开发是非常有帮助的，那个时候我们就开始慢慢的去走向敏捷道路了。


   

2. 刚才在你演讲当中，你提到了你们有一个敏捷管理平台，那么我想请问一下，像在敏捷当中，你们怎么去理解跟运用这个管理平台的，又怎么去把管理这个概念理解跟运用在敏捷上的？

其实最早这个平台我们当时在做的时候，我当时是跟Thoughtworks的人有过交流的。当时他们给我的建议说敏捷不需要平台，他说你们不用开发这个平台了，开发了也没有用。但是后来Thoughtworks也推出了这样的一些工具，其实也是看到了在企业具体落地的时候，是需要有些平台去承载的，这样你才能够保证到所有的团队都在用这个东西，否则你很难去管理或者是监控这样一种行为。其实这个平台他的好处是什么呢？第一个就是他首先是把这些研究的方法跟理念能够沉淀下来。比如说某一个团队，他有一个很好的实践总结出来以后，那我可以把这种实践归纳一下，然后在我这个平台去体现出来，我再把这个归纳的东西推广到其他的团队，或者其他很多很多团队，这是很容易去做的。但是如果你要把一个方法归纳起来以后，如果没有平台来承载你去推广，那你花的成本是非常非常高的，你一个团队，两个团队（可以），那腾讯有几百个团队几千个团队，你基本上是没有办法去做的，那这是平台的一个好处了。那第二个好处是什么？就是这个平台他所有的团队都在这个上面去运转的时候，同时也是构成了一个社区，我们可以叫做研发社区，这个社区他有个很大的作用就是大家都在分享你项目里一些东西，某个项目的一些经验，你是可以通过这个平台跟另外一个团队去分享的，那这是他第二个好处，能够通过平台去产生更多的价值。那第三个就是，对公司的管理来说，其实有一个统一的平台是能够帮助你这个管理水平迅速的去拉平，否则如果大家都在用不同的工具，比如说A项目组他用了敏捷方法，他用Mingle，B项目可能用另外一个Scrum Works，那你就很难保证这些团队他的水平是看齐的，那我统一的研发管理平台是能够做到这点。那还有一点，这对于公司长远的管理决策是有帮助的，就我通过这个平台我会产生很多的数据，但这些数据反过来是可以辅导，辅助这个决策的，那这是我们为什么去做平台的一个依据了。


   

3. 你刚才提到这个平台会帮助管理与追踪一些东西？我想知道对你来说，从管理角度来看，你会去管理与追踪哪些信息，哪些是你最看中的，如果你用了这个平台是不是会让他反而成为一种负担，因为我们的员工如果用这个平台，是需要不断的输入一些信息，甚至去做一些跟踪，去做一些录入等等，会不会有这种情况产生？

那这个其实也确实是个问题，因为我们当时在做这个平台的时候也是面临这种挑战，因为很多人员觉得这个工具给他增加了负担。但是如果从别的角度来看，就是我们反过来想，如果我们这个平台工具足够的简单，就是我刚才一直在讲用户价值，就是我足够的符合团队的需要，第一我要他的效率很高，第二操作很方便，那我相信这个不会成为负担，因为毕竟你还是会用，你不用这个平台，你还是会用其他的工具。比如说你做项目计划你可能是会用Project，其实他是一样的，所以我觉得这一点应该还是比较好，而且大家也是比较认同这样一个平台的存在。而且我们在开发这个平台时候也确实是一直在朝着怎么样把这用户体验做得更好更快这种方法去做的，所以我觉得这一点应该是不用担心的。那至于作为一个管理者，你在这个平台你会追踪什么东西，我觉得有几点，第一个，其实在腾讯，像我们的老板很关注员工的沟通，他们会非常重视这点，就是他希望在这个平台上能够看到项目组在一个很活跃的沟通氛围，所以我们有一个交流区，能够反映这个团队的一个活跃度，这是我们会关注的。那第二个，比如说作为一个项目经理或者部门的管理者，他可能会关注这个目标，所以我们这个平台，项目的每一个进展的情况都会在平台上有一个很透明的展现，其实这个也是符合敏捷的一些透明化的原则，这种展现是能够让管理者更好的去了解到这个项目的具体进展到了什么程度，出现什么问题，这个也是管理者要跟踪的一些东西。那同时我们还会关注一些核心特性的一些实现，所以我们在这个特性的导航上面也是做得比较便利的，很容易看到某个特性进展的怎么样，以及特性之间的关联，这个是我们管理者非常关注的一些东西。因为腾讯的管理者其实还是非常注重细节的，所以这种细节的特性进展我们也是希望去看到的，那这几点基本上是会去做，但我们反而不会太关注说你这个团队花了多少时间投入到这里，我们反而不会太去关注这个东西，所以我们更关注的一个是目标，一个是协作，还有一个就是一些关键特性的进展，那这是我们关注的一些东西。


   

4. 那么这个目标是团队的目标还是说会针对于每个人的目标呢？能给我举几个例子吗，就是你们会关注什么样的目标呢？

在平台上的目标可能更多的还是项目的目标，因为我们是希望团队，就是这个产品的项目团队每个阶段都会有个目标。所以我们的目标展现有几个方面，第一个就是我们有一个DashBoard，那这个DashBoard是能够看到项目的实施进展情况跟我们预期的目标是什么样子，这是我们希望看到的。第二个就是我们会看到他的一些，比如说还有一些统计报表，他是可以看到进展的一个目标情况，原来比如说我们定了一个目标时间，现在他完成了多少，还剩下多少，剩余时间多少，这个我们会去关注的。那同时我们还会去关注个人的一些具体的目标，其实也是会，但是个人我们会看他，比如说原来这个迭代他负责了10个story，每一个story他的variance是多少，总variance多少，我们会看他每个人就是剩余的variance还有多少，这些我们都去关注，因为这样是能够帮助到这个团队更好的去做他的迭代式开发，这些我们都会去关注的。


   

5. 好的，那么你觉得，因为我看到很多书上都会说，敏捷团队他不需要去做一个很严格的这种进度考量，这点上你又怎么理解呢？

其实这个目标也不是说是完全是我们的管理者给他的，当然管理者，我们公司的管理是说我们每个季度都会跟每个团队去讨论下一个季度大的一个目标是什么，他的Big Picture是什么。但是具体的一个迭代的目标我们其实还是交给团队去做的，其实我们现在的很多团队的他的迭代的周期都是非常固定的，比如说如果是两周一个迭代，他们每周一会固定有一个IPI的会，这个IPI的会是一个迭代的kick off会议，他会决定这个迭代要做什么，他的目标是什么，然后完了他会有一些回顾，回顾到第二周的周五下午可能会有一个产品会，他就会讨论我下个迭代，下下个迭代要做什么，那这些东西其实都是由团队一起去做的。当然在这个沟通的过程里面其实管理者他也是会跟你的产品经理，比如说跟你的项目经理去做一些PK，他会一起来讨论这个目标是什么，所以这个严格说也不是由我们去给他什么目标，更多还是团队自己去适应这个目标，所以我觉得很多书上写的这个东西其实是一种适应性的，就是你这个团队能不能按照自己的节奏去适应这样产品的一个发展，其实这点是很重要的。

   

6. 那你这个平台的受众其实是Team当中每个人都要去使用它？

你是说公司的那个研发平台是吧？也没有，其实我们是希望所有人在用了，但是实际上可能有些人不会在用。因为现在项目管理这块做的比较多，所以可能项目经理也是用的最多的。然后开发人员的话，他可能每天他只要去更新一下他的一个进展就OK了，他不会太去关注其他东西，因为他可能更多的工作是在开发，在coding。那测试人员可能就会去关注他的bug的一个情况，比如说产生了多少bug，fix了多少，他会关注这些东西，当然我们为每个角色都提供了很多视图，比如说管理者有管理者的一些分析的视图，然后QA有QA的视图，那我们是希望所有人都在用了，但实际上可能很多团队也未必都在用了。但是很多团队确实是每个角色都在用，因为我们现在整个过程是贯穿的，从他的产品立项开始到最终发布，这个过程都是贯穿的，包括你说测试都在上面那每个角色他都会有自己的一些视图。


   

7. 好的，我想再问一下，你们团队当中在使用这样一个工具来管理研发，那么对于你们来说，作为敏捷的一个项目团队，你的管理理念又是什么？

你是说跟这工具有关吗？


   

8. 对，可能会跟工具有关，因为工具可能会体现出你的管理理念，但是也有可能跟工具没有关系，在一个敏捷团队当中，你是怎么样来考虑管理理念方面的问题的？这种理念会不会引入到你的工具里面去？


其实是有一定的关联，包括这个产品本身的建设过程里面也是体现了这个东西。一个敏捷团队在最开始的时候，其实我们强调一个基础是什么，就是这个团队的兴奋度，其实这个兴奋度他是来度量这个团队的氛围的。因为敏捷你要沟通、要协作，如果大家都没有这样的一种这种思维，就是愿意去沟通的这种思维或者意识的话，你是很难做得到的，所以我们最开始都是在培养团队的兴奋度，而且当时我们的工具也是做了很多功能去体现这个东西，所以我觉得这个是敏捷团队的一个基本。那有了兴奋度以后，你还要有一定的这种透明度，就是你整个团队之间的所有的东西能不能共享出来，每个人通过什么样的方式共享出来。当然我们除了工具以外，还有线下的白板，我们原来是有Story Wall，就像ThoughtWorks那样我们也有做。所有这些东西都是为了增强团队的透明度，就每一个人都知道，包括目标，包括进展，包括碰到问题，你每天都会知道，而且你每天早上会有Standup Meeting，这个是能够保证你的透明，能够更好地去透明。那还有一点就是我们很强调Ownership，就是你这个团队必须有一个很好的Ownership，我们当时提倡一个口号叫什么？就是“人人都是产品经理”。虽然我今天讲产品经理主要是关注用户价值，但是我们希望开发人员也要去关注这个用户价值，因为毕竟产品是你最终去开发出来的，包括这个UI，你这个UI原型以及UI交互是什么样子，你都得去负责的。所以我们是强调团队必须有很好的Ownership，能够大家一起为这个产品的一个滚动而去滚动，这样才比较好，那这三点都是我们强调的一些东西。还有一个就是协作性，那这个协作性我们可能更多是通过这个工具去完成协作的，当然腾讯还有很多沟通的工具，比如说我们内部的IM等一些工具，他也是一个很好的协作工具。但同时我们也是很鼓励大家有问题的时候能够站出来，因为大家都坐在一起，你站出来叫一下可能这种沟通效率会更高一些，那其实这几方面就是我们在敏捷团队所要求的一些东西了。当然还有其他，比如说你如何具备更好的学习能力这些也是一个要求来的，大概就是这样几点。


   

9. 刚才你提到说使用这个工具，那么你线下还会去用一些敏捷当中的实践，比如说白板包，比如说站立会议，那最后会不会有些重复呢？


你是说有重复？


   

10. 比如说我已经跟你开完站立会议，结果你又要求你的员工再去把那个状态更新？


没错，我刚才在介绍那个工具时候我也提到了，原来那个工具他们最早做的时候，还把站立会议那个回顾这些实践他都通过一些工具的方式去承载。但是后来发现效果不明显，就是因为可能是有一定的重复性，所以我们现在就是Standup的东西你在线下去做，包括回顾你就开个会议去做就OK了，我们不要求你在平台上去体现出来，这是我们是没有强制要求的。然后至于我们线下有Story Wall，这个东西其实我们是跟平台有关联的，就是我们平台那个Story Wall他会有一个很好的界面展示，那这个界面他是能够打印出来的，打印出来以后他是能够贴在那个Story Wall这个白板下面的。然后这样就完成了一个很好的连接，这样的话就保证不会把工作重复了，这个基本上现在来说没有太大问题，因为线下最主要的是解决你的沟通的问题，那线上更多是解决你沟通跟协作的问题，因为通过平台的协作你的效率一定是会更高一些的，大概是这样子的。



   

11. 谢谢您。


好，谢谢。