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

【关注“敏捷开发俱乐部“微信，了解最新开发思想和实践】

以下是一号店基础平台部总监黄哲铿在商派技术沙龙上的演讲实录：

今天跟大家分享的主题是《一号店是怎样做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台马上纠正回来。

（附PPT）

（原文来自商派电商技术沙龙微信媒体）

【关注“敏捷开发俱乐部“微信，了解最新开发思想和实践】