一号店是怎样做Scrum和Kanban-演讲实录

一号店

商派电商技术沙龙 · 2015-08-13 15:09

一号店是怎样做Scrum和Kanban-演讲实录


各位看官等着急了吧,现在我们就把第四期商派技术沙龙的嘉宾演讲实录与PPT分享给小伙伴们,各位小板凳拿好前排就坐,热茶糕点已备好。今天出场的是一号店基础平台部总监黄哲铿,以下为演讲实录:

黄哲铿:

今天跟大家分享的主题是《一号店是怎样做Scrum和Kanban》,我从加入1号店到现在有5年的时间,开始是负责技术研发,最近两年担任PMO总监,主要的工作就是:实施1号店的敏捷、建立大项目管理制度、建立扁平化组织架构等等。

首先跟大家介绍的是,1号店的敏捷发展历程,我们从2013年开始做敏捷,成立了“敏捷专家小组”负责实施敏捷,制定了“敏捷手册”、“敏捷成熟度评估体系”,然后开始进行小范围的试点,第一期是6个团队参与,经过半年的试点和推广,我们成功树立了几个标杆团队,通过组织“敏捷沙龙”把敏捷最佳实践,在技术部内进行分享,增加影响力,吸引更多团队参与到试点中。

到了2014年的二季度,基本上我们的Scrum成型了,我们的敏捷成熟度分为L0、L1、L2,到2014年的上半年已经有几个团队达到L2,成熟度非常高了,L0也已经非常少了,大部分都处在L1上。2014年下半年我们开始尝试Kanban直到现在。

为什么要做敏捷?首先我们来看一个案例:1号店刚上线不久,每天就那么零零星星几十单,有一天我们两个老板,于刚、刘峻岭,在上午的时候突然有一个想法:做一个“每日两款”的促销活动,这两款商品的价格是市场价格的一半,把广告费用投入到商品上,让顾客尝到甜头,口碑相传。有了创意,开发团队马上把它变成了一个产品,上午有创意,傍晚就实现了,我们大概30几个人的团队规模,这个产品上线之后,获得了成功,连续几天的访问量翻了几十倍。可以看到技术产品的快速交付,缩短idea to market的时间对商业的帮助是巨大的。

这是一号店Scrum的执行过程,在需求阶段,我们实行“以价值驱动”的需求管理机制,当需求考虑得比较成熟了,我们就把它放入Sprint backlog,然后是Sprint的每日战会、评审会,这里的评审会有些不太一样的地方,跟业务部门的需求方一起做评审会议,完成后产品马上就可以上线,我们的Scrum里DoD是比较灵活的,可以是上线、合主干、回归测试结束等等。Scrum的迭代周期是两周,但是也有的团队是每周一次,现在无线团队比较特殊一些,因为移动的APP的发布周期基本上是行业里面一月一次,所以它们的迭代周期也是一样的。

实施了敏捷的方法之后,其实是要求我们的组织架构也要随之敏捷起来,我们的组织架构,最初是项目制的,抽调人过来做,做完后被调去其它项目,慢慢我们发现,这个方式做项目是可以的,做产品是不行的,做产品需要的是是一群人专注某于这个领域,人员结构相对固定,所以组织架构就演变成为Domain Team的形式,团队角色包括开发、测试、PD,业务方会作为一个虚拟成员,参与到我们团队里面。团队员有架构师,也是虚拟的,一个架构师对应好几个团队,行业里面也把这个方式是披萨团队,一个团队正好吃完一只披萨,一般9~12个人左右,人太多不利于高效协同。这个就是扁平化架构,当前吹捧得比较厉害的:小米模式、阿米巴模式,核心就是,组织结构扁平化、去中心化。

组织架构的扁平化,使这个团队里面的人有决策权,像1号店、小米这样的公司里面,Domain Team的决定权是很大的,比如说搜索这个Domain Team,它能够决定,哪些商品放在前面,哪些放在后面。为什么他怎么做这个决策呢?诀窍就是,通过数据决策、AB测试,我们是通过“埋点”的方式,在每一个网页放置追踪代码,收集用户的行为数据,分析出每一个小的功能变化对顾客的影响;另外,使用AB测试技术,让10%的用户先来尝试新上线的功能,如果发现这里转化率没有太大波动,就多切换一些流量过来,这是互联网的做法,不断小步快跑,让团队根据市场的反馈快速自行做出决策。

接下来,我们讲一些1号店在敏捷上的一些特色,一个是是“分布式敏捷”,我们团队是分布式的,在上海有一个研发中心,武汉有一个研发中心,团队不是在同一个地方的,是异地开发团队,面临最大的问题就是沟通,既然无法面对面的沟通,你每天开站会怎么办?所以需要一定的工具进行辅助,如RTX、LYNC等等,或者使用电子白板,两个地方的团队成员对着电子白板开站会,最后通过邮件确认。

1号店的敏捷我们还分成种模式:项目敏捷和产品敏捷,比较好理解的是产品敏捷,比如搜索Domain team,主要的工作是对搜索产品进行迭代优化。项目敏捷是相对于产品敏捷来讲的,1号店也会有一些项目,比如说我们有一个项目叫做“网站速度提升20%”,这个是一个大项目,这个大项目涉及了许多开发团队,包括:前台页面、搜索、购物车、商家平台,都要速度提升,我们项目经理是用项目敏捷的方式进行管理,在确认完需求后,会把这些任务分派到每个开发团队里面去,拿搜索举例,他的Sprint中假设能做10个Story,有七个是自己做搜索产品优化的,还有3个是给“网站速度提升20%”这个大项目的,这两种方式是我们1号店最常用的项目管理的方式。

当Scrum做到一年左右的时候,我们就在思考,接下来又应如何提升效率呢?有没有更快一些的方法?更灵活?质量能不能更有保障?所以我们就开始尝试Kanban,这个可能并不能解决我们所有的问题,看看我们做了哪些事情?

首先把需求的粒度从Sprint Backlog变为单个Story,高级优先级的Story可以随时插入,更加灵活,同时也让团队更加关注价值,更懂业务。技术人员都有一个误解,只要把东西很快的做出来就好了,这个是不对的,互联网产品开发里面,开发、测试还有PD,更应该关注的是价值,去思考我做的东西有没有价值?很多业务需求都是屁股决定脑袋的,都是伪需求,不一定是对商业有帮助的,这个更是需要我们思考的。Kanban里面引入了WIP,在制品的限制数概念,可以缩短价值进到系统交付的时间,是加速了端对端的价值交付。通过WIP这样一个方式,我们可以发现,这个团队它的短板在哪?以前我们会忽略这些,比如我们有一个团队,在做了Kanban之后,发现它的每日构建持续集成原来效率很低,但是以前可以忍受,为什么?以前做Scrum的时候上线的频率没有这么高,我们做的Kanban之后,一两天就有一次发布,在这样的情况下,我们原来隐藏的问题就会暴露出来,使我们更容易看到,这个团队到底短板在哪?是工具在制约生产力,还是我们对业务的理解不足,还是协作的问题,这些短板暴露出来以后,有利于我们做下一次迭代中进行提升,这样整个团队的协作能力、成熟度才会更高。

Kanban实质上把迭代变成了更小、更快的开发节奏,Kanban并没有让我们生产力提升多少,是让我们暴露了更多的问题,让我们的交付更快,更细粒度一些,是这样的作用。同时也给团队更大的空间,不再像以前一样,我们要根据自己的产能在迭代中填满Story,在Kanban里面事实上让团队更积极的去思考这些问题,这是每一次我们都在考虑,这个东西是不是真的对我们的生意有所帮助,所以你想想看,以前我们是不会有这么频繁的思考,在Kanban里面是要求更高了。这个是我们实施Kanban以来的对比,上面可以看到两个数字,1.21和4.97,这是我们从有想法到发布的时间周期,之前是11天,现在是4天,效率快很多。

1号店敏捷开发全生命周期,包括产品敏捷、项目敏捷等、需求池管理等等。一个创意出来之后会进到我们需求池,我们的需求池的管理也是1号店的特色,我们是基于价值驱动的需求的管理,五六个业务部门都会给我提需求,大家通常的做法是什么呢?谁的官大我听谁的,谁的声音响我就听谁的,或者说你们吵好,告诉我结果,但是这样对生意是有害的,你会发现,如果长期以往这样做下去,技术部会变成一个代码工具,你没有价值,这不是我们应该得到的一个结果,因为搞IT的都是理工科出身,都是智商比较高的群体,所以我们更应该思考业务,我们要建立以价值为导向的需求的管理体系,这个体系我们让每一个提需求的人想到它的价值,价值是什么呢?提升我的销售额,这也是价值,提升顾客体验,这也是价值,价值还是要量化的,比如说我们如果是后端的系统,怎么让我原来五个人做的事情变成两个人做,这是效率,这是可以衡量的效率,我们来建立了这样的需求管理体系之后,我们会对每一个需求进行价值考核,因为价值都是业务方去提供的,我们也会参与其中,我们保留了一个什么权力呢?秋后算账的权利,开始可以任意提,我这个需求可以让销售额增长300%,肯定会这样的,想让它的需求优先级高,所以会这样提,需求上线后,我们有一个验证的时效,可能是两个月、一个月就要有一个验证,到那时候我们会对它的信用进行评定,每一个业务方,我们以部门为单位,每个业务方到每季度都绘出一个排行榜,信用价值排行榜,这是排行榜的力量,排在最后的几个部门的头就很不高兴了,你可以告诉他,要么你看看排在第一第二的老大是怎么做的,所以有这样的一个体系,使大家思考我们价值,我们到底提出来的东西是有没有价值,技术团队对公司来说是很大的成本,我们如何把这些有限的成本投入到价值最高的这些产品上,所以这个是非常重要的,相信大家可能都是在公司里面做技术管理的,你们往后也要往这方面去思考,到底我们做的这个产品是为了让老板高兴,还是让公司具备更高的价值?

接下来讲一下Trident,这是基于大数据驱动的开发平台,我们这个系统是从需求有想法开始就录入这个系统,这是PD录入,也可以是业务方把自己的想法录进来,这时候我们有一个处理时效,一般是两天一定会给回复,是受理还是打回,这个需求受理时效对业务部门来说特别重要,以后我们就看这个时效,这个时效是考核PD的,业务方提的需求有没有及时跟进,有没有受理,在整个过程中,我们每一个阶段都会去收集需求,都会去收集这个数据,这是需求阶段的数据。在项目管理也是一样,我们会从整个项目的风险,项目的复杂度,像刚刚我们讲过,项目敏捷和产品敏捷,大家应该注意到,在项目敏捷里面,我们的协作是很复杂的,有很多的依赖,像1号店这么大型的电商系统,我们是基于SOA开发的,各应用之间是有依赖的,在这么复杂的项目管理里面,我们会有一个依赖管理的模块,会把这些项目里面的依赖,都维护到系统里面,就可以从这里面发现很多问题,可能是技术架构的问题,可能是组织架构的问题,我们就可以从这里面深挖我们很多的改进品。

我们Kanban和Scrum用了一些插件,也有二次开发在里面,Trident这个产品1号店投入了六到八个人的开发团队,做了一年左右。包括在自动化测试、自动审计,这些方面我们都融合进了系统里面。Trident里面还做了一些插件,能够方便的登记工时,相信很多企业里面都很头疼,我开发做了什么,每天都要登记工时,在Trident里面做了无缝的衔接,可以实时搜集这些数据,项目经理每天从这里可以看到,它还具备预警和风险控制这样的一些功能,会提醒项目经理,项目敏捷里面,哪些团队有评估风险,历史上BUG率是多少,这个在这里都有,所以我们的项目经理可以非常方便的去做管理,其实上到CTO,下到每一个开发的这些同事,它们都能够有一个非常清晰的视图,看到自己权限范围内应该看到的数据,可能对CTO来说,只要看一个宏观的就行了,现在做的几十个项目,60几个敏捷团队,它的工作的健康度多少,我们自己也建立了度量体系,衡量一个团队是不是健康,是从多方面的,你的代码质量有没有问题、你的成本控制的如何、KPI完成的怎么样、每个团队都有KPI。比如,搜索团队背的KPI是搜索的转化率,我们技术团队也是要背一些业务的KPI,这个不是销售额,是我们力所能及,能够改变的KPI,这个是促进技术和业务的融合。

Trident可以实现自动化发布、一键发布,以前我们发布都是有运维的同事,手工操作,把代码传到服务器上,现在这些手工的工作全部用我们Trident代替。测试、发布都在这个系统里面自动化执行,只要提一个上线申请单,测试同事确认测试通过,,然后SA就会把这个单子放到自动化发布的队列里面,有些应用是白天可以上线的,有些是晚上可以上的,这些都是系统设置好的的,发布完成之后系统会触发自动验证,有一些测试脚本会在线上跑,一般这个时间点我们是在凌晨2点到4点,验证的时间是从4点到6点,所以即使有问题,我们开发的测试在第二天醒来的时候,6点或者7点的时候,会收到短信或者邮件提醒,验证失败系统就会自动回馈。

所以我们现在的整个开发和发布,这些过程都是相对于以前,以前我们发布是很痛苦的,所有的人都留下来,当时是一两百人的规模,所有人留下来,发布成功了所有人回家,不成功所有人都要加班,是这样的状态,现在幸福很多了,发布对我们来说不是一个事情了,质量对我们来说不是一个事情了。

刚才讲到了,我们的报表体系对我们的整个开发生命周期里面做数据的搜集,做完数据搜集之后,就会有这种深度的挖掘,我们有一些做数据挖掘的同事会帮我们做一些算法,举一个例子,能挖掘出一些非常有意思的事情,我们发现一个规律,周三下午和周四下午请假的员工,基本上80%下个月就会离职,这是有道理的,一般周一周二开会比较多,周三周四请假比较方便,周五好像也不太方便安排面试,所以从这个数据来看,结合我自己的经验看了一下,我觉得有道理,这个很有意思。

Trident是开发治理平台,可以说是开发管理的ERP,建这个系统的初衷是想让我们所有的这些开发的工作都在系统里面,包括需求提出,以及后面对整个项目的数据的分析和总结,都在这里面,对项目管理也有一些帮助。敏捷也可以直接可以看到燃尽图,包括Kanban,对于不同纬度不同层次的人来说看到的程度是不一样的,老板只要关注公司里面最大的几个项目的进展是怎样的,只要关注这些,其他小项目就放权到下面去决策,这个是扁平化的方式,领导只会关注20%的对公司价值最大的这些东西,更大量的80%的这些决策我们都是放在团队上面去做。

复杂项目的依赖,这几个图是我们系统里面的截图,包括工时分析,哪个部门花了技术部百分之多少的开发资源,需求达成的价值情况是怎样的,达成率是多少?大致就是这样的。Trident和敏捷实施下来,我们怎样让技术部的产能不断释放,能够让技术团队发挥最大的威力,对生意的增长做出贡献。以上就是我今天想跟大家分享的内容。谢谢大家。

提问:感谢您的分享,非常感兴趣的是你们发布速度为什么这么快,我们公司项目还算比较敏捷的,您举了一个个例,公司老总上午有创意,下午就可以发布,我们公司对客户的发布,我们流程是要先测试,然后再发布,在发布之前做需求的时候,还要了解一下用户的满意度,我就是想了解一个,这个是一个个案,还是平均大概都能做到这么快?这么快是因为当时的规模小,还是规模大了以后还可以做到这么快?这么做会不会有风险,比如就卖金龙鱼,当时说促销就是在网上放500桶的量,由于产品发布的特别快,可能测试,我们是在STG上做测试,之后再到产品集上去发布,没有这儿快,是不是有风险,比如说当时只卖500桶,忽然卖了1万桶,对这个风险怎么控制?

黄哲铿:很好的问题,是这样的,为什么这么快?这个原因就是行业要求这么快,不快会死,我们在流程上和方法上怎么能够做到快?即使是我们现在,我们仍然能够做到上午一个创意,到晚上可能就被发布,但不是所有的团队都像以前那么快,因为我们架构现在已经非常复杂了. 1号店这么快的速度,我们要付出代价,代价是什么呢?我们是去牺牲质量的,不会有超卖的情况,近年来1号店很少会出现这样的情况,这是另外一个问题了,这是我们1号店多维度立体化的价格防呆体系,这个可以稍微讲一讲,比较有意思的,我们这个从后端设置,我们用价格举例子,原来想卖60块现在卖30块,这个在1号店后台要经过三层审批,即使大家都是闭上眼睛,审批都通过了,也没关系,我们在前台展示的时候还会有另外一条防线,会根据历史的价格,根据用户购买量,原来每分钟就是5、6单,突然变更每分钟变成500、600单,这时候系统就知道有问题,这些订单系统会把它放在待确定的订单,这些要经过手工确认的,这是业务层面的,有点偏主题了,但是这个是蛮有意思的东西。我们在开发方面,会牺牲一些质量,这些质量是说,我的产品有瑕疵,我们刚刚举的例子,我们在做每日两款的产品里面,用户可能要通过五个操作才能买到这个东西,但其实对这个产品来说,我们原来优化到极致的话,可能是一键购就可以买,这个就是我们牺牲下来的质量,我们牺牲了用户的一些体验,牺牲了可能有一些代码上的后续可扩展性,这些肯定会有一些受限的,但是为了商业,所以我们是更看重这个的,对于商业来说,时间成本是关乎生死的。

提问:一号店实现了快速的迭代发布,一个是从管理上入手,管理流程要特别敏捷,还有就是可以适当的牺牲产品的质量,包括第二版、第三版弥补小的BUG。

黄哲铿:对。

提问:比较感兴趣Trident系统,你们是SAAS使用还是开源?

黄哲铿:SAAS。

提问:看你们整个系统都有,上线是不是要根据各家公司自己的环境?

黄哲铿:这块我们不会这么快开忙出来,这块要做,一定要进到数据中心里面去的,在部署上,比较难实施SAAS的。

提问:现在能开放的模块是哪些?

黄哲铿:敏捷还有项目管理,还有报表系统,数据挖掘,数据分析这些东西。

提问:包括离职什么的?

黄哲铿:这是特殊的例子。

提问:这个现在有域名吗?

黄哲铿:稍候再发出来。

提问:刚才听您讲Trident整个效果的时候,我的感觉是近乎完美,实施的时候肯定会遇到一些问题,之前有没有遇到一些问题?

黄哲铿:这套系统开源出来给大家试用会有一些问题,有一些是针对互联网企业和1号店做的。比如EPIC这个概念,如果你不会使用是不行的,我们花了那么多钱,这么多人研究这个体系,这个体系是不是能够给业界,在效率方面有所提升,扩大我们的影响力,我们是本着这样的想法开放的。

提问:比较感兴趣是业务部门的信誉,业务部门最后的需求的评估,具体来说在你们组织里面是哪个角色来做的?怎么做的?

黄哲铿:这是什么?

提问:业务效果。

黄哲铿:开始业务会提一些可量化的目标,这些目标是在技术部是PD的同事,或者我们有内部的把关,这两个角色都可以做,达到验证的时候需要证据方提供证据,这种证据在一号店比较容易,我们很多管理都是数字化的,你说你的销量要增长300%,我三个月后就可以直接拿数据来看了。

提问:你们的团队人员比较稳定,还是会经常变的?

黄哲铿:相对比较稳定,我们也会有一些机制,不断评估他存在的必要性,这个评估是每个季度做一次的,像互联网行业,尤其是电商行业的业务特点是变化比较快的,历史上1号店做的很多东西,有些东西你们还没听说过,在我们内部就已经被PK掉了,就已经结束了,我们会审视在我们开发资源的利用率是多高。

提问:有两个问题,现在大家都是比较倾向于敏捷开发,因为它能给我们企业降低很多开发的成本,给我们带来高效的工作,我们正在做这方面转型的探索,一个很低级的问题,请问一号店是怎么样培养具有敏捷开发的人的?用什么东西限定这些人的发展,或者控制他们能力的方向?这个是倾向于哪个方向的?

黄哲铿:有一点敏捷是不能降低成本的,敏捷还是增加成本的,但是结果是什么呢?结果是技术跟业务融合度更高,我们做的事情更容易促进生意增长,这是核心,我们对于像1号店这样的公司会比惠普幸运一些,我们没有很多的这些固有的流程,1号店是很年轻的公司,2008年成立,我们2013年开始做敏捷,我们之前有一些迭代的概念,然后我们开始接触敏捷、实践敏捷,我们其实还是比较拥抱变化的,是没有什么历史包袱的,所以在这个转的过程中,没有很多痛苦,我们在营造这个氛围的时候从几方面做的,一个是敏捷小组,专家成员的小组,有教练在带的,另外一个,我们会举办敏捷沙龙,敏捷沙龙里面敏捷团队里面相互交流,参加的人可以是其他没有做敏捷的这些团队感兴趣就来听,事实上我们的经验,敏捷沙龙里面参加的越积极的,在下一次的试点里面越踊跃的报名想做敏捷,慢慢就会形成这样一个氛围,大家觉得敏捷就是好,我就是要去做。

提问:您的意思是说兴趣导向吗?

黄哲铿:对,也要营造这样的氛围,人里面可能10%多的人是真正有自己想法的,80%的人都是随大流的,百分之几的人是极力反对的,大致是这样的。

提问:你们是个电子商务网站,可能在4点发布的时候已经产生订单,用户已经支付了,这个数据怎么处理?

黄哲铿:这跟系统的架构、技术架构是有关系的,我们设计的这个系统,设计的这些应用,应该是向下兼容的,回退到上个版本,对数据是不影响的,为什么会有这个要求,我刚才也提到,我们是大量的在做这种AB测试,会用小范围的用户10%的尝试一下新功能,所以为什么把权力下放,自动回滚,就是因为这个因素。最坏的情况下,我们的质量极差,上线的时候会造成宕机,这也没关系,比如说搜索,搜索这个功能我们有几十台集群的机器,这只是举个例子,有这么多的机器,这么多机器是逐步验证,逐步的发布的过程,我先把10台下线,在10台下面发布,验证之后推到正式环境没问题,逐步的做,这个都是自动化发布里面的一些策略,就算失败也可以把这10台马上纠正回来。

是不是还意犹未尽,接下来的干货大餐会陆续奉上,敬请期待!


商派电商技术沙龙(shopex-salon)

 查看原文  分享到微信  文章为作者独立观点,不代表大不六文章网立场
shopex-salon
用于商派电商技术沙龙参与人员技术交流及干货分享使用。
最新文章