京东技术团队的敏捷转型模式

2012年底，有一个屌丝团队，做的产品慢慢被边缘化，客户不满意现有产品，技术负债高，团队马上要被解散去做其他产品了。这个场景听起来熟悉吗？这就是当时京麦团队的处境。

很幸运的是，团队leader旁听了一次敏捷的工作坊，知道敏捷应该怎么玩，也知道了和其他团队之间的差距在哪里。因此京麦团队决定试一试，用敏捷开发的方式进行软件开发，有了想法马上行动。

第一步，组织团队进行敏捷培训，全员知道什么是正确的敏捷软件开发。这是敏捷软件开发的第一步，也是至关重要的一步。

第二步，团队坐在一起，这里团队指的是产品、研发、测试整个团队，而不仅仅是研发。团队坐在一起的好处有很多，比如有了问题，直接喊“张三这个问题我们一起看一下？” 又或者产品和研发正在讨论某个具体的需求，测试人员听到后立刻加入进来，信息快速共享并达成一致。

另外，团队坐在一起还有其他的好处，团队的每日站会更加容易同时一起开，代码评审也会随时随地的发生，任务板上的任务团队更容易更新。简言之，团队坐在一起更容易促成团队之间的沟通，以及信息共享。

第三步，按照Scrum框架的定义，严格地开展每一个会议，如迭代计划会、每日站会、迭代评审会、迭代回顾会以及产品列表梳理会。每一个会议都不能省略。

第四步，Scrum会议坚持开的情况下，团队可以尝试引入已经被证明有效的良好工程实践。如持续集成、结对编程、测试驱动开发等

在坚持以上四步之后，京麦团队达到了如下的成果：

• 交付周期从之前的12周，降到现在的2周

• 同时在线的用户数提升了3倍

• 活跃用户数提升了5倍

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

在京麦团队的带动下，整个POP团队都已经开始了敏捷转型之旅。

仓储开放平台团队在人员数量不变的前提下，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会议。

• 挑战。作为敏捷教练，需要不断的挑战团队现状，让团队能够紧密的一起工作。另外，敏捷教练还可以把一些新想法、新的尝试带入到团队，并让这些新的内容生根发芽。