“鹅厂”面临的挑战

从2006年开始，腾讯的研发规模开始膨胀，开发模式急需规范和标准化，到底走IPD(集成产品开发)还是Agile(敏捷)的开发路线，公司管理层也在为拿不定主意而犯愁，之后研发管理部开始与ThoughtWorks公司接触，逐渐将敏捷产品开发引入进来，并正式命名为TAPD(Tencent Agile Product Development)。

实施阶段

试点期：组织很多专题研讨和内部培训，树立标杆，更大范围内进行培训

推广期：内部建立一个顾问团队，开发一些扫盲的课程，不断地进入到团队进行培训，让大家了解，接收这些理念。

面临挑战

团队非常多，每个团队特点都不一样，比如规模不一样，应用方法不一样；

产品非常广，互联网上所有的产品腾讯几乎都有，这种多元化的产品它本身产品的研发模式会有一些不一样，那么敏捷、TAPD怎么样去适应这种多元化产品的研发；

敏捷在腾讯也是存在一个过程改进，这样就会存在一些不适应性，针对这种不适应性应该怎么样去做才能更好；

腾讯人员本身的素质参差不齐，每年校园招聘大概会招聘1000多个毕业生，这些毕业生从毕业到能上手工作，他们对敏捷的了解，到融入团队都需要一个过程；

一些长周期的项目，比如QQ客户端，一个版本的发布可能要半年到1年的时间，像这样一个产品怎样去做敏捷开发呢，或许它并不适合敏捷开发。

也正是由于这些挑战，才孕育出了独特的腾讯敏捷模式！

从整体框架来看，腾讯的TAPD是吸收了XP+Scrum+FDD三者特点的并行迭代开发模式:XP完整的实践会比较理想化，很多东西不一定在实际开发中能够采纳，所以腾讯只是采纳其中的某些，比如自动化测试和持续集成，目的在于保证产品有一个快速发布的过程；腾讯采取的Scrum不完全是Scrum，与腾讯本身的特点总结出的实践相结合，项目管理过程同Scrum类似；FDD即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证，产品的方向，市场调研，用户调研等。

02、腾讯的快速迭代过程

一个完整的迭代过程包括概念，设计，开发，测试和发布五个过程

03、腾讯是如何做敏捷管理的？

1、故事墙

就是白板story wall，平时工作中很多团队都会使用，这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来，整个团队每天都会围绕这个白 板能够清晰的看到整个产品或者整个项目的一个过程，包括整个产品特性的过程。写在白板上比用Excel或者其它工具管理好，因为写在白板上让人感觉更紧 迫、更正式、更一目了然，有一种别人在监督、在注视的感觉。

2、每日晨会

每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作。对Team而言这是检查进度、快速调整非常有效的形式。

最早是通过白板的方式去做，就是每天项目经理组织团队成员对着白板，白板上体现项目的进展情况，通过会议可以很明确的知道昨天大家做到什么样子，今天大家计划做什么，最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题：

对于一个20、30人的团队，每天要怎样做晨会，这是目前遇到的比较大的困惑；

晨会很容易形式化，究竟带来什么样的效率和效果，目前也在通过一些方式去研究，去探讨。

有一些形式上的呆板，刚开始做会觉得比较有意思，觉得这跟传统做法不一样，每天这样做并且做多了就感觉很枯燥，这也是面临一个挑战。

后来腾讯也做了一些改进，比如为了让成员的参与程度更强一些，有些团队就会采取每个人轮流主持的方式，刚开始晨会的时候我们也会通过一些好玩的东西去刺激，激发一些灵感，现在看来的话，改进的不是很透彻。在腾讯内部有一个交流通信的软件，有些项目不采用站起来开晨会的方式，觉得站起来效率也不高，他们就会通过即时通信软件每天去交流，最后由一个人统一输出，这样能解决一些分布式团队的合作。（所谓分布式团队即这个团队中有些同事在这栋大楼，有些同事在另外一栋大楼，通过这种实时交流的方式也可以解决一些问题。）

3、规划游戏

对敏捷的一种常见误解：不要计划。事实上，在敏捷的体系中不仅强调计划，甚至区分Release计划、Iteration计划和Task计划等多种不同粒度，不同时长的计划。规划游戏突出的是让用户代表参与，由用户代表评估用户故事/特性的优先级，开发人员评估任务的开发时间，由用户代表+项目经理+核心成员三方共同排序、组合，确定本次迭代计划需要实现的特性列表。在腾讯用户代表就是产品经理。腾讯特别强调的是并行迭代，即多个版本并行，最大程度发挥资源的效率。Release(发布)可理解成当实现的产品特性累积到一定用户价值时的正式发布，它是比迭代更大的概念；迭代是在固定时间内开发特性的过 程，Release一般包括多次迭代。

4、时间盒

在腾讯的产品研发中，产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次IPM会议，即本次迭代的计划会议，团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导，一起去敲定本次迭代要完成的任务，一旦任务敲定下来，本次迭代就会严格按照这个去落实执行。 TimeBox反映了敏捷开发的节奏，即在固定时间内实现不固定特性的周期，抛开需求定义阶段，从设计-实现-测试到部署，一般来说，在腾讯一至两周时间居多。

5、产品演示

提交测试前由开发人员演示实现的功能，产品经理到场Review是否符合当初的设想，避免接近发布时才反馈。

6、迭代总结

在每一个产品发布的时候都会有一个总结。具体的做法是：把做得好的、不好的总结出来，做得好的在下一个迭代发扬光大，做得不好的在下一个迭代需要注意改进。这样的总结要求项目的所有成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每个人都要去总结他在上一个迭代中碰到了什么问题，通过便签纸的方式贴出来，在这里，项目经理可以看作是Scrum Master。最后会得出一个excel的文档，包括上一个迭代中出的问题，具体的解决办法等。

7、自运转团队

在早期的项目中，为了能提高效率，PM（项目经理）希望每个角色都能全力以赴地提升自己的效率，于是自己承担起来大量沟通和推进的工作，那个时候团队在被PM推着走，一旦PM休假，项目基本没什么产出，所以发现到这个问题以后，大家意识到团队的主动性必须被调动起来。

自运转团队，是将需求开发过程详细划分成开发的各环节，并明确每个环节的负责人，由该负责人来驱动上下游的负责人，而不再由项目经理来连接各个环 节，再配合高效的项目协助工具平台，一起实现开发过程自运转。这时项目经理则由指挥者变成服务者，他需要观察环节之间产生的瓶颈，并及时采取措施扫除障碍。

04、腾讯是如何进行敏捷开发的？

1、用户研究

如何加强用户的参与度，这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析，分析用户在这个产品上整个体验的过程是怎样的。通过后台的数据可以看到整个活动的曲线，同时CE也可以通过一些科学的手段去保证，包括市场调研、用户研究、数据挖掘、产品体会等，即通过一些对用户反馈、用户观察的工具一起配合做研究。比如QQ拍拍的一个用户的研究，我们到现场去做调研，通常，会由产品经理和用户研究人员到用户的实际办公地点进行一天的调研，通过观察用户如何使用你的产品，配合一些相关的工具去做科学的分析。因为互联网非常强调用户反馈，腾讯有自己内部的一个CE反馈平台，在这个平台上可以收集到所有用户的反馈，产品经理可以看到他所负责的产品有哪些反馈，包括内部的、外部的，然后根据这些反馈对产品进行快速的调整，包括开发一些产品特性，内部同事也可以踊跃地在平台上反馈，因为内部同事本身就是QQ用户。

2、故事卡片/故事墙/特征列表

StoryCard是XP中推荐的需求定义方法，要求符合Invest和Moscow原则；故事墙则用于跟踪故事卡片的变化状态，而特征列表是Tencent一直沿用的需求表达形式，在腾讯的TAPD工具中已经实现了类似ThoughtWorks 的Mingle的故事卡片管理功能，对于需求跟踪而言这是不错的方法，一目了然。

3、结对编程

理论上结对编程可以提高代码的质量，而且不会降低开发效率，但腾讯的业务繁忙，资源上不允许两人结对。但是在一些团队里面还是一直在尝试着做结对 编程的工作。一个在编写程序，旁边还有一个人同时记录编写过程、编写思路、碰到的问题、自己的想法，编写完以后一段时间他们会互相交换着进行编程，这是结对编程的一个过程。

4、测试驱动

“测试驱动开发”在腾讯执行地并不太好，腾讯的产品以Web形式居多、业务逻辑相对简单，C++下的单元测试有些力不从心。相反自动化测试在腾讯比较盛行，因为有测试部门专门的自动化测试Team在推动，而且链接的是正式生产环境，可以即时反映产品当前的状态。

5、持续集成

持续集成可以降低发布前集成阶段的难度与成本，腾讯的自动化构建系统推行得比较早，覆盖了大多数产品，而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。作用于加快产品发布的能力，持续集成在以下几个方面作用明显。

自动编译输出报告，维护代码可运行，及时暴露风险，降低集成成本。

Dailybuild日构建系统，让产品经理、测试人员可以尽早进行体验和测试。

作为一个自动化系统，利用静态代码检查、单元测试报告等手段为团队提供报告，促进编码质量不断得到重视，降低缺陷解决成本、缩短解决时间。

6、灰度发布

灰度发布是腾讯的又一创新，它将产品试用扩大到海量用户一端，在小范围及时吸取用户反馈，分析用户行为和喜好，持续修正自己产品的功能体验。在互联网行业，灰度发布已经成为最重要的发布控制手段。有时我们希望通过向小部分用户开发新功能，让他们先来体验新功能、新特性。通过用户反馈、数据运营的手段及早获得反馈，及时改进。以此方式，既可以降低发布风险，也可以提升发布频率，加快发布节奏。

简单说，即一项业务不是一下发布给所有用户，而是分批分期地发布。这样做目的有两方面，一是减轻服务器压力，二是在此期间可以在小范围收集到用户的反馈，如果业务出现问题，不会让大范围用户受到影响。随着经验的累计，我们有了许多种灰度策略和方法，灰度也有了更多的应用，甚至引入到了测试环境，即选择一些热心用户，将功能首先发布给他们，通过他们的使用，来帮助进行一些现网测试，这使得一些难于模拟的测试场景变得简单，测试人员的压力大大降低；更重要是，用户成为最好的测试人员，测试结果更加真实；同时他们也享受到了优先体验的特权，可谓一举三得。发布的时候也有策略，比如发布时如何放量，对用户有些什么样的实验，技术上怎样做一些后台开关，运营上怎样跟进，怎样保证4小时人员的留守，发布完后怎样收集用户反馈等等都会有一些统一的规则。

7、发布汽车

过于频繁的发布会打破团队节奏，有效的发布管理是必不可少的，根据业务特点，我们通常会采用三种发布模式，我们管它叫“发布汽车”。

班车模式：像班车一样，固定周期进行，比如每两周发布一次，这周比较适合特性规划比较好的产品，比如QQ客户端基本每个月都会发布一个版本。

的士模式：与QQ客户端不同，QQServer作为一个平台，它的需求来源非常多，因此它采用多线并行的方式，根据需求来源分成十多个子项目，如果想要发布，就像打的一样随叫随发布。他的好处是快，但是协调发布的成本是比较高的，比做班车花费更多。

警车模式：顾名思义可以不按法规来开车，因此对于特别紧急的需求或运营事件，必须采用警车这种模式，紧急发布，但这样做成本更高，会把交通秩序搞乱，开发节奏打破。

8、重构

好的代码不是设计出来的，而是重构出来的。

补充

流程和开发方法确定了还远远不够，更难的是如何将它推动落地。腾讯组织开发了承载敏捷思想的TAPD项目管理工具，它类似 ThoughtWorks的Mingle；然后推出了敏捷能力模型，类似CMM成熟度模型一样对Team评级加以引导；还推出了敏捷指数排行榜形成竞 争，营造你追我赶的声势氛围。