平安7年精益敏捷转型之路

文章来源：gongzhonghao:msup

导读：平安作为互联网金融的领跑者，目前有超过40个APP，传统业务全面互联网化。能够成功转型与敏捷密不可分，平安科技更是整个集团敏捷转型的领头羊。

2011年，敏捷开发试点项目大获成功之后，平安科技驶入敏捷推广的加速车道。

2012年试点范围扩大到10个团队，引入Scrum、看板(Kanban)、持续集成等流行的敏捷方法。

2013年“开启敏捷2.0”，在组织架构上成立“敏捷中心”，整合业界优秀实践，形成平安科技自己的敏捷开发方法体系和敏捷成熟度评价体系。

2014年，敏捷开发覆盖到公司大约80%的开发团队，并开始探索互联网产品的敏捷开发模式。

2015年“迈向持续交付”，从研发过程的敏捷，向上下游扩展，引入精益创业(Lean Startup)、DevOps等新的方法，打造端到端的反馈闭环。

2016年启动持续交付支撑工具链的建设，致力于打造“精、轻、快”的持续交付一体化平台与解决方案。

从2013年到2015年，公司整体的30天需求实现率从24% 提升到80%；产品研发周期从以往的6个月缩短到3个月以内。此外，更灵活的响应变化、稳定的版本质量、更高的团队产能、持续改进的习惯，都逐步显现出来。

本次分享将通过真实的案例，分享平安科技全面敏捷模式如何在小团队、大项目，乃至整个组织的实践和落地。

课程实录背景介绍

先简单介绍一下公司的背景。上图中左侧的高楼是平安金融中心，这是深圳最高的楼，118层。曾几何时，我们听到“平安”的时候只能联想到保险或歌星，如今我们可以骄傲地说，我们是做金融互联网的高科技企业。

2016年平安在世界五百强企业里排41，这个成绩和平安互联网+综合金融的转型战略是分不开的。平安现在已经有了40多个APP，近3.5亿的互联网用户，这个数字还在快速增加。

与之适应的产品策略和管理思路也在全面互联网化。我们从之前的关注能卖多少钱，到现在关注能为用户创造多大的价值，这恰恰都是敏捷所倡导的也是互联网需要的。

上图是我们从2011年到现在的转型路线图。

从2011年开始我们成立了第一个 feature team；2012年引入看板方法进行可视化管理；2013年是非常重要的一年，我们成立了敏捷中心推行敏捷2.0，也就是scrum+看板+极限编程的方法，聘请了大量的敏捷教练，也组织了很多场培训，开始全面推行敏捷。

2014年开始将敏捷实践推广到大型项目，平安是国内第一个引入LeSS（大型敏捷框架）的企业；2015年开始向敏捷的上下游拓展，引入了精益创业和持续集成、持续交付的方法；2016年，我们开始自己研发一个持续交付的工具——神兵，同时通过工具来获取一些过程数据，并进行价值流分析以提升企业的效能。

2011 元年

2011年是我们开始敏捷转型的第一年。一般改变总是有原因的，我业余时间学了些心理学和教练技术，我的老师常说“不够痛就不会动”。有的痛是切实感受到的，有的是对未来的焦虑。

平安敏捷转型的出发因素很多还是来自于互联网，当时互联网巨头纷纷涉足金融和保险，淘宝的保险频道都已经上线了。马明哲还说BAT才是平安真正的对手。

显然，之前的标准化、规范化的研发管理模式已经不适应当前变化的互联网环境了，我们更需要一种灵活多变的多元化的管理思路来更高效地做事情。

从上图左右侧的对比可以看到：2011年之前我们强调的是管理的标准化和规范化，当时还通过了CMMI的三级评审。2011年开始推行敏捷之后，我们开始倡导开发模式的灵活化多元化，应用不同的管理模式来应对不同的场景。

我们还开展了一个叫“百日行动”的活动，就是用一百天去提升效率，具体做了这么几件事：

第一，看文档有哪些是必要的，哪些是不需要的。我们把文档分为系统级和过程级两类。系统级的文档要加强，比如架构文档；过程级的文档要弱化，比如周报日报，这些只是为了沟通，实时性很强，完全可以通过面对面的沟通来取代。

第二，缩短签报的审批链。平安现在有一百多万人，审批链很长也很复杂，我们会分析每一个环节的通过率，如果这个通过率长时间以来一直是100%，那这个环节就应该是可以去掉的。

第三，讨论怎么开会更高效。

第四，搭建部署流水线。尝试将代码从手工移交变成自动化移交。

分享一个车险网销平台的案例。我们拿这个项目来做第一个敏捷试点项目。这是一个小团队，这个平台要做的功能是实现在互联网上卖车险。

这是我们第一个特性团队的照片，这个团队包括产品经理、前后端开发、测试等各个角色，这样的一个全功能团队能够实现端到端的交付。

当时进入特性团队的种子成员都是经过挑选的，我们会选择一些乐于接受新思想、愿意寻求改变的人，随着这样的实践他们后来都成长为平安的骨干人才。

上图是我们特性团队的第一个看板，虽然不够美观，但是已经有一些样子。

通过敏捷实践和落地，我们达到了以下的效果：

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

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

• 产能提升30%；

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

我们的组织在最初尝试导入敏捷的时候做了三件事：

第一，建立全功能团队，通过面对面的协作改善沟通。业务方代表最好也能够加入到这个团队中去，这样能够及时给团队答疑并提供反馈。

第二，通过看板可视化进度，今早发现问题消除瓶颈。

第三，把需求拆小拆细，以便能够尽快交付尽早得到反馈，从而降低风险、灵活应对变化。

第四，最重要的是人，需要有一些能够接受敏捷思想的人去做这样的一些改变。

2012 起跑

第一个试点项目取得成效之后，我们开始逐步深化我们的看板实践。上图是一个寿险的支持项目，这个看板系统比之前的原型看板漂亮多了，从图中还可以看到它与原型看板的区别：

首先，有了测试就绪、验收就绪的等待队列；

第二，卡片上有贴owner的照片；

第三，右下角有一个燃尽图；

第四，图中打红叉的部分是做了一个WIP的限制，就是说这个队列不能有太多的卡片，卡片不能贴到那个禁止的区域里。

说到转型时度量也非常关键。上图是一个累计流图，纵坐标是Story Point，粉色的线是启动开发的故事点数，深绿色的线是用户验收完成的故事点数，这两条线的宽度对应到横坐标大概是三周的时间，就是说这个需求的lead time，从启动开发到用户验证大概需要三周的时间来完成。

通过改进这个看板实践，我们可以看到：由于中途发现了优先级更高的需求，所以有40%的原始需求被舍弃了。从传统项目管理的强调交付范围转化为交付价值，这是互联网的要求。因为现在的社会充满了不确定性，我们也很难从一开始就把范围确定并保证后面不发生变化。

我们需要拥有灵活应对变化的能力，要保证团队一直在交付高优先级、高价值的任务。同时我们也不希望这个范围无限蔓延导致同学们天天加班，质量下降。所以当有一个高优先级的任务要加进来的时候，我们就会挤掉一个同等工作量的低优先级任务。这就是为什么上图中左下角中途增加的40%优先级更高的需求，右上角又挤掉了同样多的需求。

总结一下我们2012年敏捷转型的几个关键要素：

• 延迟决策，让它快速流动；

• 交付价值胜过交付范围；

• 通过约束限制在制品数量来拉动系统；

• 通过看板实现阻碍和问题的可视化。

2013 推广

通过前面两年的积累，我们取得了一些成果，2013年进入关键性的一年，这一年我们成立了敏捷中心推广敏捷2.0。那时主要主打的是三种方法：看板、Scrum、持续集成。我们提供三天的训练营打包培训，有很多团队成员加入进来参加这样的培训。

上图是我们的学员在玩看板沙盘游戏。这是一个从国外引进的非常经典的游戏，能够帮助我们体会看板方法的精髓。现在这个培训一直持续在做，也收到了很好的效果，

我们说2013是敏捷推广最红火的一年，这一年，我们还做了一件非常重要的事：成熟度的评估。

上图是一个成熟度评估模型的一部分，左边可以看到一级二级（后面还有三级）。这是一个在整个公司范围内发起的活动，由敏捷中心去推行，成立专家小组给团队评级，然后在全公司公布结果。这个在当时无形中成为了一个团队的KPI，但当时达到三级的只有四个团队，二级的几十个团队，其他团队大部分还处于一级。到2014年的时候，平安科技有4000多人100多个分组，80%的团队都引入了敏捷方法。

上图中这个活动叫看板大巡游，主要是由教练带队，他们像导游一样举着旗子带领大家一站一站地看过去。每个团队设计的看板都不一样，我们会考虑美观、实用等方面去给各个看板打分、写评语。然后一起讨论有哪些好的地方值得大家学习，最后还会有评比和颁奖。

这是巩固得非常好的一个实践，实施的效果是80%的团队都应用敏捷和看板，而且这么多年在平安能够很好地落地并延续。敏捷在IT领域的看板方法在刚问世时也会有一些争议，但是还是被很多公司所采用。因为即使是在各个公司文化、管理风格迥异的环境下，看板方法作为一个渐进式的变革方法还是比较容易切入进去的。

也就是说，它提供了一个更加平滑的路径，能够最大限度地减少敏捷转型带来的阵痛。其实基于现状以及实用至上，这是我在平安科技甚至在整个平安集团能够看到的，一贯执行下来的思想和策略。

我看到过一些自上而下的激进变革的例子，到最后有一些是打回原形的，员工对此产生了诸多的误解；也有一些自下而上的变革，一般这样的变革发起者都是比较超前的员工，企业没跟上最后导致员工心灰意冷离职，变革也草草收场。相比之下，我更欣赏平安这种温和的演进策略，能够更持久更有效。

2014 深化

2014年是我们敏捷深化的一年，基于前几年的成果逐步把敏捷扩展到更大型的项目里来。我们第一个大型的试点项目是做一个直销银行，这个项目有几十个人的研发团队，其中还有大量的外包，困难也很多。

敏捷转型之前的场景是业务拼命地加班写文档，他们也知道写了要被推翻，但是开发说了没有文档就不能干活，双方的互信度非常低常常僵持不下，后来有人提出来说：咱们不是有敏捷教练吗？

我们敏捷教练的团队leader林伟丹（平安科技敏捷中心资深经理、Wizard产品商业化总监，点击可以获得林伟丹分享详情信息）、著名的精益敏捷教练吴穹博士都加入了这个项目，咨询顾问带团队做了一个Quick Start，Quick Start也是平安坚持得非常好的一个实践，一般小型项目的时间是大概1-2天，像这样大型的项目可能需要一周时间。

我们把Quick Start方法总结成36计，再加上引导技术、沙盘演练提炼成两天的工作坊，通过这个工作坊也培养了很多Quick Start的引导师，这个工作坊在平安也是很受欢迎的。

需要所有的决策角色（特别是能拍板的人）都参加到Quick Start工作坊，这样能快速地把业务需求梳理成开发能够去做的迭代计划。达成的效果就是希望会议结束后马上就能开始去迭代、能够持续交付一些可见到的东西。

上图我们在Quick Start之后梳理出来的一个四层的故事墙，从主题到Epic到Feature到Story，看起来还是蛮壮观的，贴了满满的一面墙。

因为会涉及到多个Scrum team的协作，上图是一个Scrum team的看板，把迭代计划放到上面，最左边大的卡片是用户故事，右边小点的卡片是任务。我们后面也做了一些改进：用不同颜色的卡片来标示用户故事和任务，还特别用红色的卡片标示风险。

我们还有一个专门的看板，用来管理大型项目之间的关联和依赖。蓝色卡片是业务模块、黄色卡片是关联系统。里面会有很多具体的检查点，每个做完之后就用打钩的方式跟踪风险，上图右边的五角星是标示一些风险大的地方。

上图是一个比较完整的分层看板，右边每个人都有两张照片，而且只能有两张照片，这是为了避免一个人手头同时有多个并行任务、需要频繁切换任务而导致效率降低的情况，我们鼓励大家先做完一个任务再去领下一个，这样有助于任务快速流动提升效率。最左下方有一大堆卡片，这些都是被舍弃的需求。

上图是我们30多个人参加的每日站会。我们能够保证在15分钟内完成，每个人在上面移动卡片。这面墙还是蛮大的能够将所有的用户故事、任务都展示出来。

这个直销银行的项目从最开始业务和开发的互相不信任、集体焦灼的状态，到后面启动Quick Start，并取得惊人的成绩：

• 三个月之后首个版本发布可以内测；

• 四个月之后直销银行产品正式推向市场；

• 发布一年之后，用户量突破五百万，并获得中国最佳直销银行的大奖。

这个大型项目的敏捷试点也是相当成功的。

2015 延伸

2015年之前的很多实践都是在帮助我们把事情做对做好，主要是在解决域方面，而我们面对的问题是其实我们不知道什么是对的事情，问题域需要我们用精益创业和设计思维的思想来解决。所以，从2014年起我们开始往敏捷的上游拓展，建立上图这样的产品侧看板，同时我们引入了一些精益创业的实践。

上图是业务侧看板的一个实例。有澄清、评估、排期，排期就是进入了开发的迭代计划，这个看板到现在产品经理还在用。

我们也希望能够往敏捷的下游——持续交付拓展。想要交付得快自动化是不可缺少的，我们要去持续验证。自动化测试方面，其实要分层的，而接口测试是比较容易做的，我这边的团队更倾向于由开发把自动化的接口测试写好，甚至把这个部分定义到DoD（Definition of Done）里，以便能够快速地去测试。

原来都是评估从需求准备好到交付的时间，现在我们可以去评估从创意到投产的lead time，前置时间。上图中纵坐标是天数，从图中可以看出2015年9月到2016年是有显著降低的，也就是说从有了初步想法到最后上线的周期在快速缩短。

这是我们2015年实践敏捷的一些感悟和关键要素：

• 整体优化胜过局部优化；

• 形成有价值的闭环；

• 强调内建质量。

2016 神兵

2016年，我们研发管理部开发了一个能够实现：从需求管理到自动化测试到自动部署、持续集成还有一些静态扫描持续交付的工具链——神兵。我们也可以通过神兵获取很多的数据做价值流的分析。当然这个数据不仅是从神兵获取，还从公司很多系统里获取。

我们在IT领域的能力提升之后，将改进的方向扩展到了更多的领域，比如运营管理、财务管理、行政管理、法务管理、安全等方面，分析这些过程中的等待返工和浪费，并试图做出优化，缩短lead time。

我们找到了top 10，也就是最需要改进的十项来进行改善，并取得了明显的效果，比如合同签署、新建子系统、公共平台的接入、移交部署，都有了百分之十几到三十几的提升，公司整体的流程效率提升了14%。

2016年的关键要素：

• 实现了端到端的价值流建模；

• 持续不断地消除浪费；

• 慎用“流程”

这里值得强调的是：很多时候我们发现漏洞的直觉反应是加一个流程去防范这样的漏洞，这样做的结果是导致流程越来越臃肿，组织效率越来越低下。

转型心得

回顾一下我们在敏捷转型路上的一些心得体会。

首先，系统思考。当我们发现问题的时候，不要像西医一样只针对问题治病，而要从整个系统的角度去考虑，优化整个环节中可能的各个部分。

其次，发挥人的创造性和主观能动性非常重要。

第三，痛点驱动，数据闭环。痛点驱动，通过数据去发现改进的点，然后度量改进的效果。

最后，持续改进，永远在路上。

像平安这样的体量能够做到这样的变革是很不容易的，可能中小型企业的改变相对容易一些，我们经历了这么长时间的尝试和实践，后面可能就可以少走一些弯路，也许进展会更快一些。

团队现在的敏捷实践

最后分享一下团队现在的敏捷实践。

这是我辅导的一个叫伺客的团队，做在线云客服项目。我们会有一个这样的作战室，所有的角色都坐在一起，包括产品经理、前后端开发、测试等，大家能够很方便地沟通，效率也有了很大的提升。从图中可以看到这个项目室的四周也有很多的看板。

随着现在团队的扩张，很多异地的小伙伴加入，比如成都、深圳等，我们的看板也从原本的物理看板换成了电子看板，因为我们有神兵的支持，所以我们可以把所有的任务、需求、缺陷、测试用例等都放到神兵的系统里，每日站会改为站在触摸屏的电子看板前展开。

我对这个看板做了个小小的改动，把我们的DoR、DoD以及一些站会的提醒写成卡片贴到触摸屏的四周。下面还有一个屏幕来做CI监控，以及一个Sonar的扫描。

我还编了一些口诀来帮助大家记住我们的敏捷实践：

• 自治团队轮值表

• 开会严守时间盒

• 需求准入实例化

• 任务拆细两天工

• 开发单侧接口测

• 前端后端需并行

• 内建质量都有责

• CI失败马上修

• 代码review面对面

• 技术债务日日清

我们是一个自组织团队，在平安科技有很多人复用的情况，这是很难避免的，想找一个专职的Scrum master更是难上加难，所以我们就让大家轮流担任Scrum master，主持各种会议，有一个轮值表贴在墙壁上。

开会的时候，包括需求的梳理和澄清都要严守时间，一个需求的澄清不能超过15分钟。如果有很多不清楚的、团队提出质疑的地方，就需要先hold住回去弄清楚了再回来讲。

我们希望需求准入实例化场景化，让大家能有一个统一的语言清晰地理解。

还有任务的拆细，一定要保证这个任务在两天的时间里能够完成；开发人员要负责单元测试和接口测试，前后端是并行工作的；内建质量每个人都要负起责任来；一旦有CI失败马上要有人去修复。

因为我们大家都是坐在一起的，面对面沟通非常方便，包括代码review。我们有Sonar扫码监控还有哪些技术债务，随时发现随时修复，我们也预留了一些时间去解决这些技术债务。

QA&

Q：如何上线快，风险小?

A：做互联网的都有这样的诉求，希望快速上线。确定MVP（最小可行的产品）。如何去定义一个最小的可行产品，快速地开发快速地上线，然后得到验证？埋点也很重要，我们要去分析用户的行为，因为我们会有很多假设，一定要通过真实的用户去验证这些假设是否正确。

Q：有些老板或者管理者思维固化不愿意改变，如何让他们接受你的提议？

A：现在应该不太会有说为了做敏捷而做敏捷了。我们一定要告诉管理者敏捷能够解决什么样的问题、能够带来什么样的好处，这样才有可能会引发一些改变。固有思维每个人都会有，特别是老板，但是我们要相信他们既然能坐在这个位置上，应该是有很多成功经验的累积，那些成功经验可能就是基于他以往的一些方法，我们现在是提出一个新的方法，他没有尝试过，所以有一些顾虑和担心也是正常的。

作为敏捷教练，我们很多时候都是基于痛点去切入的。

首先要深入团队、深入企业了解真实的需求和想要解决的问题。

然后看看已有的实践哪些可以逐步引入并取得成效，用小成果来巩固这些实践。

同时领导能够看得到的度量指标也是不可少的，要让高层能够看得到这个方法带来的改变，让他信任我们，继而再扩大实践的范围。

Q：对于跨业务线协作有没有好的方法+工具？敏捷强调的是每个人都是主人翁，但对于国内的公司环境是普遍非扁平管理，敏捷的理论与实际应用是有差异的，怎么看待这个问题？

A：跨业务线的方法和工具还是很多的，主要看大家的需求，如果所有人都在一起办公，有一个物理的看板也是不错的，如果在不同的地方就需要一些在线的工具来支持。还有就是我们是不是多团队协作的情况，有很多大型的敏捷框架，比如LeSS、SAFe、scrum of scrums都可以用来解决协作的问题。

敏捷强调每个人都是主人翁，而国内的环境大多是非扁平的管理，我之前还蛮理想主义的，对这个问题也有纠结的时候。我当时有顾虑：这样的环境是不是能够支持我们做一些敏捷的实践呢？事实证明其实也是有不少事情可以做的。

虽然我们在组织架构上很难说做到扁平，也不像国外那样比较宽松的管理方式，但是其实我们在一些小的环境里是可以做得很好的，比如我带的这个伺客团队，大家在一起就非常融洽，我们也没有什么层级概念。虽然有些人还是偏向management contorl的方式，但是其实也会慢慢被影响。

我们也提供了很多教练和引导技术去帮助这些管理者，包括我曾在部门推行的管理3.0和读书会等，这些先进的理念大家也很容易接受。

Q:敏捷团队有效性衡量指标除了需求完成率、发布速率等，还有什么别的具体的指标么？

A：说到度量其实是一个很大的话题，需求完成率、发布速率等是一些指标。我们希望通过度量达成什么样的目的？得先明确这个目的再来确定要度量什么。

比如我们希望流动效率更高，那我们就需要知道需求从开始想法到启动开发到完成需要的时间大概是多少、每个环节耗时多少。然后借用价值流分析非常有用的一些工具来帮助做一些改进。比如我们可能从一个需求产出到发布需要三个月的时间，但实际工作在这个需求上的时间可能只有五天不到，那我们可以算一个百分比，然后想怎么能够让它加快流动，随之而来的就会有很多方法和策略可以用上了。

Q：主要是敏捷跑得快了，质量好肯定是前提，不能妥协，但是感觉敏捷和DevOpS在应用中或多或少有点削弱了测试，对此您怎么看？

A：确实质量是不能妥协的，我发现在咱们国内做互联网都还是偏向糙快猛的方式，尽快地先上线再说，但实际上质量是一个很大的成本。

敏捷和DevOps实际上应该是加强测试，更多的自动化。而现实情况是大家都在分析计算ROI、急着去赶某个时间点，有的时候可能确实会弱化了测试，这并不是我们希望看到的。

开发和测试在融合，我们也希望业务、产品经理、开发、测试能够在一起把需求实例化，然后通过ATDD在整个过程中保证质量。质量不是测出来的，而是在需求产生的时候、代码构建的时候就需要保证的。

Q：理论和实践有距离，现实也会有偏差，很多团队中专职测试人员或多或少都有在减少。现在平安开发人员必须做单元测试吧？还有专门的系统功能测试团队吗？

A：我们会有一些专职的测试，但不是说越多越好，有的时候专职测试多了我们反而容易产生依赖。我们更倾向于让开发团队做好自测，做好自动化接口测试，就是说必要的测试都是由开发这边保证、质量也是由开发这边保证，我们逐步希望培养每个人都能是多面手。

单元测试是肯定要的。专门的团队负责系统功能测试比较少，多数是和开发在一起的，非功能性测试会有一些，比如压力测试、安全测试会有专门的人来负责。

Q：如何转型成为一个敏捷教练？

A：首先，要看一下自己是不是一个愿意持续学习的人，是不是一个有开放心态的人，是不是一个愿意去帮助别人的人。这是一个很好的基础，如果具备这个基础就可以逐步地去学习一些敏捷的实践。

其次，我觉得有一些好的团队能够让你体会到敏捷的好处，比如我曾经在Autodesk的时候就很幸运地带一个特别优秀的团队，大家很乐意去尝试各种实践并承担各种工作，包括我们也做了ATDD、以及一些看板的实践，大家都能够感受到它的好处，包括我自己。

第三，做一个敏捷教练我对这些实践是深信不疑的，我相信它们能给团队给大家带来好处，然后我会去读很多的书、和社区里的小伙伴交流、参加一些大会听听其他公司是怎么用敏捷来做各种实践的。

最后有当敏捷教练的机会一定要尝试，如果发现还有些技能不足，再想办法弥补。

推荐书籍：http://www.scrumchina.com/resources/books