[转]关于腾讯敏捷框架TAPD

愚人

关于腾讯敏捷框架TAPD（Tencent Agile Product Development）

腾讯是一家典型的互联网企业，互联网行业有其鲜明的特点：
1．关注用户行为
2．追求创新（腾讯有一个创新中心部门）
3．需求不确定性高
4．快速适应变化
5．快鱼吃慢鱼

腾讯在敏捷开发方面的实践大致包括3个部分：
1．产品：采用FDD，即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证、产品的方向、市场调研、用户调研等。FDD模式是一种非常适合产品经理来对产品做一些滚动的要求，腾讯在产品设计上引入了类似FDD这样的模式，但是也不完全是FDD，只是参考FDD，所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。
2．项目管理过程：腾讯采取了SCRUM，但也不完全是SCRUM，有腾讯根据自己的特点去总结的一些实践，大概的项目管理过程同SCRUM的过程是比较类似的，包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。
3．开发实践：参考了很多XP的实践，就XP完整的实践来说会比较理想化，很多东西不一定在实际开发中能够采纳，所以腾讯也是采纳其中的某些实践，比如自动化测试和持续集成，通过这样的实践就能保证产品有一个快速发布的过程。

在腾讯的敏捷实践中，具体的实践情况是这样的：
1．故事墙：就是白板story wall，平时工作中很多团队都会使用，这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来，整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程，包括整个产品特性的过程。
2．迭代总结：在每一个产品发布的时候都会有一个总结。具体的做法是，把做得好的、不好的总结出来，做得好的在下一次迭代发扬光大，做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每个人都要去去总结他在上一个迭代中碰到了什么问题，通过便签纸的方式贴出来，项目经理实际上可以看成是SCRUM M a s t e r，包括站起来总结这样一些东西，包括我们下一次迭代继续发扬什么，必须要注意什么东西，最后就会得出一个excel的文档，包括上一个迭代中出的问题，具体的解决办法，都会有。
3．每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作（特点：是站着开会）。最早是通过白板的方式去做，就是每天项目经理组织团队成员对着白板，白板上体现项目的进展情况，通过会议可以很明确的知道昨天大家做到什么样子，今天大家计划做什么，最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题，第一、对于一个20、30人的团队，每天要怎样做晨会，这是目前遇到的比较大的困惑；第二、晨会很容易形式化，究竟带来什么样的效率和效果，目前也在通过一些方式去研究，去探讨。第三、有一些形式上的呆板，刚开始做会觉得比较有意思，觉得这跟传统做法不一样，每天这样做并且做多了就感觉很枯燥，这也是面临一个挑战。后来腾讯也做了一些改进，比如为了让成员的参与程度更强一些，包括形式上会更强一些，现在有些团队就会采取每个人轮流主持的方式，刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西，但是现在看来的话，感觉改进的还是不是很透。在腾讯内部有一个交流通信的软件，有些项目也开始不采用站起来开晨会的方式，觉得站起来效率也高，就会通过即时通信软件每天去交流，最后由一个人去统一输出，这样能解决一些分布式团队的合作。所谓分布式团队就是这个团队中有些同事在这个大楼，有些同事是在那个大楼，通过这种实时交流的方式可以解决一些问题。
4．结对编程：并没有很好的实施开来，但是在一些团队里面还是一直在尝试着做结对编程的工作。一个在编写程序，旁边还有一个人，同时记录编写过程、编写思路、碰到的问题、自己的想法，编写完以后一段时间他们会交换一下，就是互相交换着进行编程，这是一个结对编程的一个过程。
5．时间盒：timebox，在腾讯的产品研发中，产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次IPM会议，即本次迭代的计划会议，会议中团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导，一起去敲定本次迭代要完成的任务，一旦任务敲定下来，本次迭代就会严格按照这个去落实执行。
6．一个完整的迭代过程：包括概念、设计、开发、测试和发布五个过程。在概念阶段，会采用FDD里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发，会制定一些产品发布的计划，比如产品在未来，某个迭代什么时候发布，要发布哪些产品特性，都是在这个阶段做的。在设计阶段，会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验，比方产品在某个迭代的一个小迭代里面，可能会在一个团队里面先去体验，可能就会采取发布到公司某一个部门去体验，或者发布到整个公司范围去体验，它会是一个不断放大的一个过程。在开发和测试阶段，更多的采取XP的一些实践，包括编码规范，代码走读，比如1周一次代码走读，构建持续集成的环境，包括自动化构建，自动化测试等，会有一些好的测试上的实践，如全员测试，就是将测试看成不仅仅是测试人员的工作，更多的是整个团队的工作，当然也包括这个产品的其他同事的工作，通过全员测试来激发大家对产品质量负责。在发布阶段，腾讯采用的是灰度发布，同传统的软件发布不一样。项目中整个迭代过程就通过类似SCRUM模式去管理，如有每日晨会，如何建设团队氛围，统一的管理平台，每次迭代完成时的总结回顾等等，这属于项目管理的工作。还有一些基础的工作，如代码管理，版本管理，文档管理，异地开发管理，这些在腾讯的整个管理体系里面都包含的，还有会制定一些相关的规范，不过规范不是很强硬的要求每一个项目必须执行，更多的由团队自己选择，让他们根据自己团队的特点、规模去选择应该采取哪些实践。
7．灰度发布：这是互联网的一个特点，说白了，就是对用户一个逐步放量的一个过程，而且不要求团队要尽早的将产品包发布出来，也就是不要求马上发布给所有用户，而是会分批的去发布，比如按号段发布，比如在公司内部先体验。发布的时候也有策略，比如发布时如何放量，对用户有些什么样的实验，技术上怎样做一些后台开关，运营上怎样跟进，怎样保证4小时人员的留守，发布完后怎样收集用户反馈等等都会有一些统一的规则。比方实验室某WEB产品的发布，可以同时有多个版本，1.1版可能会有100%的用户在用，1.2版可能只有1%的用户在用，它们是一个交叉升级的过程。
8．用户研究：如何加强用户的参与度，这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析，分析用户在这个产品上整个体验的过程是怎样的，通过后台的数据可以看到整个活动的曲线，同时CE也可以通过一些科学的手段去保证，包括市场调研、用户研究、数据挖掘、产品体会等，这就是通过一些对用户反馈、用户观察的工具去配合去对用户做研究。比如QQ拍拍的一个用户的研究，我们可以到现场去做的一个调研，经常会由产品经理和用户研究人员到用户的实际办公地点进行调研，做一天的反馈，通过观察用户一天是如何使用你的产品，配合一些相关的工具去科学的分析。因为互联网是非常强调同用户的这种反馈的，腾讯有自己内部的一个CE反馈平台，在这个平台上可以收集到所有用户的反馈，产品经理可以每天都会看到他所负责的产品有哪些反馈，包括内部的、外部的，然后他就可以根据这些反馈对产品进行一些快速的调整，包括开发一些什么样的产品特性，内部同事也可以踊跃的在平台上反馈，内部同事本身就是QQ用户。
9．项目管理支撑工具：腾讯内部有一个团队在研究和开发这样一个工具，用来支撑项目管理过程中的工作实践，当然界面不会做得特别好，毕竟是内部团队用的。比如腾讯的IT工具中实现了故事墙（story wall），就是模拟线下的工作白板，能够把一个迭代分成不同的阶段来看这个story的工作情况，能够很方便的支持每个团队在每天晨会的时候可以对着这样一个界面去做他的这个晨会，比如说有一些story做完了，就可以将它从这个状态拖到下一个阶段的状态，每个团队每一天都会对着这样一个故事墙，就能很清晰的了解到每个成员的工作情况，帮助团队很透明化的去工作，而且目标一致。这是腾讯在工具上的支持。
10．敏捷团队团队方面的探索：比如QQMail团队是这样的，有产品组、有开发组、UI组、测试组，整个团队都是围绕QQMail去开发，采用了敏捷开发的过程，具体团队成员间分工协作的详细内容大概会有几个要点，第一、从设计上看，每周每个迭代都会有一个IPM会，IPM会要求所有角色一起参加，包括产品经理、项目经理、QA、DE、UI等等，在会议上他们一起讨论产品需求，如产品经理谈谈他了解到的用户反馈，谈谈他从公司领导那了解到多少产品上的要求，谈谈他对这些产品特性的优先级考虑，就在会议上开发人员评估开发这样一个特性大概需要多少工作量，有没有技术上的困难，测试人员也会了解大家讨论的内容，这样使得测试人员能在开发阶段之前就能了解整个产品的需求是怎么样子的，整个团队就这样来讨论并确定一个迭代开发的范围，在开发过程中，所有的角色都会参与，像QQMail团队，QQMail是一个明确的产品，07年整个用户量翻了10倍，就是采用的敏捷开发，在QQMai产品开发过程中有一个要求，就是开发人员和测试人员在每完成一个需求都要进行一次showcase，即每开发完一个产品需求，要把产品经理、开发组、测试组都叫到一起，一起来总结一下这个产品特性开发到什么样子，是不是有比较好的用户体验，是不是满足一些预想的东西，而且也会对一些用户进行调研，也就是让用户参与到产品的测试中来。会采取全员测试的过程，即测试人员、开发人员、产品人员、UI人员会参与测试，并且每个人在开发一个需求完后，都要去做测试，而且也会进行交叉测试，比如这个开发人员会去测试一下其他开发人员开发的东西，所以在腾讯是希望全员测试的理念能够深入到团队里面去，在上线后的4个小时里也会要求人员留守，去看看这个产品后台统计的数据，及时分析用户的行为，去发现用户对这个特性的感觉是怎样的，用户的反应是怎样的，看看会不会出一些错误，这个就是4个小时内必须留守的制度。QQMail从06年、07年到08年的一个发展情况可以看到整个团队的心情曲线是逐步向好的方向发展的，QQMail最早在06年的时候，本身实际是存在很多的问题，比如需求太过于前卫，因为跟用户脱节，团队内部幻想着提供什么样的产品特性给用户，采取一些什么样的技术架构去做一些更好的体验，比如06年采用了很强的Ajax框架，前台架构完全是通过Ajax去实现的，由此带来了很多的问题，而且当时它整个team的要求也非常高，搞得整个团队比较疲惫，在06年中期就有一个小小的改变，包括对整个产品在性能上的改变，但实际上对于团队来说还是比较被动的去接受，就是比较被动的去感受用户的变化，对产品究竟怎么走、怎么营收整个团队都比较茫然。到06年10月，在QQMail团队中开始推广敏捷的一些理念，提倡团队怎样去更好的关注用户需求，怎样通过一些敏捷实践让团队做得更好，10月份做了很多交流，整个团队也看到了一些希望，敏捷开发刚刚引入到一个团队是比较新鲜的，包括如快速响应、响应变化的这些理念，给团队带来了很深的感受，在06年年底就对整个团队的分工协作做了一些改进，在07年通过一些敏捷上的运作看到整个效果还是非常的明显，这是比较成功的一点，大概是07年中这个产品的用户量大概是06年的10倍，就是07年达到了1000万。现在整个团队也把迭代、整个研发节奏固定下来了，会在固定的周期有固定的角色去响应用户不同的东西，会把跟用户的这种距离拉得更近一些，这就是QQMail团队的一个大概的发展历程。
11．在腾讯敏捷是怎么样开始的。最早的时候是通过认知，认知就是包括了解业界的一些方法论，包括同Thoughtworks的一个接触去了解敏捷是怎样的，而认可的话我们会去总结我们腾讯本身是怎么样子的，我们有这样一个框架之后我们就会搞一些团队去实践，通过实践以后再不断改进，本身也是一个不断迭代的过程。整个实施阶段大概分成几个阶段：06年参加Thoughtworks外部培训和行业走察 à 试点期：组织很多专题研讨和内部培训，树立标杆，更大范围内进行培训 à 推广期：内部建立一个顾问团队，开发一些扫盲的课程，不断的到一些团队里面去介绍去培训，让大家接受这些理念。腾讯内部专门有内部门户去介绍腾讯整个产品研发体系，所有团队都可以将自己实践的感受提交到这个门户，其他团队就可以了解到另外一个团队的一些优秀的实践，同时腾讯内部做了很多的交流研讨，包括我们会有专门的团队去同大家谈敏捷，不断的将一些好的实践推广到各个团队去，在腾讯也会有一个敏捷能力模型，会把团队分A1、A2、A3三级，模型里面每个A级都会有一些标准，这样的话我们就能够看到每一个团队的敏捷能力是一个什么样子，他是不是在朝着好的一些方面去发展，每个A级都会有一些衡量的指标，可以从不同角度去看它是不是达到了这样的指标。这个有点像一个股票的排行榜，就是你可以看到每一个团队它的行情，它的涨跌是什么样子的，这有点类似股票的这样一个产品，这对于体现一个团队而言是一个蛮形象的东西，由此也能看到整个大盘是一个什么情况，体现整个公司的情况。同样的话，也会有一些个人的排行榜，关于个人的排行榜，到年终的时候都会有大奖的，有一些奖品奖励到同事去更好的实践敏捷。同样腾讯也面临一些挑战，第一个是团队非常多，每个团队特点都不一样，比如规模不一样，应用方法不一样；第二个是产品非常广，互联网上所有的产品腾讯几乎都有，这种多元化的产品它本身产品的研发模式会有一些不一样，那么敏捷、TAPD怎么样去适应这种多元化产品的研发；第三个是敏捷在腾讯也是存在一个过程改进，这样就会存在一些不适应性，针对这种不适应性应该怎么样去做才能更好；第四个，腾讯人员本身的素质也是参差不齐，每年校园招聘大概会招聘1000多个毕业生，这些毕业生从毕业到能上手工作，他们对敏捷的了解，融入到团队中都需要一个过程；第五个是一些长周期的项目，比如QQ客户端，一个版本的发布可能要半年到1年的时间，像这样一个产品怎样去做敏捷开发，也许它就不适合敏捷开发。

ddqhf

看样子，腾讯这个做敏捷还算是做得不错的。有明确的产品经理，有较多的资源保障各项活动的顺利开展。不过有点不太好的，就是一个团队太大了（主要是指一起参加晨会），这样势必会影响开会的效率，开会的时候，容易发呆的同事会很多。像这么大的团队需要采用敏捷的话，可以考虑将团队根据某种原则（比如功能模块）划分成小的子团队，子团队来采取敏捷的方式，而子团队与子团队之间，则通过分布式项目管理的原则来管理，这样的效率会更高一些。

愚人

呵呵，项目大，没办法