腾讯scrum项目案例

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

关于腾讯敏捷框架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反馈平台,在这个平台上可以收集到所有用户的反

相关文档
最新文档