先简单介绍一下公司的背景。平安集团已经是一家体量很大的综合金融服务集团，目前在世界五百强企业里排第39位，在福布斯世界2000强里排第16位，平安科技的定位是平安集团的创新孵化器和高科技引擎，平安科技在IDC FinTech全球排名是第38位,是前50位中唯一上榜的国内企业。

我们的故事将从2011年开始展开。2011年之前平安的研发过程管理还是一个非常标准化、规范化的严谨的体系；从2011年起有一些变化和变革开始发生，本文将回顾这7年的历程，每一年都会有一个敏捷的主题、有持续演进的方法，以及一些相配套的推广策略和举措。

从上图中可以得到一个信息：敏捷转型的过程其实也是一个迭代式、实验性、基于反馈驱动持续优化持续完善的过程，也就是说敏捷转型的过程本身，也需要用敏捷的方式来推进。

2011年是我们开始敏捷转型的第一年，我们称之为“敏捷元年”，万事开头难，这是一个新的开始。

这一年，我们开始构建了平安的第一个、第二个特性团队，并且在渠道侧的业务里开始做一些尝试。通常我们会选择渠道类的、互联网类的系统研发团队来做敏捷的试点，因为他们的系统特点更适合业务的拉动。

平安做了很多年CMMI（包括项目管理体系用PMI），构建了一套标准化、规范化的体系，有一级、二级、三级、四级的流程图，输入输出每个角色分工明确，步骤清晰，输入输出定义得非常仔细，同时整个管理方式也是基于过程的管理，比如我们内部实行的过程和产品的质量管理。总之，就是有严谨的过程体系，确保所有团队都按照这套体系来执行。

那时平安的开发版本周期大概是2个月，这两个月不是串行的，中间有一个交叠、并行的阶段。比如两个月里前一个月做开发，第二个月做测试，那么在前一个版本做测试的时候，后面一个版本就开始做开发，所以这两段是交叠在一起的。这样的方式会带来一些问题：比如开发人员会不太专注，要处理这个版本的开发需求，同时还要修复上个版本的缺陷，有时候甚至会变成恶性循环，开发无法在开发阶段保证质量。

变化的开始是基于一些外力的驱动，整个互联网的转型，已经可以慢慢地看到这种趋势，平安本身也受到BAT等互联网公司很大的冲击，平安集团的高层有非常强的危机意识，我们必须主动求变，我们的竞争对手其实就是BAT，如果不主动求变，我们可能就会被他们所颠覆。

在2011年，我们发起了几件事情：

首先，我们开始倡导一种更灵活的开发过程体系。不再是用同样一套标准化、规范化的流程来要求整个公司几千个开发人员的开发行为，而是希望更灵活、更多样化，鼓励大家适当地定制适合自己的开发过程。

同时，我们开始探索如何提升整个过程的效率。我们发起了一个项目，叫“提升开发过程效率百日行动”，就是用100天的时间必须把整个流程的效率提升。

为了达成这个目标，我们采取了很多措施。

• 比如评审，我们会挨个检查看每个评审是否必要，哪些人参加，用什么样的评审方式，怎样提高评审的效果和效率。

• 比如文档，哪些文档是需要保留的，哪些文档是过程性、沟通性的文档，不需要做太多强制性的要求。

• 比如工具，如何在移交部署这些工具上做到更大程度的半自动化或自动化，来提升过程的效率。

同时在这一年，我们开始启动了敏捷开发的尝试，我们做了两个项目，后面会简单分享这两个项目的情况。

第一个项目是网上销售保险的系统，这是一个渠道侧的系统，利用互联网作为销售渠道来销售传统的保险产品。这个项目不管是业务方还是IT方，都希望能够尝试一些跟传统不同的开发过程管理方式，以应对市场的挑战。这个市场的挑战很大程度上可能就来自阿里，因为阿里也在做同样的业务，大家觉得如果按原来的方式我们很难在竞争中立足，所以需要尝试一些新的方式。

这个团队可以说是平安的首个特性团队，所谓feature team就是这个团队拥有能够完成某个完整的业务特性的所有技能和职能。团队也开始用一些简单的可视化的方法，比如上图是他们当时的看板，尽管从现在专业的角度来看这个看板显得比较初级，但这并不妨碍这种方式非常大地帮助整个团队提升了沟通和协作的效率。大家每天都会聚在一起基于透明的信息分享进展、讨论解决问题。

这个项目的试点大概进行了半年，试点的效果非常好，效率提升了、质量也得到了保证，如图所示：

• 上线周期从2个月缩短到两周；

• 外部合作伙伴接入的周期从3个月缩短为1.5个月；

• 车险网销需求开发产能提升30%；

•  版本测试周期压缩一半，生产问题减少70%。

我们还同时启动了另一个团队的试点，当时叫P2P，这个概念大家都很熟悉，那个项目团队做完敏捷试点之后第二年从平安科技独立出来，发展成为今天的陆金所，陆金所是目前国内最大的独角兽之一，估值相当高。

2011年的试点之所以能取得这样立竿见影的效果，我们把它总结成几个基本的要素，看起来很简单，但往往最简单的原则如果善加应用起到的效果是非常显著的。

• 与客户紧密协作，我们希望业务、IT围绕一个目标组建同一个团队“one team one dream”，而不是各有各的目标，各自为政。

• 可视化。我们采取了简单的方式，让各种信息透明，构建了整个团队包括业务方和IT方相互信任的基础。

• 面对面沟通。这是一种最有效、传递信息损耗最少、效果最好的沟通方式。

• 加快反馈速度。这种反馈速度的提升不仅体现在业务上，我们更快地见到价值，更快获取到用户的反馈，基于这些反馈来迭代完善产品设计。也体现在质量上，我们会更早地获取质量的反馈，比如持续集成构建失败，我们会以更小的代价，更早期地、更低风险地去修复这些问题。

• 批量的减少——灵活应对fast feedback。我们基于迭代的方式限定了在同样的迭代时间窗口内批量是有一定约束的，小的批量保证了我们可以以更快的速度交付价值。
  

接下来到了2012年，这一年我们还是继续尝试和探索精益敏捷开发的模式，跟2011年相比不同之处在于：

第一，扩大了试点的范围，希望从不同的场景、从更多样性的系统团队里去验证这种新的模式是否有效。

第二，我们开始选择一些核心的金融业务系统，看看这种方式是否能行。

先分享一个保险交易系统的案例。上图是当时这个团队使用的看板，基本具备了一个看板系统应该有的要素，可以看到有些地方颜色不太一样，比如有一些红色、黄色的小纸片，从视觉效果上来讲红色、黄色一般都是代表需要关注的内容，所以通常来说，要么就是这个用户故事卡片遇到了阻碍，我们需要消除这个阻碍事情才能向前推进；要么就是某个程序缺陷我们还没有修复的。

同时还看到看板里有几个大的×，这是团队用来约束在制品，约束并行进行工作的一种方式，打×的空间是不能往上放卡片的，卡片只能放在没有打×的地方，这就限制了并行进行工作的数量，从而可以缩短每个卡片交付的时间，同时能促进上游下游之间的相互协作，尽快地让工作完成，而不是一厢情愿的推入更多的卡片。

这是一个比较常见的度量分析工具——累计流图，我们可以从三个角度来看：横向地看，图中标记的黄色横向区间是表示每一个需求从进入看板系统到出去（可能是发布上线或者验收完成）所历经的时间，可以看到这个团队的周期大概是3周，横坐标的刻度每一个刻度点大概是一周，3周的时间其实对于一个传统的保险业务系统来讲，已经是非常快的交付速度了。

除了横向地看lead time，就是周期时间之外，我们也可以看两条线之间纵向的距离，这代表WIP——在制品的多少。

还可以从第三个角度去看它的斜率，就是横轴纵轴之外的斜的方向，代表整个团队的工作速率，或吞吐量，就是单位时间团队能够完成多少个需求。这个图表达的信息非常丰富。

上图中有四叠卡片，项目做完之后，项目经理想了一个方式：把所有的需求和任务卡片分成四类卡片，分别代表原始需求开发完成的、原始需求没有被开发的、后来新增的需求、技术任务。

我记得比较清楚的是，当时我们去向CIO汇报敏捷的进展，整个汇报过程里其他的他都没记住，唯独对这一页印象非常深刻。印象深刻的地方在于原来这个项目一开始提出的需求有40%是没有价值、不需要被实现的。这一点对大家的触动也非常大，非常直接地体现了敏捷开发、敏捷项目管理的指导思想是以价值为导向。我们总是确保价值最高的需求能够优先被实现，价值不高的需求会被排在后面甚至永远都不需要被实现。

这一年，我们将范围扩大到核心业务系统的敏捷试点也取得了比较好的预期效果， 总结2012年敏捷转型的几个关键要素：

• 建立思维方式：延迟决策，和快速流动；这是两件事情：一是尽可能地推迟决策点，是不是一定要做这个需求？这个需求要做成什么样子？排期排在这个版本做还是下个版本？决策尽可能地晚，以保持更多的灵活性；二是一旦进入整个研发过程，进入看板系统，我们希望它快速流动，尽可能快地交付到用户手里。

• 交付价值胜过交付范围；项目是否成功的衡量标准更多以价值为导向，从价值视角来看，就算是一丝不苟把原来所有的给定范围100%实现，在这个上下文中也没有太大的意义，因为其中40%的需求是没有价值的，就算上线之后也没有人使用，或者实际用户并不需要这些功能。

• 通过约束限制在制品数量来拉动系统；在小批量的前提下才能实现拉动。

• 通过看板实现阻碍和问题的可视化。在看板上用红色和黄色标记需要关注的、需要升级的、需要优先被处理的问题，一旦这些问题被解决，流动就会非常顺畅，流动效率会非常高，价值可以更快交付到用户手里，我们能更快地得到用户的反馈，产品迭代响应能力会更强。

经过前两年敏捷试点的经验积累，2013年我们开始正儿八经地在组织级、公司层面推广和推进新的方法和新的变化。

首先我们构建了一套平安的敏捷方法体系，当时取名为“敏捷2.0”。这套方法体系主要是基于Scrum、精益看板、极限编程（特别是持续集成）相关的一些内建质量的实践。基于精益和敏捷这种高度兼容的价值观和原则，我们兼收并蓄，将不同的实践应用到团队的工作过程中去。

接下来是培养大家的技能，我们组织了很多场培训。上图展示的是看板方法的培训，我们有非常专业的沙盘模拟道具，可以从中体验基于看板的拉动式的开发管理过程。

敏捷中心还设计了敏捷成熟度的模型，从多个维度包括业务、团队、过程、技术等方面来评价一个团队的成熟度级别，并且跟公司本身的荣誉体系集成，表彰成熟度级别高的敏捷团队，给他们一些激励，让他们成为标杆，起到示范作用，让更多团队效仿，从而带动公司敏捷氛围的形成和敏捷行为模式的建立。

这件事情本质上是在拉动团队的行为，倡导一些好的行为方式，实际效果也非常好，大家都主动地向更高层次的级别改进和进化，从各个角度想办法提升，包括IT和业务的协作、看板的设计、改进机制的建立、技术实践的优化等。

还采取了一些措施促进这些优秀实践在整个组织层面的沉淀、传播和分享。我们把这些实践组成一条知识的走线，不强制每个实践每个团队都必须采用，而是把精力放在发现好的实践，一旦有好的实践，把它总结出来通过走线传播出去，其他团队如果觉得好用，对其有帮助和借鉴作用，就从这条走线上拉下来为我所用。我做了很多这样的事情。

上图展示的是一个活动“看板大巡游”，活动的形式是：可以自愿报名，报名后每个团队出一个人参加活动，有一个教练举着旗子，像导游一样带着每个团队的代表到各个团队的现场去观摩和评价每个团队的看板，从中互相学习，看板巡游完一圈之后大家回到一个教室或者空间，集体讨论和分享觉得哪个地方好、哪个地方可以借鉴、回去之后怎样根据学到的东西改善自己的看板设计或者流程，从而起到好的看板实践相互分享的效果。

2013年推广的结果：80%的团队应用敏捷和精益开发的方法，大家都基于自己的团队特点、系统架构以及实际管理诉求去设计和演进自己的看板系统、敏捷的实施方式。从上图可以看到没有任何一个团队的看板是长得一样的，我们鼓励百花齐放，做出个性化的符合需要的看板系统。

总结几个关键要素：

• 采用渐进式的推进变革的方法，基于现状可以不去变革现有的职衔、分工、流程，而是用一些可视化的方式更高效地识别整个流程里的痛点和阻碍，持续改进提升整个系统的效率，这种方式的好处是尽可能减小变革的阻力。

  
  

• 鼓励百花齐放，激发团队的创造力。看板是很讲求流程的，包括规则。每个环节从doing到done，要符合什么样的DOD，从每个环节的done到下个环节的doing，要设计一些什么样的挑选规则，或者协作规则，其纪律性和流程性很强。但不同以往CMMI的流程管理方式，这种流程规则的演进是完全基于团队自身的需要，由团队共同决定和演绎的，而不是一套统一的流程适用于所有的团队。

  
  

• 不陷于方法门派之争，实用至上。一开始大家对这些敏捷方法理解得也不是很透彻，在没有理解透彻的情况下难免会产生很多困惑，比如方法和方法之间是不是不可兼容的，是不是有一些冲突的地方，能不能集成在一起……会有很多疑问。但后来随着大家理解的深入、功力的加深，这种问题慢慢地就减少了，大家最后达成共识：不管用什么样的方法、工具都是为了解决用户的痛点，都是为了帮助用户达到他希望达到的目标。所以可能我们口袋里有很多好东西，像哆啦A梦一样有百宝箱，有很多武器，我们需要从目标出发，怎样帮业务实现他的目标，怎样帮业务解决他实际的痛点，然后考虑用不同的武器，或组合武器来解决这个问题或实现目标。这样想思路就清晰了。
  

基于2013年推广的成果，2014年继续深化这些敏捷的变革，比如在大型的金融项目里怎样用敏捷的方式来管理；比如我们怎样促进这种持续的协作式的改进，都是我们要去攻克的问题。

分享一个案例：2014年我们做了一个大型的创新性的金融项目——做一个直销银行。在2014年这还是一个比较前卫的事情，国内还很少有银行真正实现直销的方式。所谓直销银行就是说，不用去实体的银行柜面，通过虚拟的方式就可以开户、存钱转账、买理财产品、管理财富。

我是以教练的身份出现在这个项目中的，当时面临的困难非常多：

第一，整个业务的模式是创新性的，虽然国外已经有了一些比较成熟的应用，但国内还没有，大家都处于摸索中，到底怎么做这件事，需求处于高度不确定性状态。

第二，技术架构、技术方案也是完全不确定的。比如作为一个创新性的银行系统跟传统的核心银行系统，账户有什么关系、要不要打通、是用一个账户还是另外有一个子账户……这些问题都不明确。

第三，项目的时间非常紧张。老板的老板向他的老板做了承诺，这个项目一定要在3个月内上线，无论如何，这个时间不可协商，但需求的量非常大、不确定性非常高。

第四，团队情况比较复杂，先说研发这边大概有30个人，其中28个是外包人员，只有2个是内部的，这2个内部的人中还有一个是从别的部门借过来的项目经理，另外那个是SA，做需求分析的，相对比较懂业务。

上面4个问题还不是最困难的地方，最大的问题在于：我去的时候发现整个项目完全没有进展，推动不了，但时间在一天一天地流失，离3个月的时间底线越来越接近。

那大家都在干嘛呢？业务的同事有些是从机构抽调到这个项目组来的，他们每天晚上都在加班加点地写需求、写文档，文档写了很多，但过去一问他们都说这些需求不靠谱，过两天一定要变，现在压根想不清楚后面要做些什么东西，但IT要求一定要写，需求不写出来IT不开工，所以只好硬着头皮写了。

这是一个典型的传统项目管理甲乙方对峙的形态，相互不信任，整个项目推进非常困难。我们开始采用一些不一样的方式，希望能在这样大型的项目里用敏捷的方式确保项目成功。

上图看起来场面很宏大，实际上是为了把IT和业务拉到一起更高效地推进项目，所以找了一个新的场地，有一整排桌子都是空的，正好借这些桌子以用户故事地图的方法梳理整个项目需求。

大家的工作方式就像workshop（工作坊）一样，每天有些时间是大家聚在一起研讨，在桌子前面三三两两地讨论，卡片可以合并、增加、删除。另外一些时间大家领任务然后各干各的，比如有人去做市场分析，有人去研究竞品，有人去设计静态demo，或者交互稿，有人去电子工具里做一些记录和整理。

我们将目光拉回桌子本身，可以看到有黄色、蓝色、绿色等不同颜色的卡片，这代表了几种不同粒度不同大小的需求，我们总共大概用了240张卡片，来梳理和分析整个项目的整体需求。

在这个过程里，IT和业务双方构建了一个非常好的协作机制，沟通效率非常高，确保了整个团队所有参加工作坊的同学都完整地了解了我们的愿景、实施的整体进程，包括需求风险、技术可行性，信息得到了高度共识和一致理解。

在讨论相对稳定之后，大家会把这些信息上墙，把它们都贴到墙上，这面墙就在工作区的旁边，随时可以查阅，可视化的效果非常好。另一个层面来说，领导尤其是业务领导也时不时地会到IT的工作场来看，所以大家可以基于透明化的信息，一起沟通项目的进展情况，包括有哪些问题需要升级，怎样更快地实现业务目标。

把之前那张图中绿色的卡片抽走，绿色的卡片相当于story-用户故事，把蓝色卡片留下，蓝色卡片相当于feature，feature是相对来讲用户产品更完整、更具有可发布市场的价值，把它留下用来安排迭代和版本规划。

我们划分每两周做一个迭代，每个迭代都必须要达到一个业务目标。横向的每一行都是一个迭代，比如第一个迭代，最左边的卡片上标注了它的业务目标：信用卡用户要能够存钱转账且购买两个理财产品。实际上我们可以做到两周之后，不需要三个月，就可以发布第一个所谓的MVP版本。

同时很重要的一点，是在这4个迭代的下方还有很多卡片，这些卡片是什么意思呢？我们跟业务经过充分的沟通，大家从思维上达成一致：一定要确保3个月之后这个项目成功上线，所以那些具有核心价值的功能一定要实现，但其他一些辅助性、支撑性、锦上添花的功能可以协商，如果时间来不及可以在后面的版本再继续优化，如果时间来得及可以多做一点。

对关联方的管理，我们也用了一些可视化的实践。在平安做项目最困难的一点是涉及到很多的专业公司，因为综合金融互相交错，一个项目可能得十个公司配合才能做成功。

我们也用这样的方式，每个黄色的卡片代表一个关联方，跟关联方对接的状态，比如需求是否谈好、有没有连调等我们都会通过可视化方式跟踪，所以大家每天也会看看关联方管理的白板，如果某些地方还有风险，还有未解决的依赖，抓紧时间去解决。

团队还建立了一块大型的分层看板墙。这里体现出很多专业的管理方法，比如横向泳道来约束并行进行的需求的数量，比如做了需求的分层，每个需求的前端、后端、iOS、Android，会区分不同的任务卡片，先分层后面再合在一起做验收。

查看所有新闻