全球最具影响力的数据智能产业服务和职业发展平台

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

千亿成交额背后,京东技术团队的敏捷转型模式

[复制链接]
发表于 2019-7-3 18:28:08 | 显示全部楼层 |阅读模式
1.webp.jpg
导语:本案例主要介绍了京东敏捷转型中的案例:如京麦、仓储开放平台、途牛。并且在最后总结了京东的敏捷转型模式,即一个中心,四个基本点(价值为中心,透明、迭代、反馈、教练四个基本点)。
(全文共4052字   预计阅读时长:4分钟)

案例一 :京麦团队-创造互联网行业无人离职的奇迹
2012年底,有一个屌丝团队,做的产品慢慢被边缘化,客户不满意现有产品,技术负债高,团队马上要被解散去做其他产品了。这个场景听起来熟悉吗?这就是当时京麦团队的处境。
很幸运的是,团队leader旁听了一次敏捷的工作坊,知道敏捷应该怎么玩,也知道了和其他团队之间的差距在哪里。因此京麦团队决定试一试,用敏捷开发的方式进行软件开发,有了想法马上行动。
第一步,组织团队进行敏捷培训,全员知道什么是正确的敏捷软件开发。这是敏捷软件开发的第一步,也是至关重要的一步。
第二步,团队坐在一起,这里团队指的是产品、研发、测试整个团队,而不仅仅是研发。团队坐在一起的好处有很多,比如有了问题,直接喊“张三这个问题我们一起看一下?” 又或者产品和研发正在讨论某个具体的需求,测试人员听到后立刻加入进来,信息快速共享并达成一致。
另外,团队坐在一起还有其他的好处,团队的每日站会更加容易同时一起开,代码评审也会随时随地的发生,任务板上的任务团队更容易更新。简言之,团队坐在一起更容易促成团队之间的沟通,以及信息共享。
第三步,按照Scrum框架的定义,严格地开展每一个会议,如迭代计划会、每日站会、迭代评审会、迭代回顾会以及产品列表梳理会。每一个会议都不能省略。
第四步,Scrum会议坚持开的情况下,团队可以尝试引入已经被证明有效的良好工程实践。如持续集成、结对编程、测试驱动开发等
在坚持以上四步之后,京麦团队达到了如下的成果:
  • 交付周期从之前的12周,降到现在的2周
  • 同时在线的用户数提升了3倍
  • 活跃用户数提升了5倍

京麦团队到现在敏捷转型接近三年,团队也已经拆分成4个小团队,整个团队还是在坚持着使用Scrum的方式,每两周一个迭代,持续交付价值,持续改进。下面是他们团队任务板的一个持续改进图,供大家参考。

在京麦团队的带动下,整个POP团队都已经开始了敏捷转型之旅。
案例二:仓储开放平台-交付效率提升1倍
仓储开放平台团队在人员数量不变的前提下,2015年上半年就完成了2014年一年的任务量,即团队效率至少提升了1倍。想知道这个团队是如何做到的吗?我们一起来看看这个团队的例子。
首先这个团队经理是很开放的一个人,喜欢新鲜事物,喜欢尝试。这是非常好的开端。
第一步,仓储团队的总监找到我们,商量进行大团队的敏捷转型。
这里多说一下,为什么这个团队的总监会找到我们。前期我们(敏捷教练)在POP京麦团队的成功试点,越来越多的团队也想进行敏捷转型。也就是说通过早期成功的样板团队,树立了榜样,也为后期的敏捷转型铺好了路。
第二步,敏捷导入,即进行普及性的培训。上面提到的团队经理和他手下的几个leader都来参加了Scrum Master敏捷训练营的培训。
团队经理听完培训之后做出反馈:“在京东第一次接触敏捷研发管理的思想,是在今年春节前一次公司组织的敏捷培训课程上,听了敏捷教练BOB的授课,感觉这种管理模式既可以改善现有研发工作中的一些问题,又能给团队带来很多新鲜事物,真是我们迫切需要的。于是,在部门领导的倡导下,我们几个三级部门开始了各自团队的敏捷之旅。”
第三步,团队开始按照Scrum进行敏捷软件开发,并且持续改进。大多数团队一开始都会选择两周作为一个迭代周期,因为两周是一个很好的开始点。
第四步,制定了团队规则之后,就要执行。比如“最初开站会的时候,大家都不是很积极,到了规定的时间,很多人还在忙自己的事情,不叫不来。
后来敏捷团队制订了奖惩机制,每天不按时参加站会又不提前请假的,都要扣20块钱作为水果基金。这下大家的积极性提高了,每天参加站会的人也比较齐全了。有一次一个同事因为处理问题,晚来了2分钟,本来是有情可原的,但为了兑现承诺,他主动买了5盒草莓分给大家。”。
另外,回顾会议是非常关键的。“在敏捷回顾会上,大家都要总结上个迭代周期里的工作情况,包括做得好的地方和需要总结提高的地方。会议由Scrum Master主持,每个人会拿到不同颜色的便签纸,蓝色的便签纸上写做的好的实例和总结,红色的便签纸上写的是待提高的事例和建议。在写完总结后,大家会按顺序轮流发言,提出自己的意见和建议,最终汇总到Scrum Master处。每次回顾会,都会让大家获得很多的经验和宝贵的意见,从而提升整个敏捷团队的工作质量。”
在部门领导和公司管理层的支持下,我们敏捷团队鸟枪换炮,从以前传统的墙面看板,上升为触摸电视屏幕的电子看板。怀着激动和感激的心情,我们几个小伙伴瞬时间将高大上的触摸电视和支架组装完毕。

在团队敏捷转型的一开始,为了让大家对Scrum有更全面的了解,团队还自发组织了读书行动。每天固定时间固定地点,团队花30分钟共同阅读同一本书,并且大家会就这一个主题进行讨论。

案例三:途牛-全新项目的敏捷转型
5月8日京东和途牛联合宣布,双方展开深入战略合作。6月下旬,我作为敏捷教练进驻途牛团队,帮助途牛项目一期进行敏捷软件开发的辅导。
针对全新项目的转型,有以下几点需要注意。
  • 第一,需要先梳理出第一版的产品列表(Product Backlog)。一开始我就和途牛团队的8位产品经理进行产品需求的梳理,并且使用用户故事地图进行了产品需求的大概规划。
  • 第二,团队坐在一起。产品研发和测试全部坐在一起。由于这个项目的特殊性,需要和途牛进行频繁的接口测试和联调,途牛团队也安排坐在一起了。
  • 第三,形成Scrum of Scrums(SoS)会议。这个项目有四个团队,跟团游、门票、平台、途牛方。每个团队都有自己的每日站会,固定每天下班前每个团队代表和产品经理一起开SoS会议,同步团队开发中遇到的问题、障碍和风险。
  • 第四,团队坚持Scrum的会议。并不断改进产品和团队一起的工作方法。


京东敏捷软件开发的精髓 :一个核心,四个基本点
一个核心:价值驱动
四个基本点:透明、迭代、持续改进、教练

「一个核心:价值驱动」
不以价值驱动为导向的敏捷转型就是耍流氓。我见过很多团队要进行敏捷转型,而如果你要问他们为什么要敏捷,则答案五花八门:老板的要求,听说敏捷能让我们效率提升,质量提高。也有很多负面的声音,敏捷不适合我们团队,我们公司文化和敏捷不匹配,敏捷就是加班,等等。这些都没有回答到点子上。
敏捷软件开发的精髓就是尽早频繁的交付商业价值(感谢Alistair Cockburn博士)。任何不以价值驱动的敏捷软件开发都是伪敏捷。
以价值驱动,以价值为核心,具体到实践层面要怎么做呢?
我给大家介绍一个非常有用而且简单的工具—产品列表(Product Backlog)。团队敏捷转型,在接受了普及培训之后,第一个要做的事情就是建立一个且是唯一的产品列表。这么做最重要的原因就是需求统一入口。
一个产品只有一个产品列表,并且产品列表要符合DEEP原则,即Detailed Appropriately, Emergent, Estimated, Prioritized.
介绍一下DEEP原则,对应的中文分别是:
  • Detailed Appropriately详略得当的。也就是说产品列表中的需求条目是有粗粒度的,也有细粒度的,不是完全一样的。马上要做的需求,一定属于细粒度的;而1个月后要做的可能就是粗粒度的。

  • Emergent涌现的。产品列表中的需求是涌现出来的。可能在产品开发过程中,用户或开发人员有一个很好的想法或点子,那么我们就把它加到产品列表中去。

  • Estimated估算过的。每一个需求条目需要是做过估算的。只有做过估算,我们才知道它的规模大小,再结合已知需求的价值大小,我们就能判断出这个需求的投入产出比。
  • Prioritized排序的。每个需求条目都有一个唯一的顺序。

「四个基本点:透明  迭代  持续改进  教练」
基本点一:透明。
敏捷软件开发当中最重要的基本点就是,透明。回想一下上面的案例中,团队转型一定要尽量让团队坐在一起,这是保证透明的基础。团队坐在一起之后,团队间的沟通会比原来顺畅很多,信息也就很容易的暴露出来,即团队信息状态的透明。
敏捷转型中的另一个很重要的基础设施是任务板。对于一开始实施敏捷转型的团队,我强烈建议使用物理的任务板。物理任务板有非常多的好处:
  • 团队信息以及团队进展的公开。
  • 每个人每天都需要更新自己的任务,受到同僚压力,团队中滥竽充数的人几乎不存在。
  • 物理任务板可以任意进行重新规划和设计。(相比电子任务板)。

基本点二:迭代。
有些人在说敏捷是什么的时候就说,敏捷就是快速迭代。这个说法有点过于片面,不过也说明了迭代是敏捷当中很重要的一个基本点。
两周一个迭代周期,并且迭代结束的时候一定要交付出潜在可交付的产品增量。这样有什么好处呢?
  • 两周固定的迭代周期,省去预定会议的行政事务,团队可以形成习惯。
  • 两周就会有交付物,相比原来两个月甚至一年才有一次交付物,这是一个极大的提高。

对于软件开发来说,用户能看到(或者使用)产品才是最关键的。因为只有用户看到(或使用)产品,他才可以给出真实的反馈。团队才能基于用户的反馈做出调整,做出用户真正想要的产品。
基本点三:持续改进。
一提到持续改进我就想起一位日本友人的介绍:持续改进在日语中是Kaizen。他跟我们提到1次改进不是Kaizen,10次改进也不是Kaizen,100次改进也不是Kaizen,只有做到1000次改进才能算是真正的Kaizen,即持续改进。为什么一定是1000次呢,他说到只有做到了1000次改进才能养成改进的习惯,才能算作持续改进。
在Scrum中有三个会议可以给团队提供持续改进的机会。
  • 每日站会。每天团队在一起,同步团队整体的进展情况,相互鼓励并改进。
  • 迭代评审会。团队和产品负责人一起回顾一下迭代内的产品增量,以及利益干系人都有哪些反馈。这是一个非常好的改进产品的机会。
  • 迭代回顾会。团队在一起反思,作为一个团队我们哪里做的好,哪里可以做的更好,哪些是我们想要尝试的。回顾会是一个团队工作流程改进的机会。

基本点四:教练。
在我的Scrum Master敏捷训练营培训课上,我会介绍Scrum的三条腿的基础,即透明、检视和调整。在写完第一个基础透明之后,我会问参与者下一个基础是什么。很多次大家会回答,敏捷教练。虽然Scrum的基础没有敏捷教练,但我还是想强调一下对于敏捷转型来说,敏捷教练是非常关键的。
敏捷教练会做哪些事情帮助团队呢?
  • 培训。作为普及性的培训,让团队全员了解Scrum是如何工作的,以及团队需要如何一起工作。
  • 辅导。敏捷教练需要和团队在一起工作,指导他们的Scrum会议。
  • 挑战。作为敏捷教练,需要不断的挑战团队现状,让团队能够紧密的一起工作。另外,敏捷教练还可以把一些新想法、新的尝试带入到团队,并让这些新的内容生根发芽。


本文来自微信公众号“壹佰案例”(ID:Top100Case),作者 Bob Jiang,中国北方第一位CST,电商资深敏捷教练,《Scrum精髓》译者,Agile1001联合发起人。

楼主热帖
168大数据(www.bi168.cn)是国内首家系统性关注大数据科学与人工智能的社区媒体!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2019-11-17 20:09 , Processed in 0.086176 second(s), 23 queries , Xcache On.

Powered by BI168社区

© 2012-2014 海鸥科技

快速回复 返回顶部 返回列表