和京东等公司的大牛一起说说敏捷那些事儿

软件研发周期出现过如瀑布模型、螺旋模型、演化模型等多个开发模型，而在中国，客户要求、市场竞争、公司发展等方面的压力促使大多数软件研发项目都有一个共同追求，那就是快。

为了满足“快”的需求，敏捷软件开发模型在中国成为一种趋势，百度等企业的敏捷方法论树立了一个标杆，有越来越多的企业开始进行敏捷转型。然而，转型意味着变革，对已经拥有成百上千人研发团队的企业来说，施行敏捷转型需要更大的决心面对更大的阻力。

在每年TOP100SUMMIT全球软件案例研究峰会上，都会有来自国内外一线互联网企业分享自己的经典案例。2015年，京东、中兴、鼎桥通信等企业分享了自己的敏捷转型心得，壹佰案例经过整理，将各企业敏捷转型的核心要点进行汇总，为准备进行敏捷转型的传统团队提供一份思路。

对于一个公司来讲，任何时间都是可以进行敏捷转型的。

敏捷转型是相对于之前传统的开发方式而言的，而现在许多广为人知的方式方法，比如每日站会，（实际上）就是敏捷当中的一种实践。

除了客观条件以外，其他条件比如领导的支持也非常关键，否则敏捷转型很难走到最后。

然后再有比较积极的喜欢新鲜事物的同志或是希望更多了解敏捷的同志来支持，这样由上而下，由下而上相互结合，敏捷转型就很容易了。

首先从整体来说，通信行业这两年已经发生了很多变化，包括SDN和虚拟运营商运作之后，传统通信行业都在转型，不管是走上政企，还是终端那部分，都跟市场结合越来越紧密了。这种情况下业务会反过来倒逼转型。

第二个层面算是从下往上的层面。以做平台为例，平台确实跟市场隔得比较远，但是作为一线人员，有很多问题要解决。面对数不清的问题，需求支持、人才培养、对方参与等等，有问题就要考虑解决，所以这方面也提供了许多动力。

如我今天的分享，这是个一线团队，整个过程没有提到所谓价值，因为刚才说到那是从下往上的，需要组织的调整才能感知得到。当没有感知到的时候，一线人员并不是等在一边，而是一样有很多问题可以解决，一样可以选择不同的方式来调整做法，这也会产生一些动力。

我们把这两个动力整合起来的时候，自然会形成一个强大的力量，局部带动全体，全体影响局部。

推行敏捷要与企业生态相结合。

我的团队现在有一百多名成员，可能还算不上大型。从战略上来说，推行敏捷还是要问一下自己为什么要推。互联网的创业公司是不做不行，但是传统公司并非如此。

那么到底为什么要推，还有推到什么程度是适合这个生态的？我们刚开始只是项目级的敏捷，还没有到版本级或产品级敏捷，但是要不要推到全敏捷？

比如我们对外还是一个大周期，可能是六个月九个月的交付，但是对内是迭代的，且周期也偏长，约是一个月迭代转给测试，但是这个客户不可见。理论上说它可能不算纯敏捷，正常的话应该发布到客户那边去，但我们的客户——中国移动不需要。

即使我们每个月给一个版本，他也不可能每个月跑来跟我们升级。我们发半年版本，他可能也只是评估一下，某些要开通新业务的上，其他保持不变。

推行敏捷还是要和企业生态结合起来，不能硬推所谓百分之百的敏捷；还有要根据切入点（确切来说是痛点）进行切入，否则敏捷就很痛苦。如果（公司的发展）没有敏捷也可以，那么强要实行敏捷就没什么意义。

很多企业可能面临这种困境因此对敏捷望而却步。通常认为小项目小团队的互联网创业更适合敏捷，但是我们从几个角度看：

第一，我们可以自己摸索出一套项目级敏捷或产品级敏捷的思路，通过SOS这种方式把整个项目协同起来，让大项目像小项目一样进行协作，进行快速的交付和迭代；

第二，不仅要重视敏捷的形式，更要注重它的本质。因为形式可能是一种scrum，本质更多是一种“我让团队更好”的意识。比如消除团队的浪费（大型企业中有非常大的浪费），我们通过敏捷的思想识别浪费，以更高效有序的工作，也就是利用敏捷思想的本质，使整个研发团队更顺畅；

第三，要单点突破。大型项目方方面面细枝末节非常多，如果骤然全面运行敏捷，一定会碰到很多问题。敏捷的本质是为了更好地交付，任何为了敏捷做敏捷都是伪敏捷。

对一个项目，特别是大型项目来说，敏捷是否成功，是否合理，首先要看它是不是对交付有帮助。基于这个思路，我倡导单点突破，找出大型项目中需求分析、妨碍设计、编程、测试等方面的痛点，然后进行梳理。

敏捷体系实际上是一个关联性非常强的体系，某一点突破之后很多其他的关键点其实会被迫跟着突破，所以单点突破之后以点带线全面开花，效果就会比较明显。

此外，单点突破之后很容易形成小步胜利，一旦小步胜利，无论是团队外在的干系人，也就是领导人，还是团队本身，都能够获得信心。这个时候引入另外一个项目就很容易开展下去，也很容易取得成果。

总而言之，推广敏捷的经验是，第一采取Scrum of Scrums方式，第二更注重敏捷的内涵和本质，第三强调单点突破。

如何在团队中推动敏捷文化？这是目前很多公司或项目推敏捷碰到的困境和难点，外部教练在的时候运作的很流畅，教练一撤马上打回原形。

其实任何一种管理的流程或习惯都是有惯性的，我们引入敏捷，改变以前的工作方式和流程。虽然之前的有问题，但员工已经习惯了，所以只靠外力很难改变。

我的观点是第一，要推拉结合，既有一些外力去推，去指导他们，也有一种内力去拉，去吸引他们，让他们看到敏捷实施之后的益处，或相似的团队做了敏捷之后的变化。

第二，我特别强调团队的造血能力。就是当敏捷影响团队的时候，我们很容易识别出团队中的同盟者，与他进行沟通、甚至洗脑，让他自发地认可敏捷并且做一些事情，然后他再去影响更多的人。

实践中我发现，绝大多数团队在敏捷面前都是三三分：三分之一的人反对，三分之一的人支持，三分之一的人打酱油。我只要把敏捷的支持者吸引过来，让他们主动做一些事情，自己接受敏捷的价值观，并且按照我的方式思考和解决问题，就很容易把其他人带动起来。先带动中间三分之一的人，而后三分之一只要轻轻一推，制定一个流程就把他们引过来了，这样阻力也会小，他们自己也会容易成长起来。

这就是所谓的造血能力，也是敏捷的关键和根本。不是简单的把敏捷的概念和做法灌输给他们，而是让他们去做，这样才能有比较好的效果。

京东一个中心四个基本点的敏捷模型（一个中心四个基本点：就是价值为中心，透明、迭代、反馈、教练四个基本点。）

这是我通过京东一些案例总结出来的一种敏捷转型的模式。但是从某种程度来说，所有的模式可以说都是错误的，模式在真正应用的时候，要根据实际的情况去做调整。

“一个中心四个基本点”大致是这样的：

一个中心是以价值为中心，就是团队的输入或者说需求，这对于一个团队特别是研发团队非常重要。需求一定是要把握清楚，并且要能够列出明显的顺序，这样才能够保证团队每时每刻做的都是最重要或价值最高的事情。

四个基本点对应价值为核心，进一步体现团队所做的事情是有价值的。

第一个基本点——透明。

在传统的软件开发团队中很多事情是不透明的。举个例子，我们经常说一个软件项目的进度是50%、60%、70%，哪怕到90%，它其实也不是最终完成的。

我们会用任务板的形式把团队整个进度展示出来，这样团队、经理层、需求发起方都能够很清楚的知道团队的进度是怎样的。

第二个基本点——迭代。

在软件开发的敏捷过程中，一个重要的特征是迭代。尤其现在，很多做转型的团队都在说小步快跑，是指用一周或者两周的时间作为一个迭代的周期。在这个周期结束的时候要有产出——要拿出一个真正可以操作的软件，而不是一个文档或者一个设计等。

第三个基本点——反馈。

有了真正可以操作的软件之后，把它拿给用户（最终使用这个软件的操作人员）或客户（给我们埋单的人），由他们来使用这个软件，最终提出一些反馈。我们就知道这个软件的下一步应该怎么做，应该怎样去迭代，怎样去修改。

第四个基本点——教练。

所有敏捷模式是在敏捷庞大的体系中抽取非常重要的一部分，整个敏捷转型还需要有一个教练。不管是团队内部的教练还是从外部引入的咨询公司，这个都是有必要的。

践行敏捷更适合物理工具

践行敏捷方法最好的工具是物理的，比如任务板的方式。我们用一面墙，团队根据自己的需要划成不同的列，去跟踪每个需求的进度。

我个人不是很推荐电子的方式，因为物理的方式基本可以解决很多的问题。

实践方法层面我比较推荐用户故事地图的方式。一开始我们在梳理需求列表（产品列表）时，要找一下哪些是最基本需要做的，我们称为（MVP），就是我们第一个迭代或者第一个版本要做的事情。

用用户故事地图的方式可以很好地梳理出这些需求之间的依赖关系，然后打通一个业务的闭环，团队在做的事情就会很有关联性，最终能够产生出价值。

统一团队从需求提出到需求印证完成一个交付的闭环。之所以会体验差是因为彼此之间角色放在一起干扰很大。这是最直接的问题。

举个例子，在统一团队有测试、研发、设计，各自专注于自己的特性，实际这三个角色目标是不一样的，放在一起相互干扰更大。于是我们做了操作上的改变：首先，刚开始我们只有研发人员，他们具备了需求、研发、印证这三者闭环的能力。所以我们只采取如下行动：

第一用集团讨论辨明需求；

第二管理者收集来自外部的需求，形成一个纯需求的管理者，他也具备了需求能力；

第三自动化印证。最初我们通过降低门槛让团员能够快速接受自动化能力，具备这种能力以后则要求交互的时候必须有自动化用力，这样团队具备了闭环能力。

怎么样让测试团队具备闭环能力？

我们让一个研发管理者去做测试的管理者。因为研发管理者经过锻炼以后具备了需求闭环能力，同时也具备研发闭环能力。他加入测试团队，让团队快速闭环之后，实际上让两个团队进入了自己内部的高效循环。

培养全功能和弹性团队。

第一点，让团队具有弹性。弹性就是可以将工作拆的够小。比如说一个人的工作有两天时间，我们可以评判这个工作可不可以在两天以后再做。

第二点，培养全功能团队。提出的需求只要有人空闲他就能顶上去。

统一团队做了400个测试用例，发现大量缺陷，研发解决了大量缺陷，中间是没有干扰的。测试将缺陷提给研发的时候，研发会自己判断要不要解决，真正紧急的、急迫的（缺陷）测试团队已经定位出来，对于重要但是不紧急的（缺陷解决）可以有弹性，因为时间（拆分）够小，可以做完之后找一个人过来替，这样在交互工作的同时也解决了大量的缺陷。

而且两个团队聚焦不同：研发团队聚焦简单、量大，而且快速，测试团队则关注专业、集成、质量；这位管理者让我们项目的功能、质量这两个维度的需求都闭环，以此让项目效率得到极大的提升。

这也是我们在这个过程中打破决策墙的策略，可能不是直接的打破，但万事俱备，他们会更加主动踊跃。比如测试团队管理者认可之后，和测试团队的沟通会增加，研发如果具备自动化能力测试，也可能增加交互沟通，对象甚至包括对外部需求方。

这种方法显然促进成员有想法打破部门墙并接触外面的社会。

敏捷客观上是一种经验性方法论。当面对未知境况的时候，试错的方式是非常适合的。而对确定性很强的那种行业则较明显，对通信行业来说，过去我们很熟悉，而现在整个局面发生变化，包括互联网往通信行业走向，未来会怎样现在难以断言，但值得尝试。

这个情况下它是比较适合向敏捷靠拢的，你未来发生变化，跟以前不一样了，包括运营商也得变，那么设备上自然也要变化。

而从团队层面来说，随着通信行业的变化，它的行为一定会影响组织调整，这个时候团队也要面对这个问题，它要尝试新的方法和做法，也适合引入一些敏捷的做法。

严格来讲，对于一线公司，很多时候不提出敏捷这个词也没关系，因为面对问题，尝试解决，尝试改变，行为上就是一种敏捷了。这个词本身相比之下反而不那么重要。

在转型当中我们需要把更多人卷进来，而这个时候敏捷教练是非常重要的。

敏捷教练应该怎样使用才是最好的，应该说中兴正在摸索。以前我们起步（某件事）可能始于一个团队，团队管理者有心思就可以。但是现在，我们一个项目（的成员）动辄几百人，一个团队的模式已经不适用。

多个团队如何引起来？组织上的变化很重要。

我们尝试引入一些模式：把纵横两面结合起来：纵即业务团队，各个小团队要完成业务这是毫无疑问的；横即测试整合，比如测试植入团队，测试支持应怎样发展。

实行敏捷scrum master往往是驱动者之一，对他们来说分散的话肯定不够，那么能不能把他们横向构成很多组织，这其实已经引入了实践社区的概念。

纵横结合就是以业务为主，同时横向把小组拉起来，优先发展一部分教练。这种策略其实源于大家最开始共有的困惑：缺少足够的经验怎么搞敏捷，怎么交流,我们优先发展一部分教练，即找一些较自愿的人参与，再由他们分成小组，牵动整个团队，教练这个组织影响着各个小组的行动，把整个项目串起来。

这一举措从今年的实践情况来看是有一定效果的，当然明年我们可能会做的更多，因为业务团队不能以零散孤点形态存在，网状联系起来才能长久而稳定。

处理好开发和产品之间“打架”的问题。

开发人员最大的特点是，喜欢埋头去做，对产出不太关心。

敏捷以端拉动的概念一定程度上把开发人员推到台前：要求他去呈现业务的价值。比如把一些业务分析BA放到团队里去，和团队经常交流，通过Cof来展示，这使得开发人员有了“我做的可能是不够的”的认知，从而自发关注展示环节以促成成果的完整。

这对于产品也是一样，如果仅考虑投入，即便开发人员辛苦编了很多东西，拿不出来也是没有意义的。而当敏捷实行，开发和产品的交流增加，加上Cof相互影响，慢慢就发生了良性改变。开发人员不再低头做事，而是可以抬头看看周边，有利于消除开发和产品的隔阂。

同时，我们的客户组和教练组有些时候也会有意识做一些影响开发人员视角的东西，比如在我们部门里搞每周一次Idea talk分享，让大家来分享经验。

开始是技术分享，中间会邀请产品经理，讲述产品在外面市场的境遇，如何向客户介绍产品的优点和缺点等等。开发人员也在感知这些信息，信息积累的同时，他们的行为也在潜移默化的发生改变。

当然不能指望罗马一天建成，这种变化是循序渐进的，很多开发人员慢慢地从单纯做代码到开始参加教练的活动，甚至参加scrum master的活动，这些都有利于他们拥有全局观。

不要把案例当做模板。

我有一个观点：到底是流程改造人的思维还是人主动思考去重新设计流程，这是一个有争议性的话题，也在华为上引起了一些讨论。我个人比较支持人主动思考然后再重新定义流程。

有必要强调的是，案例不是模板，我的案例中，对象是一个新的团队，所以进行低成本的培养以及集体作战加快进度。但是如果团队中有一个很牛的人，就可以围绕这个人来做事情。或者你是一个皇马这样具备大量高级人才的团队，那么你的流程设计就是人际关系方面的思考。

所以案例只提供一个思考的借鉴，还需要结合项目具体分析。（敏捷教练或管理者）可以根据思考看它带入能不能感动自己，是不是可以经过一些细节转化然后应用到团队中，最关键的是要思考，然后再重新设计。

第五届TOP100summit全球案例研究峰会案例征集中，如果在您心目中有非常合适的演讲人选，欢迎向组委会推荐。请发邮件至speaker@top100summit.com。

如果您想担任演讲嘉宾或者专题出品人，请立刻点击「阅读原文」填写您的简要个人信息，我们会有专人在24小时内联络您。