构建发布 腾讯:敏捷企鹅的创新功夫

liuxue.gu@hotmail.com · 2012年04月17日 · 2 次阅读

2011 年 6 月 24~25 日,敏捷实践者的盛会 Scrum Gathering 大会在上海召开,此次盛会云集了传统行业和互联网行业的众多知名企业,如百度、支付宝、SAP、爱立信……来自于腾讯的嘉宾们也带来了腾讯 6 年敏捷实践的精华——创新的敏捷实践,结合着腾讯实际业务,故事性的展现了各项实践的由来和价值。腾讯公司敏捷教练&高级项目经理艾永亮在本次活动中分享了腾讯在敏捷探索中的六项独特的实践:

本文将回顾一下其中最为吸引人的关于如何做到极速开发的几项实践。

2009 年最火的游戏 QQ 农场,一周最多发布 23 个版本,它为什么需要如此之快的开发速度呢?由于农场玩法非常简单,必须要持续推出新的玩法,新的作物,才能让用户被长期吸引在这里,因此 2 周已经太慢了,必须要更快的速度才能满足用户。

那么它如何做到的呢? [attach] 1777[/attach] 创新实践:自运转团队

早期的农场项目,大家的压力都非常大,为了能提高效率,项目经理希望每个角色都能全力以赴的提升自己的效率,于是自己承担起来大量沟通和推进的工作,那个时候的感觉是大家都在被 PM 推着走,一旦 PM 休假,项目基本没有什么产出,当时去了以后,发现问题很严重,觉得团队的主动性必须被调动起来才行,但是大家都已经习惯了了现有的工作方式,短期内很难到达自组织团队。更加思考和一段时间的尝试,我找到一个中间阶段 “准自组织团队”,我们管它叫 “自运转团队”。

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

借此团队的主动性和合作性明显提升,一次女生节活动,早上提出想法,下午 6 点就上线了。

如果再能配合上一些其他实践,例如任务墙和版本墙(两种创新的故事墙),以及多种团队建设方法,团队的整体效率以及默契程度会有进一步的提升。

创新实践:发布汽车

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

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

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

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

创新实践:灰度发布

腾讯很早就提出灰度发布的概念,简单说就是,将一项业务不是一下发布给所有用户,而是分批分期的发布,目的有两个方面,一是减轻服务器压力,二是期间可以在小范围收集到用户的反馈,如果业务出现问题,不会让大范围用户受到影响。

随着经验的累计,我们有了许多种灰度策略和方法,灰度也有了更多的应用,甚至引入到了测试环境,即选择一些热心用户,将功能首先发布给他们,通过他们的使用,来帮助我们进行一些现网测试,这使得一些难于模拟的测试场景变得简单,测试人员的压力大大降低;更重要的用户是最好的测试人员,测试结果更加真实;同时他们也享受到了优先体验的特权,可谓一举三得。

http://djt.open.qq.com/portal.php?mod=view&aid=209

很多公司都会把自己的产品让少部分用户试用,从而收集意见和反馈。。。。这不是腾讯首创的

原来灰度发布的原创在这里

作者:enki_ding 转自:http://enki-ding-yeah-net.iteye.com/blog/1114565  灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB test 就是一种灰度发布方式,让一部用户继续用 A,一部分用户开始用 B,如果用户对 B 没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到 B 上面 来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。   Gmail Labs 是一个新特性橱窗,用户可以自己选择一些未正式发布的新特性进行体验,不喜欢可以关闭,在这个过程中,吃了螃蟹,也当了 Google 的小白鼠。   这个做法比传统的灰度要高明很多,更加尊重用户:   1、它没有强 X 用户,用户是否愿意当小白鼠完全自愿   2、新特性不是打包在一起的一个大版本,可以选择某几个喜欢的螃蟹尝尝   3、螃蟹不好吃可以扔掉,不用硬吃进肚子里引发肠胃炎   当然这些好处也是有代价的:   1、要开发一个 labs 平台实现新特性上架、独立尝试的功能,这可能要改动 Gmail 的前后台架构   2、新特性要按照一定规范来写,才能发布到这个平台上,可能会增加一些工作量   3、小白鼠用户增多之后,对系统的压力可能会有一定提升,因为没有用户调用的界面都不一样了   既然 Gmail Labs 能够顺利发布,那么说明对 Google 来说,以上这些问题都不算问题。另外,现在展示的新特性,都注明了开发者的名字,那么,Gmail Labs 可能会开放这个平台让外部开发者也能提交特性?这倒是很 open 的一种开发模式,非常适合 Google 的 web app 产品线。   互联网产品有一个特点,就是不停的升级,升级,再升级。我所在的项目组,基本上保持每周一次的发布频率,系统升级总是伴随着风险,新旧版本兼容的风险,用户使用习惯突然改变而造成用户流失的风险,系统 down 机的风险.....   为了避免这些风险,很多产品都采用了灰度发布的策略,其主要思想就是把影响集中到一个点,然后再发散到一个面,出现意外情况后很容易就回退。   很长时间,我们都一直在改进搜索引擎的排序算法,尽量让最好的商品出现在搜索结果的第一屏。我 们尝试了很多中算法,不断调整各个排序因子所占的比重。但是我们无法确信我们的排序结果能满足所有用户的需求。所以我们采用了灰度发布,选取几个一级商品 类目,在其中应用不同的排序算法,比如在女装类目中,我们把卖家信用所占的比率调整到 60%,在珠宝类目中,我们把销售量所占的比率调整到 60%.. 然后发布出去,收集用户反馈,最终选择一种大部分人认为好的算法。   QZone 是另外一个采用灰度发布的例子。大家都知道,QZone 在过去的一年中改进是巨大 的,从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。其中经历了大小无数次的发布,他们的发布也都是采用了灰度发布的策略,用户数据的升级并不是大 面积的一次性升级,而是通过一个用户升级标志服务器,如果用户数据没有升级,后台会把此用户的数据逐步迁移到新版本上,然后将升级标志位置 1,升级过程 中,用户仍然可以访问旧的数据,升级完成后的访问都将转发给新的版本。   QQ 的很多产品发布都采用灰度发布,有些是抽取部分 QQ 号段升级成新系统,然后根据用户反馈再大范围升级。我们的产品大部分也是采用灰度发布。

需要 登录 后方可回复。